General notes on hivemind development process

Branching methodology

Hivemind is being developed using a master/develop branching process. Production builds should always be made from the master branch, and only production fixes should be merged to the master branch except when an official release is ready. Normal development changes should be merged to the develop branch. We are using this process to enable fixes to be made to production systems without requiring the production fixes to reside in branches.

A side-effect of this is that someone should always be able to build a production node using the head of the master branch.

If you plan to commit your own remote branches to the repo (if you're working for more than a day or two in a branch, this is recommended), please add a prefix with your initials, so that a casual viewer of the branches list can see who is responsible for the branch.

Coding conventions

• 2 space indention (DO NOT USE TABS)
• Avoid the use of acronyms and abbreviations in source code (i.e. in variable names) and file names unless it is standard abbreviation/acronym of the English language.