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?

  • onlinepersona
    link
    fedilink
    English
    arrow-up
    4
    Ā·
    13 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