27 ms·

GitHub Stale Bots – A False Economy

288 points by gitgud 6y ago

lucideer 6y ago
I'm so glad someone's written this. I've been arguing this point on individual tickets for quite some time, and have yet to see anyone who agrees with me. I thought I was the only one.
- pferde 6y ago
  Oh, you're far from the only one. It's just most of us just quietly shrug and move away from any project that does this. Life is too short, we should spend our time where it's valued.
lathiat 6y ago
I guess there are some that close issues and others that lock them. I’ve always thought even the auto close bots suck but for a different reason than your thread locking example. That seems particularly terrible.
- necovek 6y ago
  Indeed, I've never seen auto-lock bots on bug trackers before: this is terrible. I am fine with auto-close because they can indicate reality if they are closed with a WONTFIX status: nobody will work on fixing this. As opposed to eg OBSOLETE status which is not necessarily reality. If there is no explicit comment indicating how the project doesn't even want this, it is still an invitation for someone else to solve it themselves (for a free software project).
aetherspawn 6y ago
Makes me hate Angular when I see my old, unsolved, tickets get locked with 100+ upvotes and comments.
Aissen 6y ago
The ansible community does that too, and it's a pain. Instead of locking issues, they should be auto-transformed into a forum/community post, letting users discuss them if they want, and coordinate opening a new issue if necessary.
- thih9 6y ago
  I like this idea; especially from the point of view of future visitors, having a link that directs somewhere relevant is much more helpful than the “this issue is now closed” dead end.
- geerlingguy 6y ago
  I've argued constantly against the locking of old issues, sadly I've lost that battle. Locking issues is hostile to the user experience, especially for issues that could be deemed as bug reports and where users could still collaborate among themselves in the closed issue.
codebeaker 6y ago
The post solely looks at open source products, and for the author's example case (the Angular repository) it may be valid criticism. For internal repositories we find this to be really valuable in my company, the odd duplicated branch (when we couldn't get through CI for some reason, but recreating the branch) for whatever reason will be garbage collected, and all those `[CHORE]` branches people quickly hacked up without following our issue tracking process will be GC'ed too, if not handled. We run our (home made, with GitHub Actions, actually) bot in two stages, 30 days without activity, they get a label and a comment "stale, will be closed in 5 days, remove the stale label to prevent this", and then closure. This works great, except when people take extended vacation, or happen to switch between teams with WIP branches that are unmerged, but because Git never really loses anything, we've never lost work this way,we just benefit from easier summaries when looking for PRs to review, and having better metrics about mean time to merge, and other factors.
- necovek 6y ago
  Note that even you are not auto-locking, but only auto-closing tickets.
baobabKoodaa 6y ago
I used to open GitHub issues to Gatsby to report bugs. Almost nothing was ever fixed and every few weeks I had to manually clickety-click to keep the issues alive because of the stale bot. Guess what I do now? I don't report bugs to Gatsby, and I recommend against using Gatsby in newer projects.
- tvanantwerp 6y ago
  Sadly, I've had this same experience with Gatsby.
- z77dj3kl 6y ago
  Yes, I've had a similar experience. Gatsby is a dumpster fire once you venture off the beaten path.
  - madeofpalk 6y ago
    Or, stay on the beaten path for too long and get "too big" and it turns into a dumpster fire.
  - sneak 6y ago
    It's also spyware, transmitting your usage without consent: https://www.gatsbyjs.com/docs/telemetry/ https://www.gatsbyjs.com/docs/telemetry/
    - rgovostes 6y ago
      "Spyware" has a specific meaning and shouldn't be applied to any instance of data collection you disagree with. That you can point to their documentation about their data collection practices, which are explained in concise English with opt-out instructions, and that this is apparently detailed to the user on install, strongly suggests Gatsby is not spyware. Telemetry can be very valuable to open source projects which have extremely limited resources. The Adium project used telemetry to decide when they could drop support for PowerPC processors and old versions of macOS[0]. Homebrew uses it to track which of its thousands of packages are the most problematic to install[1]. 0: https://sparkle.adium.im/?year=2020&week=*&graph=bar https://sparkle.adium.im/?year=2020&week=*&graph=bar 1: https://formulae.brew.sh/analytics/ https://formulae.brew.sh/analytics/
al2o3cr 6y ago
I don't agree with the author's premise - the reason that users create duplicate issues isn't completely (or even mostly) because they can't add comments onto old issues. If it _was_, then surely the typical duplicate issue would start with "Reopening #1234" since the user has literally looked at that page already.
- spoiler 6y ago
  I've had to do that a few times in the Kubernetes family of repos, because of fejita bot. I'm sure I've done it a couple of other times in less popular repos too.
bluehatbrit 6y ago
From brief conversations with the team behind the GitHub stale bot, the original idea was clearing up tickets where the user didn't respond to the maintainer. I don't think this is what happens usually though. Sadly most cases I see are the same as the angular case in this article. I made an issue suggesting tickets not be marked as stale if they've not had a maintainer comment yet. As you can imagine, the stale bot installed on the repo itself kept trying to close it due to it being "stale". After several months the irony wore off and I let it get closed.
- tobr 6y ago
  Ideally an issue is not a conversation between a “user” and a “maintainer” though, but a place for a community to coordinate around a bug or feature request. I wouldn’t open an issue unless I thought someone more than me might find the topic useful, and so I also don’t feel like I have an obligation to participate in the conversation – after all, it’s not about me, but about ways to improve the code. I find it somewhat offensive when people post to request support on something that can’t reasonably be useful to anyone else.
  - geerlingguy 6y ago
    Sadly it seems about 90% of people don't have your mentality :( And the worse fact is, in terms of sponsorships the 10% of people who are more helpful in the issue queues and are already helping make maintainers lives easier are often the ones who consider sponsorship or other means of support. That's great, but it's disheartening that the people who feel entitled to an answer about a support question are almost 100x less likely to show any kind of support to open source projects (monetary or otherwise).
    - wolco5 6y ago
      This makes total sense. 10% of your users are superfans they read / understand everything you publish. They are so into it they give support (word of mouth, helping onboard others, bug patches, they will test alpha builds and give money/time where possible). 90% of users don't understand your product as well. They haven't totally bought in. They will need more support/handholding in order to convert. People are trying to get your product to work for their situation and if they can't 90% will go away and 10% will ask (usually dumb questions). Your unhappy with the 10% who can't get it working but want your product to work enough to bother to ask? I guess you can feel that way. Those 10% do represent an opportunity to get a group of people who want to use your product to onboard. The ones who tried and failed and never asked a question will probably never come back. If you ultimately want more support you are going to need to convert this group (or invest more time in advertising hoping to get more superusers/fanboys)
djohnston 6y ago
I am currently inundated with other people's bots making automatic tasks / warnings etc, totally overwhelming everyone around them. The only way to cope with the noise is to... build a bot :)
wraptile 6y ago
There's also this discrimination in open source culture where's "a lot of issues" are often interpreted as "low quality package". I'd often hear people complain in the lines of "it's has a lot of stars and constant commits but there's over 100 issues so we might want to avoid it". Which really rarely correlates. Maybe the term "issues" is just too loaded, especially when often those are feature suggestions or even information/how-to tickets - not exclusively bugs or "issues".
- yhoiseth 6y ago
  Good point. “Observation” is a better term in my experience.
- wott 6y ago
  Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like. Before Github, it wouldn't have come across any sane mind to file a feature request or other discussion/information under the name 'issue', for... they are not issues. It would have gone on a mailing-list (occasionally a web-forum). Issues (identified bugs) on the bug tracker, and the rest in a place of discussion.
  - nickjj 6y ago
    > Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like. Agreed. But GitHub is also slowly fixing this. For example the "Discussions" beta feature is enabled for specific repos. Here's it in action for the ImageMagick repo at https://github.com/ImageMagick/ImageMagick/discussions https://github.com/ImageMagick/ImageMagick/discussions. It's only available on a small subset of repos tho and it's something you can turn on and off at the repo level. I was given the option to enable it in my one of my repos, but it's a fairly new project with no discussions yet https://github.com/nickjj/flask-db/discussions https://github.com/nickjj/flask-db/discussions. I hope the Discussions feature becomes generally available soon.
    - wott 6y ago
