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.

[targos]

I created a project to start with: https://github.com/orgs/nodejs/projects/4

[cjihrig]

We also have https://github.com/nodejs/node/projects/16, which refack created a few years ago. It tracks more than feature requests, and hasn't been updated since October 2020.

[mhdawson]

@targos can you provide some outline of how that project would be used and who would have to do what? I think we want to be able to update #41420 to capture whatever the flow we believe we can implement is.

[mhdawson]

@jasnell

If the feature requests are things that are desirable, we should capture those in a list or project somewhere more discover-able than just in a sea of closed issues.

#41420 already says:

If a collaborator believes a feature request must be implemented
they can add the `never-stale` label to the issue and it will
be excluded from the automated feature request handling
as outlined below.

This is the simplest way that collaborators can take action. This allows them to keep issues they believe are needed out of the "sea of closed issues". It would still be better than what we have today because the "sea of open issues" would be smaller as those that are not marked as never-stale will eventually be closed.

I did not include anything more as, today I don't think anybody does anything more. If that's incorrect we should add to #41420 what we are doing or what people are willing to volunteer to do.

[targos]

I'll try to find some time tomorrow to think about it. The utility I see in a project is that we can add custom fields to track the status of the feature requests and create different views to filter and browse them.

[mhdawson]

@targos thanks that makes sense now. If we can create some additional labels on the issues and those can automatically help to generate reports/views that would be useful.

[tniessen]

@mhdawson Can this be closed now that #41420 has landed?

[targos]

I think we can keep this open until https://github.com/orgs/nodejs/projects/4 is ready (or abandoned)

[mhdawson]

@tniessen I'm ok with this closing. I'm hoping to work on adding the action to close feature requests in line with #41420 but I'm also ok with it staying open.

@targos it might make more sense to open a new issue which covers what we want to achieve with https://github.com/orgs/nodejs/projects/4 as a clean issue for discussion on that topic versus the original issue I'd mentiond?

[mhdawson]

@targos would you like to open that other issue and then we can close this one saying that conversation will continue in that new issue?

[targos]

@mhdawson I opened #41988

[mhdawson]

Ok closing this issue.