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

x/build/cmd/gopherbot: consider having WaitingForInfo check for the last comment instead of time applied #39796

Closed
stamblerre opened this issue Jun 24, 2020 · 2 comments
Labels
Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@stamblerre
Copy link
Contributor

stamblerre commented Jun 24, 2020

In my experience, I often forget to apply WaitingForInfo to an issue, but the last response for the reporter has been weeks ago. When I come back to it and do apply it, I still have to wait another month for the issue to be automatically closed.

Would it make more sense for WaitingForInfo to check for the last comment? I believe the vscode bot checks for the last comment from a maintainer - maybe we could check for the last comment from an "unknown GitHub person"?

@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Jun 24, 2020
@gopherbot gopherbot added this to the Unreleased milestone Jun 24, 2020
@stamblerre stamblerre changed the title x/build/cmd/gopherbot: x/build/cmd/gopherbot: consider having WaitingForInfo check for the last comment instead of time applied Jun 24, 2020
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 24, 2020
@cagedmantis
Copy link
Contributor

/cc @andybons @dmitshur @toothrot

@dmitshur
Copy link
Contributor

dmitshur commented Jun 28, 2023

Thanks for making this suggestion.

gopherbot's current behavior optimizes for cases where an issue report may be a real problem to fix in Go, but investigating and resolving it cannot progress further until additional information is provided. Closing such an issue is a suboptimal outcome that we wish to avoid, but unavoidable in some cases. So having gopherbot extend the timer on the addition of WaitingForInfo label helps increase the chances of the original author noticing that their input is needed, and closing immediately would be counter-productive.

For cases where an issue is obsolete and waiting another 30 days has no chance of helping, it is now possible to close the issue and specify "not planned" as the reason. (This GitHub feature was added last year.)

We're relying on gopherbot giving at least 30 days after the addition of the label in more places now, so it's become more clear this gopherbot behavior is worth keeping as is. Closing this as not planned.

@dmitshur dmitshur closed this as not planned Won't fix, can't repro, duplicate, stale Jun 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants