Auto-closing inactive issues to shift focus towards important issues #48997
Replies: 11 comments 16 replies
-
|
cc @mburridge @bph |
Beta Was this translation helpful? Give feedback.
-
|
I approve of this strategy. Old and inactive issues clutter things up and a method is needed to close them otherwise they could linger around for years adding to "noise". If in a complete orbit of the Sun there's no activity in an issue then to me that's a good point at which to close them off. Of course the OP should be notified that this is happening and provided with a reason. In fact why not send them a month's notice that it will be closed offering them the opportunity to resuscitate the issue or close it themselves, then when the month has elapsed and nothing has been done it can be auto-closed. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly! And to add to this, it can have very positive side effects as well. E.g. having a lot of inactive/old issues can also demotivate people to leave new issues or contribute, or have a negative impact. What would be the next step if we want to move in this direction? Invite people to join the discussion? Create an issue? |
Beta Was this translation helpful? Give feedback.
-
|
Maybe a good initial step is to draw attention to this conversation over in #core-editor and get others to chime in with their opinions, both regarding the proposal and possible next steps. |
Beta Was this translation helpful? Give feedback.
-
|
I think doing this automatically is extremely disrespectful of the time of the issue filer. They've already spent time filing the issue, and now you're making it their responsibility to keep it open by replying to a robot every X months, which also clutters up the discussion and generates a bunch of unnecessary notifications for everyone involved. For instance: an existing bot continually tried to close #10235 for a period of time in addition to multiple contributors closing it without fully understanding the original ask. It was extremely irritating to experience and I wasn't even the author. In contrast, getting a message about an old issue from an actual person asking if it is still a problem instead of straight up closing it makes me feel like someone is actually paying attention and that it's worth continuing to file issues. A contributor with a reasonable understanding of the project can sweep through old issues and make a judgment call on whether or not it's worth asking "is this still a problem in the latest version?" If the answer is clearly "yes, still a problem" then they might also know of a tracking issue or other place to raise the profile of the issue and keep it from getting stale. tldr: This is a good idea, but it needs a person to do the job, not a robot. |
Beta Was this translation helpful? Give feedback.
-
|
@cbirdsong Thanks for the comment! I agree that there will be some issues where it can be annoying, but I also believe those will be exceptions in great minority. Last weekend I spend about 2-3 hours replying and closing old issues and without exception they were all ready to be closed. A lot even got solved in the meantime, but because no one gets reminded about them they just stayed open. Those 2-3 hours could've been spent doing PR's or responding to new tickets as well, something that can't be automated. If an issue has been open for 6 months e.g. and no one commented anymore, that might mean the issue needs a better explanation or checking if it's still an issue at all. With the scope of this project and the community growing everyday, I don't think it's sustainable to lean on people to do this kind of work, as we're already short on developers to keep up with all the issues. So yeah, I see where you're coming from and in an ideal world where we would have enough contributors I agree it would be favorable to have people do this, but I think we also need to be realistic and pragmatic here. |
Beta Was this translation helpful? Give feedback.
-
|
If it must be done, I'd start with an extremely long timeframe and slowly reduce that while keeping an eye out for false positives and/or annoying behaviors. You throw out a year as too long and that might be true, but is there a way to tell how many issues would immediately be affected by an automation before enabling it? |
Beta Was this translation helpful? Give feedback.
-
Good question and something I've been thinking about. I think we can solve this by maybe making an exception/whitelisting some issues depending on their label given by the current StaleBot. Another idea is to make a default message explaining about the inactivity bot, to add to all the inactive/stale issues. Just copy pasting that shouldn't take too long for the inactive ones. Just some ideas, but I'm sure there's a more solutions. And I agree on starting with a large timeframe and slowly moving up to find a good balance. |
Beta Was this translation helpful? Give feedback.
-
|
well, for me we need first to clean up the 940 open PRs !!! example : 77 PRs labelled as Bugs, and not merged aka 4 pages !! example : 807 are waiting for a review !!!! About the issues, if we close them, user can still reopen, no ?
It seems to be a true reasonnable solution. But the message should be polite, e.g. indicate that to ease clean up, we ask the author to declare if the issue is still accurate on current GB version. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly, we can shift the focus from administrative tasks to actually solving issues! |
Beta Was this translation helpful? Give feedback.
-
|
seems there is a housecleaning session to be launched on the Gutenberg repo !
@audrasjb made such an effort on trac recently, with dedicated triage sessions. Maybe something to consider. About the automatic closing, as i stated above, "the message should be polite, e.g. indicate that to ease clean up, we ask the author to declare if the issue is still accurate on current GB version, since the issue is older than xxxx months" |
Beta Was this translation helpful? Give feedback.
-
True, but if this system works well, it should bring those back to our attention instead of just letting them go stale and/or closing them. Closing is of course never deleting an issue, I'd see it as a "friendly reminder". "Hey, is this still something we need to look at?" |
Beta Was this translation helpful? Give feedback.
-
|
Linking up some previous discussion: https://make.wordpress.org/core/2021/01/14/stale-issues-in-gutenberg-repository/ |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
And here's a link to the issue that implemented the current stalebot: |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
The "Flaky tests" issues are the only ones closing automatically after 30 days of inactivity. Since those are created by GitHub action, they'll be reopened if the tests become flaky again. |
Beta Was this translation helpful? Give feedback.
-
|
good to know ! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @tomdevisser. Thanks for creating this proposal. I would love to collaborate on this since @Mamaduka and I have been running weekly Editor Bug Scrubs in #core-editor on Tuesdays at 14:00 UTC. Given the volume of issues/PRs, these meetings make only a small dent in the larger backlog, and improvements can definitely be made to our process. I remember the days when we had less than 4k issues fondly 😂 |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks @ndiego! Sounds great. I'm not sure what the next step should be from here and who makes the final decisions on these kind of discussions, but I'm open to call/discuss to brainstorm about it anytime! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all of your work recently. I've done a fair amount of triaging (a few hundred) and generally, more often than not, existing issues that have been open for >1 year and have had no activity are still applicable. As @cbirdsong mentioned; I would refrain from automatically closing issues that haven't seen activity. |
Beta Was this translation helpful? Give feedback.
-
|
+1 this. |
Beta Was this translation helpful? Give feedback.
-
|
Also string +1 with this |
Beta Was this translation helpful? Give feedback.
-
|
I personally would love to reduce the volume, as it has become difficult to do some every day tasks like searching for duplicate issues. In the past I've put a lot of effort into triage, but found it's hard to make a dent in the mountain of issues. As the project operates under the open source WordPress umbrella, my take on it is that Gutenberg follows some general practices for triage from other WordPress projects, and that has historically involved avoiding auto-closing issues. One aspect is there is often a transfer of tickets between Gutenberg and Core Trac to the appropriate bug tracker when they're created in the wrong place, and it might be unusual if Gutenberg suddenly had much stricter rules than Trac. That's to say it might require more buy-in than just Gutenberg contributors. There are a couple of past discussions on the topic that might be of interest: |
Beta Was this translation helpful? Give feedback.
-
|
The real problem seems to be the system that GitHub has setup. It puts very little responsibility on the issue creator to move the issue forward or confirm it's a continuing problem. In my opinion auto-closing an issue is not a removal, and shouldn't been seen as an issuing becoming less important. Every detail of the issue is still retained and searchable. If issues continue to come up and new issues are linked to old, patterns can start to emerge that can help solve the actual problem. Putting all the responsibility for maintaining an ever growing list of todos all on the contributors isn't fair to them. |
Beta Was this translation helpful? Give feedback.
-
|
YES, that's exactly my thoughts. We're not deleting everything, just closing until further notice, like a reminder. |
Beta Was this translation helpful? Give feedback.
-
|
This could easily be messaged when someone opens an issue.
|
Beta Was this translation helpful? Give feedback.
-
I just finished discussing an idea with @ryanwelcher about how we could make triage and issue management more efficient, and I would love to hear everyone's thoughts and if you deem this worth exploring. I asked him about how issues get prioritized and what the deciding factors are for adding an issue to a project/milestone, something that was also discussed briefly in one of the core editor meetings. The question why a lot of new issues are merged in earlier than really old ones, even if the old ones might be easier to fix. The answer turned out to be, it's mainly a thing of where the focus lies, and often that's not on older, inactive tickets.
The problem
Right now there's lots of open issues, including issues dating back to 4-5 years ago. This makes it hard to keep a bird's-eye view. Some haven't had activity in months, or are already solved/no longer relevant because of updates done in the meantime.
A proposed solution
A lot of support systems have a feature where issues (tickets) are closed when there's a certain period of inactivity (e.g. 1 month, but this could be any period of time suitable). The last few weeks I experimented by asking old-issue openers whether or not the issue was still relevant, and I got a LOT of issues closed that way. It was even so that in the last 20-30 issues I asked this, not a single one needed to stay open. I think there's a huge opportunity here to close a lot of issues and greatly improve focus on the ones that need it.
Some considerations
Ryan rightly mentioned that there are issues from non-developers, that could get annoyed if they keep opening issues that get closed without the deserved attention. This means we need to have some way for issue-openers to tell everyone the issue is still important. One solution for this might simply be, sending them an email saying "you're ticket has been closed due to inactivity, if you think this is still an issue, please re-open the issue". We could even suggest some people to tag so it gets the attention needed.
Just to emphasize, this would close issues based on being inactive/stale, not on being old. I understand some issues take time to solve, and might take months (or years), but in that case let's at least keep them active.
A month of inactivity is probably too short, a year probably too long, so we have to find a good balance on how long an issue has to be inactive in order to close it automatically. We could for example start at a year, and make it shorter when we think it's possible, until we find a good value.
Resources
One action we could use for closing these stale/inactive issues is this one: https://docs.github.com/en/github-ae@latest/actions/managing-issues-and-pull-requests/closing-inactive-issues
I would love to hear your thoughts on this!
Beta Was this translation helpful? Give feedback.
All reactions