donatj 6y ago
We have had essentially this argument with our internal issue tracker a number of times. Project managers always seem to get some bug in their butt to close old issues. If they are not fixed, closing the ticket solves nothing. There is no virtue in having more untracked bugs.
- marcinzm 6y ago
  I'm guessing someone is measuring the Project Manager's performance based on number of open issues. Or they think someone is doing so. Even if it's just a side comment from a VP noting how many open issues there are.
- NullPrefix 6y ago
  >What gets measured, gets managed. Measuring open/closed issue tally is way easier than interpreting why and for what reason that particular issue is still relevant to the big picture.
- Hackbraten 6y ago
  In some projects, the maintainers use issues to represent their task queue. That’s not necessarily intuitive for users but a perfectly legitimate thing to do. I think that if a project uses that model then there’s nothing wrong with closing issues if you don’t intend to ever work on them.
  - mook 6y ago
    I think in that case the maintainer needs a different view of the bug tracker; for example, in GitHub that would be their projects view, or if you don't like that, label the issues as stale (without closing) and using a search that excludes those results. I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair). The important thing is that new users would be able to find them, so that non-maintainers can still collaborate.
    - Hackbraten 6y ago
cycomanic 6y ago
I can somewhat understand closing issues, but locking?! That's crazy I always understood looking to be about stopping unhealthy discussions etc. not to prevent bu reports. My main gripe with stale bots is that some have incredibly short timelimits attached to them. We were arguing about the expectations from users on maintainers to fix their issues immediately and I was strongly arguing that users can expect oss maintainers who are not compensated for their work to just jump. But there is also the other side to it, if I report a bug and the maintainer gets to it and ask for some more information (sometime quite extensive) to close the bug because I didn't reply within a week. I also have a live outside of reporting bugs.
- WhyNotHugo 6y ago
  Yeah, locking stale issues is crazy. "Oh, you didn't respond in time, so this issue can never be discussed by anyone again.".
m3nu 6y ago
It's a tool like every other. Can be used in a good or bad way. I also use the stale bot, but with many labels excluded. If an issue has a proper label, it will stay open forever. If it's just a question or support request, it will be closed after 2 months. This prevents me from reviewing too many irrelevant and outdated issues, where the reporter moved on a long time ago.
ponyous 6y ago
Stale bots caused me to waste weeks on libraries that were garbage. The moment I see stalebot on repository I start to think the company is just doing open source so they look cool for new hires. Please stop using stale bots.
- pwdisswordfish5 6y ago
  It comes with the territory; aiding you in the quest for cool is one of GitHub's only value propositions. Because it's certainly not about productivity. People substitute having a conspicuous social presence for getting work done. Looking around at what everyone else is doing and copying that without thinking about what value it brings. Retroactively insisting they have value with subjective and unfalsifiable claims. It's all part of the tao of GitHub.
ddevault 6y ago
This mostly happens, I think, on projects which don't care about bugs from the general public. This includes Angular, but also Go and Firefox, for example. Their teams are working at a level too far detached from the general public to care, and they mostly focus on their internal priorities instead. And that's a valid approach to managing your FOSS project - it comes with no express or implied warranty of merchantability or fitness for a particular purpose, in all caps no less. If a bug report does not immediately catch the attention of the maintainers under such circumstances, it's unlikely to do so later on. The maintainers don't care about dupes, because they didn't care about the original either. They're going to have tens of thousands of tickets no matter what. Of course, if you find yourself at the wrong end of this process, the best way to get attention for your bug report is to attach a patch.
- swills 6y ago
  To me, this is exactly right and summarizes the situation well. Maintainers actions demonstrate their priorities, which are driven by their funding rather than community needs. This is the difference between community driven projects and corporate driven ones (even if the corporate drive is indirect via funding). Writing a patch is often the only path forward and often even that is ignored or nit picked until people move on.
- cdubzzz 6y ago
  This is a solid explanation. It also makes me wonder, why even use GitHub at a certain point? It seems like GH is a one-size-fits-all approach and the primary reason to use it is to get _more_ issue, PRs, etc. in your project. But once you hit a certain scale, maybe it’s time to move to a more customizable solution?
  - ddevault 6y ago
    Beats me. This is why SourceHut lets you pick and choose any number of repos, bug trackers, mailing lists, etc, including zero, to associate with a project. I suspect that some projects just use GH to shut the peanut gallery up; a lot of people will demand that any large-ish project moves to GH if they aren't already there. That certainly seems like why Golang did it, for one.
cute_boi 6y ago
I used to report bugs but now I don't report any bugs. Many developer thinks that I am reporting issue is adding work on them. I have faced such issue on Gatsby and VScode where they just lock issue.
timdaub 6y ago
On some projects, I took the time to write a nice issue about a bug I sometimes even went so far as to debugging it in the dependencies code. I feel let down when a bot comes along and closes this issue. Maybe it's stale, but the issues sometimes remain...
trinovantes 6y ago
GitHub's generous free plans and accessible UI, especially in recent years, has removed a lot of the barriers that traditionally prevented many people from participating in open source projects. Consequently, this also resulted in a lot more noise on GitHub projects vs projects managed via mailing lists where bug reports are more concise and maintainers are more receptive (at least from my experience with LLVM). I think we're still in a transitional period where nobody really knows how to properly run large scale open source projects with low/no barriers to entry. Even well-funded projects repos like Typescript, VSCode, React receive more issues than they can close. Stale bot is not perfect but some automation is definitely required for these popular repositories. I suspect some barrier to entry may also required for a healthy repository to filter out the noise e.g. mandatory repository that reproduces the bug.
- WesolyKubeczek 6y ago
  Really makes me wish we go back to mailing lists.
