Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs(contrib): Improve triage instructions #14052

Merged
merged 5 commits into from
Jun 13, 2024
Merged
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 16 additions & 12 deletions src/doc/contrib/src/issues.md
Original file line number Diff line number Diff line change
Expand Up @@ -155,8 +155,9 @@ different steps, or in rare cases have multiple statuses.
* **[S-needs-rfc]** --- Needs an [RFC] before this can make more progress.

Anyone is welcome to help at this stage, but it should be clear that it is
not yet accepted. However, this should only be tagged for changes that are
somewhat likely to be accepted.
not yet accepted.
See [Before creating an RFC](https://github.com/rust-lang/rfcs?tab=readme-ov-file#before-creating-an-rfc)
for next steps.

* **[S-needs-mentor]** --- Needs a Cargo team member to commit to helping and
reviewing.
Expand Down Expand Up @@ -197,10 +198,13 @@ issues have not yet been triaged.
There are several things to consider when triaging an issue:

* Is this a duplicate? Search the issue tracker (including closed issues) to
see if there is something similar or identical to what is reported. If it is
obviously a duplicate, write a comment that it is a duplicate of the other
issue, and close the issue. If it isn't obvious that it is a duplicate,
leave a comment asking the author if the other issue covers what they reported.
see if there is an issue with a similar or identical root cause to what is reported.
We generally focus issues around root causes so alternative solutions can be
discussed and evaluated together.
If it is obviously a duplicate, write a comment that it is a duplicate of the
other issue, and close the issue.
If it isn't obvious that it is a duplicate, leave a comment asking the author
if the other issue covers what they reported.

* For a bug, check if the report contains enough information to reproduce it.
If you can't reproduce it, solicit more information from the author to
Expand All @@ -217,17 +221,17 @@ There are several things to consider when triaging an issue:
* Assuming the issue looks valid, remove the [S-triage] label and move it onto
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove the [S-triage] label

This is part of what doesn't sit well with me. What if the next natural status is one of the (reserved for Cargo team) ones? Isn't removing [S-triage] reserved as well then?

I suggest something like this:

Assuming the issue looks valid, consider assigning it a new status label:

... (bullet points)

Remove the [S-triage] label if you moved the issue to a new status.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried a slightly different wording

Assuming the issue looks valid, switch the [S-triage] label for one of the following:

My thinking is that this makes it clearer that this is an "atomic" operation; that you should only remove S-triage if you can add the new label. In practice, if there is no more design work, then its "needs-team-input".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks reasonable. Thanks!

a new status:

* [S-needs-rfc] --- This is a large feature request that will require a
public design process.
* [S-needs-design] --- The resolution of the issue or small feature request
will need more work to come up with the appropriate design.
* [S-needs-team-input] --- The next steps are not clear, and the Cargo team
needs to discuss whether or not to proceed and what needs to be done to
address the issue.
* [S-needs-design] --- The resolution of the issue or small feature request
will need more work to come up with the appropriate design.
* [S-needs-rfc] --- This is a large feature request that will require a
public design process.
* [S-needs-mentor] --- This is something the Cargo team wants to address,
but does not currently have the capacity to help with reviewing.
but does not currently have the capacity to help with reviewing. **(reserved for Cargo team)**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about S-needs-rfc?

Anyone is welcome to help at this stage, but it should be clear that it is not yet accepted. However, this should only be tagged for changes that are somewhat likely to be accepted.

Should we include that or adjust its text a bit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took out the "likely to be accepted". I didn't realize that and have been tagging things that are RFC scope. I did link out to the instructions on socializing an RFC which kind of fills a similar role of pre-vetting.

* [S-accepted] --- This is something that clearly needs to be addressed, and
a Cargo team member has volunteered to help review.
a Cargo team member has volunteered to help review. **(reserved for Cargo team)**

Anyone is welcome to help with the triaging process. You can help with
reproducing issues, checking for duplicates, gathering more information from
Expand Down