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.
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).
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 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.
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.
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.
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.
"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].
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.
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 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.
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.
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?
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'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 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.
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.
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.
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.
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.
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).
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)
> 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.
Those personas are not mutually exclusive. Projects that divide the two don’t tend to be successful, leading to maintainer burnout, and autoclosed issues.
> 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.
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.
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 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".
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.
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.
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?
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.
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.
> 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)
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.
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
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.
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.
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.
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.
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 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.
> 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).
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 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.
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.
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.
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.
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.
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:
A more in-depth research effort into the solution space also turned up things like FontForge and github.com/google/woff2, neither of which showed up in the GitHub results, but depending on your use-case are likely to have been compelling options.
I think it's more important to use FOSS infrastructure for FOSS projects than it is for those projects to turn up in a search result. I also think that projects can and should market themselves in a manner which extends beyond appearing in search results. However, I do acknowledge that GitHub search can be useful. I have been thinking about letting you link up repositories hosted on not-sr.ht for your sr.ht projects, which are indexed here:
So you could, for example, have a GitHub repository, a GitLab repository, and a sr.ht mailing list, all under the same project, indexed in one place. This would go a long way towards establishing a single list of FOSS projects. It would be centralized at first, but I have also been thinking about using RSS to federate the project list across many independent sr.ht installations: centralization gone.
I 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.
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 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'?
…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.
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.
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.
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.
• 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 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.
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.
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
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
157 comments
[ 1.5 ms ] story [ 322 ms ] threadI’ve always thought even the auto close bots suck but for a different reason than your thread locking example. That seems particularly terrible.
I am fine with auto-close because they can indicate reality if they are closed with a WONTFIX status: nobody will work on fixing this. As opposed to eg OBSOLETE status which is not necessarily reality.
If there is no explicit comment indicating how the project doesn't even want this, it is still an invitation for someone else to solve it themselves (for a free software project).
Locking issues is hostile to the user experience, especially for issues that could be deemed as bug reports and where users could still collaborate among themselves in the closed issue.
For internal repositories we find this to be really valuable in my company, the odd duplicated branch (when we couldn't get through CI for some reason, but recreating the branch) for whatever reason will be garbage collected, and all those `[CHORE]` branches people quickly hacked up without following our issue tracking process will be GC'ed too, if not handled.
We run our (home made, with GitHub Actions, actually) bot in two stages, 30 days without activity, they get a label and a comment "stale, will be closed in 5 days, remove the stale label to prevent this", and then closure.
This works great, except when people take extended vacation, or happen to switch between teams with WIP branches that are unmerged, but because Git never really loses anything, we've never lost work this way,we just benefit from easier summaries when looking for PRs to review, and having better metrics about mean time to merge, and other factors.
https://www.gatsbyjs.com/docs/telemetry/
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/
Sounds like spyware to me to do that without opt-in. Projects that do that wont take your privacy seriously.
They transmit your unique identifier to Google every time you run brew, which effectively provides Google with your coarse location tracklog via client IP geolocation.
Data collection like this that is done without the consent of the user is extremely unethical, rude, and in some jurisdictions actually illegal. The fact that the data they steal is useful to them is not relevant and your bringing it up is telling.
It actually has nothing to do with whether or not I agree with it, and everything to do with whether or not they obtain consent to exfiltrate this information. Neither Homebrew nor Gatsby obtain the consent of the user to transmit their spying data.
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 like Gatsby's createPage API that lets you programatically create pages from source data at any url, rather than the "traditional" approach of binding views to URL patterns. It's useful for some kinds of static sites that might have a radically different template or data source/model for multiple pages that fit the same URL pattern.
Gatsby's use of GraphQL, which can be a pain especially as you scale larger, is nice how it lets you query just the fields you need, so your dehydrated data remains pretty minimal. It's something that I've struggle with when building a site with NextJS - I would have to set up and create my own GraphQL server.
Gatsby is a weird one because it has these "advanced" features that really benefit larger sites (or sites with larger ambitions), but Gatsby really can't handle large sites or data.
Hell, just throw in some PHP if you want dynamic bits and pieces. Your fancy netlify/cloudflare/vercel setup may not like it but your infinitely cheaper shared host/VPS provider will.
If you still wanted static output, you could probably serve it locally and then let wget crawl it for you.
Here's the complexity part that tools try to solve.
Looks like a great tool for migrating an existing dynamic site into a more static workflow, but it's not exactly the workflow I was replying to.
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).
There you go. Go beyond Netlify's free plan and it can get pretty expensive.
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?
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.
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 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 it _was_, then surely the typical duplicate issue would start with "Reopening #1234" since the user has literally looked at that page already.
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.
And the worse fact is, in terms of sponsorships the 10% of people who are more helpful in the issue queues and are already helping make maintainers lives easier are often the ones who consider sponsorship or other means of support.
That's great, but it's disheartening that the people who feel entitled to an answer about a support question are almost 100x less likely to show any kind of support to open source projects (monetary or otherwise).
90% of users don't understand your product as well. They haven't totally bought in. They will need more support/handholding in order to convert. People are trying to get your product to work for their situation and if they can't 90% will go away and 10% will ask (usually dumb questions).
Your unhappy with the 10% who can't get it working but want your product to work enough to bother to ask?
I guess you can feel that way. Those 10% do represent an opportunity to get a group of people who want to use your product to onboard. The ones who tried and failed and never asked a question will probably never come back. If you ultimately want more support you are going to need to convert this group (or invest more time in advertising hoping to get more superusers/fanboys)
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.
This is true for me, but I also would admit that it's not all altruistic.
Specifically, I will report problems that may be rare for others and unlikely to be reproducible by the maintainer. I often provide information about the operating system, version, etc. in those cases to put a reasonable amount of effort into it, but I don't always expect it to be fixed by the maintainer.
However, if I determine later that the bug was caused by something else, I'll go find the bug I created and add a comment indicating that it was fixed or related to another problem, if it's simple.
Ask the player to clarify something, assign the bug to feedback. If no one ever comments to save it, it'll get nudged a few times before it's automatically dismissed.
It was a godsend, because it got those issues out of the triage queue and didn't return them until they were actionable again.
I.e. you make a bug report, it get's verified but is low priority. Because of higher priority issues the maintainers do not yet work on it. The issues becomes stale and now the maintainers will never work on it unless you always prevent stall or reopen a new issue.
And sometimes there are issues which can not be resolved but still are issues (e.g. (for now) unsolvable bug) IMHO such issue should stay open even if there will not be any work/improvement on them for maybe years.
I'd often hear people complain in the lines of "it's has a lot of stars and constant commits but there's over 100 issues so we might want to avoid it". Which really rarely correlates. Maybe the term "issues" is just too loaded, especially when often those are feature suggestions or even information/how-to tickets - not exclusively bugs or "issues".
Before Github, it wouldn't have come across any sane mind to file a feature request or other discussion/information under the name 'issue', for... they are not issues. It would have gone on a mailing-list (occasionally a web-forum). Issues (identified bugs) on the bug tracker, and the rest in a place of discussion.
Agreed.
But GitHub is also slowly fixing this.
For example the "Discussions" beta feature is enabled for specific repos. Here's it in action for the ImageMagick repo at https://github.com/ImageMagick/ImageMagick/discussions.
It's only available on a small subset of repos tho and it's something you can turn on and off at the repo level. I was given the option to enable it in my one of my repos, but it's a fairly new project with no discussions yet https://github.com/nickjj/flask-db/discussions.
I hope the Discussions feature becomes generally available soon.
That's also true but where do you draw the line with vendor lock-in and convenience?
If you use Google's mailing list service then you're locked into Google. What if they decide to drop that like many other services in the past?
If you use a self hosted forum / mailing list instead, the repo owner is on the hook for setting up and configuring a server along with potentially registering a domain name just for that aspect of an open source repo. With something like Discourse that could be like $20 / month + domain just for 1 instance of it.
If you decide to use Discord or Slack as a side channel for casual chatting or feature requests then you're locked in there too and there's no persistence (at least not with Slack) or SEO discoverability.
That and with any of the above solutions chances are folks will end up reporting bugs in those side channels which means someone needs to go back and write them up as proper issues, often times that'll be the repo owner. Plus now all users need to jump through hoops by registering on those external platforms to give a feature request on a project on GitHub.
I hate the idea of vendor lock-in but at some point integrated platforms make sense because the alternative is worse. As a developer I really like having my code, CI, issues and a place to chat all in 1 spot. If GitHub dies, that's fine there's always Gitlab. If Gitlab dies, there's always Bitbucket but at this point the developer community would likely revolt and come up with a new solution.
Can I export all the data in a publicly documented, machine-digestible, patent-unencumbered format? Is the site helping, or at least not obstructing, alternative clients for interfacing with the feature?
If the answer to any of these questions is "no", then it's vendor lock-in.
So I'd say, GitHub isn't locked in as of now, they're quite open. But your definition is good, and it's probably a good idea to re-evaluate every now and then.
[1]: https://stackoverflow.com/questions/41369365/how-can-i-expor... [2]: https://docs.github.com/en/rest
Discussions can already be enabled on any public repository in the repository Settings ("Options" tab, "Features" section, check the "Discussions" checkbox)
Keeps issue bloat under control and allows users to request features in the same place as the code.
What's wrong with just tagging feature requests?
Of course, that led to the same problems, and they eventually allowed customizing the term "bug" on your own bugzilla installations.
And I know the PMs actually went through the enhancement requests the customers logged (I think it was once per a release cycle), and evaluated whether any of them were worthwhile to implement or not.
So, in proprietary software, using a bug tracker to track feature requests is a lot older than Mozilla/Bugzilla.
If they are not fixed, closing the ticket solves nothing.
There is no virtue in having more untracked bugs.
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 think that if a project uses that model then there’s nothing wrong with closing issues if you don’t intend to ever work on them.
The important thing is that new users would be able to find them, so that non-maintainers can still collaborate.
But it’s a lot quicker and easier to use the default view (and default search).
> I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair).
What would be an example where this kind of tracking is useful?
> The important thing is that new users would be able to find them
Users can find them either by full-text search or by browsing all issues.
Yes it is; that's why all the new people would be using it. A maintainer would be visiting a pre-baked search list often, which can be done with things like bookmarks.
> > I believe the important thing is to make the default search return the issues that the maintainers are not working on, so that known issues are still tracked (but possibly out of the maintainer's hair).
> What would be an example where this kind of tracking is useful?
People would be able to find the existing issues and not file duplicates, reducing bug management burden on the maintainers? As a secondary effect, people might be able to collaborate independent of the maintainer.
> > The important thing is that new users would be able to find them
> Users can find them either by full-text search or by browsing all issues.
Yes, they could. But users generally would make new issues, possible mentioning the existing closed ones, because they are still affected by it, causing more noise. Ideally they'd just subscribe to it instead and make no noise for the maintainer.
My main gripe with stale bots is that some have incredibly short timelimits attached to them. We were arguing about the expectations from users on maintainers to fix their issues immediately and I was strongly arguing that users can expect oss maintainers who are not compensated for their work to just jump.
But there is also the other side to it, if I report a bug and the maintainer gets to it and ask for some more information (sometime quite extensive) to close the bug because I didn't reply within a week. I also have a live outside of reporting bugs.
"Oh, you didn't respond in time, so this issue can never be discussed by anyone again.".
I also use the stale bot, but with many labels excluded. If an issue has a proper label, it will stay open forever. If it's just a question or support request, it will be closed after 2 months.
This prevents me from reviewing too many irrelevant and outdated issues, where the reporter moved on a long time ago.
If a bug report does not immediately catch the attention of the maintainers under such circumstances, it's unlikely to do so later on. The maintainers don't care about dupes, because they didn't care about the original either. They're going to have tens of thousands of tickets no matter what.
Of course, if you find yourself at the wrong end of this process, the best way to get attention for your bug report is to attach a patch.
Maintainers actions demonstrate their priorities, which are driven by their funding rather than community needs. This is the difference between community driven projects and corporate driven ones (even if the corporate drive is indirect via funding). Writing a patch is often the only path forward and often even that is ignored or nit picked until people move on.
Searching for “Open source foo” often times results in a bad search results: https://www.google.com/search?query=Open+Source+WOFF+generat... doesn’t link to the open source reference C language WOFF generator but https://github.com/search?l=C&q=WOFF&type=Repositories does find it.
https://www.google.com/search?q=ttf2+to+woff+reference+conve...
A more in-depth research effort into the solution space also turned up things like FontForge and github.com/google/woff2, neither of which showed up in the GitHub results, but depending on your use-case are likely to have been compelling options.
I think it's more important to use FOSS infrastructure for FOSS projects than it is for those projects to turn up in a search result. I also think that projects can and should market themselves in a manner which extends beyond appearing in search results. However, I do acknowledge that GitHub search can be useful. I have been thinking about letting you link up repositories hosted on not-sr.ht for your sr.ht projects, which are indexed here:
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 feel let down when a bot comes along and closes this issue. Maybe it's stale, but the issues sometimes remain...
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.
People simply act obnoxious and entitled for its own sake.
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.
• 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.)
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.
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.
- 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.
Those bots keep closing valid issues!
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
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.
I wholeheartedly agree that closing issues just because they are old is a terrible practice. It's also why I have stopped sending radars. No point of doing work for somebody else if it just generates even more work for me.
But in case of a feature request, where the project maintainer agreed it's a long term goal, a bot closing it is just noise, which IMHO discourages useful/insightful comments.
This assumes a list of bugs that are actually reproductible bugs not an unfiltered feedback from the clients.
On the other hand, stale TICKETS make it difficult to get an overview of the project and its priorities. Actually important issues can get lost in a sea of wishes. You can't have the team vote on the priority of 400+ tickets with no description, no justification, and no owner. Those tickets just sink to the bottom of the backlog, never to be seen again. On occasion, they're actually important, but hard to notice amid the 400 other tickets.
I always liked Kanban, because the to-do column is sorted. You can only sort a list by going through every item.
When I was the agile whip, I always pushed for separate "triage" and "to do" tickets. The former is a bucket of wishes and stream-of-consciousness tickets. The latter is for tasks we understand and commit to. Our backlog refinement sessions cleaned the triage column, then sorted the to do column.
Also, I don’t have much of an issue with closing low quality issues, but if a user writes up a good issue and it is stale due to low priority, or not enough resources, or whatnot that’s a different story.
I also find it really easy to sort high priority issues amongst 400 because there are comments, likes, and activity on issues. So there’s multiple ways for me to understand what it means.