ROARosen 6y ago
I never understood why Github needs to 'lock' the stale issues. Isn't it possible to just 'mark' stale issues as being just that. What's the point of 'locking'?
- geerlingguy 6y ago
  By default the stale bot does not lock issues. And you can configure it to mark stale, then either close or not close the issue.
  - ROARosen 6y ago
    OK let me rephrase that. Why do maintainers choose to lock issues as as opposed to just marking them?
    - raziel2p 6y ago
      Most likely because "me too" or "any update on this?" type comments are extremely common.
      - deathanatos 6y ago
        …perhaps if Github had a way to indicate directly on the bug that it affects you too. (And yes, most of the community is using the "thumbs-up" on the original issue to indicate that. That's a workaround for a missing feature, not a feature.)
        suprfsat 6y ago
        All of buganizer, monorail, launchpad have a way to indicate that a bug affects you too. Launchpad literally has a button that says "this bug affects me". People simply act obnoxious and entitled for its own sake.
    - Dumbdo 6y ago
      I assume they do that do avoid comments on old issues. If they are already using bots like that they are probably barely able to respond to new issues, so comments on old issues will never be read anyways. By forcing users to open new issues, it increases the chance for replies. That's at least what I understood from bigger repositories. It's not great and most maintainers are aware of the several shortcomings of that practive, but especially in huge repositories there are so many new (and sometimes low effort) issues daily that some maintainers are simply overwhelmed.
geerlingguy 6y ago
There's a huge difference between closing and locking issues. If you close an issue, people can still leave follow-up comments, and the issue can be re-opened if warranted. Some of the best issues on GitHub are closed issues where people have come in months or years after the fact and left useful additional information. Locking an issue leads to tons of duplication, annoying UX, and an overall hostile experience. In the 10,000+ issues I've managed on my own repos over the years, I've locked a grand total of ONE issues and that was just due to some borderline harassment (though unintended) that was going on long after useful discourse was over.
- deleted 6y ago
  [deleted]
- intellix 6y ago
  Yep. I also like to leave a paper trail for myself when I'm having a similar issue. I'll typically leave information like workarounds/patches or explain how I ended up there
Ayesh 6y ago
I think a bit that closes (but not lock) issues that keetna certain criteria (maintainer marks is as "needs reporter feedback", and are support issues makes more sense. Big reports shouldn't be discouraged not stale-locked.
chelmertz 6y ago
If the goal is to either reduce the number of open issues, or make it easy to find the most recently reported/recently active issues, it could be accomplished in other ways. What about: - not having "TOTAL issues" as a counter, but "TOTAL RECENTLY ACTIVE issues", for some value of "recently" - defaulting to only showing the RECENTLY ACTIVE issues when searching for them (or finding them through other views) - displaying a warning such as "this issues is dusty, consider it not being prioritized highly" As with all other bug reporting systems, having slices/views to work with seems to be preferred to closing issues. Someone supporting the product might really want to find the issues being "most reacted to" recently, the planning "product manager role" maybe only wants to see the high level "epics/initiatives/visions" in a certain order, etc. I think much of this comes down to all issues being on the same "level" in a Github issue tracker, i.e. "tagging is enough", which some projects solves with a huge taxonomy, and some don't.
- gmueckl 6y ago
  Even when looking only at recent ticket activity, overall popularity of a project also plays into it. A young project that generates a lot of interest may attract a lot of reports and still work great. An old, unpopular project may be a hot mess but the ticket count is low because the user base isn't there to find issues in the first place.
  - onionisafruit 6y ago
    Number of issues shouldn’t be a primary factor in evaluating a project. Maybe GitHub should stop featuring that so prominently in the UI.
joshxyz 6y ago
Stale bots are stupid i wanna smack the face of whoever invented them. Those bots keep closing valid issues!
pingiun 6y ago
IMO NixOS has the right stalebot settings[0]. It was discussed thouroughly in the RFC, as to choose the right information text and other actions by the bot. For example, the bot will only mark the issue/PR as stale and will never close the issue or lock it. Issues are only ever closed by humans. The information text they came up with is quite a bit longer than the ansible one[1]. I think this is a very important point when adding such a bot, otherwise the user will be left helpless. [0]: https://github.com/NixOS/rfcs/pull/51 https://github.com/NixOS/rfcs/pull/51 [1]: https://github.com/NixOS/nixpkgs/pull/92254 https://github.com/NixOS/nixpkgs/pull/92254
- iFreilicht 6y ago
  Oh wow, that is very well worded! Not only do they explain why issues have to be marked as stale and how the reporter can remove the label. It's also friendly and appreciates that the user made the effort to create an issue in the first place and helps them do more to get attention to the issue.
prepend 6y ago
I’ve run into this on a few projects where PMs want to close all issues. Oddly there’s no external metric on this, it’s just some internal driver. It would result in closing old or low priority items rather than leaving them. It would also result in things not fixed being closed. It was a surreal conversation where I asked how they knew my issue was resolved without asking me, the person who submitted it. The PM said “what do you mean, we closed it. It’s closed.” And it took time to explain the difference between thinking it’s done and properly confirming it’s done. I find the most frustrating as a user is “closed, won’t fix” as for OSS projects someone could eventually submit a fix. Closing “stale” issues is vanity tidying that’s not necessary in a digital, “free” world. I think the fix for this is to look at the “unaddressed” metric to include any closed issues that weren’t resolved. A high number of stale issues closed is a negative metric for a project. But a high number of lingering issues isn’t so bad.
- yoz-y 6y ago
  A won't fix might make sense if the issue is a feature request that goes against the program philosophy. In that case forking the repo makes more sense. I wholeheartedly agree that closing issues just because they are old is a terrible practice. It's also why I have stopped sending radars. No point of doing work for somebody else if it just generates even more work for me.
  - pas 6y ago
    I have no problem with closing them for bugs, because in a few major versions usually the software changes sufficiently to have a good chance of that original bug report simply being obsolete (not reproducible, log/debug output not useful anymore, architecture changes, GUI changes, client software/driver changes, kernel changes, etc.) But in case of a feature request, where the project maintainer agreed it's a long term goal, a bot closing it is just noise, which IMHO discourages useful/insightful comments.
    - yoz-y 6y ago
      I don't think it's justified for bugs either. At least it should be opt-in per bug. It can hide especially sinister bugs that happen only in an uncommon case. This assumes a list of bugs that are actually reproductible bugs not an unfiltered feedback from the clients.
siraben 6y ago
Locking a stale issue seems a bit excessive to me. Nixpkgs, an extremely active repository (> 109K issues and PRs) has the stale bot configured to mark the issue or PR as stale[0] after 180 days. [0] Example: https://github.com/NixOS/nixpkgs/issues/36217#issuecomment-639234148 https://github.com/NixOS/nixpkgs/issues/36217#issuecomment-6...
strenholme 6y ago
I think it’s irresponsible to let bugs languish like this. The way I handle bug reports is to say “Hey, look, I just can’t fix this right now because I’m working full time and don’t know when I’ll be able to get around to fixing this without getting paid for my work.” E.g. https://github.com/samboy/MaraDNS/issues/84 https://github.com/samboy/MaraDNS/issues/84 I can see why a lot of people don’t do that: It’s a little rude, and there’s a small but significant chance it’ll become a flame war. I have only once had someone get rude in a ticket when I told them “That’s not a bug report, but a support issue”; I ended up deleting the ticket. GitHub also allows you to edit or delete other people’s comments in your tickets, as well as locking the conversation.
Hackbraten 6y ago
Some projects use issues to represent maintainer work items. So if no maintainer plans to work on something, why not close the issue? It can be reopened anytime. Locking is a whole different thing because it prevents people from commenting. In closed issues, commenting is allowed though. I think closing an issue with a “thanks, we don’t plan to work on this anytime soon but PRs are welcome” shouldn’t be frowned upon.
- ocdtrekkie 6y ago
  I disagree heavily because closed issues are less visible. An unresolved issue may be notable for other users to see and communicate about, a closed issue should be "done with". Either it is invalid or it is addressed or fixed. I'd argue developers who use the issues list as a personal todo list are using issues incorrectly.
  - Hackbraten 6y ago
    > I'd argue developers who use the issues list as a personal todo list are using issues incorrectly. If that method helps maintainers run their projects efficiently, why would you call it incorrect?
    - ocdtrekkie 6y ago
      Because it is user hostile. Even if it is helpful for them, if it hurts their users, they probably should be doing something else. If you hate your users, why open source at all?
      - Hackbraten 6y ago
        > it hurts their users Please help me understand why you think it hurts users.
  - Hackbraten 6y ago
    > I disagree heavily because closed issues are less visible. It takes one single extra click to include closed issues in a search. As a user/contributor, I’d figure that’s a rather small price to pay, given that it helps maintainers handle their workload.
ocdtrekkie 6y ago
I absolutely loathe stale bots. It essentially assumes a problem is irrelevant because nobody has fixed it yet. Sometimes I bother to ask the maintainer to put issues I report on hold. Mostly I just assume if you have a stale bot that you are going to wontfix all my issues and I should find a different project.
8K832d7tNmiQ 6y ago
Isn’t this the reason why Github Discussion exists? To basically become an internal StackOverflow for the repo?
- ocdtrekkie 6y ago
  I think there's a difference between "languishing issue that hasn't gotten fixed" and a discussion. Both have a purpose, and they are separate purposes.
stblack 6y ago
Our stale bot doesn't lock issues, merely marks them as closed after a configurable notification time, and a configurable no-activity time. Which stale bot is the author referring to? This stale bot (THE stale bot?) https://github.com/probot/stale https://github.com/probot/stale, doesn't even have an option to lock the issue.
intellix 6y ago
Massively agree. Also hate repositories that have issue templates that ask the same reworded question. I typically start writing it out and then just give up cause I can't think of how to answer the same question without just copy/pasting. You still get the typical "how can fix, not work?" issues so why overdo it? Should be simply: 1) What's wrong? 2) What's correct? 3) Reproduction
- pas 6y ago
  It's (probably? totally!) arrogance, but usually I delete the questions from the template that have already been answered by what I wrote. In my experience the templates are for those who are simply so new to "open source", bug reporting, programming/software-development, GitHub and this amazing Internet thing, that they really benefit from going through it. (Sure, alas many people are inexperienced and doesn't read the templates ... :D)
