Issue Tracking Process

Author: IB

This process documents how we deal with issues, and the weekly developer meetings. Please note that (at least initially) we don't need to follow this strictly for experiment branches, only for fix and feature branches i.e. work which has a direct route into released code.

Principles

Please adhere to the following principles, which will make all of our lives easier!

• All development (i.e. commits to git) should be related to an issue or PR. If one does not exist, please create it!
• Issues should be closed by the person who opened them, and the closing message should document what level of testing has been done to ensure that the issue is in fact resolved.
• Issues should be assigned to a milestone - either a current release, "Future Release" (i.e. to be considered for inclusion in the next one or two releases) or "Backburner" (i.e. no current plan to fix)

Triaging new Issues

• New issues should be investigated (briefly) by a developer, and come to agreement with the reporter as to what should be done with the issue:
  • Further investigation (assign to developer, no milestone needed at this stage)
  • Requires immediate fix (assign to developer, add to current release milestone)
  • Not urgent / no plan to fix (add to "Future Release" or "Backburner", no need to assign to a developer)
• Active issues (those assigned to current release, or updated in last week) will be reviewed at weekly development meeting

Development Meeting

• Meeting held at 10am EST / 3pm UK / 4pm CET on Mondays in Hangouts
• Meeting chaired by IB, all to attend
• Standing agenda:
  • Review of actions from previous weekly meeting / release monitoring meeting
  • Review active issues
  • Any other business
• Minutes are linked from the main page of the wiki