GitHub Stale Bots – A False Economy(blog.benwinding.com)
blog.benwinding.com
GitHub Stale Bots – A False Economy
https://blog.benwinding.com/github-stale-bots/
157 comments
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.
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.
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.
I’ve always thought even the auto close bots suck but for a different reason than your thread locking example. That seems particularly terrible.
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).
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).
Makes me hate Angular when I see my old, unsolved, tickets get locked with 100+ upvotes and comments.
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.
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.
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.
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.
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.
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.
Note that even you are not auto-locking, but only auto-closing tickets.
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.
Yes, I've had a similar experience. Gatsby is a dumpster fire once you venture off the beaten path.
Or, stay on the beaten path for too long and get "too big" and it turns into a dumpster fire.
It's also spyware, transmitting your usage without consent:
https://www.gatsbyjs.com/docs/telemetry/
https://www.gatsbyjs.com/docs/telemetry/
"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
1: https://formulae.brew.sh/analytics/
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
1: https://formulae.brew.sh/analytics/
> We track general usage details, including command invocation, build process status updates, performance measurements, and errors.
Sounds like spyware to me to do that without opt-in. Projects that do that wont take your privacy seriously.
Sounds like spyware to me to do that without opt-in. Projects that do that wont take your privacy seriously.
Opt-out telemetry is spyware, regardless of how convenient you might find it to spy on your users without their consent. The only ethical telemetry is opt-in, such as the system Debian uses, where users are given the option to install the "popularity-contest" telemetry package during install, with the default being not installing.
Homebrew is also spyware.
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.
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.
Gatsby is probbably the worst static site generator that exists and I am not really sure what it brings to the table other than incredibly slow build times, pointless use of graphql (which falls apart quite quickly) and an over complicated framework which is difficult to customize and costly to maintain.
Yes, I've seen the same problems from Gatsby and it wouldnt be my first choice, but I do really like it's use of GraphQL - i think it's a smart way to solve a problem that does exist for some use cases.
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.
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.
I found the GraphQL decision really works if you're combining multiple datasources. One example we built in practice is combining a CMS-as-a-service (Contentful, Prismic) and a webshop back-end as a service (Commercetools) to build rich product pages.
Yeah, it can be really helpful when you want to combine multiple data types/sources into a single meta type to query multiple types with just a single graphql query.
It turns out that building a site in plain HTML, without fancy tools, isn't nearly as difficult as using stuff like gatsby once you get down to it.
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.
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.
> infinitely cheaper
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).
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).
That's the cost of hosting the end result. How much of your precious time did you spend building your site in a way to make 'static site hosting' (i.e. a file server behind a CDN) work? Did you put time into some CI workflow on Github to precompile the site and push it to Netlify? Did you mess around with Netlify itself to build what you want?
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?
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?
Nah, no CI workflow, I generate locally. Creating the site was just
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.
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.
> I never went beyond Netlify's free plan
There you go. Go beyond Netlify's free plan and it can get pretty expensive.
There you go. Go beyond Netlify's free plan and it can get pretty expensive.
Not really, you can just easily switch to another solution, like B2+Cloudflare, which costs pennies.
> If you still wanted static output, you could probably serve it locally and then let wget crawl it for you.
Here's the complexity part that tools try to solve.
Here's the complexity part that tools try to solve.
There are decoupled tools like https://statically.io/ to do this. One can have the straightforward builds of GP and still have good static site generation.
cool, we've just made something more complicated than netlify or whatever.
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.
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.
I used Gatsby about 3 years ago and loved it. With that being said, I feel like it's grown well beyond it's useful value proposition for me.
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.
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.
If you are looking for an efficient static site builder try YASSB! [1]
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/...
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/...
I've just started using Eleventy for our site. For someone completely new to this it was bit difficult to start but once off the ground have started to love it. The best thing is if any feature is missing you can quickly write a plugin in javascript.
I like that I can write pretty much normal React in it, and that it has a lot of features and plugins. But I'm still a pretty casual user probably.
Sadly, I've had this same experience with Gatsby.
My experience is different, back when I used it (about a year and a half ago last? Ish?), they seemed to have dedicated community management staff doing the rounds and making sure all issues were acknowledged, tagged, and addressed. Has that changed since then? At the time I found it a really welcoming and active community. I even got a T-shirt for contributing.
I also found the community active and welcoming. I also got a t-shirt. All of my issues were tagged. Unfortunately they weren't fixed, and the stale bot kept marking them as stale. It seemed to me like Gatsby developers were focusing the majority of their time on writing "fun" new features rather than fixing all the sharp edges and broken pipes of the complicated pile of old features.
That fits if we think about it in POSIWID terms: https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
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?
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?
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.
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'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.
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.
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.
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.
> 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.
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.
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.
Those personas are not mutually exclusive. Projects that divide the two don’t tend to be successful, leading to maintainer burnout, and autoclosed issues.
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).
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).
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)
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)
> it’s not about me, but about ways to improve the code
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.
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.
A not-stale bot is needed here, that reacts on stale notifications. /s
Right. In a very different context, I implemented something a lot like this for a game's bug tracker, using assignments.
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.
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.
The problem is it had become not uncommon that
any kind of stale issues get automatically closed not just such which "need feedback".
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.
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.
Yes, this is why I'm describing a design that focuses on just what needs feedback.
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 :)
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".
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".
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.
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.
On (Mozilla's) bugzilla, feature requests (in local jargon, "RFE", request for enhancement) were filed on the same bug tracker and were indexed as bugs, too, long before GitHub existed.
Of course, that led to the same problems, and they eventually allowed customizing the term "bug" on your own bugzilla installations.
Of course, that led to the same problems, and they eventually allowed customizing the term "bug" on your own bugzilla installations.
I remember when I used to work for Oracle, and Oracle's internal home-grown bugtracker (BugDB) had both bugs and enhancement requests logged in it going back to the 1980s. (I actually tried to find the oldest record... the oldest one I could find was from something like 1984 or 1985, if I remember right.)
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.
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.
NPM really exacerbated the problem with the npms.io ranking service. They rank searches like https://www.npmjs.com/search?q=pad%20string on metrics like "quality" and "maintenance". They track how many issues are open more than 7 days, more than 1 month and more than 1 year in order to make a judgment, so there's a strong incentive to aggressively close issues early
> 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.
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.
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.
> I hope the Discussions feature becomes generally available soon.
Discussions can already be enabled on any public repository in the repository Settings ("Options" tab, "Features" section, check the "Discussions" checkbox)
Discussions can already be enabled on any public repository in the repository Settings ("Options" tab, "Features" section, check the "Discussions" checkbox)
Yes. On the other hand, the goal is also to increase the vendor lock-in, by providing everything inside their garden walls, so that people keep going further into giving up any side channel and into putting all their eggs into the same Github basket.
> On the other hand, the goal is also to increase the vendor lock-in, by providing everything inside their garden walls, so that people keep going further into giving up any side channel and into putting all their eggs into the same Github basket.
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.
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.
Agreed. Just moving discussions to Slack is bad for discoverability.
> That's also true but where do you draw the line with vendor lock-in and convenience?
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.
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.
Github issues can be exported to csv [1] and they have an extensive and well documented API. [2]
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
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
It seems like any non-trivial feature will increase vendor lock-in. Dark mode is the only recent GitHub feature that can’t be said to increase lock-in.
Makes me think of having a single issue on a github repo for feature requests and anyone can dogpile onto it. If anyone opens a new issue with a feature request you direct to the other "feature request issue" and close their new issue.
Keeps issue bloat under control and allows users to request features in the same place as the code.
Keeps issue bloat under control and allows users to request features in the same place as the code.
Sounds like somewhere for feature requests and discussions to die.
What's wrong with just tagging feature requests?
What's wrong with just tagging feature requests?
perception of neglected or under-resourced project from too many open issues. I don't like it and its not correlated but thats the realty.
Good point. “Observation” is a better term in my experience.
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.
If they are not fixed, closing the ticket solves nothing.
There is no virtue in having more untracked bugs.
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.
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.
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.
The important thing is that new users would be able to find them, so that non-maintainers can still collaborate.
> 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.
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.
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.
> But it’s a lot quicker and easier to use the default view (and default search).
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.
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.
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.
>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.
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.
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.
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.
Yeah, locking stale issues is crazy.
"Oh, you didn't respond in time, so this issue can never be discussed by anyone again.".
"Oh, you didn't respond in time, so this issue can never be discussed by anyone again.".
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
One reason for the demand to move to GitHub is because it makes it easier to find software to solve a problem which is actually open source software if everyone has a GitHub mirror.
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.
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.
Your case is a bit weird. You're looking for a specific niche codebase, whose authoratative source has disappeared, and end up at a non-authoratiative archive. That's Google on hard mode. If you knew you wanted the reference converter, a more specific Google search would have worked:
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:
https://sr.ht/projects
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.
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:
https://sr.ht/projects
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 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.
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...
I feel let down when a bot comes along and closes this issue. Maybe it's stale, but the issues sometimes remain...
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.
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.
Really makes me wish we go back to mailing lists.
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'?
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.
OK let me rephrase that. Why do maintainers choose to lock issues as as opposed to just marking them?
Some people don't care and necro old threads, just to get the attention. They assume that it's worth pinging all the people involved in that thread, just in case somebody might know about their vaguely-relevant issue. After a while it becomes too tiresome and some maintainers decide that it's worth closing old threads.
Never understood the disdain for "necroposting" - neither here, nor in general in on-line discussions. Yes, posting in an old thread will bump it up to the top of the queue - that's the whole point. The alternative is... to start a new thread on the same topic, which now has no context and will lead to pointless re-treading of the same paths.
• Sometimes there's already a newer, still-alive thread on the same subject (usually created by someone who didn't know there was already a thread on the subject, but sometimes created by someone who "wanted to avoid necroposting" and so intentionally created a new thread.) You shouldn't be posting in thread 1 about topic X, if you could instead be posting in thread N about topic X.
• 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.)
• 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.)
The question for me is "do I want people to read through all this old content or not? is it relevant context or suffocating baggage?". If it's somewhere in between, a middle road option is to create a new thread but link the old one.
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.
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.
Most likely because "me too" or "any update on this?" type comments are extremely common.
…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.)
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.
People simply act obnoxious and entitled for its own sake.
The pessimistic/realist view is that issues are sometimes ignored because, though they may actually be quite important, they are a pain to deal with or the maintainer of contributors just don't want to think about them.
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.
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.
Closing and locking are two different things.
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.
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.
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
[deleted]
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.
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.
- 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.
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.
Number of issues shouldn’t be a primary factor in evaluating a project. Maybe GitHub should stop featuring that so prominently in the UI.
Stale bots are stupid i wanna smack the face of whoever invented them.
Those bots keep closing valid issues!
Those bots keep closing valid issues!
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
[1]: https://github.com/NixOS/nixpkgs/pull/92254
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
[1]: https://github.com/NixOS/nixpkgs/pull/92254
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.
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.
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.
Public ISSUES are important, because they measure the need for a feature. An important issue will generate more noise, and that indicates a lot of people struggle with it. "Me too" is a valuable metric, as is additional reproduction information from other users. User requirements are not final, so the answers to it should not be.
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.
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.
Issues can be tagged. So if there’s a sea of wishes just tag them to reduce confusion and let people know they are low priority.
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.
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.
That's why we ended up with the triage row. This way we had a list of issues we could actually sort and work on. Triage issues were de facto assigned to me, the guy in charge of refining tickets into actionable tasks. Now that I think of it, the triage column was the PM/PO's todo column.
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.
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.
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.
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.
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.
This assumes a list of bugs that are actually reproductible bugs not an unfiltered feedback from the clients.
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-6...
[0] Example: https://github.com/NixOS/nixpkgs/issues/36217#issuecomment-6...
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
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.
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.
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.
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 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.
I'd argue developers who use the issues list as a personal todo list are using issues incorrectly.
> 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.
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.
Sure, but now you're diving through an incredibly thick soup: Some of those issues might have been resolved/fixed, as closed issues should be. Others might be current issues obscured because the maintainer hates their users and closes issues that are not resolved. Instead of having a clear marker on whether or not an issue is still a problem or not, you have to read the full text of every one.
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.
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.
> having a clear marker on whether or not an issue is still a problem or not
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?
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?
So, let's say your project has a bug in a feature.
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.
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.
> because you hate your users
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.”
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.”
> a closed-resolved issue could mean there’s a known workaround, which the user needs to apply.
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.
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.
> 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?
If that method helps maintainers run their projects efficiently, why would you call it incorrect?
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?
If you hate your users, why open source at all?
> it hurts their users
Please help me understand why you think it hurts users.
Please help me understand why you think it hurts users.
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.
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.
Isn’t this the reason why Github Discussion exists? To basically become an internal StackOverflow for the repo?
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.
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, doesn't even have an option to lock the issue.
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.
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
1) What's wrong? 2) What's correct? 3) Reproduction
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)
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)
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.
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.
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.
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 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.
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.
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.
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 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)
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)
And old rant in their issue queue: 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.
> 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.
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.
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.
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.
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.
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".
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.
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.
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".
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".
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.
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.
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?
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
I think closing PRs as stale is particularly annoying.
[0] https://github.com/libuv/libuv/pull/3076
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
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