dathinab 6y ago
I can only agree with that. I have had been involved in to many "stale" but neither fixed nor forgotten issues which would have become very cumbersome if a stale bot was involved. Common reasons for "staleness" include: - blocked on other issues - blocked on external dependencies - blocked because no one has currently time to fix the issue because there are many other high or very high priority issues. This doesn't mean it has low priority, just not high/very high priority. - feature requests which the author agreed to should be implemented, but neither the maintainer nor the issuer has currently time to work on. - feature requests which are braking changes and as such will only included if a new version is made - bugs with low priority if there are higher priority things Sure you can work around this by using many labels and making the stale bot label aware e.g.: - label contains "blocked" => do not stale close - label contains "bug" => do not stale close (and only assign bug if issuer provides the necessary information) - label contains "next-version" => do not stale - label contains "...." => do not stale But that seems somewhat pointless for the large majority of crates. Furthermore I believe stale bots come to some degree from the (IMHO) unrealistic idea that the amount of open issues, issue closing time and issues staleness indicate how health a project is. But the moment you have feature request issues or "will be fixed in next release as braking change" this metrics fall apart completely. Similar some software projects get a lot of spam issues (often an indication that a popular project probably needs some improvements of documentation or UX aspects). For this it can sometimes be reasonable to have stale bot if it doesn't act on certain labels IMHO.
habosa 6y ago
Hmmm there are two things here: 1) Marking inactive issues as stale and eventually closing them automatically. 2) Locking old closed issues so they don't get comments. Many bots do these things and do them badly. I maintain a bot that I think does (1) better. The key is that an issue is only stale if a maintainer has asked a question of the person who filed the issue and that person is not responding. That's the only condition. An issue is NOT stale just because there's been no activity recently. That could just mean the maintainer is on vacation or has other things to do. Repos which have bots that close issues for lack of maintainer action are getting off to easy. I’m a bit more torn about locking old issues. On the one hand it saves you from a lot of low-value “me too” spam comments and lets you focus on only open issues. On the other hand you will miss legitimate regressions.
- jsmith45 6y ago
  >The key is that an issue is only stale if a maintainer has asked a question of the person who filed the issue and that person is not responding. That's the only condition. The possible issue with that criteria in general is that it need not actually be the original poster who replies with the needed details. Another user with the same problem could supply the needed details as well. A different user supplying the answer is especially common on widespread issues that the maintainers are having problems tracking down. For example, it might be that the problem only reproduces on a certain version of a specific distro, or only if certain kernel configuration options are used. Those sorts of issues can be hard for the maintainer to discover, but might be easier for impacted users to locate. You may well have stuff in place to handle this, but thought it was worth pointing out for completeness sake.
  - habosa 6y ago
    My opinion keeps changing on this one. Sometimes a non-author user will come by and say "this is happening to me too and here's some helpful logs". But other times a non-author user will just drive by and say "+1 any solution?". The former should reset the stale timer, the latter should not. I think in the end this depends on the project. In the end you need humans to pay attention to ongoing conversations or you'll always get some cases wrong.
no_wizard 6y ago
I feel this has a lot less value in a world where you enable GitHub discussions. While not a panacea, it does remove the clutter of 'issues as discussions' and allows you to really use the issue tracker for just issues. This is what I would recommend every open source project do on GitHub: - Convert discussion issues to discussions - Label the existing issues as issue type (e.g. bug) if this makes sense for your project - Add an issue template that specifies if it is a feature request / discussion etc that it will be moved to discussions and they should proceed there, otherwise it can be filed as an issue - And importantly, close issues you don't intend to address, and a short explainer why (even if its just 'no longer relevant' or 'is not going to be considered, if requested open a new *discussion etc, make some boilerplate) That makes sense to me at least. I know discussions isn't perfect (far from it) however it cuts down the clutter on the issue tracker and makes it much easier I think to engage with the community (issues have this 'binding' status a lot of the times that discussions implicitly don't, so its much safer to spitball IMHO)
patcon 6y ago
And old rant in their issue queue: https://github.com/probot/stale/pull/107#issuecomment-379021783 https://github.com/probot/stale/pull/107#issuecomment-379021... > Thesis: Stalebot -- in dutiful service of current human resource constraints -- feels like it unthinkingly prioritizes discard of past contributors' time resources, over the mobilization of new human resources. I've had a beef with Stale since early on. It's a very old-world view of solving the problem of open source capacity. A better tool would instead try to find and encourage new resources (new contributors), whereas stalebot drives them away, and so kinda cuts the project off at the knees imho, in the short-term, it rescues the cognitive and emotional resources of current contributors, but (in the long-term) drives future contributors away through promoting lack of care and by encouraging maintainers to not interact with them.
Jugurtha 6y ago
Stale Bots are one thing, it's another thing when a huge company puts an intern in charge of issues and pull requests. You open an issue, and a pull request. The intern fails to see what the problem even is and closes the pull request and the issue telling you they don't see a problem. In other instances, pull requests would sit there for months for use cases that are no-brainers. We made the decision not to contribute to that project and not to maintain a fork. Instead, we developed plugins that are independent so we do not depend on pull requests being accepted, nor have to keep the fork in sync.
jrockway 6y ago
If you open a bug, you are saying "here's a problem I found that's not important enough to me to spend time fixing". The auto-close bot says "we agree that this is not important enough to fix." If you're paying for a support contract and an auto-close bot is closing all your issues, you should stop paying for the support contract, though.
- mook 6y ago
  Sometimes external contributors do not have the correct power to fix the issues they open; mainly that means the maintainer needs to take some decision (and possibly instruct the issue creator to make a PR). That is, the amount of effort the external person needs to spend time to fix it is "become the maintainer".
- pseudalopex 6y ago
  Here's a problem I found I don't know how to fix. Here's a problem I found and how I would fix it. Does it sound good to you? Here's a problem I found. It's important enough for me to fix but I can only work on it sporadically. Here's a problem I found. My employer owns everything I write. Here's a problem I found. I'm not a programmer.
habitue 6y ago
Assuming it's not locking an issue, I really like stalebots for internal projects. There are lots of things that just become moot after a while because things change so rapidly. If you run into the problem again, it's always easy to reopen the issue or refer to the old one, usually with more up to date context. It also means if you sort issues by oldest and is:open, you get longstanding problems rather than "things we were worried about 2 years ago, but were never important enough to fix or close".
chrismorgan 6y ago
I’m bemused that this complaint is almost entirely about locking issues. Most I’ve ever had the misfortune to encounter haven’t been locking issues, just closing them, which isn’t quite as bad (but almost). I loathe, despise and abominate the GitHub bot with the name “stale” and think it should be discontinued with prejudice. I have never had a positive experience with it, and genuinely cannot imagine any scenario in which it would provide more value than the harm it causes. What of other stale bots that are more nuanced or that provide more meaningful descriptions of what and why? Well, I can think of one or two interactions over the years that seemed more reasonable (e.g. TypeScript’s “it’s been a while, there aren’t ten votes and it hasn’t been accepted, probably nothing’s going to happen, speak now or it’ll be closed”), but even they still cause substantial harm (duplicates, &c.) because GitHub’s search defaults to excluding closed issues. But most of them should definitely be killed with fire. Ooh, ooh! If we’re ranting about issue management systems, here’s another of mine: free-form text fields with templates. You ever tried searching for a word that happens to appear in the template? Yeah, it’s completely useless. I guess this one could be mitigated by a more intelligent indexer that filtered out the template first.
- TonyTrapp 6y ago
  I'm completely with you on the free-form text fields. How could we end up with such an unstructured way of filing issues as the default?
skissane 6y ago
I submitted a PR to make a tiny improvement to the libuv documentation... [0] and the stale bot wants to close it on me. I think closing PRs as stale is particularly annoying. [0] https://github.com/libuv/libuv/pull/3076 https://github.com/libuv/libuv/pull/3076
ajnin 6y ago
This tendency to close "stale" issues is a symptom of Goodhart's law [0]. Once the number of open issues is used as a proxy for software quality, then lowering that number becomes a goal in itself. And thus it ceases to be a pertinent metric, and it might even become counter-productive by discouraging contributors. Another reason I think is that it's also a nice excuse to avoid working on old boring stuff and focus on new exciting stuff. https://en.m.wikipedia.org/wiki/Goodhart%27s_law https://en.m.wikipedia.org/wiki/Goodhart%27s_law

