Development Processes

This page captures the processes we follow when developing this project. As these are early days it is as much a discussion document as anything else. Please get in touch with suggestions or add your ideas directly. Please don't remove existing text unless it is as the result of a core team decision.

Tracking the Work

We like to raise issues for forthcoming pieces of work. These issues may be associated with a milestone. Once a changeset has been developed which tackles all or part of the issue it will be raised as a pull request. If the change is a complete implementation of the issue please include in the pull request description the magic string closes followed by the issue number. If it is only a partial solution just include the ticket number and a suitably non-magic string explanation.

Currently we associate both issues and pull requests with both milestones and projects. This leads to a real mess in the projects as both appear and noodle around between columns. I wonder if we should use only milestones for tickets and only projects for pull requests.

Merging to 'Master'

There are a number of requirements which must be met before a change (pull request) can be merged to master.

Code Review

Before a branch may be merged to trunk it requires to pass review by at least one reviewer from the core team. This was discussed in #17 and should be enforced by GitHub.

Pass Automatic Tests

GitHub will automatically run a number of tests on modification of a pull request. This includes running unit tests and potentially other tests. All of these must be successful before a branch may be merged to master.

Collapse Merger

This was discussed in #18 and the conclusion was that we are not interested in the history of the branch. As such we require and have enforced collapsing merges to master.