Managing feature requests

[mhdawson]

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.

[gireeshpunathil]

I had spent some time earlier to classify feature requests. My thinking is that our open RFEs suffer from i) lack of technical assessment ii) drive to initiate / follow up implementation - both may be root caused by reduced number of active collaborators.

Closing a request through voting may be good, if the vote truly reflects interest / disinterest; however it may be an injustice to the isse, if the vote is the result mere inactivity?

Some proposals (along side voting):

• a working group that drives the feature request life cycle
• a slot in the TSC to review the feature request statistics
• a champion / advocate associated with every triaged RFE

[mhdawson]

@gireeshpunathil

Closing a request through voting may be good, if the vote truly reflects interest / disinterest; however it may be an injustice to the issue, if the vote is the result mere inactivity?

I think if we can't either get an advocate with the collaborator base or a number of people showing their support through votes then keeping an open issue does not really help and may give the false impression that something will happen. An issue can always be re-opened if there is interest/support for moving it forward later on.

All of your proposals sound good if we can line up people to do the required work. Some sort of review/curation of the feature requests is needed. I think the approach taken in the angular case is to help narrow the issues to those which have broad support in order to manage the amount of work needed. I could see us adding a periodic review to the TSC meeting but I don't think we would necessarily be able to review all feature requests opened.

[Trott]

It may be worth considering some variation requiring feature requests to go through a lightweight RFC process. The lightweight RFC process could be crafted to guarantee that after a certain period of time, a result of "yes, pending an implementation, this seems like something we'd want" or "no, not right now, although this can be re-submitted at a future date".

Ref: nodejs/TSC#962

[mhdawson]

@Trott I'm not sure I'd want to ask people to do extra work to submit an RFC unless we had a good likelihood that it would have a higher chance of work taking place if it was accepted. I don't think a "default to yes" would do that. Unless there is active support for something it's not really a yes, but more of a nobody cares enough to block at this point.

When somebody is volunteering to implement a new feature and wants/needs input/agreement before investing time the RFC progress would be a good fit. In this case we have people requesting a feature but not volunteering to implement so I'm less sure.

[Trott]

I don't think a "default to yes" would do that.

The way I wrote it wasn't very clear. It's not "default to 'yes'". It's "you will get an answer one way or the other". (And not an answer on whether or not it will happen. Just an answer on whether or not we are interested/open enough to the idea that we think someone somewhere might want to spend some time implementing it.)

[Trott]

I'm not sure I'd want to ask people to do extra work to submit an RFC unless we had a good likelihood that it would have a higher chance of work taking place if it was accepted.

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.

[Trott]

In this case we have people requesting a feature but not volunteering to implement so I'm less sure.

We don't have anyone managing our backlog and we don't have a development roadmap, and that is unlikely to change (and I'm honestly not sure it should change). Given all that, having 1000+ open issues is a problem.

By having hundreds and hundreds of open issues that no one ever looks at or comments on, we convey to the community that opening an issue is a waste of their time.

Closing these kinds of issues if they are inactive/stale is a service. It lets people know that we don't think that feature is going to be implemented any time soon (unless they step up to implement it themselves), and it at least is consistent with a project that tries to keep their issue tracker effective.

[mhdawson]

I'm +1 on the suggestion that we close and suggest that if somebody thinks its important opening an RFC would be a next step. It lines up with my original suggestion that we close after some period of time automatically if they did not meet a certain threshold of votes.

While I still like the idea of somehow letting people vote, the easiest initial step is probably just for them to be closed after some period of inactivity. It looks like stale bot can be limited to act on issues with specific tags so we could enable just for feature requests and then tailor the message along the lines of your suggestion.