288 points by gitgud 6y ago

I'm so glad someone's written this. I've been arguing this point on individual tickets for quite some time, and have yet to see anyone who agrees with me. I thought I was the only one.

pferde 6y ago
Oh, you're far from the only one. It's just most of us just quietly shrug and move away from any project that does this. Life is too short, we should spend our time where it's valued.

lathiat 6y ago

I guess there are some that close issues and others that lock them. I’ve always thought even the auto close bots suck but for a different reason than your thread locking example. That seems particularly terrible.

necovek 6y ago
Indeed, I've never seen auto-lock bots on bug trackers before: this is terrible. I am fine with auto-close because they can indicate reality if they are closed with a WONTFIX status: nobody will work on fixing this. As opposed to eg OBSOLETE status which is not necessarily reality. If there is no explicit comment indicating how the project doesn't even want this, it is still an invitation for someone else to solve it themselves (for a free software project).

aetherspawn 6y ago

Makes me hate Angular when I see my old, unsolved, tickets get locked with 100+ upvotes and comments.

Aissen 6y ago

The ansible community does that too, and it's a pain. Instead of locking issues, they should be auto-transformed into a forum/community post, letting users discuss them if they want, and coordinate opening a new issue if necessary.

thih9 6y ago
I like this idea; especially from the point of view of future visitors, having a link that directs somewhere relevant is much more helpful than the “this issue is now closed” dead end.
geerlingguy 6y ago
I've argued constantly against the locking of old issues, sadly I've lost that battle. Locking issues is hostile to the user experience, especially for issues that could be deemed as bug reports and where users could still collaborate among themselves in the closed issue.

codebeaker 6y ago

The post solely looks at open source products, and for the author's example case (the Angular repository) it may be valid criticism. For internal repositories we find this to be really valuable in my company, the odd duplicated branch (when we couldn't get through CI for some reason, but recreating the branch) for whatever reason will be garbage collected, and all those `[CHORE]` branches people quickly hacked up without following our issue tracking process will be GC'ed too, if not handled. We run our (home made, with GitHub Actions, actually) bot in two stages, 30 days without activity, they get a label and a comment "stale, will be closed in 5 days, remove the stale label to prevent this", and then closure. This works great, except when people take extended vacation, or happen to switch between teams with WIP branches that are unmerged, but because Git never really loses anything, we've never lost work this way,we just benefit from easier summaries when looking for PRs to review, and having better metrics about mean time to merge, and other factors.

necovek 6y ago
Note that even you are not auto-locking, but only auto-closing tickets.

baobabKoodaa 6y ago

I used to open GitHub issues to Gatsby to report bugs. Almost nothing was ever fixed and every few weeks I had to manually clickety-click to keep the issues alive because of the stale bot. Guess what I do now? I don't report bugs to Gatsby, and I recommend against using Gatsby in newer projects.

tvanantwerp 6y ago
Sadly, I've had this same experience with Gatsby.
z77dj3kl 6y ago
Yes, I've had a similar experience. Gatsby is a dumpster fire once you venture off the beaten path.
- madeofpalk 6y ago
  Or, stay on the beaten path for too long and get "too big" and it turns into a dumpster fire.
- sneak 6y ago
  It's also spyware, transmitting your usage without consent: https://www.gatsbyjs.com/docs/telemetry/ https://www.gatsbyjs.com/docs/telemetry/
  - rgovostes 6y ago
    "Spyware" has a specific meaning and shouldn't be applied to any instance of data collection you disagree with. That you can point to their documentation about their data collection practices, which are explained in concise English with opt-out instructions, and that this is apparently detailed to the user on install, strongly suggests Gatsby is not spyware. Telemetry can be very valuable to open source projects which have extremely limited resources. The Adium project used telemetry to decide when they could drop support for PowerPC processors and old versions of macOS[0]. Homebrew uses it to track which of its thousands of packages are the most problematic to install[1]. 0: https://sparkle.adium.im/?year=2020&week=*&graph=bar https://sparkle.adium.im/?year=2020&week=*&graph=bar 1: https://formulae.brew.sh/analytics/ https://formulae.brew.sh/analytics/

al2o3cr 6y ago

I don't agree with the author's premise - the reason that users create duplicate issues isn't completely (or even mostly) because they can't add comments onto old issues. If it _was_, then surely the typical duplicate issue would start with "Reopening #1234" since the user has literally looked at that page already.

spoiler 6y ago
I've had to do that a few times in the Kubernetes family of repos, because of fejita bot. I'm sure I've done it a couple of other times in less popular repos too.

bluehatbrit 6y ago

From brief conversations with the team behind the GitHub stale bot, the original idea was clearing up tickets where the user didn't respond to the maintainer. I don't think this is what happens usually though. Sadly most cases I see are the same as the angular case in this article. I made an issue suggesting tickets not be marked as stale if they've not had a maintainer comment yet. As you can imagine, the stale bot installed on the repo itself kept trying to close it due to it being "stale". After several months the irony wore off and I let it get closed.

tobr 6y ago
Ideally an issue is not a conversation between a “user” and a “maintainer” though, but a place for a community to coordinate around a bug or feature request. I wouldn’t open an issue unless I thought someone more than me might find the topic useful, and so I also don’t feel like I have an obligation to participate in the conversation – after all, it’s not about me, but about ways to improve the code. I find it somewhat offensive when people post to request support on something that can’t reasonably be useful to anyone else.
- geerlingguy 6y ago
  Sadly it seems about 90% of people don't have your mentality :( And the worse fact is, in terms of sponsorships the 10% of people who are more helpful in the issue queues and are already helping make maintainers lives easier are often the ones who consider sponsorship or other means of support. That's great, but it's disheartening that the people who feel entitled to an answer about a support question are almost 100x less likely to show any kind of support to open source projects (monetary or otherwise).
  - wolco5 6y ago
    This makes total sense. 10% of your users are superfans they read / understand everything you publish. They are so into it they give support (word of mouth, helping onboard others, bug patches, they will test alpha builds and give money/time where possible). 90% of users don't understand your product as well. They haven't totally bought in. They will need more support/handholding in order to convert. People are trying to get your product to work for their situation and if they can't 90% will go away and 10% will ask (usually dumb questions). Your unhappy with the 10% who can't get it working but want your product to work enough to bother to ask? I guess you can feel that way. Those 10% do represent an opportunity to get a group of people who want to use your product to onboard. The ones who tried and failed and never asked a question will probably never come back. If you ultimately want more support you are going to need to convert this group (or invest more time in advertising hoping to get more superusers/fanboys)

djohnston 6y ago

I am currently inundated with other people's bots making automatic tasks / warnings etc, totally overwhelming everyone around them. The only way to cope with the noise is to... build a bot :)

wraptile 6y ago

There's also this discrimination in open source culture where's "a lot of issues" are often interpreted as "low quality package". I'd often hear people complain in the lines of "it's has a lot of stars and constant commits but there's over 100 issues so we might want to avoid it". Which really rarely correlates. Maybe the term "issues" is just too loaded, especially when often those are feature suggestions or even information/how-to tickets - not exclusively bugs or "issues".

yhoiseth 6y ago
Good point. “Observation” is a better term in my experience.
wott 6y ago
Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like. Before Github, it wouldn't have come across any sane mind to file a feature request or other discussion/information under the name 'issue', for... they are not issues. It would have gone on a mailing-list (occasionally a web-forum). Issues (identified bugs) on the bug tracker, and the rest in a place of discussion.
- nickjj 6y ago
  > Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like. Agreed. But GitHub is also slowly fixing this. For example the "Discussions" beta feature is enabled for specific repos. Here's it in action for the ImageMagick repo at https://github.com/ImageMagick/ImageMagick/discussions https://github.com/ImageMagick/ImageMagick/discussions. It's only available on a small subset of repos tho and it's something you can turn on and off at the repo level. I was given the option to enable it in my one of my repos, but it's a fairly new project with no discussions yet https://github.com/nickjj/flask-db/discussions https://github.com/nickjj/flask-db/discussions. I hope the Discussions feature becomes generally available soon.
  - wott 6y ago

