Closing an inactive feature request?

Question

Consider the following GitHub issue representing a suggested feature.

1. Inactive - has not been commented on in four months
2. Not popular - requested by a single person, and no evidence suggests that anyone else is interested in it
3. No implementation ideas - there have not been any suggestions about how to implement the suggested feature

While perception varies a bit from project to project, are these criteria usually considered sufficient to close the issue? If not, what other criteria should be considered?

Or is the concept of criteria a bad idea to start with, maybe? Or should feature requests not be closed in the first place?

Answer 1

As the question stands, the best option (of the three we're supposed to choose between) is:
"Not Sufficient".

There is, however, a follow-up question:

What other criteria should be considered?

The answer to this is:
This depends on the project, the request and the maintainer's outlook.

There comes a time when it is clear that a feature request is not going to be worked on and it is time to close. When that time comes is not easy to pin down in the generic case.

I maintain projects that has more than two year old feature requests (fitting all of your three criteria) open. I keep such requests open because I (the project owner and maintainer) think the project will benefit from from having such a feature - even it has not attracted any "me too"-responses. I haven't found time to work on it myself, but keeping it open means that it is not off he charts, and a pull request to implement it will be welcome. I usually leave a comment like this:

• I don't think I can find the time to work on this anytime soon, but it looks like a nifty feature, and I will commit a pull request that does a good job implementing it.

And I have closed a feature request after 14 days that fits none of your criteria. In the latter case, the criterion may (for instance) be given as (in somewhat more diplomatic language):

• It is an aim of this project to stay small and lightweight. Your pull request is bloated and ugly, and will only benefit a small group of users who will be better served by using project X for this feature.

Clearly, this is not the only criterion for an almost instant closure - the list is almost infinite (depending on the project, the request and the maintainer's outlook), but you get the idea.

I usually respond to a feature requests with no pull request that is pretty marginal with something that indicates that imminent closure is likely unless the community takes steps to prevent closure. Example:

• I (the maintaner) am not going to work on this feature. This will be closed in about two weeks unless there a pull request is posted in the next two weeks that passes community review for code quality and desirability.

(The latter answer depends on having in place a community driven triage system for pull requests, which I have for all my community driven free software projects.)

Answer 2

Short answer (and not too useful): it is your project, given as a gift to the world. You can do as you please. Here "you" is generically the group actively participating in development.

You should set up some guidelines (the ones you outline in the question look fine to me), and perhaps publish them. Just make sure that nobody feels entitled to have their pet feature implemented because people pester you daily. I'd probably keep a list of new/active/interesting feature requests (say, for some drive-by party to pick up and work on), relegate others to a backburner, and even others to a list of "won't happen" (decorate them with a comment explaining why they won't be considered, if not just by virtue of timeout). How to triage feature requests, and when to move them between lists, is up to you.