Add Stale Bot configuration #26300

pull aureleoules wants to merge 1 commits into bitcoin:master from aureleoules:2022-10-stale-bot-config changing 1 files +57 −0
  1. aureleoules commented at 6:40 PM on October 12, 2022: member

    It might be a good idea to add the Stale Bot to close issues and pulls that do not receive any activity for a certain period instead of doing it manually once in a while. The timeout in this PR is configured to be 6 months.

    How it works After a period of inactivity, a label will be applied to mark an issue as stale, and optionally post a comment to notify contributors that the Issue or Pull Request will be closed.

    If the Issue or Pull Request is updated, or anyone comments, then the stale label is removed.

    If no more activity occurs, the Issue or Pull Request will be automatically closed with an optional comment.

    This could also help revive old pulls/issues that were forgotten by receiving the notification from the bot.

    Note: Merging the PR is not sufficient to activate the bot, it needs to be activated by maintainers here. See also https://github.com/probot/stale#usage.

  2. Add Stale Bot configuration 2a400aafda
  3. aureleoules commented at 6:42 PM on October 12, 2022: member

    Friendly ping as you might be interested @achow101 @glozow considering you're closing stale pulls.

  4. brunoerg commented at 9:39 PM on October 12, 2022: contributor

    Seems interesting. I believe it is difficult to manage which PRs look "abandoned" and which PRs are lacking reviewing.

  5. fanquake commented at 10:16 PM on October 12, 2022: member

    We already have a drahtbot that does something very similar.

  6. achow101 commented at 11:15 PM on October 12, 2022: member

    Drahtbot does do part of this, but not the closing part. The issue with closing of "stale" PRs is the determination of staleness. It is context dependent, for example PRs that are the parents of a project may become "stale" but shouldn't be closed. The author of a PR also has an effect on staleness, e.g. a frequent contributor having a "stale" PR is probably more likely to come back and update the PR when prompted vs. a one time drive-by contribution may not get any follow-up.

  7. fanquake commented at 11:20 PM on October 12, 2022: member

    Does this also have the issue of contributors not being able to reopen their own PRs that have been closed by this bot?

  8. aureleoules commented at 1:16 PM on October 13, 2022: member

    for example PRs that are the parents of a project may become "stale" but shouldn't be closed

    I believe these are edge-cases. Since there is a delay before the PR/issue is closed (7 days here), a maintainer could remove the Stale tag every 6 months or anyone could write a comment. Also, I believe that usually these parent PRs get activity by being referenced in sub-PRs so the delay before being stale is usually extended.

    This may be preferable to having to manually check the activity of all PRs every once in a while?

    Does this also have the issue of contributors not being able to reopen their own PRs that have been closed by this bot?

    I'm not familiar with GitHub permissions sorry.

  9. maflcko commented at 2:05 PM on October 13, 2022: member

    Personally I don't see the problem of open pull requests that are uncontroversial and maintained by their author. Surely if someone walks away or if something is controversial, it may be better to close. Also, I prefer if people raised their concern instead of silently hoping that a pull they don't like goes stale.

    So if the goal is for the bot to achieve that, it might be better for it to provide actionable instructions. Similar to #19876 (comment)

    Some ideas:

    • If there is outstanding feedback, it should be replied to or otherwise addressed
    • If the CI fails or the last run is older than 6 months, it might be good to rebase to get a fresh CI run and also update the code context to the latest state to simplify review (obviously only if there hasn't been any ACKs to avoid invalidating them)
  10. in .github/stale.yml:8 in 2a400aafda
       0 | @@ -0,0 +1,57 @@
       1 | +# Configuration for probot-stale - https://github.com/probot/stale
       2 | +
       3 | +# Number of days of inactivity before an Issue or Pull Request becomes stale
       4 | +daysUntilStale: 180 # 6 months
       5 | +
       6 | +# Number of days of inactivity before an Issue or Pull Request with the stale label is closed.
       7 | +# Set to false to disable. If disabled, issues still need to be closed manually, but will remain marked as stale.
       8 | +daysUntilClose: 7
    


    maflcko commented at 2:07 PM on October 13, 2022:

    Not sure if this can be done by the bot. Sometimes additional stuff needs to be done, like marking "up for grabs" or closing a related issue as well, etc ...


    aureleoules commented at 11:08 AM on October 18, 2022:

    It might be easier to implement these features in Drahtbot, do you plan to open-source it?


    aureleoules commented at 3:08 PM on October 18, 2022:

    It would also be nice if Drahtbot could automatically add to a PR the labels "Concept ACK", "Approach ACK" and even count current ACKs, that way it's easy to quickly glance at the state of a PR, or even filter PRs for reviewers. I believe @JeremyRubin had a similar idea.


    maflcko commented at 3:11 PM on October 18, 2022:

    Yeah, I wanted to do that for a long time as well. Though, @DrahtBot is currently written such that it needs to scan every comment, so it will run into the rate limit quite fast.


    aureleoules commented at 3:36 PM on October 18, 2022:

    it will run into the rate limit quite fast

    This could be fixed by using webhooks no? When a comment/review is added to a PR Drahbot could fetch the PR's comments and apply labels. Fetching comments is limited to 100 per req, which is probably fine for most PRs and could also be cached. And another webhook for when a user pushes to a PR, Drahbot would invalidate ACKs by removing the label.

    The rate-limit doesn't seem too restrictive either? Unless I'm missing something

    User-to-server requests are limited to 5,000 requests per hour and per authenticated user

    I'd love to work on this but the code is nowhere to be found :frog:.


    maflcko commented at 4:05 PM on October 18, 2022:

    I am not sure how reliably webhooks are. If they are down or otherwise missed, it wouldn't be possible to catch up, unless you have script to catch up, in which case you can just use that script all the time.


    aureleoules commented at 4:19 PM on October 18, 2022:

    If a webhook is missed, which I believe is relatively rare, the bot will catch up on the next webhook received (the next comment/review/push), because it will rescan the PR comments. I don't think it's that big of a deal to miss an event, this feature is to provide heuristics anyway.


    maflcko commented at 8:55 AM on October 20, 2022:

    The source code is of low quality, but I just made it public. See for example https://github.com/MarcoFalke/DrahtBot/blob/main/scripts/stale.py

  11. fanquake commented at 8:28 AM on October 31, 2022: member

    Concept NACK - I don't see how this (contextless) bot is going to be beneficial, or better than drahtbot + maintainers. Now that drahtbot is open for contrbutions, I'd rather see any enhancements made there.

  12. aureleoules commented at 9:17 AM on October 31, 2022: member

    Yes, I am currently working on DrahtBot. Closing.

  13. aureleoules closed this on Oct 31, 2022

  14. aureleoules deleted the branch on Nov 2, 2022
  15. bitcoin locked this on Nov 9, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-21 18:13 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me