[RFC 0051] Mark stale nixpkgs issues #51
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,74 @@ | ||
| --- | ||
| feature: close-stale-issues | ||
| start-date: 2019-08-24 | ||
| author: Ryan Mulligan | ||
| co-authors: (find a buddy later to help our with the RFC) | ||
| shepherd-team: (names, to be nominated and accepted by RFC steering committee) | ||
| shepherd-leader: (name to be appointed by RFC steering committee) | ||
| related-issues: (will contain links to implementation PRs) | ||
| --- | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| Close stale Nixpkgs issues and pull requests (hereafter both referred | ||
| to as simply "issues") on GitHub using an application provided by | ||
| GitHub. | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| The Nixpkgs GitHub page has a large number of open issues causing | ||
| community angst and misrepresenting the responsiveness of the project. | ||
|
|
||
| By closing stale issues, we can (in an automated way) refocus our | ||
| efforts on the ones that have at least one person interested in them. | ||
|
|
||
| # Detailed design | ||
| [design]: #detailed-design | ||
|
|
||
| 1. Use the [Stale](https://github.com/marketplace/stale) application | ||
| provided by GitHub on the [Nixpkgs | ||
| repository](https://github.com/NixOS/nixpkgs). | ||
| 2. Start by using the following `.github/stale.yml` configuration | ||
| file: | ||
|
|
||
| ``` | ||
| # Number of days of inactivity before an issue becomes stale | ||
| daysUntilStale: 60 | ||
|
There was a problem hiding this comment. I think this should be much higher, perhaps ~1 stable release of NixOS? There are a lot of useful issues older than 60 days! There was a problem hiding this comment. stale does not mean "not-useful" — neither does it mean "not valid"... It just reflects the fact that nobody has bothered interacting. There was a problem hiding this comment. I think it must be not less than 6 months. One year is even better. In this way, it'll help get rid of issues that can't be reproduced anymore, but also it'll not cause frustration of issue creator. |
||
| # Number of days of inactivity before a stale issue is closed | ||
| daysUntilClose: 7 | ||
|
There was a problem hiding this comment. I would prefer never. Let humans to decide. |
||
| # Issues with these labels will never be considered stale | ||
| exemptLabels: | ||
| # Label to use when marking an issue as stale | ||
| staleLabel: stale | ||
| # Comment to post when marking an issue as stale. Set to `false` to disable | ||
| markComment: > | ||
| This issue has been automatically marked as stale because it has not had | ||
| recent activity. It will be closed if no further activity occurs. Thank you | ||
| for your contributions. | ||
|
There was a problem hiding this comment. I think the framing here is very important to (1) don't make anyone feel like they're just a drag on the project, make clear that it's totally fine to just keep bumping an issue; (2) give constructive feedback on how to get attention for an issue, like actively searching for maintainers / previous people that touched the code and pinging them. There was a problem hiding this comment. I think this is a great point. Phrasing it as helping the user seems much more likely to turn out well. "It looks like this issue hasn't attracted much attention. Here are n suggestions for how to progress this issue further." |
||
| # Comment to post when closing a stale issue. Set to `false` to disable | ||
| closeComment: false | ||
| ``` | ||
|
|
||
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| People who want to keeps issues open will need to keep indicating | ||
| their interest. | ||
|
|
||
| Closing issues might make valueable contributions hard to find. | ||
|
|
||
| Marking issues stale might dissuade contributors who already feel | ||
| their contribution was being ignored. | ||
|
|
||
|
There was a problem hiding this comment. There are some security considerations to have to giving access to the org to a third-party application. I don't know what access rights the stale bot needs, hopefully just access to the issues. Alternatively it would also be possible to deploy https://probot.github.io/apps/stale/ ourselves. |
||
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| 1. Do nothing | ||
| 2. Make custom tooling to do something more sophisticated | ||
|
There was a problem hiding this comment. There is also a whole set of other bots in the same project that might better fit our needs: https://probot.github.io/apps/ |
||
|
|
||
| # Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| 1. Should we make use of the `exemptLabels` option? | ||
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.
It would be good to find metrics that better represent our project's health and communicate that instead. It seems quite natural to me that due to the size of nixpkgs we have many known problems that needs to be addressed.
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.
Yes, when I first came here, I remember being shocked by the numbers. But now they just seem realistic. We'd all like them to go down, but I feel like closing issues prematurely would cause more angst, not less. Imagine how it would feel when, in addition to having your issue "ignored", you then suffer the further indignity of having it closed by a bot!
It's already easy to get the impression that nobody cares about your issue or PR. Wouldn't closing outstanding issues would basically confirm that?
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 think it really depends on the bot's abilities. For example I am never annoyed by the existence of ofborg as it helps me move my PR along. Even when it was posting build results as comments, I was happy to get the notifications because it was an asynchronous prompt for me to react on the feedback.
Stale bots are less clear cut. It depends how precise their heuristics are. If implemented correctly I can see how it could prompt people to react and move the issue or PR along. But if they generate too much noise it can also lead to notification fatigue. It really depends on the implementation.
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.
Sure, I wouldn't be opposed to a kind of ping-bot. But I understood this RFC as being primarily about closing issues, with the bot being an implementation detail.
I actually wasn't thinking about the case where the submitter has not responded; in that case, I'm not opposed to automated closing if it's a "support ticket" kind of issue where others can't reproduce. That would help make the list of open issues more relevant, I think.
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.
Maybe it would be an option to only ask for a follow up if the last message is not from the submitter? This way the submitter would only have to say "no, this is still an issue" once and the bot won't bother them again until someone else asks for some followup.
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.
Either this, or maybe it would be possible to have the bot only trigger on
9.needs: reporter feedback?That said, my experience using codetriage is that the issues I click on usually would not fall under this label -- it's only maybe one in four or five. But it does happen that when I ping from triage to re-request the requested information, the reporter just states they've stopped using NixOS altogether, and then it's possible to close the ticket.
All that to say: I think a stale bot would make sense, but more for the “regularly poke people with a message to help them figure out how to push it forward” part of it and less for the “automatically close issues” part of it. If it's done this way, we should be careful to not have it poke too many issues on the first start, or maintainers would be overwhelmed by people directly reaching to them at once, though.
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.
Another scenario is when a PR gets stuck because the author and the reviewers don't agree on the outcome. In that case, if the bot is pinging, it's not bringing in new information that could help move the PR forward. If it's closing it favours the status quo over innovation.
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.
Not necessarily. If for example the bot links to a page containing as many suggestions as possible on how to move on in such situations (which in my opinion should be a part of this RFC), I would consider it very helpful.