GitHub Stale Bots – A False Economy
blog.benwinding.com
blog.benwinding.com
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.
What do you mean by this? A bug report or feature request will generally come from a “user” and is likely of interest to a “maintainer”. What should the two do if not converse? Neither the maintainer nor the user really knows whether or not an issue will be “reasonably useful to anyone else” without talking about it.
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).
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)
This is true for me, but I also would admit that it's not all altruistic.
Specifically, I will report problems that may be rare for others and unlikely to be reproducible by the maintainer. I often provide information about the operating system, version, etc. in those cases to put a reasonable amount of effort into it, but I don't always expect it to be fixed by the maintainer.
However, if I determine later that the bug was caused by something else, I'll go find the bug I created and add a comment indicating that it was fixed or related to another problem, if it's simple.
Ask the player to clarify something, assign the bug to feedback. If no one ever comments to save it, it'll get nudged a few times before it's automatically dismissed.
It was a godsend, because it got those issues out of the triage queue and didn't return them until they were actionable again.
I.e. you make a bug report, it get's verified but is low priority. Because of higher priority issues the maintainers do not yet work on it. The issues becomes stale and now the maintainers will never work on it unless you always prevent stall or reopen a new issue.
And sometimes there are issues which can not be resolved but still are issues (e.g. (for now) unsolvable bug) IMHO such issue should stay open even if there will not be any work/improvement on them for maybe years.
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.
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.
"Oh, you didn't respond in time, so this issue can never be discussed by anyone again.".
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.
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".
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.
Of course, that led to the same problems, and they eventually allowed customizing the term "bug" on your own bugzilla installations.
And I know the PMs actually went through the enhancement requests the customers logged (I think it was once per a release cycle), and evaluated whether any of them were worthwhile to implement or not.
So, in proprietary software, using a bug tracker to track feature requests is a lot older than Mozilla/Bugzilla.
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.
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.
I hope the Discussions feature becomes generally available soon.
That's also true but where do you draw the line with vendor lock-in and convenience?
If you use Google's mailing list service then you're locked into Google. What if they decide to drop that like many other services in the past?
If you use a self hosted forum / mailing list instead, the repo owner is on the hook for setting up and configuring a server along with potentially registering a domain name just for that aspect of an open source repo. With something like Discourse that could be like $20 / month + domain just for 1 instance of it.
If you decide to use Discord or Slack as a side channel for casual chatting or feature requests then you're locked in there too and there's no persistence (at least not with Slack) or SEO discoverability.
That and with any of the above solutions chances are folks will end up reporting bugs in those side channels which means someone needs to go back and write them up as proper issues, often times that'll be the repo owner. Plus now all users need to jump through hoops by registering on those external platforms to give a feature request on a project on GitHub.
I hate the idea of vendor lock-in but at some point integrated platforms make sense because the alternative is worse. As a developer I really like having my code, CI, issues and a place to chat all in 1 spot. If GitHub dies, that's fine there's always Gitlab. If Gitlab dies, there's always Bitbucket but at this point the developer community would likely revolt and come up with a new solution.
Can I export all the data in a publicly documented, machine-digestible, patent-unencumbered format? Is the site helping, or at least not obstructing, alternative clients for interfacing with the feature?
If the answer to any of these questions is "no", then it's vendor lock-in.
So I'd say, GitHub isn't locked in as of now, they're quite open. But your definition is good, and it's probably a good idea to re-evaluate every now and then.
[1]: https://stackoverflow.com/questions/41369365/how-can-i-expor... [2]: https://docs.github.com/en/rest
Discussions can already be enabled on any public repository in the repository Settings ("Options" tab, "Features" section, check the "Discussions" checkbox)
Keeps issue bloat under control and allows users to request features in the same place as the code.
What's wrong with just tagging feature requests?
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].
Sounds like spyware to me to do that without opt-in. Projects that do that wont take your privacy seriously.
They transmit your unique identifier to Google every time you run brew, which effectively provides Google with your coarse location tracklog via client IP geolocation.
Data collection like this that is done without the consent of the user is extremely unethical, rude, and in some jurisdictions actually illegal. The fact that the data they steal is useful to them is not relevant and your bringing it up is telling.
It actually has nothing to do with whether or not I agree with it, and everything to do with whether or not they obtain consent to exfiltrate this information. Neither Homebrew nor Gatsby obtain the consent of the user to transmit their spying data.
I like Gatsby's createPage API that lets you programatically create pages from source data at any url, rather than the "traditional" approach of binding views to URL patterns. It's useful for some kinds of static sites that might have a radically different template or data source/model for multiple pages that fit the same URL pattern.
Gatsby's use of GraphQL, which can be a pain especially as you scale larger, is nice how it lets you query just the fields you need, so your dehydrated data remains pretty minimal. It's something that I've struggle with when building a site with NextJS - I would have to set up and create my own GraphQL server.
Gatsby is a weird one because it has these "advanced" features that really benefit larger sites (or sites with larger ambitions), but Gatsby really can't handle large sites or data.
Hell, just throw in some PHP if you want dynamic bits and pieces. Your fancy netlify/cloudflare/vercel setup may not like it but your infinitely cheaper shared host/VPS provider will.
If you still wanted static output, you could probably serve it locally and then let wget crawl it for you.
It's actually the opposite. Static site hosting is so much easier to optimize, that it costs just few cents a month, if anything at all (I never went beyond Netlify's free plan).
I can do exactly the same with a cheap VPS running apache and PHP and a deploy is little more than an SCP or FTP upload away. I don't have to worry about a build pipeline at all.
I'm not aiming this at you, but in general I'd love to see how newer engineers would tackle things like deployment if they couldn't rely on some SaaS offering.
Or are we talking about static sites that are static because they do all the server side stuff on the browser, and you're pulling down things like react and graphql to render a blog post?
pip install pelican; git init . ; pelican-quickstart; vim pelicanconf.py # to set the theme
pelican . && git add -A && git commit -m "post title" && git push
But I think you overestimate the time to "setup the CI workflow" actually takes. It's just a text file where you put the commands above, so it can run on the server instead of your machine. There's no black magic to it.
> I don't have to worry about a build pipeline at all.
Of course you do; it's just that your build pipeline runs every time someone accesses your site.
> I'm not aiming this at you, but in general I'd love to see how newer engineers would tackle things like deployment if they couldn't rely on some SaaS offering.
I've done that too. I created a bare git repo on the server, with a post-receive hook that checkouts "master" and runs the static site generator. Then I had Nginx serve the directory.
There you go. Go beyond Netlify's free plan and it can get pretty expensive.
Here's the complexity part that tools try to solve.
Looks like a great tool for migrating an existing dynamic site into a more static workflow, but it's not exactly the workflow I was replying to.
The biggest value was I could share a lot of components between my app and marketing site. Even though most of the marketing site was static content, Gatsby made it incredibly easy to introduce well integrated custom features.
I never hit of the point of needing a full CMS (the site wasn't large enough), so it was great for my needs. Not sure why anyone would use it if they're going full CMS, though.
YASSB processes HTML, (S)CSS, JavaScript/TypeScript, JSX/TSX, JSON, MarkDown and many other files and combines them into beautiful static websites.
I am the creator of YASSB, I'd love to hear what you think about it!
[1] [https://yassb-foss.github.io/](https://yassb-foss.github.io/...
If the true goal of the devs is to do the fun first 25% of the work, then the signs that a particular job hasn't been finished are unwelcome. A stale-bot sweeps most problems under the rug and, as we see in the discussion here, discourages reporting in the first place. The numbers look better, the devs get to feel like things are under control, and they get to rush on to the next shiny thing.
And perhaps it works one layer deeper, too. Their website's all about "fast, fast, fast"! They advertise the ability to "create a complete website in the time it usually takes to build a prototype". I would read a claim like that suspiciously: when I build prototypes, I leave out things that are important for sustainability. But the things I think are "finishing the job right" seem to others as tedious and uninteresting things to be skipped if possible. So perhaps the devs have found themselves an audience like themselves that are fine with a high level of brokenness as long as they get the feeling of moving forward quickly?
• The older thread probably has a bunch of context given within it that's no longer relevant, and will just confuse the people trying to comment in the thread years later (e.g. requirements that are no longer valid or are already satisfied; requests/advice given in terms of architecture that's been refactored away from, or tooling that no longer exists; etc.) These threads are essentially "rotten" — only of value to a cultural anthropologist, not for driving present goals. Better to avoid reviving such a "rotten" thread, and instead to create a new thread on the same subject, where you can provide a fresh context that doesn't conflict with the previous "rotten" context.
IMHO, if comment/forum systems had richer semantics, the ideal would be to have "threads of threads" (meta-threads?), where repeated discussions on the same topic exist both as distinct threads, but also viewed in the context of a larger ongoing meta-thread (sort of like threads within a channel on Slack, but where the "channel" is still just one discussion. Maybe closer to a "user story" issue-tree-node in Jira, that has individual issues nested below it.)
As it is, frequently maintainers use some microformat or issue-tracker annotation to mark new issues as dups of old issues as a reason for closing them. (But I'd honestly suggest that that's backward: usually, the old issue is "rotten"; so a new issue should be allowed on the same topic; and moderators of the forum should go back to old, "rotten" issues and mark them as dups of the new issue, to allow people who find the old issue to follow the link to see the newer discussion on the same topic.)
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.
People simply act obnoxious and entitled for its own sake.
A matter of "out of sight, out of mind" but with the benefit of being able to instantly close off new issues without begetting discussion by marking them as a duplicate of the old locked and closed issue. A roundabout and obfuscated form of the "closed: wontfix/not interested" patterns of yore.
Of course that's not the main or majority reason, but it is there. And it is fair.
- 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.
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.
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.
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.
If they are not fixed, closing the ticket solves nothing.
There is no virtue in having more untracked bugs.
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.
The important thing is that new users would be able to find them, so that non-maintainers can still collaborate.
But it’s a lot quicker and easier to use the default view (and default search).
> 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).
What would be an example where this kind of tracking is useful?
> The important thing is that new users would be able to find them
Users can find them either by full-text search or by browsing all issues.
Yes it is; that's why all the new people would be using it. A maintainer would be visiting a pre-baked search list often, which can be done with things like bookmarks.
> > 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).
> What would be an example where this kind of tracking is useful?
People would be able to find the existing issues and not file duplicates, reducing bug management burden on the maintainers? As a secondary effect, people might be able to collaborate independent of the maintainer.
> > The important thing is that new users would be able to find them
> Users can find them either by full-text search or by browsing all issues.
Yes, they could. But users generally would make new issues, possible mentioning the existing closed ones, because they are still affected by it, causing more noise. Ideally they'd just subscribe to it instead and make no noise for the maintainer.
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.
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.
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.
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.
> 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.
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.
On the other hand, stale TICKETS make it difficult to get an overview of the project and its priorities. Actually important issues can get lost in a sea of wishes. You can't have the team vote on the priority of 400+ tickets with no description, no justification, and no owner. Those tickets just sink to the bottom of the backlog, never to be seen again. On occasion, they're actually important, but hard to notice amid the 400 other tickets.
I always liked Kanban, because the to-do column is sorted. You can only sort a list by going through every item.
When I was the agile whip, I always pushed for separate "triage" and "to do" tickets. The former is a bucket of wishes and stream-of-consciousness tickets. The latter is for tasks we understand and commit to. Our backlog refinement sessions cleaned the triage column, then sorted the to do column.
Also, I don’t have much of an issue with closing low quality issues, but if a user writes up a good issue and it is stale due to low priority, or not enough resources, or whatnot that’s a different story.
I also find it really easy to sort high priority issues amongst 400 because there are comments, likes, and activity on issues. So there’s multiple ways for me to understand what it means.
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.
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.
This assumes a list of bugs that are actually reproductible bugs not an unfiltered feedback from the clients.
I’ve always thought even the auto close bots suck but for a different reason than your thread locking example. That seems particularly 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).
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.
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.
Searching for “Open source foo” often times results in a bad search results: https://www.google.com/search?query=Open+Source+WOFF+generat... doesn’t link to the open source reference C language WOFF generator but https://github.com/search?l=C&q=WOFF&type=Repositories does find it.
https://www.google.com/search?q=ttf2+to+woff+reference+conve...
A more in-depth research effort into the solution space also turned up things like FontForge and github.com/google/woff2, neither of which showed up in the GitHub results, but depending on your use-case are likely to have been compelling options.
I think it's more important to use FOSS infrastructure for FOSS projects than it is for those projects to turn up in a search result. I also think that projects can and should market themselves in a manner which extends beyond appearing in search results. However, I do acknowledge that GitHub search can be useful. I have been thinking about letting you link up repositories hosted on not-sr.ht for your sr.ht projects, which are indexed here:
So you could, for example, have a GitHub repository, a GitLab repository, and a sr.ht mailing list, all under the same project, indexed in one place. This would go a long way towards establishing a single list of FOSS projects. It would be centralized at first, but I have also been thinking about using RSS to federate the project list across many independent sr.ht installations: centralization gone.
I feel let down when a bot comes along and closes this issue. Maybe it's stale, but the issues sometimes remain...
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.
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)
1) What's wrong? 2) What's correct? 3) Reproduction
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)
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.
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.
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.
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.
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.
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".
[0] Example: https://github.com/NixOS/nixpkgs/issues/36217#issuecomment-6...
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.
I'd argue developers who use the issues list as a personal todo list are using issues incorrectly.
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.
It literally makes "issues" worthless as a tool for anyone but the one dude who has it in their head to do things focused solely on themselves and their needs and ignorant to everyone else.
And frankly: Issues is a terrible way to manage your own workload, so doing it harms you and everyone else at the same time. Use a project board or something, there are tools designed for this. Even on GitHub itself, labels and milestones and projects all can be employed to enable reasonable project management... closing user issues without resolving them is definitely not one of them. Seriously, don't do this.
Is that a goal worth pursuing? What problem would be solved by having such a “clear marker”?
> you have to read the full text of every one.
Even if “closed” meant “marked resolved”, wouldn’t you (mostly) still have to read the solution to get any benefit from it?
Someone opened an issue about it, maybe even documented a workaround of some sort, but you didn't have time to fix it, and then you closed it because you hate your users. Now I experience the issue. First place I'm going to look is open GitHub issues. I find nothing, suffer more self-troubleshooting, maybe file an issue myself, because why would I look at closed issues... closed issues are generally resolved! I end up annoying you with an extra issue report, and wasting hours of my time. If I'm lucky enough I happen to run a search that shows me the other user's report, I have no way to reopen the issue. I can maybe "me too" it, but given that you closed it already, I know you don't care.
More than likely, after wasting a bunch of time with your project, I'm going to find someone else's.
Even if, again, even if, your non-standard way of abusing GitHub works for you, it's going to confuse, frustrate, and annoy everyone else you interact with. Which, if you don't hate your users, you should consider a big problem.
In which way do you think repeatedly stating that point is going to help?
> because why would I look at closed issues... closed issues are generally resolved!
I fail to see how this is related. Of course you may end up wasting your time with a new report – unless you include closed issues in your search.
For example, a closed-resolved issue could mean there’s a known workaround, which the user needs to apply. In that case, you have to look at that workaround to solve the issue for you personally. If you miss that closed issue and report it again, you’re going to waste your time, no matter the semantics of “closed.”
I disagree. Because a workaround is generally, and should be treated as, temporary. Which means there should still be an open issue tracking the fact that your software has an unresolved issue.
If that method helps maintainers run their projects efficiently, why would you call it incorrect?
If you hate your users, why open source at all?
Please help me understand why you think it hurts users.
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.
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.
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.
If it _was_, then surely the typical duplicate issue would start with "Reopening #1234" since the user has literally looked at that page already.
I think closing PRs as stale is particularly annoying.
Which stale bot is the author referring to? This stale bot (THE stale bot?) https://github.com/probot/stale, doesn't even have an option to lock the issue.
Those bots keep closing valid issues!