Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
66 lines (48 loc) · 4.03 KB

CONTRIBUTING.md

File metadata and controls

66 lines (48 loc) · 4.03 KB
Raw

How to contribute

We would like to start with saying thank you for wanting to contribute to the X-Splinter codebase. We want to keep it as easy as possible to contribute changes that get things working in your environment. There are a few guidelines that we need contributors to follow so that we have a chance of keeping on top of things.

Making Changes

  1. Fork on GitHub
  2. Clone your fork locally
  3. Configure the upstream repo (git remote add upstream git://github.com/STARIONGROUP/X-Splinter)
  4. Checkout development
  5. Create a local branch (git checkout -b myBranch) from development
  6. Work on your feature
  7. Rebase if required (see below)
  8. Push the branch up to GitHub (git push origin myBranch)
  9. Send a Pull Request on GitHub

You should never work on a clone of master or development, and you should never send a pull request from master or development - always from a branch. The reasons for this are detailed below.

Handling Updates from Upstream/Development

While you're working away in your branch it's quite possible that your upstream development (most likely the canonical X-Splinter version) may be updated. If this happens you should:

  1. Stash any un-committed changes you need to
  2. git checkout development
  3. git pull upstream development
  4. git checkout myBranch
  5. git rebase development myBranch
  6. git push origin development - (optional) this makes sure your remote development is up to date

This ensures that your history is "clean" i.e. you have one branch off from development followed by your changes in a straight line. Failing to do this ends up with several "messy" merges in your history, which we don't want. This is the reason why you should always work in a branch and you should never be working in, or sending pull requests from, development.

If you're working on a long running feature then you may want to do this quite often, rather than run the risk of potential merge issues further down the line.

Sending a Pull Request

While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "Feature branch". We care about your commits, and we care about your feature branch; but we don't care about how many or which branches you created while you were working on it 😄.

When you're ready to go you should confirm that you are up to date and rebased with upstream/development (see "Handling Updates from Upstream/development" above), and then:

  1. git push origin myBranch
  2. Send a descriptive Pull Request on GitHub - making sure you have selected the correct branch in the GitHub UI!
  3. Wait for a maintainer to merge your changes in.

And remember; A pull-request with tests is a pull-request that's likely to be pulled in. 😁

Style Guidelines

  • Indent with 4 spaces, not tabs.
  • No underscore (_) prefix for member names.
  • Use this when accessing instance members, e.g. this.Name = "X-Splinter";.
  • Use the var keyword unless the inferred type is not obvious.
  • Use the C# type aliases for types that have them, e.g. int instead of Int32, string instead of String etc.
  • Use meaningful names (no hungarian notation), we like long descriptive names of methods, variables and parameters.
  • Wrap if, else and using blocks (or blocks in general, really) in curly braces, even if it's a single line.
  • Put using statements inside namespace.
  • One type per file.
  • Add the Starion Group copyright header to every file.
  • Pay attention to whitespace and extra blank lines
  • Absolutely no regions

Please pay attention to the style of existing code and keep new contributions consistent with it.