Page History

...

1. No broken builds on the Master Branch, ever.
   • All commits / Pull Requests should be tested beforehand to ensure they will not "break" the Master Branch (this includes Unit Testing the code to ensure our Continuous Integration system doesn't report a unit test failure).
   • A broken build is a matter of urgency. Mistakes happen, but if you break the build, please make sure to fix it ASAP or temporarily rollback your changes until you can resolve the issues.
   • Obviously, there may be situations where temporarily breaking the build may be necessary. However, we should make all attempts to keep breakage to a minimum (or forewarn the Committer team if anticipated). Longer-term breakage (a few days or more) can negatively affect us all.
2. No unapproved / incomplete features on the Master Branch.
   • As mentioned, all your code / new feature development should take place in your own fork and submitted via a Pull Request once it is ready for feedback (see Development with Git). The only exception to this rule is trivial changes (e.g. typos / improved comments / obvious bug fixes).
   • Your work should have as close to a "complete feature set" as possible. Note that this doesn't necessarily mean all work is "completed", but the code should not not be obviously missing functionality, or be only partially integrated, in a way that would make the system difficult to use in the near term or otherwise hamper other development efforts.
   • If your code is known to be "incomplete" in any way, you must make this clear to the Committers and detail what work is still required.
   • Before your work can be merged, it must satisfy Rule #1 AND be approved for merging by the Committers (See "code approval processes" note in the #General Guidelines for Committing above). During the "release window", the Release Team has the final say.
   • Once something is merged to master, we are effectively committed to it being in the next release.
3. All new features must have documentation before merging into the Master Branch.
   • New features/improvements should not be merged into the Master Branch until there is some minimal documentation (minimal documentation includes documenting all configuration options). Ideally, they should also come with usage documentation (i.e. examples of how to use the feature, how to configure the feature, etc.) This will help us all ensure that Documentation is ready by the time we get to the next release, and hopefully lessen the time that any one person has to spend cleaning up or rewriting documentation.