Managing feature requests

[mhdawson]

Discussed in #40823

^{Originally posted by mhdawson November 15, 2021}
We were doing a triage day within the Red Hat Node.js team and as part of that I looked at some of the old issues in the Node.js core repo. Turns out a lot of them are tagged as feature request.

Some stats:

249 issues out of a total of 1318 are feature requests which is 19% of the total backlog.

153 are greater than 1 year old
96 are greater than 2 years old
49 are greater than 3 years old
17 are greater than 4 years old

103 have not been updated for a year
40 have not been updated for 2 years
9 have not been updated for 3 years

Are there people regularly looking at the issues tagged feature request.? Do people look at those issues when finding ways to contribute?

I'm asking because I'm wondering about having 2+ year old issues (7% of the backlog) hanging around if they are not actively reviewed/used.

Some light searching on how feature requests lead me to

• https://blog.angular.io/new-feature-request-process-a9f69d106fc8

Getting some feedback through voting on the feature requests to help identify those which are highly requested and closing those which don't reach a certain threshold makes sense to me.

[mhdawson]

Discussion does not show up on TSC agenda, converting to issue so it shows up/we discuss in next meeting.

[Trott]

Discussion does not show up on TSC agenda, converting to issue so it shows up/we discuss in next meeting.

What do you hope to get as an outcome of the conversation?

[mhdawson]

@Trott an agreement on an approach to manage feature requests.

In the discussion item we've discussed some options and I'm hoping we can get TSC engagement to figure out what is a good path to pursue. Discussion so far is in -> #40823

From the discussion issue I'd be ok with your suggestion:

Sure. So maybe the thing to do is to close feature requests after a certain amount of inactive time with a boilerplate comment that says that:

* The fact that it's being closed is due to lack of discussion or other activity. It is not necessarily an indication that the request itself is unreasonable or being rejected.
* If someone feels like the feature is important and we should not close it, then the next step is for someone to submit an RFC.

As with just about everything that can be interpreted as conflict or negativity, we are really bad at closing issues, no matter how badly needed a deluge of issue-closings is. So if we want to go this route, to the extent that we could automate this with a bot or something, all the better.

I also like the approach of trying to get some community feedback on the issues using ideas along the lines of -https://blog.angular.io/new-feature-request-process-a9f69d106fc8. I could be a simple as documenting that people can +1 a feature request and we'll avoid auto closing those that have more than X +1s.

[targos]

I think we can probably use the new github projects spreadsheet to help us manage feature requests (to be determined how)

[jasnell]

FWIW, I regularly look through the feature requests but I've found that many leave a ton of unanswered questions and most definitely don't fall into a critical/must-have category. I don't think it makes sense keeping the issues open indefinitely but it would be good to capture them somewhere.

[mhdawson]

@jasnell the issues will still be there so no information is going to be lost.

I do agree it would be even better if we could be more pro-active/manged the requests more actively including digesting and storing in a more consumable manner I don't think we have any volunteers to do that.

[jasnell]

Yes, I know they won't be lost but just closing them doesn't capture the difference between "Things people still want" vs. "Things we closed because they're not needed or not wanted"... If the feature requests are things that are desirable, we should capture those in a list or project somewhere more discoverable than just in a sea of closed issues.