donatj 6y ago

We have had essentially this argument with our internal issue tracker a number of times. Project managers always seem to get some bug in their butt to close old issues. If they are not fixed, closing the ticket solves nothing. There is no virtue in having more untracked bugs.

marcinzm 6y ago
I'm guessing someone is measuring the Project Manager's performance based on number of open issues. Or they think someone is doing so. Even if it's just a side comment from a VP noting how many open issues there are.
NullPrefix 6y ago
>What gets measured, gets managed. Measuring open/closed issue tally is way easier than interpreting why and for what reason that particular issue is still relevant to the big picture.
Hackbraten 6y ago
In some projects, the maintainers use issues to represent their task queue. That’s not necessarily intuitive for users but a perfectly legitimate thing to do. I think that if a project uses that model then there’s nothing wrong with closing issues if you don’t intend to ever work on them.
- mook 6y ago
  I think in that case the maintainer needs a different view of the bug tracker; for example, in GitHub that would be their projects view, or if you don't like that, label the issues as stale (without closing) and using a search that excludes those results. I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair). The important thing is that new users would be able to find them, so that non-maintainers can still collaborate.
  - Hackbraten 6y ago

cycomanic 6y ago

I can somewhat understand closing issues, but locking?! That's crazy I always understood looking to be about stopping unhealthy discussions etc. not to prevent bu reports. My main gripe with stale bots is that some have incredibly short timelimits attached to them. We were arguing about the expectations from users on maintainers to fix their issues immediately and I was strongly arguing that users can expect oss maintainers who are not compensated for their work to just jump. But there is also the other side to it, if I report a bug and the maintainer gets to it and ask for some more information (sometime quite extensive) to close the bug because I didn't reply within a week. I also have a live outside of reporting bugs.

WhyNotHugo 6y ago
Yeah, locking stale issues is crazy. "Oh, you didn't respond in time, so this issue can never be discussed by anyone again.".

m3nu 6y ago

It's a tool like every other. Can be used in a good or bad way. I also use the stale bot, but with many labels excluded. If an issue has a proper label, it will stay open forever. If it's just a question or support request, it will be closed after 2 months. This prevents me from reviewing too many irrelevant and outdated issues, where the reporter moved on a long time ago.

ponyous 6y ago

Stale bots caused me to waste weeks on libraries that were garbage. The moment I see stalebot on repository I start to think the company is just doing open source so they look cool for new hires. Please stop using stale bots.

pwdisswordfish5 6y ago
It comes with the territory; aiding you in the quest for cool is one of GitHub's only value propositions. Because it's certainly not about productivity. People substitute having a conspicuous social presence for getting work done. Looking around at what everyone else is doing and copying that without thinking about what value it brings. Retroactively insisting they have value with subjective and unfalsifiable claims. It's all part of the tao of GitHub.

ddevault 6y ago

This mostly happens, I think, on projects which don't care about bugs from the general public. This includes Angular, but also Go and Firefox, for example. Their teams are working at a level too far detached from the general public to care, and they mostly focus on their internal priorities instead. And that's a valid approach to managing your FOSS project - it comes with no express or implied warranty of merchantability or fitness for a particular purpose, in all caps no less. If a bug report does not immediately catch the attention of the maintainers under such circumstances, it's unlikely to do so later on. The maintainers don't care about dupes, because they didn't care about the original either. They're going to have tens of thousands of tickets no matter what. Of course, if you find yourself at the wrong end of this process, the best way to get attention for your bug report is to attach a patch.

swills 6y ago
To me, this is exactly right and summarizes the situation well. Maintainers actions demonstrate their priorities, which are driven by their funding rather than community needs. This is the difference between community driven projects and corporate driven ones (even if the corporate drive is indirect via funding). Writing a patch is often the only path forward and often even that is ignored or nit picked until people move on.
cdubzzz 6y ago
This is a solid explanation. It also makes me wonder, why even use GitHub at a certain point? It seems like GH is a one-size-fits-all approach and the primary reason to use it is to get _more_ issue, PRs, etc. in your project. But once you hit a certain scale, maybe it’s time to move to a more customizable solution?
- ddevault 6y ago
  Beats me. This is why SourceHut lets you pick and choose any number of repos, bug trackers, mailing lists, etc, including zero, to associate with a project. I suspect that some projects just use GH to shut the peanut gallery up; a lot of people will demand that any large-ish project moves to GH if they aren't already there. That certainly seems like why Golang did it, for one.

cute_boi 6y ago

I used to report bugs but now I don't report any bugs. Many developer thinks that I am reporting issue is adding work on them. I have faced such issue on Gatsby and VScode where they just lock issue.

timdaub 6y ago

On some projects, I took the time to write a nice issue about a bug I sometimes even went so far as to debugging it in the dependencies code. I feel let down when a bot comes along and closes this issue. Maybe it's stale, but the issues sometimes remain...

trinovantes 6y ago

GitHub's generous free plans and accessible UI, especially in recent years, has removed a lot of the barriers that traditionally prevented many people from participating in open source projects. Consequently, this also resulted in a lot more noise on GitHub projects vs projects managed via mailing lists where bug reports are more concise and maintainers are more receptive (at least from my experience with LLVM). I think we're still in a transitional period where nobody really knows how to properly run large scale open source projects with low/no barriers to entry. Even well-funded projects repos like Typescript, VSCode, React receive more issues than they can close. Stale bot is not perfect but some automation is definitely required for these popular repositories. I suspect some barrier to entry may also required for a healthy repository to filter out the noise e.g. mandatory repository that reproduces the bug.

WesolyKubeczek 6y ago
Really makes me wish we go back to mailing lists.

ROARosen 6y ago

I never understood why Github needs to 'lock' the stale issues. Isn't it possible to just 'mark' stale issues as being just that. What's the point of 'locking'?

