PR triage

Status tag meanings:

Procedure:

IMPORTANT: Whenever you do PR triage, please fill out the following form: https://goo.gl/forms/YKYVFYjBq28Hm3qQ2. If you want to create a bookmark for yourself, you can adapt this link to prefill your GitHub username.

Note: When you are pinging people in triage comments, you should mention that you are doing triage in the comment you post. For example, start your comments with something like “Ping from triage …”.”

Unlabeled PRs

All unlabeled PRs should be processed. The steps below are not mutually exclusive, any number of them may apply.

When there is no assignee, because highfive flaked, figure out the responsible team and randomly choose a reviewer from the team by manually assigning in GitHub.

When no review has happened, if the PR is a work in progress (e.g., test failures, merge conflict) mark S-waiting-on-author. Otherwise, mark S-waiting-on-review. If no human has checked in yet and you don’t recognise the submitter as a regular contributor, leave a comment saying something like “Thanks for the PR! We’ll periodically check in on it to make sure that @reviewer or someone else from the team reviews it soon.”

At this point, all PRs must have a tag applied.

S-waiting-on-author PRs

PRs with greater than 3 days of inactivity need to be processed. These can be found by looking at the “updated X days ago” on GitHub’s PR list.

First, ensure that the status tag matches the current state of the PR. Change the tag if necessary, and apply the procedure for the new tag.

Then, if the author hasn’t responded for more than 7 days to a request for changes or a status update, ping the author on GitHub asking for an update. If they’ve given advance warning that they won’t be able to address comments for a period of time, allow for that.

If the author’s been unresponsive for more than 14 days, close the PR due to inactivity and ask the author to reopen when they have a chance to make the necessary changes. Make sure to thank the author for the changes. Also tag the PR with S-inactive-closed.

If there has been no meaningful updates after two triage updates, with no meaningful being defined as no commits or no status updates that show progress (i.e. “Soon TM”). The PR should be closed due to prolonged inactivity and ask the author to reopen when they have a chance to make the necessary changes. Make sure to thank the author for the changes, and warn them not to push to the PR while it is closed as GitHub will prevent the PR from being reopened. Make sure to also tag the PR with S-inactive-closed.

TIP: if an author is on holiday and you know they won’t have a chance to come to a PR for a while, you can ‘bump’ the PR by removing and readding the tag (note that removing/readding requires clicking off the tag selection dropdown between the two actions).

