Page History

...

1. Use JIRA to track your changes
   • Ensure there is an issue describing the fix/improvement/feature in JIRA (If this is a minor typo fix, or an obvious bug, you need not add a JIRA issue – use your judgment on whether this fix is worth tracking in JIRA or not)
2. Submit a Pull Request for your code changes
   • First off, you should be doing the majority of your development in your own GitHub Fork. See Development with Git.
   • Generally speaking, code changes should come in via a Pull Request. This gives the rest of the Committers/Developers a chance to comment on the Pull Request.
   • If this is a very minor fix/change (typo/improved comments/obvious bug), you can bypass creating a Pull Request and commit it immediately. This is an exception to the rule.
3. Code approval processes
   • General Rule of Thumb: Committers are trusted developers. Use your best judgment on whether or not you feel a particular piece of code should be approved before committing/merging your Pull Request. The below guidelines are just suggestions and they may not apply to all scenarios:
   • If this is a small, obvious fix (typo/improved comments/obvious bug), just commit it immediately. This is the exception to all other rules – there's no reason to add a JIRA issue for every typo or obvious fix, and no reason to wait around for approval to commit it.
   • If this is a bug/issue fix, try to get approval for your Pull Request from at least one other Committer. If there is any doubt, feel free to run it by others or ask to have it added to the agenda of the next developers meeting.
   • If this is a new feature, generally speaking you need at least three Committers to approve (or bring it up in a developer meeting, if it's a larger change). The only reason we suggest to run it by more than one committer is that oftentimes others may be able to provide additional suggestions or configurations that may be worth investigating.
   • Please note that our Developer Voting Procedures actually state that at least three Committers should approve of all code changes, and none should disapprove. We tend to be lenient on minor code changes / bug fixes (as these tend to be non-controversial changes). But, new Features features should really get the approval of at least 3 Committersthree Committers (and larger features should be discussed / voted on in a public forum, e.g. IRC meeting or email).
4. Document your code early & often
   • New features/improvements need to come with documentation, otherwise we won't be able to accept them. Keep this in mind while you are developing, and use the Wiki or JIRA to start your documentation early on (it'll make it easier on you in the long run).
5. Once Approved, Merge your Pull Request in a timely manner
   • Once your Pull Request is approved, you should work to merge it as soon as you can.
   • Before merging, please ensure that your code doesn't break any Unit Tests. This will save you a potential headache later, when our Continuous Integration system does a verification of all Unit Tests.
   • If the Pull Request was not created by a Committer, the Committer(s) who are most familiar with the work (and who may have been supporting/giving feedback) should merge the Pull Request.
   • Obviously, Committers can ask for someone else to take over the merge process as needed.

...