> I would first suggest looking into pi.dev
Looked into this one. Thought it was suspicious that it only had 7 open issues on github. Turns out they have a bot that auto-closes every single issue just because.
I honestly have no words.
> I would first suggest looking into pi.dev
Looked into this one. Thought it was suspicious that it only had 7 open issues on github. Turns out they have a bot that auto-closes every single issue just because.
I honestly have no words.
Their process is outlined here: https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...
> Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar below will not be reopened or receive a reply.
Seems like not an unreasonable way to deal with the problem of large numbers of low quality issues being submitted.
If that process actually happens then there’s absolutely no reason not to have the reviewing maintainer close it after review instead. The only reasonable conclusion is that documented process is aspirational at best and vibed itself at worst.
Sounds like a perfect way to agitate the community going against the established culture like that.
The established culture on a lot of projects is that you open an issue, and then you have to keep pinging it every week otherwise the stale bot closes it with "this issue is stale, closing, but your contribution is very important to us".
It's crap either way.
But how is it any different from keeping them open?
Like if they are going to sort through all the issues eventually (like they claim), why not just close the ones that are not worthy when they get to them instead of closing all by default?
Is it just so that the project doesnt have open issues on its github page? But they are open issues in reality because the maintainer will eventually go through them?
Nothing is "unreasonable" in the sense that an open source project should have the right to do what it wants with its rules but its definitely a weird stance.
They address the decision at the end of those contribution guidelines linked above, specifically:
It is a guardrail against burnout and tracker spam
Its based on their implied perspective that the majority of submissions don't follow those guidelines which helps determine their quality threshold.
https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...
> But how is it any different from keeping them open?
If all open issues are actionable items, that makes expected workload a lot easier to handle.
If most open issues are actually in "needs triage / needs review" state, you lose the signal from the noise.
The issue tracker for a project exists primarily as a tool for maintainers, not for outsiders. Yes, the maintainers could change their workflow to create a new view that only shows triaged tickets.
Or, they could ensure the default 'open' view serves their needs.
Somehow going through closed issues just to reopen them sounds like more effort than just using the built in label system which is made for this purpose, but maybe that's just me.
I can either change my daily workflow to accommodate the noisy herd, or I can change the noisy herd to accommodate my daily workflow.
The maintainer, Mario, sometimes declares the repo is on an “issue holiday” where issues are auto closed. This particular holiday is because there is a big refactor coming up. In non holiday periods issues can be reported as normal.
They have a pretty decent explanation.
https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...
"Decent" is doing some work. This is going beyond any norms I've encountered in OSS to close issues by default via a LLM or an "issue holiday".
These aren't normal times though. Low quality submissions have suddenly seriously amplified with the use of LLMs. There has to be a response so project quality and maintainer sanity can be preserved.
It was pretty well received when mitchellh copied the idea and formalized it into vouch.
- https://news.ycombinator.com/item?id=46930961 - https://github.com/mitchellh/vouch
The idea is for it to he extremely minimal which strikes me as a very opinionated stance, and not opinions I agree with.
It's a very interesting project. Many popular open source projects are inundated with poor quality issues and prs, hence the defences they are starting to erect.