Issue Management

Our GitHub community is one of the biggest reasons for our success. Every single day, we receive issues with inspiring ideas for new functionality, you tell us what works as expected and what doesn't, and you tell us how to improve what's already there. We appreciate every single issue you create. Thank you!

Despite our best efforts to deal with all of those issues, over the course of time we may fall behind. When you look at an issue it's sometimes unclear whether or not we intend to provide the functionality you propose, whether or not we fix the bug, whether or not the issue is a duplicate of another one. Outlined below is our (ideal) process for issue management to give you a better idea of how we think about each issue you submit!

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 triage-needed 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 the area owner
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. If the issue is found to be legitimate, the appropriate needs label replaces the triage-needed 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. When the bug is scheduled to be fixed, it is added to the appropriate milestone.

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.

Won't fix Bugs

Sometimes we close bugs as "won't fix" if there is a negative cost-benefit balance. It's not that we don't care about users who are affected by an issue but, for example, if the fix is so complex that despite all of our tests, we risk regressions for many users, fixing is not a reasonable choice. When we close a bug as won't fix, we'll make our case why we do so.

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 community feedback is added and a comment detailing how the community is expected to provide feedback.

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. When a feature is scheduled to be worked on it is added to the appropriate milestone.

Closing feature requests

There are a variety of reasons why we might close a feature request:

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)
3. The feature request is out of scope

Feature requests, like all issues, are a means of communication between us and our community, as well as among members of the community. Thus, in principle, we could keep all feature requests open no matter what will happen to the feature they describe. But this makes it hard for you to understand what has realistic chances to ever make it into the repository. We therefore close feature requests we won't address.

If you are the author of a feature request, you might not like that we close your issue. It might even feel like a slap in your face. We understand that. All of us have been there as well - in this project or others we have contributed to. So, be assured, we love all of your input. Don't take personal offense when we decide to close your issue ☮️. If you feel your feature request deserves to stay open, improve your use case or gather more up-votes. Then ping us and we'll consider reopening the feature request.

Criteria for closing out of scope feature requests:

1. Does the functionality described in the feature request have any reasonable chance to be implemented in the next 24 months? 24 months is longer than our roadmap which outlines the next 6-12 months. Thus, there is some crystal ball reading on our part, and we'll most likely keep more feature requests open than what we can accomplish in 24 months.
2. Has the community at large expressed interest in this functionality? I.e. has it gathered more than 7 up-votes?
3. Do we think the feature request is bold and forward looking and would we like to see it be tackled at some point even if it's further out than 24 months? (Clearly, this one is the most subjective criterion.)

If the answer to any of the three questions is yes, then we ask about affordability:

4. Can our team afford to implement the feature? I.e. are the costs to implement the functionality reasonable compared to the size of our team?

In summary, a feature needs to pass one of 1-3 and 4. Otherwise, we'll close it as out of scope. We'll unsubscribe from these issues to reduce the overall number of issue notifications we receive every day.