GitHub stale bot considered harmful
drewdevault.com
drewdevault.com
This treatment of issue-as-a-task is made worse by corporate micromanagement frameworks like Agile, which encourage metrics on how many of these issues-as-tasks are closed, which leads to ill-advised features like this that close them automatically because "Duh, no one said anything in 30 days".
If I were to design this myself, I would argue that the correct way to treat an issue is not to have it have a closed or open state at all. If the issue spawns a task or related tasks, you can close those. Or you can provide feedback on the issue that states that it is invalid. The user has already experienced a problem or wants a feature, there is no value in putting a red label that indicates "I'm done with this, please go away". It unnecessarily invalidates the experience of users who have their provided valuable time to report something to your software project. I think this is similar to the approach used by forums like Discourse, where a thread about a problem will usually not be closed or locked, but will just age out of current discussion if nobody brings it up.
Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To.
It's not that it will ruin your relationships if you work with good people or vice versa but I've seen bad blood and insecurities exacetbated by the workflow that were unnecessary.
If you have good relationships with your colleagues/contributors, this will be reflected in the review process.
If you have a bad relationship, the process will be painful.
I don't think this is particularly a technology problem.
GitHub also allows "comments" for points which are suggestions, rather than requirements.
The same comment made in person while doing a code review wouldn't have nearly the same effect because the body language would convey additional meaning (e.g. this is an honest question, I'm not indirectly calling you stupid here).
This is often an inherent problem with internet forums which is why people often blow up on them over perceived slights, but there's many ways to mitigate this type of thing, e.g.
* low friction means of expressing appreciation
* some sort of low friction one-click polite programmed responses (e.g. X doesn't understand this area of the code, could you explain it?)
* something monitoring comments and suggesting rewordings
I don’t want this to sound trite or disingenuous, and I especially don’t want to assign blame (unless you know me personally, you probably won’t ever encounter an instance of my intentionally assigning blame to individuals), but short-form, semi-synchronous textual communication is just different, to the point that linguists extend the usual classification of discourse from spoken and written into spoken, written, and “IM-ish” (which turns out to be closer to spoken despite using writing). Not all modes of expression are immediately accessible to everybody (I’m constantly anxious over emails, which is tremendously inconvenient), and we should absolutely try and help people adjust, but to say that the mere requirement of adjusting is evidence of inferiority or evil nature is unfair to things that are just not the same as other things (insert UI/UX example here). This is not to say that there are no evil things, just that this particular argument for evilness is so weak as to be tautologically true for almost any thing at all (when I was a child, they would sell vegetables marked “zero cholesterol”).
I mean, “why did [they] do it like this” is one of the most harmless questions to ever exist as far as I can see (provided there’s enough context to figure out what “it” refers to and what “this” specifically is supposed to be surprising, so that it is not disproportionately low-effort or bad-faith obstructive, but that equally applies to spoken interaction). Literally most of my brain-time is devoted to answering questions of this type I ask myself, so when somebody else asks such a question it’s the most unsurprising thing I could imagine. I was similarly baffled when in a recent discussion someone suggested starting a sentence with “I might be wrong, but ...” is perceived as aggressive. How else am I supposed to communicate “I don’t feel competent in this particular area but on general principles I’m fairly sure that ...”, and in what world does warning people of the potential irrelevance of your opinion read as aggressive?
I’d be happy if it turned out I’m just not perceiving a subtlety of language (despite using English for most of my life, I am not and will never be a native speaker), but that’s not what people seem to be saying. A cultural disconnect sounds more plausible (cf. “ ’Splain it to me”), but again “people foreign to the culture can feel uncomfortable or misunderstand” is by itself not a sufficient argument for a change of culture, especially if that culture (chat or comment etiquette) is more or less inherent to the environment (short-form semi-synchronous communication).
[In case the gentle reader is wondering how this comment could ever count as “short-form communication”: I’m like this in person, too. Sigh.]
I'm pretty sure I could change the meaning of that sentence wildly using intonation and body language. I could certainly make it an offensive statement intended to undermine the listener.
One problem with textual discourse is that people just fill in the body language themselves. Often wrongly. Especially if they let their insecurities fill in the gaps. Which developers with imposter syndrome (i.e. most) will often do.
Emojis help fill in this gap somewhat for some kinds of written discourse (e.g. to intonate sarcasm, "only joking", etc) but on a PR i've never really seen them put to good use.
I think on a PR it might help if the user gets somewhat railroaded into a set of default replies that precisely convey what would otherwise be unstated feeling, emotiom and intent but I'm not totally sure that's how to fix the problem.
It also wouldnt stop wanton dicks from being dicks (not that i think that it's githubs job to fix that).
I do know it is a problem though and i dont think it's on githubs radar at all.
To be fair it used to be much worse before they had comments and every PR comment got treated as a FIXME.
That's a very standard phrase to signal you're not being confrontational. I don't know how they could perceive that as aggressive.
I'm not at all a fan of GH's PR UI*, but this is a very intense characterization. Could you expand on the flaws you see?
*I think it doesn't do its job of presenting information and letting me navigate the change very well.
Code-bases, especially large ones “Must Be Attended To” and reviews should be impersonal. A good review is inherently inspection and critiquing code, not the author and can present many good learning opportunities for both sides of it.
Good god no.
I'm, ironically enough, suggesting that misinterpretation of textual content is a bit of a problem :)
>reviews should be impersonal. A good review is inherently inspection and critiquing code, not the author
I can remember hundreds of times I've seen textual code reviews that were "just critiquing code" that were interpreted as a critique of the author.
It's particularly a problem when coders with slightly less social awareness than others write comments and don't pause to think how they might be interpreted. The example I gave in the comment above is just one of these.
That's why I'm so excited/hopeful about Github Discussions, that seems like it was a huge hole in the whole Github and finally being addressed. A place to ask questions, meta questions, show YOUR issues using the library, etc. just a place to have conversations around the library. So you can leave the Issues for bug reports/potential issues.
I closed the Issues tab in two of my most popular libraries because they just got low quality questions where devs were expecting me/others to basically fix their code/do their homework.
And yeah, the GP is calling for a forum. Bug reports, feature requests, and interface issues are a topic of discussion first, and a work item as a distant second.
There is some value in once you identify something as a bug to be fixed or an impromevent to be made, to tag the discussion saying if the work is in progress or done, and what release has it complete. None of those tags invalidate the discussion, and it's not realistic to expect all items to have a tag like this.
If you have 100 reports created in a month on a form, then it is very difficult to see what is triaged, who is working on what, and what still needs attention. The reporter wants something, which is by definition a task.
The simple reports get resolved quickly, so you post a message saying that it is resolved. In a form that is now the top message. Other team members are more and more likely to click on already resolved issues at the top, which may not obviously be resolved.
Eventually these resolved posts will age out and be paginated away, along with other non-resolved reports. The non-resolved reports are essentially closed by being stale. They have been aged out, and no one looks at old reports because they are mixed with things already actioned.
People will still search the form, just as they do tickets, which is the same either way.
First, I triage issues - this should be done relatively quickly (within a day is a good target), and should involve reviewing the issue, determining whether it represents a genuine bug, a misunderstanding, a missing feature, etc., tries to identify where the problem might be occurring, and provides any workarounds, etc. That should happen on every issue without exception.
Second is actually solving the issue, if it wasn't solved during triage. The 60 days can be useful here - as much as we all want to have bug free software, an issue that a single person encountered 60 days ago and hasn't been seen or reported by anyone since might just not be worth fixing or might not even exist anymore. Maybe it's unfair to users, but also keeping an issue open indefinitely can be equally unfair - if you're realistically not going to fix something, better that the user knows now.
There's for sure cases where a single report is actually about multiple bugs, but that's relatively rare and I'm happy treating that as the exception rather than the rule.
As you say, issues are bugs (which often need fixing ASAP), feature requests, general requests for help, etc. etc. It seem very hard to stop issues piling up to the point where you lose control out of them on any github project.
You can see examples of scoping here. "devops/create" etc, https://gitlab.com/gitlab-org/gitlab-docs/-/issues
That said, I guess it's got some value in that it forces someone to become a squeaky wheel by bumping an issue they want to get fixed?
> 10. User Protection
> You must not engage in activity that significantly harms other users. We will resolve disputes in favor of protecting users as a whole.
I can see a lot of arguments that GitHub could use to label any kind of automatic "bumpbot" bot/tool/service in widespread use as violating this clause. If I was more confident it wouldn't get ban-hammered and shutdown, I'd pop back open that folder of notes and get at it.
Making a completely automated bot certainly falls short of GitHub's acceptable use policy.
On second thought... maybe not. I could see it quickly becoming a battering ram that just annoys OSS devs. Ultimately, this isn't something users can't improve, it has to be the maintainer. Nagging OSS maintainers is how we wind up with incidents like left-pad. In the most extreme of circumstances, if a maintainer is hiding issues behind the stale bot, it could be interpreted as abandonment and a fork should be made.
Sometimes a bump is a "Hey, just incase you forgot" so automatically closing is just "Ok I forgot this, but who cares now" attitude.
Closing issues automatically is bad enough—I’ve long complained about the stale bot, seeking for it to be discontinued with prejudice as it’s only harmful, literally never helpful (as an issue tracker, that is—it may possibly help maintainers’ mental state because it can facilitate more effective ostrich imitation than just ignoring the issues as they pile up).
Then there’s the GitHub action that has largely supplanted it (and which is what’s actually in the screenshot), which doesn’t just close, but locks (no idea if it’s configurable). A bot to close issues I can understand, people have been copying this misfeature from other sorts of trackers (… where it’s also normally a misfeature) for a long time. But making it lock issues is an even stupider idea than closing, amplifying the problems of closing even further for no reason that I can imagine, and I am baffled that that ever got implemented at all. I think it’s indefensible, but I’m rather curious to hear a defence of it.
And it's mostly worthless because we know what we're doing - we know what will be worked on, what will be ignored. We just tag the issues that we'll work on and Stale Bot will skip these.
So now I don't close anything anymore and let users get mad at Stale Bot instead. It's a bit weird but the end result is the same.
... why should respect be something that needs to scale ? it's fine to admit that this kind of respect itself does not scale when you're a single OSS maintainer.
I’m not getting angry, per se, but more disappointed and concerned that the project might not have enough resources to make me feel comfortable using it in the way I intended. (The one I’m thinking of was a cross-cloud app that obviously got more love on AWS than GCP. I got the feeling from the staled bugs that GCP was the “red-headed stepchild”, so we phased that app out after the POC.)
I like the “bug reports are signals, not tasks” idea, though. As a user, I’ll keep that in mind and see if that helps change my gut reaction to the stalebot.
The problem is those bugs don't affect the right people to have them care about fixing them, so they'll just sit there open forever.
At least the stale bot would signal "as a community of developers, this issue doesn't have enough interest or priority to get fixed".
There's a far cry between disrespect and avoidance/minimization of challenging social interaction.
I think that's a pretty harsh take. At the end of the day issue trackers are a tool for maintainers to help manage the project/codebase and the details are largely up to them. Im sure some maintainers also use it as a tool for communicating with users, but I don't think it should be compulsory. At the same time, if I as a user of a project add a bug then I do that as a favour to the maintainer. I don't think you should necessarily expect something back from the maintainer (assuming we're talking about open source here, not some payed service with an SLA etc.)
People are weirdly entitled and feel like you really, really must fix the bug.
Often with no real actual datapoints or way to reproduce.
Still, auto-closing bots are annoying. But I see why people might want them
Unfortunately, most maintainers just don't have the time to handhold 5-10 users per day for there projects, not when that means they'd not have time for other things, like family, recreation, etc.
We have extremely limited time, it's an impossible task to manually handle the deluge of issues.
At least I'm not expecting this of anyone maintaining any Open Source, popular or not. (Thanks for your great Ansible work, BTW!).
But how is auto-closing after X days a solution to "manually handling a deluge of issues"? Would, for example, it not be a much simpler and logical workflow to read those issues which you will handle manually and ignore all the rest? Why do they need to be closed?
Likewise, why do they need to be open? Closed or open is just a state anyway, since the issue is still there.
The fact that it's closed at least makes it clear that we won't deal with that issue (why we won't is explained in the template when the user creates the issue). If it stays open, we also won't dealt with it, but it will give the wrong impression that we might, some day.
Closing does not send the same signal as flagging, tagging or simply ignoring. Closing implies finality. It implies it's gone; and in fact it will be gone from most searches.
Edit: to be clear: I don't mind someone closing my PR with a short explanation. Say "thanks for your Makefile, but since we have a lot of developers on Windows, we fear that switching to makefiles for our automation only adds to confusion. So I am closing this". this is very different from a bot coming in and closing such a PR. The latter signals to me "we are so overwhelmed that your help is not welcome so we sent a bot to keep you away from us. No-one even looked at the work you did for us. Now shut up"
Tagging something as "backlog", "someday" or "low-prio" is a far different signal than closed.
Maybe the root of the entire problem lies in the github-issues being too simple for large open source workflows. A lack or additional statuses, a lack of dimensions maybe. open/closed is one-dimensional, tags add a second dimension, and swimlanes when using GH projects a third. Maybe we need "read"/"ignored", or "team assignments" or such as additional dimension. Or maybe we need worked out templates for tagging-structures and workflows? (without it becoming another jira mess)
Because clearly there is a need for workflows on top of Github, as can be seen by people pulling in bots that clearly piss off a lot of other people.
This attitude is really the crux of it. Someone is working on a project, and has to argue - endlessly - with users who demand "respect" but don't contribute.
Quick tip to users:
The maintainers and bug tracker is generally not a support / training channel.
The quickest way to get respect is to help out.
every open source maintainer I know dreads the Issues UI, and only a few get anything useful out of it.
We have templates, clear explanations about what the issues are for (it's purely used as a bug tracker for us), we even say plainly that if your issue is a support or feature request, it's very likely to be ignored. But still, probably 90% of new issues are feature requests, support requests or duplicates.
We've also considered closing the bug tracker altogether but in the end we prefer to leave it open for the 10% of issues we actually want to hear about.
They haven't reached GitLab's focus on cramming in more features at the cost of maintainers' workflows yet.
I am not surprised many projects chose to automatically close inactive items. It's the epitome of "the squeaky wheel gets the grease".
But even when not already curating, what is effectively a simple rename could already prevent a lot of complaints: rather than automatically closing stale issues, you could either just have them tagged "Stale" and filter those out of your own view (if you prefer passively dealing with stale issues), or automatically tag all new issues as "Untriaged" and remove that tag if you want them to show up in your view (if you want more active curation).
Or do you mean some good bug reports are going to be missed because of this?
Because in general if an issue is even moderately important, we'll hear about it via multiple channels - the issue tracker, the forum, Discord, etc. so we'll eventually be aware of it and there will be a proper bug report on the issue tracker. Either we'll select a good one among the duplicates, or we'll create one.
I can assure you I'm personally mad at whoever set up stalebot, not the bot or the people behind the idea itself.
I have several high traffic repos, or repos that got very popular. The minute they're no longer manageable by myself, I've opened up the maintenance of the repository to more people than myself. If I stop showing up altogether in one of my repos I want it to keep breathing.
This problem is easily solvable WITHOUT stalebot for all kinds of repositories up to the hyper-popular (tens of thousands of issues), at which point, there are still better ways to triage than with a stalebot. (Early in my career I used to triage for Wine, Webkit and later Chromium. It was fun. Stalebots didn't exist and would have been a dumb idea then, still are now.)
This behavior, among other things, makes skimming through existing issues far less useful to anyone not actively working on the project. Which in turn leads to much worse new issue reports.
The way I handle it is essentially never setting up automatic thread locking, and then, default to closing the issue, unless I add some specific label.
This is mostly for my sanity. There's a lot of issues where you get an issue raised with "x doesn't work", with little to no information. Great, I can't do anything with that, so I push back, and often you don't hear anything back. At this point, I close it (or rather, stale bot does after inactivity). If the user then provides more information and the issue is triaged and valid, I add a label, which makes sure stale bot does not close the issue.
If an issue does get closed, I'll get a notification if someone ends up commenting, and I can take appropriate action. It also gives others the opportunity to comment if they can provide additional context.
As it stands, a few of my moderately popular repos get on average 5-10 new issues per day. One of them might have any relevance towards improving the project.
I don't see the same people who complain about stale bots volunteering to sit there babysitting issue queues closing irrelevant ones and responding to, essentially, free support requests.
Good bug discipline isn't new. It was understood at least 20 years ago and widely practiced with Bugzilla. GitHub and the types of users who go for it, though, seem to have a bent on organizational and operational regression. It's more important to chase self-actualization by doing things that feel productive because they keep you busy rather than thinking critically about how to actually be productive, apparently.
You essentially need to have a label ("needs user feedback") that isn't applied by default, have the stale bot only act on issues with that label, and get that label cleared automatically on any comment. I don't think that last part is doable without your own custom bot.
Edit: Someone below has suggested a way to roughly do this with tags; I'll have to try that.
I usually take the time to write well-written bug reports for any problems I spot. If my reports are closed as "stale" by this bot, that is a surefire way to get me to never report a single bug again and probably also to stop using the project altogether. It's demeaning because the bot is telling me that I wasted my time and that I shouldn't bother. Next to patches languishing for years, this is the absolutely most annoying "misfeature" of any free software project. Please stop!
Ticket overload may be a problem, but stale bots do not solve it.
There might be an issue like "I get an error message, and then the software crashes!", you ask "what error message? What version? What does the log say?", and you never get a response, and the issues gets burried and forgotten.
I'm having trouble imagining it. My brain keeps telling me that the words I would search for would show up in the content even if they're used in a template. Is it maybe an issue of synonyms. Like error and exception might mean the same to one person and not another?
The problem is that as soon as the template contains the word you’re searching for, every issue matches your search.
Thats exactly how I read the description of the original problem. The issue template says something like "What text appears in the 'Current Status' pop-up?", and so then it becomes difficult to search for issues related to the "Current Status" pop-up not appearing at all, because searching for it will return all issues.
This also highlights another crucial difference in Bugzilla: it keeps track of not just open/closed state, but also the reason: fixed, can’t reproduce, won’t fix, incomplete… whereas stale bots are a single awful blunt instrument that seem like they might help with closing incomplete bug reports, but in practice they do much more closing of real stuff, annoying of reporters, shoving of stuff under the carpet, &c.
What the stale bots lack is nuance, because GitHub Issues is too generic to support a good triage bot that isn’t deeply specialised to a project.
And even if you have a decent triage bot, there is no substitute for manual triage. It doesn’t need to take very long.
In my experience, in many projects the issue does stay in that state indefinitely, even after the reporter provides the info. The reporter doesn't have permissions to remove the label; the people who do have the permissions miss the notification and never do the manual triage you mention. They might as well just close anything that doesn't have enough information or (depending on your perspective) that they don't understand/care to understand.
(For example: I filed an issue a couple months ago in which I explained the problem I was having, pointed out it contradicted the documentation, then proposed a solution. Then I opened a PR with the solution and explained it within the documentation and the commit message. Then I got asked a question in a PR comment that was answered in all three of those other places. I replied (explaining it in a fourth place), but the PR still has the "needs-reporter-feedback ?" label and isn't going anywhere.)
Maybe the most useful thing a bot could do is remove this label after the next comment... or maybe it's just hopeless if a project doesn't care enough about their issues.
Like. What. The conversation is not over, you’re wrong, now I have to open a new issue.
I'm looking at you VSCode.
Just tag them "unpopular" if it makes you feel better.
I personally wish issues weren't auto-closed as it can give the wrong (i.e. feature is dead) impression, however I know popular OSS maintainers get a TON of issue requests and are doing a work of love.
So, thank you OSS maintainers, you the real MVP.
P.S. For those interested, the issue[1] is NVMe performance for OpenZFS[2]
Issues do get stale: maybe the problem has been solved in the meantime or is no longer relevant, in which case you close the issue, and if the problem is still there, it's nice to have a reminder.
But I can't be bothered anymore. Sucks for the people who won't realize there's - sometimes quite important - things wrong with these projects.
Handling and communicating well is an important aspect of quality in software development land and if a project is using such a bot it's probably falling short on that front. Bonus points if they have like 1.7k open issues anyways, lots of them duplicates of automatically closed ones.
Instead, should that read...? <<Disclaimer: I own a GitHub competitor.>>
For other readers, Drew is the founder / owner of SourceHut (https://sr.ht/, https://sourcehut.org/), and he is an excellent blogger!
Please correct if I am wrong about Drew's role as founder / owner.
If nobody is attending a given issue, definitionally it doesn't have an economic value: nobody deemed the issue/task worth solving OR paying for it. It might be annoying, but not sufficiently annoying to take action.
It doesn't block your business, workflow, productivity etc; if it was, you'd be personally involved in solving the issue in some or other way.
Open-ended projects may have design/feature request issues, but those should be distinct from bug reports. And those design/feature request issues are exactly the kind that most require human interaction, to decide whether something should be part of the program.
> Bugs will be a permanent condition of the project
Bugs are a fact of life for any developing software. Any particular bug is not. Closing an issue is a statement about that particular bug being fixed. Auto-closing an issue due to staleness is a lie that the bug has been fixed.
That said, if there's an automated reproducible test case for the bug, then it could be closed when that reproducible test case passes. If a seemingly unrelated change resolves the issue, and that can be verified, then it would be acceptable to auto-close the issue as a result.
> so some bugs might be not deemed relevant, ever. Auto-closing helps here.
There's a big difference between "not deemed relevant" and "deemed not relevant". The former is when you have an issue that sits open for some time, and sure, that might not be relevant right now, but could be important later. The latter is an active decision that something is irrelevant and never will be relevant. That's the message received from an issue being closed, which is a far more aggressive message.
Auto-closing delivers this aggressive message, throwing away the work somebody has done in reporting the issue, without even so much as an acknowledgement.
> if it was, you'd be personally involved in solving the issue in some or other way.
Reporting an issue is being personally involved in solving it. Writing a solid issue, clearly documenting how to reproduce, expected behavior, observed behavior, why the expected behavior would be closer aligned with other behavior in the program, etc, takes time and effort.
In my experience, the number one problem I see on github / gitlab projects, is the maintainers not being able to or willing to allow others help them. Volunteering to triage issues, review code, etc. is very often meant with silence or reservations, even on projects that are specifically asking for help.
Maintainers want help but they are very untrustworthy of those who wish to help them. That's completely understandable. The work is their baby and they want control over it. The internet is full of people who are untrustworthy. But this is a huge problem and there are a ton of open source projects that die as a result.
The tools offered do not provide a good solution for this ownership problem, but they are all that is offered, so things like stale bot are used to try to reduce the load on the maintainers, which ends up making the problem worse, not better.
There are some projects that don't run into these issues, at least not to the same degree. Those projects almost always have a high degree of collaboration between maintainers and contributors. It usually feels more like a collective than a maintainer/user relationship.
Resolved - issue has been fixed/addressed
Won’t Resolve - addressing the issue is not aligned with the direction of the project; it is not and will not be resolved
Paused - issue is valid but no one is continuing to discuss it, explore it, or work on it at this time; someone can resume the issue if they have new data or ideas.
Maybe issues aren’t just “tasks” but they’re part of your work, and you need some tools to prioritize your work and help communicate to yourself and others what you’re focusing on and what state things are in.
Many large repositories use labels to show the state of the issue. You do not need to rely on open or closed.
This mentality is what prevents me from open sourcing most of my for-fun projects. The fact that there is people that as soon as I publish my code in Github, and someone finds it useful, they will put me as "responsible" for fixing whatever bug is affecting someone else.
In my view, if I were to open source some of my code, it will be on an "as is" basis. If someone gets my code and burns his house, it is not my problem. I do my code to scratch my own itches, and don't really agree with catering to some 3rd party entitlement over some free text I share on the internet.
It’s when authors try to eat their cake and have it too that I have a problem; i.e. when authors want the fame and renown of being seen as responsible for widely-used software without doing the maintenance work necessary, then I have a problem.
Personally, I find stale bots are refreshing in their honesty about what people actually have capacity and willingness to chase down and solve. They definitely can improve life for maintainers by turning an issues list into a manageable workflow.
After all, an issue that has people who care about it enough to comment isn't stale at all. Issues which are truly stale deserve to get a ping from the stale bot: "Is this issue still relevant? If I don't see anyone comment then I will close this issue in 7 days". Then after 7 days of inactivity the issue should be closed.
Why do this? Because it enables prioritisation. Fixing every single issue is unrealistic and something that might have been a pain to someone in the past they may no longer care about.
The most problematic part is that the older issues become irrelevant over time, in part because the system changed too much and they don't apply anymore or because the people originally asking aren't interested anymore in the answer. If you just accumulate old issues it becomes hard to find still relevant issues in this whole pile.
I don't think closing based on time is always a bad idea, but you should have a good mechanism to save issues that are relevant from the bot. In the end you always need some minimal triage on issues to keep them usable.
The idea is if it's been closed that long, a new issue should be filed so you get the context refreshed, and any patch for the original problem would also (most likely) have been in a release already, so it deserves a new issue so we can e.g. link to it in the release notes.
The closing part is all manual, tho.
In a well-run project, the bugtracker is part of the project's digital memory. This means that the appropriate thing is to cross-link the new bug and the old bug. Not doing so—or being unable to do so because the original bug was locked—makes triage and archaeology needlessly difficult. Say hello to selection pressure: you drive away the most valuable collaborators and are left with the ones that you're spending all your time trying to protect yourself against.
The problem is that there's no way to say to stalebot "this issue won't magically be fixed by time, I'm not going to comment here every 3 months to keep it open".
That's not better.
> I’m not sure what motivates maintainers to install this on their repository
You can always browse closed issues. The fact that issue is closed means absolutely nothing to the promoted methodology.
The point of closed bug is one among the not confirmed, not affecting too many users, hard to fix, unable to fix, no time to fix, no interest in fixing it, higher priority fixes piled up etc...
Staleness is also meaningful on its own.
Let me repeat - Nonsence.
It absolutely isn’t. Look at Mozilla’s bugzilla instead: You’ll find plenty of bugs open for years and eventually fixed.
Plus, stale bots don’t take Reactions into consideration. Spend a week on a popular repo and you’ll find a bunch of issues with dozens of “+1” reactions and that are closed as stale. Just because no one is working on a bug it doesn’t mean it doesn’t exist.
Heck I regularly see maintainer themselves fighting the stale bot over the months. It’s hilarious to see because they do it to themselves.
- closed because stale
- reopened
- closed because stale
- reopened
So? Its still stale issue. Stale issue get fixes some times, but most of the time they don't. So its a metric. If you need good examples, Redmine is probably greatest example as in any major release they have something that lived 10+ years as a ticket.
>Plus, stale bots don’t take Reactions into consideration.
That is not true. As soon as somebody comments on my Github repo after the bot announce that issue is going to be closed soon, it resets the period to 6mo again. So this is configuration setting. I have not seen so far that somebody says something else except equivalent of "its still not resolved" just to reset the period. So now I have tickets with that last couple of years with last several comments that it is not resolved :S. Totally meaningless.
> Just because no one is working on a bug it doesn’t mean it doesn’t exist.
Just because ticket is closed it doesn't mean bug is resolved. I usually have some form of meta label like resultion-wontfix, resolution-done, resolution-stale...
> It’s hilarious to see because they do it to themselves.
Its because they didn't get it. When you repeat the same meaningless thing over and over you should question the methodology.
Yet another way to mangle your issue tracker into uselessness. At least this one is manual (for now).
Often times even close issues have fruitful conversation after the closure.
Locking should only happen in extreme circumstances, like if the discussion gets heated and people are personally attacking others.
That option is certainly valuable in some context, but not in general.
That really depends on the community. I always search both closed and open and comment on closed issues if I find there is more to say.
It's not like project owners can't still see / search / work on closed tasks. They could still maintain data elsewhere about tasks which didn't get priority, or with a click or two see every stale issue that was closed..
I used to work on OSS health, and feel very strongly it's much worse (for most projects) to have hundreds/thousands of open issues stretching years.
That is not how human relations work. If you give away free lemonade on you driveway it has to be drinkable. The "not fit for any particular purpose" is legaleaze BS and everyone knows it.
Of course there has to be rim and reason. And any project can be marked as "abandoned" or whatever, etc. But a FOSS project do owe the users honesty, or being called out for it.
As for the bot, this is grown of "all tasks must be completed" "Inbox zero" type of thinking. Feels like we're holding issues wrong, but that is my view.
There are tons of projects/scripts/junk I've put online that do a thing, or have done a thing, and putting it out there might be useful for someone. You will likely need to know something to use it, if not, it's not up to me to handhold you. I'm not going to go dig deep on some module I wrote for ImageJ eight years ago to solve someone's problem. It did work for me, and it's up to you to figure out if it works for you. I don't like your line of thinking because it adds a burden to publishing, "What happens if it burns down someone's house or dog?!"
FOSS projects owe users NOTHING, you are free to do whatever you want. If it's useful to you, great. If you have a problem, it is your problem! Don't like it? Fork it. You can run your own version. Griping at someone on their issue tracker because it doesn't do a thing you want is what causes burnout and conflict. We're all people, so try to see it from their perspective as well.
In my view, there is no such thing as abandoned software in open source. This is a contrivance of the latest hot framework js world.
> Software is not lemonade. > "What happens if it burns down someone's house or dog?!"
I meant lemonade as an analogy on human relations.
I would say a FOSS dog house sprinkler system project would "owe the users" to not ignore bugs - or close the project.
But that would be an extreme example. I Boeing crashes planes because of a 7Zip lib bug, it is not the 7Zip maintainers fault. Or e.g. more realistically, Linus Torvalds' fault.
The only candidate for such a system is probably Driver.ai or what ever they are called, who are mighty irresponsible in their open source approach ...
There is no guarantee of any relationship. You are searching the internet junk pile for artifacts that help you accomplish some goal. Your expertise helps you make this decision. If you do not have the expertise, tough shit. Use the internet and figure it out.
You could go slam them in your forum of choice, that's up to you. "Project being bad" "Complain and whine" Cmon man. I have written a ton of scientific code, some published some not, and I love helping my users. I am also glad it is very old and not in a project anyone that would "complain and whine about my project being bad to warn others".
No one asked you for a Yelp review. No one owes you a bug fix, emojis, or likes or whatever. "owe the users" "Or close the project." No no no. It is up to the user to figure out "Does this work for me." There is ZERO burden on someone who chooses to share their project.
Why is it everyone equivocates plane crashes with software bugs?! Yes! If Boeing decides to gamble lives on an open source project from the internet (!!) without vetting/testing the code they deserve everything they get! The FAA would love that story I'm sure.
It is up to the user (hopefully a developer!) to decide what works and what doesn't. This is consumerist thinking otherwise.
Would that be comma.ai? Again, caveat emptor, if you choose to drive your car with an android phone (this is 100% a conscious choice) and it drives into a house, it sounds like you're in a load of trouble! Hope you have insurance when you get sued into oblivion.
Sorry for the rant here, but I do think this kind of issue bombing / crapping on people's contributions and sharing is degrading a model of open source I particularly enjoy which is casually sharing your work hoping that someone might find a use for it.
Example: Ryan Geiss' milkdrop timer code has powered more science than you can know in my lab who insisted on using Windows to control a bunch of lab hardware. Bugs are my own.
http://www.geisswerks.com/ryan/FAQS/timing.html
That's right, I cribbed a high resolution timer from an mp3 audio visualizer to drive experiments that cost real taxpayer money in my lab. Am I going to go tell Ryan Geiss he is an idiot for sharing this when my experiment fails? Nope.
The idea that maintainers owe nothing to reporters but reporters owe maintainers to deal with the bots, repeatedly, possibly forever, is such a weird take.