this post was submitted on 18 Mar 2025
20 points (100.0% liked)

Cool GitHub Projects

1395 readers
1 users here now

Wormhole

!code_review@programming.dev

Icon base by Caro Asercion under CC BY 3.0 with modifications to add a gradient

founded 2 years ago
MODERATORS
 

One frustrating trend I’ve noticed in many open-source projects is maintainers closing issues as quickly as possible—often in a dismissive and even confrontational manner. It sometimes feels like a game, where the goal is to shut down as many issues as possible rather than foster meaningful discussion.

But here’s the thing: issues aren’t just demands for the maintainer to do work. They serve a much bigger purpose in open-source projects:

✅ They help users realize they’re not alone—people with the same issue can come together, share insights, or even hire someone to solve it.

✅ They serve as documentation—a record of what’s been discussed, what problems exist, and what solutions have been proposed.

✅ They create opportunities for new contributors—someone trying their hand at coding might pick up an issue, or someone with the same problem might decide to implement a fix.

✅ They signal what users actually need—even if the maintainer doesn’t plan to fix something, an open issue can indicate demand to potential contributors.

But when an issue gets shut down immediately, all of this breaks down. Closed issues don’t appear in GitHub’s default search, meaning 99% of people who might have seen it now won’t. This leads to:

  • Duplicate issues because users can’t find past discussions.
  • Missed opportunities for new contributors to pick up low-hanging fruit.
  • Users feeling unheard, which can make them disengage from the project entirely.
  • Preventing others from seeing the issue and potentially contributing.

So why do some maintainers do this? Why Maintainers Close Issues So Aggressively

There are a few common reasons:

🔹 Burnout & Overload – Many maintainers are drowning in issues, and closing them fast is a survival mechanism.

🔹 Entitlement Fatigue – Dealing with demanding users can make maintainers defensive and dismissive, even toward good-faith issues.

🔹 “Keeping the Board Clean” Mentality – Some maintainers see issues as a to-do list, not a place for discussion. They close anything that doesn’t fit their personal roadmap.

🔹 Power Trip – Let’s be honest—some people just like saying “no.” They get used to shutting things down and enjoy exerting control.

🔹 Lack of Interest – Not every maintainer wants new features or community discussions. Some prefer to build things their own way and reject anything that doesn’t align.

Of course, every project is different, and maintainers have the right to decide how they manage their issue tracker. But closing everything by default discourages contribution and community involvement. A Better Approach?

Instead of aggressively shutting things down, maintainers could:

✅ Leave issues open for discussion, even if they don’t plan to act on them.

✅ Use labels like “help wanted” or “waiting for contributors” instead of closing things outright.

✅ Let issues sit for a while to gauge community interest. If nobody cares, they’ll fade naturally. If people keep commenting, that’s a sign it’s worth keeping open.

✅ Recognize that open-source isn’t just about code—it’s about community. The issue tracker isn’t just for them, it’s for everyone who might contribute.

What’s your experience with this? Have you seen issue-closing behavior that helped or hurt a project?

top 6 comments
sorted by: hot top controversial new old
[–] FizzyOrange@programming.dev 8 points 6 days ago

I guess it's just because they don't want things cluttering up the open issue list that are completely irrelevant. But I agree many projects go way too far, especially

  • Locking issues. Just don't. Unless there's some spam or political issues or something, don't do it. I have several times come across an issue that was closed and locked but maybe not actually fixed and I have relevant info but can't add a comment. Why?
  • Stalebot. Don't use it. It is bad. It's ok to ask "is this still relevant?" and close it if you don't get a reply, but don't imagine you can automatically clean up your backlog with something as blunt force as just closing everything without a recent comment or enough emojis or whatever. Some bugs just exist for a long time. Ignoring them doesn't mean they are fixed.
[–] ravermeister@lemmy.rimkus.it 5 points 6 days ago* (last edited 6 days ago) (1 children)

For me there is a tipping point, for example the OpenApi Generator has 4,7k open issues, which could prevent people from jumping in because you feel overwhelmed from issues

[–] interdimensionalmeme@lemmy.ml 4 points 6 days ago (2 children)

That sounds like a vibrant and healthy community. That means for any aspect thete is probably 10 issues that point toward the solution.

[–] onlinepersona@programming.dev 6 points 6 days ago

Agreed. It has 4.7k open issues, but 4.2k closed issues. That's about 50/50. And the have 11k closed PRs with 500 open. I think that's pretty amazing. If they added the "good first issue" tag, it could help with beginners feeling overwhelmed.

Anti Commercial-AI license

[–] sxan@midwest.social 5 points 6 days ago

It also indicates someone isn't curating the bug list. I'll bet at least 20% are straight-up duplicates, and a fair number of the rest are as you describe: the same issue, under different disguises.

That's a lot of tickets for that amount of software.

[–] onlinepersona@programming.dev 4 points 6 days ago

Very well put. Bots that automatically close bugs are annoying, especially when they just close it instead of pinging the user to ask if the ticket is still valid. It has led me to check the number of closed issues before using stuff because I don't trust the issue count.

Anti Commercial-AI license