Add public triage information #9136
Conversation
| @@ -1,6 +1,6 @@ | |||
| name: Bug Report | |||
| description: File a bug report | |||
| labels: ["t/bug", "s/needs-verification"] | |||
There was a problem hiding this comment.
Since our only filter for triage is now basically going to be: is it on a milestone? We could opt for no initial label at all and add it during triage. That way it's also clear that we actually identified it as a bug.
Thoughts?
There was a problem hiding this comment.
yea, this seems implicit. If it doesn't have "verified" than it needs verification
There was a problem hiding this comment.
But same for bug? Should we only label it as a bug if we actually find it to be a bug instead of applying that simply when the issue is opened?
There was a problem hiding this comment.
I think because it's the "bug" template then labeling as "bug" is reasonable. Of course sometimes it turns out to be wrong, but I'd consider it a strong indicator.
| { | ||
| "name": "addLabel", | ||
| "parameters": { | ||
| "label": "i/great-reporter" |
There was a problem hiding this comment.
Added the i/great-reporter label for issue reporters who have a good track record authoring issues on our repo.
| { | ||
| "name": "labelAdded", | ||
| "parameters": { | ||
| "label": "s/try-latest-version" |
There was a problem hiding this comment.
Added a "please try latest version" label so we can easily instruct people to please try again on the latest version. Please review the description just below if it's clear enough or it needs work.
There was a problem hiding this comment.
I love this. We need to be careful to apply it only to issues that are fixed in public releases, as opposed to "we merged the fix last night so good luck building the MAUI repo and using it in your app."
| } | ||
| } | ||
| ], | ||
| "taskName": "[Idle Issue Management] Close stale 's/try-latest-version' issues", |
There was a problem hiding this comment.
Close the "please try latest version" labeled issues if no response comes within 7 days
| "issues", | ||
| "project_card" | ||
| ], | ||
| "taskName": "Add 'community ✨' label to community contributions", |
There was a problem hiding this comment.
Automatically add the community label to opened PRs so we can prioritize those
| } | ||
| } | ||
| ], | ||
| "taskName": "Stale PR reminder", |
There was a problem hiding this comment.
Mark PRs as stale after 10 days if we requested author input
| } | ||
| } | ||
| ], | ||
| "taskName": "Close stale PRs", |
There was a problem hiding this comment.
Close stale PRs after 14 days if we requested author input but nothing has happened since
| "issues", | ||
| "project_card" | ||
| ], | ||
| "taskName": "Revitalize stale PR and reopen", |
There was a problem hiding this comment.
If author of a stale PR does update the PR remove the stale label(s)
| "issues", | ||
| "project_card" | ||
| ], | ||
| "taskName": "Add comment when 's/pr-needs-author-input' is applied to PR", |
There was a problem hiding this comment.
Add a friendly comment to the author of the PR that we need some info/action from their side when we add this label
jfversluis
added
the
area-infrastructure
.github/IssueManagementPolicies.md
Outdated
| If the author does not post a response within **7 days**, the issue will be automatically closed. If the author responds within **7 days** after the issue is closed, the issue will be automatically re-opened. We recognize that you may not be able to respond immediately to our requests, we're happy to hear from you whenever you're able to provide the new information. | ||
|
|
||
| ### PR: pending author input | ||
| Similar to the `Needs Author Feedback` process above, PRs also require author input from time to time. When a member of our team asks for some follow-up changes from the author, we mark these PRs with `s/pr-needs-author-input` label. After doing so, we expect the author to respond within 14 days. |
There was a problem hiding this comment.
New label to let the PR author know we are waiting for input and stale PRs will be closed
.github/TriageProcess.md
Outdated
|
|
||
| ### Feature requests | ||
|
|
||
| As soon as we identify an issue represents an ask for a new feature, we will label the issue with the `t/enhancement ☀️` label. |
There was a problem hiding this comment.
Hooks into the comment on the bug report template: Should we not add any labels by default at all?
There was a problem hiding this comment.
Similar to the "bug" label, I think if we have specific templates for bug, feature request, etc. then we might as well apply the label in the template. We can always change the labels if they're incorrect.
.github/TriageProcess.md
Outdated
|
|
||
| ### Investigations | ||
|
|
||
| In many situations it's not immediately clear whether a specific issue reported is a bug or not. To be certain, the team will need to spend time to investigate it before making a call regarding the faith of the issue. In these situations we will apply the `investigate` label to the issue. |
There was a problem hiding this comment.
Let's slap the investigate label on so we know we need to investigate more first, this can then happen in a sprint rather than at triage.
Description of Change
Adds our public triage information so it's clear for everyone how our process works.
Additionally I've added rules to the Fabric bot to better support this new flow and the process altogether.
See inline comments for important parts and if you're a maintainer; please read through the whole thing :)