If the PR is blocked on another PR, issue, or some kind of discussion, add a comment clearly identifying what is blocking the PR (something like “This PR appears to be blocked on #12345”) and change the state to S-blocked. Follow the instruction for S-blocked to determine whether you should also close the PR.

S-waiting-on-review PRs

PRs with greater than 3 days of inactivity need to be processed. These can be found by looking at the “updated X days ago” on GitHub’s PR list.

First, ensure that the status tag matches the current state of the PR. Change the tag if necessary, and apply the procedure for the new tag.

If there are no comments from the reviewer:

If the review is incomplete:

If the PR is blocked on another PR, add a comment clearly identifying the blocking PR (something like “This PR appears to be blocked on #12345”) and change the state to S-blocked.

S-waiting-on-team PRs

PRs active within the last 4 days or inactive for greater than 2 weeks need to be processed. These can be found by looking at the “updated X days ago” on GitHub’s PR list.

First, ensure that the status tag matches the current state of the PR. Change the tag if necessary, and apply the procedure for the new tag now. Verify that there is a T- tag for all PRs that remain in this category.

If the PR has been inactive for greater than 2 weeks, add the I-nominated label and ping the team, requesting a new assignee or other appropriate action.

If there has been recent activity, the team might have taken some action meaning the state has changed but the label has not yet been updated. Therefore, we also check the most recent ones.

S-waiting-on-bors PRs

All PRs should be processed. First, ensure that the status tag matches the current state of the PR. Change the tag if necessary, and apply the procedure for the new tag now.

S-waiting-on-crater PRs

All PRs should be processed.

If the PR has been active in the last three days, make sure it’s present on the crater spreadsheet. Fill in the link to the PR and set status as “Pending”.

If crater has been run and results include failures, change the tag to S-waiting-on-review for the reviewer to be responsible for deciding what should be done with the information provided by the failures.

If crater has been run and the results do not include failures, change the tag to S-waiting-on-review for the reviewer to take one last look and approve.

If crater has not been run and it has been more than 3 days since a crater run was requested, ping the last three distinct listed people on the spreadsheet in the infra irc channel and request a crater run.

If crater has been started (the person starting should leave a comment) and it has been more than 5 days since an update, ping the person starting the run on IRC and GitHub.

S-waiting-on-bikeshed

PRs inactive for greater than 7 days need to be processed. These can be found by looking at the “updated X days ago” on GitHub’s PR list.

Find the source of the discussion and see if it has been resolved.

If it has been resolved, move it back to S-waiting-on-author or S-waiting-on-review as appropriate. Add a comment notifying the author or reviewer that the PR is now unblocked.

If it has not been resolved, remove and re-add the S-waiting-on-bikeshed tag. This resets the update time so the PR won’t be reviewed for another week.

S-blocked PRs

Blocked PRs can remain blocked for a long time. To avoid needlessly re-triaging them, they should be closed if the blocking issue is unlikely to be resolved soon. If you close a blocked PR, apply the S-blocked-closed label and invite the author to re-open the PR once the issue has been resolved. If you feel uncomfortable just closing the PR, feel free to link to this document. As a rule of thumb, consider these guidelines:

Blocked PRs which have not been closed should be triaged as follows:

PRs inactive for greater than 7 days need to be processed. These can be found by looking at the “updated X days ago” on GitHub’s PR list.

Find the blocking issue from the triage comment and see if it has been resolved.

If it has been resolved, move it back to S-waiting-on-author or S-waiting-on-review as appropriate. Add a comment notifying the author or reviewer that the PR is now unblocked.

If it has not been resolved, remove and re-add the S-blocked tag. This resets the update time so the PR won’t be reviewed for another week.

S-blocked-closed PRs

These never need to be looked at, although if you want you can go through the PRs and see if any have been unblocked. This label is for PRs which are blocked and have been closed because it is unlikely that the blocking issue will be resolved soon.

S-inactive-closed PRs

These never need to be looked at. PRs which have been closed due inactivity. This is a terminal state for the time being, primarily oriented towards easing future work.

Issue triage

Issue triage is mostly much simpler. After finishing PR triage, go to the list of untagged issues and add tags as you see fit. The following categories should, ideally, be assigned to each issue:

If an issue has been tagged with an E- category tag, such as E-help-wanted and has been taken up by someone, but there has been no activity for 7 days, ask if they require assistance, and inform them that after 14 days this issue will be made available to anyone. After 14 days re-add the help tag and deassign them if necessary.

State Of Rust Triage

  1. Visit the State Of Rust project page. Each card has three pieces of information.
    • “Feature” — The name of the feature with a link to the tracking issue.
    • “What’s next?” — What we are waiting on to implement and stabilise the RFC.
    • “Last Update” — The last time this card has been triaged.
  2. For each card that you choose to triage:
  3. Visit the respective tracking issue, and any related issues that the tracking issue is recently mentioned in.
  4. If the “What’s next?” on the card does not match what you think the current state is, update it with the new information.
  5. If the implementation of an RFC has changed since the last update, move it to the relevant column.
    • If there are PRs merged that implement the RFC the card would move to “Implemented”.
    • If there are only open PRs or the PRs don’t implement the full RFC the card would be moved to “Implementation in progress”.
    • If there has been a decision to deprecate the RFC, move that to the “Deprecated” column.
  6. If there have been no meaningful changes to the RFC within 21 days, ping someone for an update on the status of the feature.
    • If there have been PRs implementing the RFC, ping the author(s).
    • If author has not responded within a week, or there are no relevant PRs, ping the relevant team.
    • If there is no clear choice for the team that should be doing the implementation, please add this to release team meeting notes (which can be found in the #rust-release IRC channel).
  7. Update the date on the “Last update” and move that to the bottom of the column.