Closed jasnell closed 6 years ago
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.)
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!)
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.
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.
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.
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).
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.
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.