“Inactive” workflow: bump operations to 175 #25938
Conversation
|
Semi-OT: I believe the process logic is flawed. Do core devs systematically check the items marked “inactive”? At least I don’t. If there is no check, the whole mechanism becomes an almost automatic close. For PRs this might be okish. But for issues it is not. I think we need an active decision to “close as not planned”. This needs a core dev review, who then should actively close. If that does not happen, the issue should remain “inactive” - which is really the logical state: nobody has taken a decision what to do. This is distinctly different from “closed as not planned”. IMHO we can and should live with the imperfection that we have issues in an unclear state, and we should be explicit and transparent about that. IMHO Bumping the inactive rate in the current process only leads to a faster auto-close of issues. |
|
I think some core devs have been checking through the "inactive" items. Also, any user or contributor who is interested in a particular issue should be subscribed to it and will be notified when the bot makes its comment. They can then leave a comment, which results in the label being removed on the next run. We can also filter issues that were closed as inactive if we want to retrospectively review what has been closed. Edit: since the bot closes things as “not planned”, all the issues here showing as “closed as completed” must have been closed by a core dev or the original author. |
|
I had the same concern, but the majority were thinking that it should work like that. |
|
There are two parts to this Semantics of closedIn my eyes “closed” means: There is nothing left to be done on the topic. Either because it’s resolved, or because we don‘t want this or can‘t fix it. IMHO an unresolved bug or something we have not come to a conclusion about should not closed. If I search for a strange/buggy behavior, I‘d expect related issues to be open. Related issues should only be closed if the behavior is intended . One could take the standpoint that „ closed“ is: We don’t plan to work on this topic. IMHO this is not quite helpful and slightly diffuse. Anybody could take that up anytime again. In practice, I assue we reduce the likelyhood of being picked up again through the "closed" flag. Clear communication of actionability
|
|
A bunch of issues have been closed since I opened this, so perhaps it was premature anyway. |
|
Case in point: #9957 (comment) |
|
#9957 is a good example, but clearly we take different lessons from it. There are two external libraries that provide the functionality, but in 6 years no one has acted on the issue. No one has given it a thumbs up, or had further follow up comments. Now, under threat of closure, someone has said "keep" and some discussion has ensued. To me the system is working better than passively keeping the issue around and ignoring it. |
Very much so!
This is not an easy task. Limited knowledge for new contributors a lack of time for core devs may very well explain non-action even for fundamentally desired functionality.
I fundamentally disagree. I feel pressured by this system. I'm constantly worried that it will close things that should be kept open, but nobody got around to look at it. I see "inactive" labels popping up and feel pressured to look at them. But I don't have the time, so I start keeping a list of inactive issues that I should have a look at. Then, issues get auto-closed without active feedback. Again I start to make a list "auto-closed issues that should be checked whether we should still keep this". I see the open issues as a valuable asset. It records ideas, plans and discussions. If we "closed as not planned", we effectively reject these. It's a much higher barrier to speak up for or even start working on something that is "closed as not planned", compared to "open and inactive". We should face the fact, that we don't have the resources to judge what should be done with every open issue. (And if we had, that time could be spend more productively). But the honest and transparent way of dealing with them is to leave them in an undecided state ("inactive" - nobody has worked on this for a while). Let's for now keep "inactive and open" as a permanent state so that anybody can go through them and explicitly "keep" or "close" in their own time. |
|
I understand where you are coming from. However, this procedure allows a lot of time for feedback from all involved parties. If anyone comments on the issue, the timer is reset for another year, so that gives the user base a chance to chime in. And of course the maintainers get a ping. We have had quite a few of these where people have indeed chimed in and we have set to "keep". If no one bothered to give a final answer after 6 years, and then when pinged no one bothers to advocate for the issue, whether it is "valid" or not is besides the point - its clearly a low priority. We decided to do this for a while, but if it's not working for folks we can reevaluate. Please request an add to the agenda if you'd like to redisucss. |
For the original posters yes. Not for core devs when multiple of them come in per day.
The only thing we can deduce from that is that the original posters are not interested anymore, which is not too surprising. People move on. The point is that by closing we discourage any new people looking at the topic.
Will/might do. This matters a lot to me. Unfortunately, it's currently hard for me to plan whether I'll be able to join the dev call. |
|
I had not noticed before, but the action has the option to add a label of our choice when it automatically closes things. That would make it significantly easier to review closed items after the fact. Would it help? @timhoffm @oscargus |
|
Setting a dedicated label would help making the closing reason more explicit. Currently one has to filter Setting a label "closed-due-to-inactivity" or "inactive->closed" (better name welcome) is an improvement. We still have the problem of discoverability. If somebody wants feature X, they will check the issues page, which by default only lists the open issues. Likely only a small fraction would switch to the closed issues to go through them and see whether their feature is listed in there so that they can revive the closed issue. Side note: We have a lot of "status: ..." labels. Should "keep" and "inactive" be part of that? I also noted we have a "status: inactive" label. |
|
OK I opened #25999 to add the label.
I also noticed that when I set up the bot-related labels. At the time it was only on six open items, and now only four. It doesn't seem like we're really using it any more. |
|
I can report that so far 93 issues have been closed by the bot Detailsfrom github import Github
# Set up personal access token
# https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/
# creating-a-personal-access-token#creating-a-personal-access-token-classic
token =
g = Github(token)
repo = g.get_repo("matplotlib/matplotlib")
issues = repo.get_issues(state="closed", labels=["inactive"])
bot_closed_issues = []
for issue in issues:
if issue.closed_by.login == "github-actions[bot]":
print(issue.number)
bot_closed_issues.append(issue.number)
print("Number of bot-closed issues:", len(bot_closed_issues)) |
|
The label makes the process now transparent, which is a good thing. Personal opinion on the overall process: I do not have the time to read through multiple stalled discussions a day (and that they're stalled often means there is some decision pending or open things to be done. So they need careful reading and thinking effort). I've therefore decided to largely ignore the "inactive" and "closed as inactive" notifications. Cleaning up the backlog has its value, and there are good things coming back in individual cases. But overall I believe that the limited time I can give (and in general that we as a project have) can be spend more productively than sorting out topics that nobody has been interested in recently. If others are happy with the current process, I can live alongside that. However, if you want to do better in cleaning up, I suggest to apply this process only to PRs first. PRs are typically in a state that can be decided more clearly. We can often either move the suggested code forward (maybe just some small parts misssing) or we can decide that the suggested code is not helpful anymore because the codebase has evolved too far underneath. Also, there are only 350 PRs compared to 1300 issues, so that one can bring the open PRs down much more quickly compared to the open issues. On another side-note: Even more important than cleaning up old PRs is responding to new and active PRs timely. For 5 of the most recently active 11 PRs that are not by core contributors, the next action would be on our side:
We should have a focus on moving them along so that they don't get inactive as well. |
|
When I first suggested this bot, I was actually thinking more of PRs than issues because (as a new core dev) I was struggling to sift through and figure out which of the open PRs I could usefully do something about. It's flagged mostly issues so far because it goes through from oldest to newest and our issue backlog is older than our PR backlog. It is an option to only run it for PRs if we wanted to do that, although
When we first switched it on we had nearly 1600 open issues so a lot have been closed by a fix or an active decision (won't-fix or duplicate), which seems worth doing to me. Having said that, we clearly don't want the process to be causing anyone stress/worry. |
|
We discussed this on the call today, and the consensus was to keep the bot closing issues, but reduce its frequency. Can still be revisited, if that is still not working for folks. I think the plan was to change to every other day, so at least folks have a couple of days to dig through the new crop each day. Could also reduce the number of actions assigned to the bot |
|
Since we decided the bot definitely shouldn’t go any faster, I’ll close this PR. |
PR summary
The “inactive” workflow isn’t getting through so many issues at the moment. There are currently 67 issues and PRs with the label and the action uses up two operations checking each of these. It also uses up three operations downloading the three batches of issues. With a limit of 150, this only leaves 13 operations for actioning new stuff. Adding a new label uses four operations.
So I think it’s worth increasing the operations limit again.
PR checklist