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

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" #1449

Closed
bstrie opened this issue Jul 24, 2021 · 8 comments
Labels
enhancement New feature or request

Comments

@bstrie
Copy link

bstrie commented Jul 24, 2021

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
Copy link
Collaborator

rustbot commented Jul 24, 2021

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
Copy link
Author

bstrie commented Jul 24, 2021

^ A demonstration of the potential hazards. :P

@Mark-Simulacrum
Copy link
Member

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
Copy link
Author

bstrie commented Jul 25, 2021

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
Copy link
Member

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
Copy link
Member

camelid commented Jul 27, 2021

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
Copy link
Author

bstrie commented Jul 28, 2021

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
Copy link
Contributor

apiraino commented Jun 7, 2023

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).

@ehuss ehuss added the enhancement New feature or request label Jul 20, 2023
@Kobzol Kobzol closed this as completed Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants