4

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?

  • 2
    It's not entirely clear what the body of your question is about to me. Are you asking if all three of your criteria should be fulfilled before a suggested feature should be closed? I'm also not 100% certain that this is on-topic. I feel like proprietary software can get feature requests just as well as open source software. All in all it's a good question though, maybe we can make it work. But I'll vote to close for now. – overactor Jul 23 '15 at 6:02
  • @overactor. I believe this is supposed to be a multiple choice question, where OP want us to pick 1,2, or 3 of the last set of alternatives (where "sufficient" is with related to the first 3). However I've voted to close because the obvious answer: "4) It depends on the project and the maintainer's outlook" is missing. – Free Radical Jul 23 '15 at 7:40
  • 1
    @overactor I was looking for an answer like, e.g. "Those criteria are sufficient, and you should leave the issue open for 2-3 weeks". It's really a question about politeness. I always feel bad closing someone's feature request. How can I rephrase the question to make it satisfactory? Thanks. – Jared Beck Jul 24 '15 at 15:56
  • @overactor a question coincidentally applying to proprietary development as well doesn't make it off topic. – RubberDuck Feb 12 '16 at 10:46
4

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.)

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.