The first time that a PR receives the "waiting-on-author" label, leave a comment explaining how the author can use rustbot to change the label back to "waiting-on-review"

[bstrie]

Reviewers filter their lists of potential PRs to review based on the existence of the "waiting-on-review" tag. When a PR has been reviewed but is awaiting additional changes before it can be merged, the "waiting-on-review" label is removed and the "waiting-on-author" label is added. But most people submitting PRs don't realize that after making changes they have to signify this by changing the labels back, and even then they likely don't have the authority to modify labels in the Rust repos. There exist rustbot commands that allow users to modify the labels on their own PRs, but most users are unaware of this and even the users that are aware tend to forget the syntax. Thus it falls on the shoulders of the triage team to occasionally read PRs and figure out if they're ready for review and fix the tags accordingly. It would both reduce the burden on the triage team and improve PR turnaround times if users were made aware of how they could fix up the labels on their PRs appropriately.

On PRs, triagebot should listen for the "waiting-on-author" label to be applied. If this is the first time that a PR has had the "waiting-on-author" label applied, it should leave a comment on the PR as follows:

This PR is now awaiting changes from the author and has been removed from the review queue. When the changes have all been made and this PR is ready to be reviewed again, please leave a comment with the following line, which will re-add this PR to the review queue:

@rustbot ready

The comment should only be left the first time that the "waiting-on-author" label is applied, because doing so every time will likely result in a lot of spam (especially since removing and immediately re-adding labels is common practice among the triage team to silently bump Github's "last updated" timestamp). Triagebot shouldn't need to have any sort of database in order to achieve this; if Github's API doesn't make this easy then it should suffice to walk the comment history looking for this comment. Also, the comment itself must obviously not trigger any action from rustbot, either by wording it such that rustbot won't see it or by making it so that rustbot ignores comments from other bots.

Discussed on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/242269-t-release.2Ftriage/topic/automatic.20rustbot.20info/near/246774009

[rustbot]

Error: The feature shortcut is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please let @rust-lang/release know if you're having trouble with this bot.

[bstrie]

^ A demonstration of the potential hazards. :P

[Mark-Simulacrum]

I feel like this is a little noisy. Maybe we can just mention this on all PRs in the first comment highfive leaves?

If you put the command either in code or in a block quote triagebot should ignore it.

[bstrie]

That would at least help relative to the current situation, although I think it will be easy to overlook, especially since there will be a gap between the first comment from highfive and the point in time where the label is applied.

[Mark-Simulacrum]

We can also have triagebot add a status to the github checks (e.g., like github actions) when the work is waiting on author as failing/pending. I don't think we should leave a comment which generates notifications and increases likelihood for "N hidden items" in github, but am open to alternatives.

[camelid]

We can also have triagebot add a status to the github checks (e.g., like github actions) when the work is waiting on author as failing/pending. I don't think we should leave a comment which generates notifications and increases likelihood for "N hidden items" in github, but am open to alternatives.

Hmm, it seems confusing to me to use CI to communicate things other than the status of the code itself.

[bstrie]

On Zulip it was noted that Triagebot already keeps a database, so that unblocks the question of how this could be done and leaves only the question of whether it should be done.

[apiraino]

In #1684 the opening comment for "your first contribution" now explains better the commands to switch to waiting on review / author.

Hope this satisfies most of the ask expressed in this issue. I think it can be closed (can't close this issue myself).