-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Setup Stale Probot #6020
Setup Stale Probot #6020
Conversation
Nice, that was easy! Do you know if the docs say anything about rate limiting? Ideally we'd just receive at most 5 stale notifications a day (or something like that). I'm not sure if we'd want to get hundreds of notifications here all at once :( Additionally, could the default threshold for being stale be lifted? I think something like 180 days should probably be a good cushion to start with (although a year may be more conservative). For wording, I like what you've got! Perhaps tweak it a bit like so?
I also really like how we can have labels for "never stale" issues! We may want to remove E-easy and E-help-wanted from that list though because if it's been stale for so long it likely isn't easy or doesn't have good enough mentoring instructions! I'd also remove I-nominated from the list because if we haven't gotten to removing the nominated tag in such a long time we definitely should! (probably same with P-high, if it's been stale for so long as P-high it may not actually be high priority) I think C-tracking-issue is good to leave as "never stale" along with "Feature accepted". I wonder if we should perhaps conservatively say that feature requests are never stale? On one hand that may be one of the big pain points of closing issues, but on the other hand it's also good to clear these out as they're often fixed by other PRs that happen after the issue was initially open. Curious to hear what you think! |
Ah it looks like the README also has more configuration options documented. Perhaps we could add:
The |
Makes sense to let these be closed as it's likely they aren't easy or don't have good enough mentoring instructions.
If they haven't had any activity (or been solved) in long enough, they're probably just as stale as every other issue.
Great suggestions. I went with 180 days, over a year, though I'm not against a year. The idea to include feature requests is an interesting one. It's our biggest label, at 237/735 issues currently. Aleksey also specifically called it out in the contributing guide ("C-feature-request marks proposals for new features"). So I don't know what the best choice is. Maybe start exempting them and then when we get more comfortable with the idea of stale bot remove the exemption? Do you feel strongly about restricting stale bot to just issues? Personally I feel that the pull request queue even more than the issue backlog shouldn't be left to go stale. |
.. and we might want a shorter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rust-highfive sometimes uses "I" messages, So I experimented with that form hear. What do you think?
.github/stale.yml
Outdated
|
||
markComment: > | ||
As there hasn't been any recent activity here for 180 days this has been | ||
marked as stale, and if no further activity happens for 7 days this will be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that there has not been any activity in over 180 days, can I close this issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the"I" is being overused then maybe:
Move to close? As there has not been activity in over 180 days. If there is no response in 7 days this will be closed for now.
The teem would appreciate if anyone could give an update on:
.github/stale.yml
Outdated
As there hasn't been any recent activity here for 180 days this has been | ||
marked as stale, and if no further activity happens for 7 days this will be | ||
automatically closed. This is an automatic action and may be in error, if this | ||
issue should remain open please comment to that effect! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am just a bot, so if this should stay open leave a comment.
.github/stale.yml
Outdated
issue should remain open please comment to that effect! | ||
|
||
When commenting, we'd be eternally grateful if some details such as these | ||
could be included: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The teem would appreciate if anyone could give an update on:
.github/stale.yml
Outdated
acceptable! | ||
|
||
closeComment: > | ||
A comment to confirm that this is being closed due to being stale and the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am going to close this for now as I did not see an update. If it's still an issue, I am sorry. Please leave a comment and a team member can reopen it, or open a new issue to start a new discussion of the problem.
.github/stale.yml
Outdated
If you're reading this comment from the distant future, fear not if this issue | ||
was closed automatically. If you believe it's still an issue please leave a | ||
comment and a team member can reopen this issue. Opening a new issue is also | ||
acceptable! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I don't see new activity in the next 7 days I will close this for now.
Sounds like a good idea to me!
PRs are sort of interesting in the sense that if it's blocked on us (cargo reviewers) then we should never close the PR. If the PR is blocked on the author, though, it makes sense to auto-close after awhile. I think we can try this out though, the repo is relatively low-traffic in the sense that we as authors can hold ourselves accountable for responding to stale PRs. So yes, let's enable PRs! |
Looking good to me! @Eh2406's suggestions sound great to me, and after that I think we might be ready to kick the tires |
/cc @wycats, happy with wording, at least to start with? |
Looks great to me! Thanks for the updates. |
@bors: r+ Alright let's try this! |
📌 Commit 53d10c8 has been approved by |
Setup Stale Probot r? @alexcrichton /cc @Eh2406
☀️ Test successful - status-appveyor, status-travis |
@dwijnand ok the next step is to install the app? Is that all that's needed? |
@alexcrichton I believe so! |
Ok! It's now installed, so let's see how it goes... |
r? @alexcrichton
/cc @Eh2406