Issue Management

Goals

Every issue in the repository should:

• A clear title.
• Have labels explaining why the issue is still open.
• Have labels explaining what the issue applies to (e.g. debugging).
• Have labels explaining what sort of issue something is (e.g. a bug).

Workflow

New issues

... receive the classify label so they can be triaged.

Bugs

Triaging

1. The bug label is added.
2. The appropriate area label is added.
3. Issues get assigned to someone and receive the triage label, replacing the classify label.
4. If more information is needed from the original poster (OP), the info needed label is added, being removed once the OP responds with the requested information.
5. The investigating label is applied when the person assigned to triage the issue has started looking into the cause of the issue (this may come after a couple of messages between the OP and the assigned person to clearly understand what needs investigation).
6. If the issue is found to be legitimate, the appropriate needs label replaces the investigating label (e.g. needs spike, needs PR).

Fixing

1. If a fix requires investigation, it will have the needs spike label.
2. Once a solution is decided upon, the bug will have the needs PR label.
3. Scheduling a fix will be based on how many users are affected, is there a workaround and how arduous is it, difficulty of the fix, etc.

Closing

Bugs can be closed if:

1. The issue was opened in error by the OP.
2. The issue cannot be reproduced.
3. The OP did not respond to a request for more information.
4. The bug has been fixed in the next release and has been added to the appropriate milestone.

Feature requests

Triaging

1. The feature-request label is added.
2. The appropriate area label is added.
3. A determination is made whether the team wants to accept the suggestion, outright, adding needs PR or needs proposal if it is.
4. If the team isn't ready to necessarily accept a feature request, needs feedback is added and a comment detailing what is required for an issue to be re-considered for acceptance is left.

Implementing

1. If needs proposal is on the feature request then a discussion needs to occur to decide how to implement the request.
2. Once a solution is agreed upon, the needs PR label is added.
3. A feature request will be scheduled to implementation based on number of users who will benefit, difficulty of implementing, etc.

Closing

1. We have chosen not to pursue a feature request based on community feedback.
2. A feature has been implemented for the next release and has been added to the appropriate milestone (the issue is expected to also have either the on-testplan or verification-needed label applied as appropriate before we reach endgame week; see release testing for details)