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.
Exactly. If you want to improve quality of reports, GH now let's projects even ask some questions before opening an issue, to redirect users to the proper channel. And if the proper channel is an issue, there is the ISSUE.md template that has been working for several years already now.
I only know the issue templates with the chooser.
Can you point me to the feature you referred to with „GH now let's projects even ask some questions before opening an issue“?
Contrarian view: I hate issue templates (at least as implemented) because they utterly cripple search for any word that appears in the template (and I’ve had this bite me more than once or twice). Most of the stuff people use templates for should instead be instructions outside the box, but GitHub doesn’t support that. If you’re going to follow the “big blob of text” model rather than having separate fields for much of the metadata, then your goal should be to have as little text as possible in any template, and avoid any words that people might want to search on.
Could you provide an example of the problem you describe?
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?
Sorry, it’s a year or so since it last happened (I haven’t been interacting with projects with heavy templates so recently) and I can’t remember any of them off the top of my head. One that I recall (but not the project or word) was a fairly common English word with two senses where I would have expected one or two false positives only, another was something more along the lines of “Versions (`uname -a`, `mylangc --version`, `mylangpkg --version`):” making “mylangpkg” unsearchable (in cases like this, disciplined use of labels can mitigate the damage).
The problem is that as soon as the template contains the word you’re searching for, every issue matches your search.
> 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.
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.
Bugzilla’s approach: in your “what error message?” comment, you also set the needsinfo?(reporter@example.com) flag (a single checkbox does it), and it can stay in that state indefinitely. This is then readily searchable, so that when you get round to doing another batch of manual triage you can quickly close it as incomplete, or try to follow it up, or whatever you like.
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.
This kind of workflow can be achieved with GitHub or GitLab issues by using labels. For instance, I often add a waiting-on-reporter label when asking for more info.
> Bugzilla’s approach: in your “what error message?” comment, you also set the needsinfo?(reporter@example.com) flag (a single checkbox does it), and it can stay in that state indefinitely.
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.
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.
I agree, this is incredibly frustrating. Sometimes it's hard enough to even get developers to reopen issues closed for inactivity, if they're locked it's even worse. I often don't even bother trying to open a new issue for the same thing unless it's critical, I just leave in frustration.
In my experience, these auto-closing bots are the natural result of software development workflows that treat issues as tasks to be closed, rather than a data point that a user is experiencing a problem of some kind (maybe they are doing things wrong, expecting something the project doesn't provide, or triggering a real problem – the exact cause is immaterial).
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.
If its point is really consumer discussion with authors (I don't think it is) then Issues is a pretty terrible name for it. Given the overall quality of GitHub in literally every other aspect of the product, I find that unlikely.
Yes, I think this is it. It all might have been started as "bugs" or "Issues" but over time, the functionality was extended to have feature requests, different discussions, etc. I don't have an alternative name for this, Notes maybe? But Issues sounds more severe than what it usually is.
It's ironic that github sold itself as "social coding" coz while the design was pretty and the usability is good the social aspects are almost programmed to bring the worst out in people.
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.
> Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To.
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.
One example I was thinking of was a comment where one coworker left a comment that said "why did you do it like this?". The other coworker took offense at the remark.
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
* actually adjusting to textual modes of communication?
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 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).
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.
> I was similarly baffled when in a recent discussion someone suggested starting a sentence with “I might be wrong, but ...” is perceived as aggressive.
That's a very standard phrase to signal you're not being confrontational. I don't know how they could perceive that as aggressive.
> Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To.
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.
Are suggesting that code review is a net negative or that having a visual interface for reviewing a patch set brings out worse in people than emailing around patchsets?
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.
>Are suggesting that code review is a net negative
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.
As a OSS author, the problem is that other developers also treat issues as tasks. If you look at anywhere or any kind of rubric that tries to measure the "health" of a repository, things like the number or lifetime of issues play an important role. Even npm shows publicly (open) "Issues" and "Pull Requests". Well, if my project is working as intended, I like that people look at it and see the "Issues" count to be as close to 0 as possible.
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.
Maybe I'm different, but if the repo has some dozens of issues open, I take it as a sign of health. It means people are using it enough to find problems or ask for more features. If there's no issues, it tends to mean I'm treading on new, untested (or at least less tested) ground.
A few dozen issues is one thing, but lots of the major OSS projects have thousands of open issues at any given time. If people think that each open issue is an unfixed bug or missing feature, then thousands of issues would mean that the project is at best unreliable and at worst fundamentally broken or dead. Except most of those issues are from users who should be asking questions on stack overflow.
An another OSS author, I am glad that you think that way (and I agree with you) but unfortunately not all users think that way. I have literally heard stories from users who think that my project is unstable because it had a sizable open issues count (~200). They didn't even look at the fact that 1/3rd are feature requests.
That's why there shouldn't be any "open" or "closed" state.
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.
I'm not sure you're implementation would actually be useful, and effectively you are doing the same thing as stalebot, just in a less obvious way.
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.
I think it's possible to work this way while still having single issues - I usually like to do a two phase resolution of an issue.
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.
Or, what usually happens, is someone like me runs into the bug. I search the issues and find it closed. I consider the maintainer incompetent because the issue was reported and either fixed, but they obviously don’t have regression testing, or the don’t care about actually fixing bugs. Either way, I will probably seek out a different project if I can. If the issue is open, even for years, that’s totally different and understandable.
Does the stalebot check for recent reactions (thumbs up, etc) or just comments? I think it’s the latter, meaning it is closing issues others may have and know that “me too” replies are frowned upon.
I wish github made it easier to seperate issues into different tabs -- while I can tag issues, by default you click on the 'issues' tab and see 100 (or 1000) issues, sorted by date.
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.
I never had to use Github professionally until the last 2 years and it's horrible for anything but basic projects. Gitlab has "scoped" labels, for instance "db:mysql" or "mysql:bugfix" "mysql:performance", maybe one day Github will copy that or come up with something unique on their own but with the way github actions is going I don't see it happening.
It's not perfect, but the GitHub CLI might help you with this. You can list issues filted by tags and potentially use your own tagging conventions to construct useful views.
Completely agree with Drew here. Nothing pisses me off more than seeing an issue I care about or raised closed because it was "inactive". Just why? If issues went away by themselves we'd all be out of jobs. All these bots do is piss off the consumers and make your life harder by losing discussions. They also waste the time of those who put a lot of effort into their report to be helpful, encouraging lazy spam issues to be created in their place. GitHub should remove this disgraceful bot.
I was going to ... In fact I just did a bunch of research for half an hour. I picked a language, hosting, UI tools, looked up the API calls and worked out how to do most of the mechanical process behind the scenes. Despite being a decent idea and a product I'd 100% use myself, I'm not sure I should do any more work on the idea due to GitHub's Acceptable Use Policy...
> 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.
I was considering making a browser plugin to have a one-click button to comment "this issue is not going away by itself, please read it before you decide it's stale" or similar. Now that ddevault wrote this it might be a good resource to put in there.
Making a completely automated bot certainly falls short of GitHub's acceptable use policy.
My first thought: Maybe include a link to the ddvault post in the template?
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.
Kind of, yeah. People get emails and notifications for you to say "+1", which can be pretty annoying. It's the equivalent of writing "this" instead of just upvoting on HN.
Can concur. I submitted a couple of pull requests that fix bugs. I addressed all the issues the maintainer pointed out, and then the maintainer went silent for 2 months. Every 2 weeks I spammed the thread in order to chase away the auto-close bot.
Realistically, for a lot of projects, if it's open for 60 days without activity it's not ever getting fixed. If anything, things like stalebot make the issues list match the reality of the situation more closely.
That's not true, sometimes issues get seen from notifications, not answered right away, then not revisited because it was forgotten. I've done this a few times.
Sometimes a bump is a "Hey, just incase you forgot" so automatically closing is just "Ok I forgot this, but who cares now" attitude.
A lot of issues that ask for breaking backwards compatibility are usually going to be "treated in the next version". I'm glad most projects don't put out new incompatible versions every 60 days. The issue could stay here for a few years, to serve as a source of information and a reminder. Milestone: 2.0 is usually a good way to indicate that.
Devil's advocate: some projects are extremely open-ended and will always have issues, hundreds of them. Bugs will be a permanent condition of the project so some bugs might be not deemed relevant, ever. Auto-closing helps here.
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.
> Devil's advocate: some projects are extremely open-ended and will always have issues, hundreds of them.
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.
I rely a lot on stale bot actually, simply because I don't like closing issues. When you do that, users sometimes get upset and you have to explain that this is not a bug, or it's a duplicate of another bug, or that we use GitHub issues as a bug tracker, not for support, etc. Then the user might argue that it's not exactly the same bug, or that we should leave it open for reason x or y. It's a time consuming process that needs to be repeated very often when you manually close bugs.
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.
If you define "respect" as personally responding to every user request, on a product used by thousands of people, then your definition of respect just doesn't scale.
> then your definition of respect just doesn't scale.
... 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.
It’s quite discouraging to stumble upon a well-written bug report that matches exactly an issue I’m having and see that it’s been “sent away”.
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.
Welcome to open source. Even projects that don't use the stale bot and let open issues rot forever "don't have enough resources". Case in point, look at projects like Drupal, with tens of thousands of open issues, a large portion of which are verifiable bugs.
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".
> It doesn't sound like you respect your users at all.
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.)
And there are a ton of non-bug issues that people feel entitled to your time (as a maintainer) to respond to and help them. Often for many, many comments.
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.
I don't think people are saying you should 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.
To me, closing sends a clear signal. I know it is not "deleted" but the signal is close to that. "Thanks for your work, but no thanks. And now shut up".
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.
What an odd point of view. It doesn't sound like you as a user respect a maintainers free labor at all.
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.
yeah, the really harmful thing is not the stale bot but the fact that people can open Issues in the first place. it's not a helpful feature at all. it assumes wildly inaccurate things about the people who are using it.
every open source maintainer I know dreads the Issues UI, and only a few get anything useful out of it.
Yes we tried various things to better manage issues but there's just no easy solution when anybody can open issues.
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.
Here's something I don't understand: if you're already tagging the issues you'll work on, why go through the effort of closing the others? Can't you just filter by that tag to effectively "close" the non-tagged ones?
Generally the amount of work should be equal, especially when, as in OPs case, the curation is already happening.
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).
But what would be the value in leaving hundreds of open reports and nobody looking after them?
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.
The "value" would be that nobody would be complaining about issues getting closed. Of course, that's just a small upside, but since I don't see any downside with it, I'm still wondering why one wouldn't do that.
The value would be in somebody else encountering the problem — they don't need to open a new issue (that will eventually get closed due to being stale later). Net effect is that you get less mail.
> So now I don't close anything anymore and let users get mad at Stale Bot instead.
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.)
If that strategy works for you then you should continue doing so. However, I noticed that in the read me for your project (https://github.com/laurent22/joplin) you are not explaining that this is how you handle bug reports. Perhaps as a courtesy to users you could add that? Then people like me who think that strategy is bonkers could avoid wasting our time by filing bug reports to your project.
You're hindering your project because you don't want people getting upset with you. Sounds like you don't realize that, if you're acting in good faith, it's their fault they get upset, and it's nothing but harmful towards yourself to even care about something like this.
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.
It's not that much about caring, it's more about how to allocate time. If I have one hour to spare, do I want to spend it arguing with users over closed issues, or do I want to spend it to improve some feature or fix a bug?
Please interpret the author's words charitably. In the context of the rest of the article, the opening sentence doesn't imply ignorance of the reasons why it is used, but rather understanding those reasons and finding them insufficient.
While I think that closing issues after a certain time is really problematic, there is an inherent problem with a certain subset of stale issues.
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.
Also, on GitHub when you want to search an issue it filters by open only (you need to remove it manually). This brings on a lot of duplicated issues, so in some cases it increases the mantainers job.
The point is that visibility state of the ticket is irrelevant and not connected to the resolving state.
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...
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
The only issues that could be closed automatically are those that are not reproducible and are abandoned by the author. With no further details nor “me too”s, then it’s fine to close as stale.
> It absolutely isn’t. Look at Mozilla’s bugzilla instead: You’ll find plenty of bugs open for years and eventually fixed.
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.
We could have a whole talk about that too. Since GitHub added a "move issue to discussion" button, I've been getting a lot of replies like "I'm not sure how to address this immediately so I'm moving it to discussions".
Yet another way to mangle your issue tracker into uselessness. At least this one is manual (for now).
stale bot does more than closing. It also locks issues; that is the gist of the discussion here. If projects want to treat issues as tasks, then they should at least auto-convert any locked issue into a forum post; or use appropriate tagging to hide issues they don't care about from their "task list". If projects don't want to handle this, disabling issues on their project is even better than this middle ground "stale bot locks it all".
That isn't the default behavior. Locking issues is ridiculous, IMO, because then you get tons of duplicate discussions and it's impossible to follow one discussion thread.
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.
Thanks for the clarification, I only remembered the "locked" behavior, and that seems to be what is discussed in the article (see main screenshot). I agree that closing without locking is a good enough middleground (i.e same as tagging the issue).
Whether you include "stale" issues to your view of "open" issues or not, those are not triaged. And once closed as stale, they are never getting triaged.
I think a useful approach is, instead of closing or locking the issue, to have a bot that periodically (say every 90 days) pings everyone involved in that issue and tags it as "stale" if no one replies, but nothing else.
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.
That would be a huge pain in the ass for maintainers of even mildly popular open source projects. They’d be getting an avalanche of such mails on the daily.
It is when you're watching all the activity in the repository, but this is already an avalanche of mails if the project is very large. If you only get notifications for issues you've actively partecipate in, it's fine.
As a maintainer of such, there is already an avalanche of mail. The suggestion though can help to give PRs/issues one final chance at eyeballs before it gets to be old. It is similar to a “bump” comment, which is generally considered useful after 1-2 weeks.
Got pissed off on it on ioredis repo. Project touts its low open issue count but most of its closed issues are bugs unaddressed by the maintainers. Fucking stupid.
I sympathise with this, however, I disagree that it's harmful at all times. I think having it misconfigured it's definitely harmful.
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.
This is exactly how I use it. Some people do complain, and I get it. But they don't realize that 98% of all issues are spam that clutters up the issue queue, and outside of dedicated time just sitting around labeling issues and manually closing them, there would be no way for maintainers of anything near-popular to sift through issues for anything that actually matters.
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.
You're way mistaken; there are absolutely people who recognize that these bots suck and also dump on the GitHub community for its tendency to abuse bugtrackers for dumb stuff like support requests and general project discussion. This comprises like half of my GitHub-related comments on HN. (The other half includes complaints that the GitHub generation has rendered the word "wiki" meaningless by applying it to things that are clearly not wikis and then taking an IDGAF attitude if you bring it up. The author of the blog post here is among the guilty.)
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.
Yes, auto-closing an issue waiting on external feedback that hasn't happened is a great thing. Unfortunately GitHub isn't set up for that at all — there's no easy configuration to do that; instead the easy thing is to close based on inactivity without considering who the issue is waiting on.
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.
I agree with this generally, but I’ll offer a bit of nuance for an edge case: for extremely active repositories with “rolling” changes (i.e., ones where it’s a user error to not be on the latest HEAD), stale bots do a great job of handling the “it broke for me last week, but I haven’t tried any of the changes since” issues that frequently occur.
They do a great job of closing those issues, and also issues that are still valid. Not very useful.
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".
At this point I'd have to revive about five outstanding things a month because of bots like these.
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.
Obviously it's a subjective thing. I disagree with Drew and his incredibly entitled perspective on this completely. As a user of OSS, the project owner owes me nothing at all, and has no responsibility to field my requests, however valid they may be. From a solo dev to a large team, there's still only so many barrels in your gun. Mad that no one fixed it? Send a PR. Issues is not a customer service counter.
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.
> As a user of OSS, the project owner owes me nothing at all
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.
Sure. I am not disagreeing with you. My main point is that even though someone does not owe me anything, I can still complain and whine about their project being bad to warn others.
> 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.
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.
That is how human relations work. If you don't like my lemonade, I really don't have to listen to your alternative recipe. You can get your lemonade somewhere else, or make your own.
The fact that someone owes you nothing means you should expect that they might do nothing. If they lose a bot on you to spit in your face every two weeks, that is not doing nothing. They do owe you better than that.
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.
Feels like GitHub issues needs states other than Open or Closed. How about:
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.
171 comments
[ 2.1 ms ] story [ 190 ms ] threadTicket 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.
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.
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.
https://meyerweb.com/eric/comment/chech.html
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.
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 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.
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.
The only issues that could be closed automatically are those that are not reproducible and are abandoned by the author. With no further details nor “me too”s, then it’s fine to close as stale.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.
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.
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.
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.
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".
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.
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.
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.