Skip to content

Latest commit

 

History

History
56 lines (45 loc) · 3.56 KB

Contributing.md

File metadata and controls

56 lines (45 loc) · 3.56 KB
Raw

Contributors Wanted: Inquire Within

It isn't wise to build something that can be a part of someone's ecosystem without help, and we are always open to contributions to help us fix issues or work on features

Getting Started

Making Changes

  • Make sure you have the latest version
  • Submit a ticket for the issue, using the GitHub Issue Tracker
  • It's worth checking first to see if someone else has raised your issue. We might have responded to them, or someone might be fixing it.
  • If you want to add a feature, as opposed to fixing something that is broken, you should still raise an issue.
    • That helps us understand what you want to add, so we can give more specific advice and check it does not conflict with some work in progress on a branch etc.
    • If someone else is already working on the suggestion, then hopefully you can collaborate with them.
    • Add a comment to an issue if you pick it up to work on, so everyone else knows.
  • If you have a defect please include the following:
    • Steps to reproduce the issue
    • A failing test if possible (see below)
    • The stacktrace for any errors you encountered

Submitting Changes

  1. Fork the project
  2. Clone your fork
  3. Branch your fork. This is your active development branch
  4. Use Test Driven-Development. 0. New features should have a test or 0. Defects should have a test 0. You might want to watch this video to understand our preferred testing approach 0. This project uses MSpec and FakeItEasy. So should you to contribute.
  5. We separate the core library from add-ons. Consider if your change is really core, or could be shipped as an add-on. Let the user 'buy-in' to your feature over making them take it.
  6. Make your tests pass
  7. Try to follow the [Microsoft .NET Framework Design Guidelines] (https://github.com/dotnet/corefx/wiki/Framework-Design-Guidelines-Digest) when writing your code 0. Providing [BDD] (http://dannorth.net/introducing-bdd/) style tests should provide for the need to use scenarios to test the design of your API
    1. Use the coding style from [dotnet/corefx] (https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style)
    2. You can use [codeformatter] (https://github.com/dotnet/codeformatter) if you can run VS2015 to automatically update your format 3. Ensure you update the template for your copyright if using codeformatter
  8. Commit 0. Try to write a good commit message.
  9. Merge back into your fork
  10. Push to your fork
  11. Submit a pull request
  12. Sit back, and wait. 0. Try pinging @BrighterCommmand on Twitter if you hear nothing

Contributor Licence Agreement

To safeguard the project we ask you to sign a Contributor Licence Agreement. The goal is to let you keep your copyright, but to assign it to the project so that it can use it in perpetuity. It is still yours, but the project is not at risk from having multiple contributors holding the copyright, with anyone able to hold it to ransom by removing their grant of licence.

The process of signing works through GitHub.

To get started, sign the Contributor License Agreement.

Contributor Code of Conduct

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

The code of conduct is from Contributor Covenant