Framework for closing GitHub issues on an open source project

[maya]

Hey Ben, I was wondering if you knew of any decision frameworks around closing issues on an open source project. For example, close when stale vs. leave open, what to do when it's an interesting idea but don't have plans to do it, etc...

It's a balance between keeping issues at a manageable level for a team and still being open to contributors (e.g. they could be offended if you closed their issue and discouraged to open new issues). Thanks!

[benbalter]

I used to be in the "don't close" camp, but since activating probot stale on some long-running projects that I maintain, a simple "hey, is anyone still interested in this?" on year+ old issues, can go a long way to help prioritize (and lessen maintainer guilt/burnout).

From Probot's docs:

In an ideal world with infinite resources, there would be no need for this app.

But in any successful software project, there's always more work to do than people to do it. As more and more work piles up, it becomes paralyzing. Just making decisions about what work should and shouldn't get done can exhaust all available resources. In the experience of the maintainers of this app—and the hundreds of other projects and organizations that use it—focusing on issues that are actively affecting humans is an effective method for prioritizing work.

To some, a robot trying to close stale issues may seem inhospitable or offensive to contributors. But the alternative is to disrespect them by setting false expectations and implicitly ignoring their work. This app makes it explicit: if work is not progressing, then it's stale. A comment is all it takes to keep the conversation alive.

In my mind, if a feature was requested or a bug reported that nobody currently using the project wants added/fixed, it should be closed. If it's something that there's still active interest in (by maintainers and users), you should leave it open, potentially with a "help wanted" label to funnel the communities efforts and provide opportunities to contribute where they can most benefit users.

[benbalter]

I asked some of GitHub's open source maintainers, and the general consensus is "close it if you're not going to work on it any time soon", which my coworkers ironically pointed me to https://ben.balter.com/2018/05/04/yes-no-maybe/.

[maya]

This is really helpful, thanks! Someone also mentioned the idea of labeling something you close which is a maybe or "good idea but not right now" so you can come back to it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.