Triaging an issue is a multi-step process that is collaboratively performed by the HotSeat, the triage meeting, area owners, and our issue bot. Triaging an issue usually takes around one week but may take longer, for example, when the feature area owner is not around, or we need more information.
|We didn't get the information we need within 28 days. | Resolution:NeedMoreInfo|
|It's a duplicate of another issue. | Resolution:Duplicate |
|What is described is the designed behavior. | Resolution:ByDesign |
|The issue is a user question. | Resolution:Question |
|Given the information we have we can't reproduce the issue.| Resolution:NotRepro |
|This issue appears to be External to NuGet. | Resolution:External |
|This issue appears to not be a bug. | Resolution:NotABug |
|It has a negative cost-benefit balance. | Resolution:WontFix |
We close issues with the help of a bot that responds to a particular comment or to assigning a label with adding a pre-canned comment to the issue and closing the issue.
### Requesting Information
If an issue misses information that we need to understand the issue, we assign the `WaitingForCustomer` label. We usually manually add the `WaitingForCustomer` label at first, then bot will switch between the `WaitingForCustomer` and `WaitingForClientTeam` labels automatically when there is a new comment.
The bot is monitoring all issues labeled `WaitingForCustomer`. If we don't receive the needed information within 14 days, the bot will add a `no recent activity` label and a comment. After another 14 days without any comment from the author, the bot closes the issue and add `Resolution:NeedMoreInfo` label.
We label issues with `help wanted` to encourage the community to take up. If issues are suitable for beginners, we may add the `good first issue` label and we add code pointers that help beginners to get started with a pull request.
Sometimes, we get issues that we can't or don't have the time to reproduce due to the complexity or time requirements of the setup but that we indeed suspect to be issues. We label those issues with `Triage:Investigate`. What we are looking for is help in reproducing and analyzing the issue. In the best of all worlds, we receive a pull request from you. :smiley:
Please note, issues with the `Priority:2` label usually have higher impact than issues with the `Priority:3` label. So, if you'd like to make more impact, please prioritize working on fixing issues with the `Priority:2` label.
We appreciate everyone who takes their time creating issues of feature requests to help us improve our product. In theory, we could keep all issues open no matter if what will happen in the future. But that makes it hard to understand what has realistic chances to ever make it into the repository.
Here are the questions we consider when triaging:
* Does it match our general philosophy? Does the proposal match with our general product direction?
* Can our team afford to implement and maintain it? Are the direct and the opportunity costs to implement the functionality and maintain it going forward reasonable compared to the size of our team?
* Does it align with our roadmap?
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.
* 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 is quite subjective.)
* Has the community at large expressed interest in this functionality? I.e. has it gathered more than 5 up-votes.
After triaging, the issue will fall into one of the following categories:
* The feature is under consideration. A `Priority:3` label is added.
A bot monitors the issues having a `Priority:3` label. If an issue receives 5 or more up-votes in 90 days, the bot adds a `Triage:NeedsTriageDiscussion` label. The NuGet team meets weekly to discuss issues labeled `Triage:NeedsTriageDiscussion` and we will do more analysis to determine the cost/benefit. If we decide the issue should be on the backlog, we will change the priority label to `Priority:2`.
> Currently, the threshold is 5 up-votes. We start with this low threshold as we don't want to miss your voices. Going forward, we might need to adjust the threshold if it doesn't fit well.
### Up-voting a feature request/bug
When we refer to "up-voting" a feature request/bug, we specifically mean adding a GitHub +1/"👍" reaction to the issue description. In the GitHub UI this looks like so:
We close bugs as wont-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 wont-fix we'll make our case why we do so.
