Pull Request Triage

Status Tags

Procedure

IMPORTANT: Whenever you do PR triage, please fill out the following form: 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 …”.”

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.

Unassigned PRs

All PRs that have no assignee (except rollups) should be assigned to a random member of the responsible team.

Unlabeled PRs

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

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, roughly, more than a week of inactivity need to be processed. These can be found by looking at the “updated X days ago” on GitHub’s PR list.

If the author hasn’t responded for more than a week to a request for changes or a status update, ping the author on GitHub asking for them to check in on the PR’s state. If they’ve given advance warning that they are unavailable for a period of time and therefore won’t be able to address comments, do not ping until after that time. It is a good idea to start the message with “Ping from Triage…” so that the concerned parties know it is coming from the triage team.

If the author has not responded to a previous ping, meaning more than 2 weeks have passed with no activity, the PR should be closed with a message thanking the author for their work, asking the them to reopen when they have a chance to make the necessary changes, and warning them not to push to the PR while it is closed as that prevents it from being reopened. Tag the PR with S-inactive-closed.

TIP: if an author is unavailable 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, roughly, more than a week of inactivity need to be processed. These can be found by looking at the “updated X days ago” on GitHub’s PR list.

If the review is complete the label should be changed from S-waiting-on-review to S-waiting-on-author.

Otherwise, the reviewer should be pinged. It is a good idea to start the message with “Ping from Triage…” so that the concerned parties know it is coming from the triage team, and the message should be asking the reviewer to either review or update a review of the PR. If the reviewer has already been pinged, meaning more than 2 weeks have passed with no activity, another reviewer on their team should be pinged. Note that if the reviewer has expressed that they are busy, do not ping them until they are available again. If the PR is not already labeled with a team (T-), find the team assigned to the PR’s issue which should have a T- label.

The r? command is needed to override a reviewer, however not all triagers will have sufficient permissions. In this case sending a message to the #triage-wg Discord or pinging @Dylan-DPC will be necessary.

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

Bors automatically manages this label but human intervention may be required if there is an issue.

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.