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