geerlingguy 6y ago
By default the stale bot does not lock issues. And you can configure it to mark stale, then either close or not close the issue.
- ROARosen 6y ago
  OK let me rephrase that. Why do maintainers choose to lock issues as as opposed to just marking them?
  - raziel2p 6y ago
    Most likely because "me too" or "any update on this?" type comments are extremely common.
    - deathanatos 6y ago
      …perhaps if Github had a way to indicate directly on the bug that it affects you too. (And yes, most of the community is using the "thumbs-up" on the original issue to indicate that. That's a workaround for a missing feature, not a feature.)
      - suprfsat 6y ago
        All of buganizer, monorail, launchpad have a way to indicate that a bug affects you too. Launchpad literally has a button that says "this bug affects me". People simply act obnoxious and entitled for its own sake.
  - Dumbdo 6y ago
    I assume they do that do avoid comments on old issues. If they are already using bots like that they are probably barely able to respond to new issues, so comments on old issues will never be read anyways. By forcing users to open new issues, it increases the chance for replies. That's at least what I understood from bigger repositories. It's not great and most maintainers are aware of the several shortcomings of that practive, but especially in huge repositories there are so many new (and sometimes low effort) issues daily that some maintainers are simply overwhelmed.

geerlingguy 6y ago

There's a huge difference between closing and locking issues. If you close an issue, people can still leave follow-up comments, and the issue can be re-opened if warranted. Some of the best issues on GitHub are closed issues where people have come in months or years after the fact and left useful additional information. Locking an issue leads to tons of duplication, annoying UX, and an overall hostile experience. In the 10,000+ issues I've managed on my own repos over the years, I've locked a grand total of ONE issues and that was just due to some borderline harassment (though unintended) that was going on long after useful discourse was over.

deleted 6y ago
[deleted]
intellix 6y ago
Yep. I also like to leave a paper trail for myself when I'm having a similar issue. I'll typically leave information like workarounds/patches or explain how I ended up there

Ayesh 6y ago

I think a bit that closes (but not lock) issues that keetna certain criteria (maintainer marks is as "needs reporter feedback", and are support issues makes more sense. Big reports shouldn't be discouraged not stale-locked.

chelmertz 6y ago

If the goal is to either reduce the number of open issues, or make it easy to find the most recently reported/recently active issues, it could be accomplished in other ways. What about: - not having "TOTAL issues" as a counter, but "TOTAL RECENTLY ACTIVE issues", for some value of "recently" - defaulting to only showing the RECENTLY ACTIVE issues when searching for them (or finding them through other views) - displaying a warning such as "this issues is dusty, consider it not being prioritized highly" As with all other bug reporting systems, having slices/views to work with seems to be preferred to closing issues. Someone supporting the product might really want to find the issues being "most reacted to" recently, the planning "product manager role" maybe only wants to see the high level "epics/initiatives/visions" in a certain order, etc. I think much of this comes down to all issues being on the same "level" in a Github issue tracker, i.e. "tagging is enough", which some projects solves with a huge taxonomy, and some don't.

gmueckl 6y ago
Even when looking only at recent ticket activity, overall popularity of a project also plays into it. A young project that generates a lot of interest may attract a lot of reports and still work great. An old, unpopular project may be a hot mess but the ticket count is low because the user base isn't there to find issues in the first place.
- onionisafruit 6y ago
  Number of issues shouldn’t be a primary factor in evaluating a project. Maybe GitHub should stop featuring that so prominently in the UI.

joshxyz 6y ago

Stale bots are stupid i wanna smack the face of whoever invented them. Those bots keep closing valid issues!

pingiun 6y ago

IMO NixOS has the right stalebot settings[0]. It was discussed thouroughly in the RFC, as to choose the right information text and other actions by the bot. For example, the bot will only mark the issue/PR as stale and will never close the issue or lock it. Issues are only ever closed by humans. The information text they came up with is quite a bit longer than the ansible one[1]. I think this is a very important point when adding such a bot, otherwise the user will be left helpless. [0]: https://github.com/NixOS/rfcs/pull/51 https://github.com/NixOS/rfcs/pull/51 [1]: https://github.com/NixOS/nixpkgs/pull/92254 https://github.com/NixOS/nixpkgs/pull/92254

iFreilicht 6y ago
Oh wow, that is very well worded! Not only do they explain why issues have to be marked as stale and how the reporter can remove the label. It's also friendly and appreciates that the user made the effort to create an issue in the first place and helps them do more to get attention to the issue.

prepend 6y ago

I’ve run into this on a few projects where PMs want to close all issues. Oddly there’s no external metric on this, it’s just some internal driver. It would result in closing old or low priority items rather than leaving them. It would also result in things not fixed being closed. It was a surreal conversation where I asked how they knew my issue was resolved without asking me, the person who submitted it. The PM said “what do you mean, we closed it. It’s closed.” And it took time to explain the difference between thinking it’s done and properly confirming it’s done. I find the most frustrating as a user is “closed, won’t fix” as for OSS projects someone could eventually submit a fix. Closing “stale” issues is vanity tidying that’s not necessary in a digital, “free” world. I think the fix for this is to look at the “unaddressed” metric to include any closed issues that weren’t resolved. A high number of stale issues closed is a negative metric for a project. But a high number of lingering issues isn’t so bad.

yoz-y 6y ago
A won't fix might make sense if the issue is a feature request that goes against the program philosophy. In that case forking the repo makes more sense. I wholeheartedly agree that closing issues just because they are old is a terrible practice. It's also why I have stopped sending radars. No point of doing work for somebody else if it just generates even more work for me.
- pas 6y ago
  I have no problem with closing them for bugs, because in a few major versions usually the software changes sufficiently to have a good chance of that original bug report simply being obsolete (not reproducible, log/debug output not useful anymore, architecture changes, GUI changes, client software/driver changes, kernel changes, etc.) But in case of a feature request, where the project maintainer agreed it's a long term goal, a bot closing it is just noise, which IMHO discourages useful/insightful comments.
  - yoz-y 6y ago
    I don't think it's justified for bugs either. At least it should be opt-in per bug. It can hide especially sinister bugs that happen only in an uncommon case. This assumes a list of bugs that are actually reproductible bugs not an unfiltered feedback from the clients.

siraben 6y ago

Locking a stale issue seems a bit excessive to me. Nixpkgs, an extremely active repository (> 109K issues and PRs) has the stale bot configured to mark the issue or PR as stale[0] after 180 days. [0] Example: https://github.com/NixOS/nixpkgs/issues/36217#issuecomment-639234148 https://github.com/NixOS/nixpkgs/issues/36217#issuecomment-6...

strenholme 6y ago

I think it’s irresponsible to let bugs languish like this. The way I handle bug reports is to say “Hey, look, I just can’t fix this right now because I’m working full time and don’t know when I’ll be able to get around to fixing this without getting paid for my work.” E.g. https://github.com/samboy/MaraDNS/issues/84 https://github.com/samboy/MaraDNS/issues/84 I can see why a lot of people don’t do that: It’s a little rude, and there’s a small but significant chance it’ll become a flame war. I have only once had someone get rude in a ticket when I told them “That’s not a bug report, but a support issue”; I ended up deleting the ticket. GitHub also allows you to edit or delete other people’s comments in your tickets, as well as locking the conversation.

Hackbraten 6y ago

Some projects use issues to represent maintainer work items. So if no maintainer plans to work on something, why not close the issue? It can be reopened anytime. Locking is a whole different thing because it prevents people from commenting. In closed issues, commenting is allowed though. I think closing an issue with a “thanks, we don’t plan to work on this anytime soon but PRs are welcome” shouldn’t be frowned upon.

ocdtrekkie 6y ago
I disagree heavily because closed issues are less visible. An unresolved issue may be notable for other users to see and communicate about, a closed issue should be "done with". Either it is invalid or it is addressed or fixed. I'd argue developers who use the issues list as a personal todo list are using issues incorrectly.
- Hackbraten 6y ago
  > I'd argue developers who use the issues list as a personal todo list are using issues incorrectly. If that method helps maintainers run their projects efficiently, why would you call it incorrect?
  - ocdtrekkie 6y ago
    Because it is user hostile. Even if it is helpful for them, if it hurts their users, they probably should be doing something else. If you hate your users, why open source at all?
    - Hackbraten 6y ago
      > it hurts their users Please help me understand why you think it hurts users.
- Hackbraten 6y ago
  > I disagree heavily because closed issues are less visible. It takes one single extra click to include closed issues in a search. As a user/contributor, I’d figure that’s a rather small price to pay, given that it helps maintainers handle their workload.

ocdtrekkie 6y ago

I absolutely loathe stale bots. It essentially assumes a problem is irrelevant because nobody has fixed it yet. Sometimes I bother to ask the maintainer to put issues I report on hold. Mostly I just assume if you have a stale bot that you are going to wontfix all my issues and I should find a different project.

8K832d7tNmiQ 6y ago

Isn’t this the reason why Github Discussion exists? To basically become an internal StackOverflow for the repo?

ocdtrekkie 6y ago
I think there's a difference between "languishing issue that hasn't gotten fixed" and a discussion. Both have a purpose, and they are separate purposes.

stblack 6y ago

Our stale bot doesn't lock issues, merely marks them as closed after a configurable notification time, and a configurable no-activity time. Which stale bot is the author referring to? This stale bot (THE stale bot?) https://github.com/probot/stale https://github.com/probot/stale, doesn't even have an option to lock the issue.

intellix 6y ago

Massively agree. Also hate repositories that have issue templates that ask the same reworded question. I typically start writing it out and then just give up cause I can't think of how to answer the same question without just copy/pasting. You still get the typical "how can fix, not work?" issues so why overdo it? Should be simply: 1) What's wrong? 2) What's correct? 3) Reproduction

pas 6y ago
It's (probably? totally!) arrogance, but usually I delete the questions from the template that have already been answered by what I wrote. In my experience the templates are for those who are simply so new to "open source", bug reporting, programming/software-development, GitHub and this amazing Internet thing, that they really benefit from going through it. (Sure, alas many people are inexperienced and doesn't read the templates ... :D)

dathinab 6y ago

