Issue Tracking

Orchestrator development is centred around the use of GitHub's issue tracker, which is here for this repository. GitHub's issue tracker is documented here, which is quite a pleasant read.

Notable Features

The issue tracker allows developers to define various types of items of work through its labelling mechanism:

• Features: Created by developers to introduce new functionality to the system.

• Bugs: Created by developers and users to identify problems with the currently implemented set of features, and to discuss how they should be repaired.

• Refactors: Created by developers to make future work easier or possible.

Create other types of labels as necessary. People will call you on it if you make a redundant label, but you might identify something that is missing.

You can (and should) associate issues with milestones (e.g. "Advisory Board Release") so that progress for a given objective can be filtered on. This also gives context for the background of your issue.

General Rules

• When creating an issue, assign one of the "refactor", "bug", or "feature" labels to it.

• In the description for your issue, include:

  • A motivation for why the issue is being worked on.

  • If a bug, include the version it was encountered on, the hardware used, and the date it was encountered. If you have suspicions of the origin of the bug, also voice those.

  • An estimate for when you expect it to be completed.

• Encourage discussion through the use of mentions "@mvousden" and assignees. Be civil.

• Assign a milestone to your issue.

• Close your issue once it has been completed. If your issue is resolved by work on a work branch (see Our Approach to Version Control: GitFlow (ish)), only close the issue once the work has been completed and the work branch merged in following the review process.