But as for the policy itself, why not? If an issue is inactive for 60 days it's very likely to stay so forever.
Many issues are evergreen and people will come around continue to comment on them as they get hit. The idea that no one comments on old issues is simply a false premise.
If you look up examples of stalebot feedback the only people who think its a good idea are people literally only caring about how many issues are open.
GitHub stale bot considered harmful | https://news.ycombinator.com/item?id=28998374
Or a longing for “cleanliness” by just throwing things away.
Reminds of a TV show scene where doing the dishes meant using them for target practice. If you have no dishes, there is no dishes to do!
If a team does not have the bandwidth to fix an issue, closing it acknowledges this and doesn't leave people in false hope. Ideally with a status like 'won't fix' to clarify the situation. Users can move on and deal with the reality, perhaps even rally resources if they are in a position to do so, so the issue can be reopened and addressed. Everyone hates it when you get a 'me too' or 'the developers suck' email to a bug opened 15 years ago. The bug is making the world a worse place.
Secondly, the larger the collection of open issues the harder it is to actually triage and manage. There are plenty of projects where everyone would benefit if the issue tracker suffered catastrophic data loss. So many dangling issues in features that no longer exist or are completely unrecognizable, making it impossible to separate the wheat from the chaff. You are in a twisty maze of 30,000 issues, all of them alike. What should I be working on?
Unfortunately, people react to the first reason poorly if their issue gets closed as won't fix. They take it personally and abuse the developers. So we generally don't use won't fix, because of people being hostile. And then triage falls behind. And then you find you have an unmaintainable bug database of 30,000 open issues, un-triaged, many duplicated, unknown how many actionable. 'open' status has become the unofficial 'wont fix'. When you submit a new bug, you hope someone is watching and you get lucky and someone assigns it 'in progress' or sticks it on a task list. The bug tracker gets bypassed, with real issues going via back channels to developers. The project realizes it has a problem and makes it harder to submit bugs, in a hope they can get on top of things.
Has happened with over a dozen I’ve opened. What you’re saying may be true of Anthropic (and you've done a good job justifying it for them) but certainly not its competition.
They only manually close my feature request tickets if they've been open for a long time (several months) without "upvotes" from the community and aren't already planned. A senior engineer always explains why they're closing these.
if (botCommentDate < oneMonthAgo) {
// Close the issue - it's been stale for 60+ days
Hard to imagine how this got past code review...https://github.com/anthropics/claude-code/blob/5e3e9408feea9...
This implies they do any. Every Claude Code release is full of regressions and new features that are released barely work or need hotfixes.
dcreater•1w ago
bmitc•1w ago
I wonder if it's because of cost.
sdwr•1w ago
stuckinhell•1w ago