I can only agree with that. I have had been involved in to many "stale" but neither fixed nor forgotten issues which would have become very cumbersome if a stale bot was involved. Common reasons for "staleness" include: - blocked on other issues - blocked on external dependencies - blocked because no one has currently time to fix the issue because there are many other high or very high priority issues. This doesn't mean it has low priority, just not high/very high priority. - feature requests which the author agreed to should be implemented, but neither the maintainer nor the issuer has currently time to work on. - feature requests which are braking changes and as such will only included if a new version is made - bugs with low priority if there are higher priority things Sure you can work around this by using many labels and making the stale bot label aware e.g.: - label contains "blocked" => do not stale close - label contains "bug" => do not stale close (and only assign bug if issuer provides the necessary information) - label contains "next-version" => do not stale - label contains "...." => do not stale But that seems somewhat pointless for the large majority of crates. Furthermore I believe stale bots come to some degree from the (IMHO) unrealistic idea that the amount of open issues, issue closing time and issues staleness indicate how health a project is. But the moment you have feature request issues or "will be fixed in next release as braking change" this metrics fall apart completely. Similar some software projects get a lot of spam issues (often an indication that a popular project probably needs some improvements of documentation or UX aspects). For this it can sometimes be reasonable to have stale bot if it doesn't act on certain labels IMHO.

habosa 6y ago

Hmmm there are two things here: 1) Marking inactive issues as stale and eventually closing them automatically. 2) Locking old closed issues so they don't get comments. Many bots do these things and do them badly. I maintain a bot that I think does (1) better. The key is that an issue is only stale if a maintainer has asked a question of the person who filed the issue and that person is not responding. That's the only condition. An issue is NOT stale just because there's been no activity recently. That could just mean the maintainer is on vacation or has other things to do. Repos which have bots that close issues for lack of maintainer action are getting off to easy. I’m a bit more torn about locking old issues. On the one hand it saves you from a lot of low-value “me too” spam comments and lets you focus on only open issues. On the other hand you will miss legitimate regressions.

jsmith45 6y ago
>The key is that an issue is only stale if a maintainer has asked a question of the person who filed the issue and that person is not responding. That's the only condition. The possible issue with that criteria in general is that it need not actually be the original poster who replies with the needed details. Another user with the same problem could supply the needed details as well. A different user supplying the answer is especially common on widespread issues that the maintainers are having problems tracking down. For example, it might be that the problem only reproduces on a certain version of a specific distro, or only if certain kernel configuration options are used. Those sorts of issues can be hard for the maintainer to discover, but might be easier for impacted users to locate. You may well have stuff in place to handle this, but thought it was worth pointing out for completeness sake.
- habosa 6y ago
  My opinion keeps changing on this one. Sometimes a non-author user will come by and say "this is happening to me too and here's some helpful logs". But other times a non-author user will just drive by and say "+1 any solution?". The former should reset the stale timer, the latter should not. I think in the end this depends on the project. In the end you need humans to pay attention to ongoing conversations or you'll always get some cases wrong.

no_wizard 6y ago

I feel this has a lot less value in a world where you enable GitHub discussions. While not a panacea, it does remove the clutter of 'issues as discussions' and allows you to really use the issue tracker for just issues. This is what I would recommend every open source project do on GitHub: - Convert discussion issues to discussions - Label the existing issues as issue type (e.g. bug) if this makes sense for your project - Add an issue template that specifies if it is a feature request / discussion etc that it will be moved to discussions and they should proceed there, otherwise it can be filed as an issue - And importantly, close issues you don't intend to address, and a short explainer why (even if its just 'no longer relevant' or 'is not going to be considered, if requested open a new *discussion etc, make some boilerplate) That makes sense to me at least. I know discussions isn't perfect (far from it) however it cuts down the clutter on the issue tracker and makes it much easier I think to engage with the community (issues have this 'binding' status a lot of the times that discussions implicitly don't, so its much safer to spitball IMHO)

patcon 6y ago

And old rant in their issue queue: https://github.com/probot/stale/pull/107#issuecomment-379021783 https://github.com/probot/stale/pull/107#issuecomment-379021... > Thesis: Stalebot -- in dutiful service of current human resource constraints -- feels like it unthinkingly prioritizes discard of past contributors' time resources, over the mobilization of new human resources. I've had a beef with Stale since early on. It's a very old-world view of solving the problem of open source capacity. A better tool would instead try to find and encourage new resources (new contributors), whereas stalebot drives them away, and so kinda cuts the project off at the knees imho, in the short-term, it rescues the cognitive and emotional resources of current contributors, but (in the long-term) drives future contributors away through promoting lack of care and by encouraging maintainers to not interact with them.

Jugurtha 6y ago

Stale Bots are one thing, it's another thing when a huge company puts an intern in charge of issues and pull requests. You open an issue, and a pull request. The intern fails to see what the problem even is and closes the pull request and the issue telling you they don't see a problem. In other instances, pull requests would sit there for months for use cases that are no-brainers. We made the decision not to contribute to that project and not to maintain a fork. Instead, we developed plugins that are independent so we do not depend on pull requests being accepted, nor have to keep the fork in sync.

jrockway 6y ago

If you open a bug, you are saying "here's a problem I found that's not important enough to me to spend time fixing". The auto-close bot says "we agree that this is not important enough to fix." If you're paying for a support contract and an auto-close bot is closing all your issues, you should stop paying for the support contract, though.

mook 6y ago
Sometimes external contributors do not have the correct power to fix the issues they open; mainly that means the maintainer needs to take some decision (and possibly instruct the issue creator to make a PR). That is, the amount of effort the external person needs to spend time to fix it is "become the maintainer".
pseudalopex 6y ago
Here's a problem I found I don't know how to fix. Here's a problem I found and how I would fix it. Does it sound good to you? Here's a problem I found. It's important enough for me to fix but I can only work on it sporadically. Here's a problem I found. My employer owns everything I write. Here's a problem I found. I'm not a programmer.

habitue 6y ago

Assuming it's not locking an issue, I really like stalebots for internal projects. There are lots of things that just become moot after a while because things change so rapidly. If you run into the problem again, it's always easy to reopen the issue or refer to the old one, usually with more up to date context. It also means if you sort issues by oldest and is:open, you get longstanding problems rather than "things we were worried about 2 years ago, but were never important enough to fix or close".

chrismorgan 6y ago

I’m bemused that this complaint is almost entirely about locking issues. Most I’ve ever had the misfortune to encounter haven’t been locking issues, just closing them, which isn’t quite as bad (but almost). I loathe, despise and abominate the GitHub bot with the name “stale” and think it should be discontinued with prejudice. I have never had a positive experience with it, and genuinely cannot imagine any scenario in which it would provide more value than the harm it causes. What of other stale bots that are more nuanced or that provide more meaningful descriptions of what and why? Well, I can think of one or two interactions over the years that seemed more reasonable (e.g. TypeScript’s “it’s been a while, there aren’t ten votes and it hasn’t been accepted, probably nothing’s going to happen, speak now or it’ll be closed”), but even they still cause substantial harm (duplicates, &c.) because GitHub’s search defaults to excluding closed issues. But most of them should definitely be killed with fire. Ooh, ooh! If we’re ranting about issue management systems, here’s another of mine: free-form text fields with templates. You ever tried searching for a word that happens to appear in the template? Yeah, it’s completely useless. I guess this one could be mitigated by a more intelligent indexer that filtered out the template first.

TonyTrapp 6y ago
I'm completely with you on the free-form text fields. How could we end up with such an unstructured way of filing issues as the default?

skissane 6y ago

I submitted a PR to make a tiny improvement to the libuv documentation... [0] and the stale bot wants to close it on me. I think closing PRs as stale is particularly annoying. [0] https://github.com/libuv/libuv/pull/3076 https://github.com/libuv/libuv/pull/3076

ajnin 6y ago

This tendency to close "stale" issues is a symptom of Goodhart's law [0]. Once the number of open issues is used as a proxy for software quality, then lowering that number becomes a goal in itself. And thus it ceases to be a pertinent metric, and it might even become counter-productive by discouraging contributors. Another reason I think is that it's also a nice excuse to avoid working on old boring stuff and focus on new exciting stuff. https://en.m.wikipedia.org/wiki/Goodhart%27s_law https://en.m.wikipedia.org/wiki/Goodhart%27s_law