Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

Proposal: new way of handling feature requests #139

Closed
jasnell opened this issue May 30, 2017 · 7 comments
Closed

Proposal: new way of handling feature requests #139

jasnell opened this issue May 30, 2017 · 7 comments

Comments

@jasnell
Copy link
Member

jasnell commented May 30, 2017

Right now feature requests are opened as issues in the Node.js tracker... where they tend to be labeled as feature requests and are quickly forgotten. The feature-request label has the highest number of issues and the lower number of resolutions.

What I'd like to propose is the creation of a new nodejs/requests repository where feature requests can be directed to and discussed. Much like the node-eps repo, the requests that advance forward are added as individual files with complete descriptions in the repository. This would make it easier for us to track, and would make it easier for someone to locate something they may be able to help out with. Obviously, it would require additional curation and some folks who care enough to keep it updated.

With this proposal... The existing feature request issues in the nodejs/node would be closed.

@Trott
Copy link
Member

Trott commented May 30, 2017

I'm not opposed to this, but all things equal, I'd prefer we find a better way of triaging and handling feature requests in the nodejs repo rather than move it to a separate repo.

There may be some bits and pieces we can pull from https://github.com/maintainerati/events/blob/master/wontfix_cabal/notes-3/backlog.md and other resources. For example, from that document, it might be worth considering:

  • Have a document that defines what's out of scope to make it easier and faster to close feature requests that aren't a good fit for the project. (This would sort of be the opposite of a roadmap, and might be easier to define and maintain than a roadmap.)

  • Related, but come up with rules about feature requests, especially about saying "no" to them. Basically, it is much easier (and probably kinder too) to point to a set of rules or something that logically lead to "no" rather than having established contributors on the project expressing their opinion that a feature is a bad fit.

  • I know closing old PRs just because they're old and inactive has been a somewhat controversial approach, but I think it is probably less controversial with feature requests. If no one is actively working on it, it can be closed with a note that if someone works up a proof of concept, they should open a pull request. (Even for questionable ideas, it's easier to make an informed decision if there is an implementation.)

@Trott
Copy link
Member

Trott commented May 30, 2017

I wouldn't mind discussing this at the CTC meeting this week, if it's not too short notice for people to have a decent think about it ahead of time. Better triaging and management of the issue tracker is one of those things that never gets bad enough for us that it's a crisis, but for which there seems to be huge opportunity for improvement. (Thanks for raising this issue!)

@fhinkel
Copy link
Member

fhinkel commented May 30, 2017

My 2 cents: highly dislike the new repos popping up all the time. Makes it so hard to find any issues because now I have to search over 5 different repos.

@jasnell
Copy link
Member Author

jasnell commented May 30, 2017

A new repo is definitely not ideal, but also having these requests sitting there neglected isn't great either. We definitely need to figure out a more effective system.

@mhdawson
Copy link
Member

The key issue sounds like getting people to review/comment on the feature requests along with guidance to help that process. It might make sense to try to bring people together who are willing/interested in staying on top of that (a team?) and then figure out what the team needs to do in order have visibility/tools required to do the work effectively.

If we don't have people stepping up to lead the effort then the issues will likely languish regardless of where they are.

What I'd like to see is us put together a list of areas/scopes that we need as a team to make sure get some attention and then possibly review the status on that list regularly in the CTC or TSC meetings as appropriate.

@jkrems
Copy link

jkrems commented May 30, 2017

Have a document that defines what's out of scope to make it easier and faster to close feature requests that aren't a good fit for the project.

I think that would definitely help.

I'm not sure if it would create a false sense of democracy but would it make sense to encourage 👍 /subscriptions to issues to mark feature requests that have wide support (obvious downside: encourages flooding the issue with friends & family).

@Trott
Copy link
Member

Trott commented Sep 8, 2017

This issue has been inactive for a while and this repository is now obsolete. I'm going to close this, but feel free to open another issue in a relevant active repository (TSC perhaps?) and include a link back to this issue if this is a subject that should receive continued attention.

@Trott Trott closed this as completed Sep 8, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants