Feature request management
Feature requests are a valuable source of input to the project. They help our maintainers understand what additions will be of value to users of the Node.js runtime.
At the same time, the project is volunteer run and does not have the ability to direct resources toward specific work. The features which are implemented are those for which volunteers are individually motivated to work on. The best way to ensure a feature gets implemented is to create a PR to add it. The project strives to support people who do that.
An open feature request does not provide any indication that work on that feature will take place and after some period of time may be detrimental as it may result in an expectation that will never be fulfilled.
This process tries to balance retaining the valuable input we get through feature requests and the overhead of maintaining open feature requests that will never get implemented.
Creating feature requests
A feature request can be created by adding the feature request
label to an issue. This may be done automatically when the issue
is opened or at a later point (often when investigation of a bug
report results in it being considered a feature request as opposed
to a bug).
The current list of feature requests can be found through the is:issue is:open label:"feature request" query.
Triage of feature requests
There is no set process for triaging/handling feature requests.
Individual collaborators review issues marked as feature request
along with other issues and may or may not decide to
work on an implementation or advocate on their behalf.
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.
Expressing support for a feature request
If you come across a feature request and want to add your support for that feature please express your support with the thumbs up emoji as a reaction. At some point in the future we may use this as additional input in the automated handling of feature requests.
Automated feature request handling
Our experience is that most feature requests that are likely to be addressed, will be addressed within the first 6 months after they are submitted.
Once there has been no activity on a feature request for 5 months, the following comment will be added to the issue:
There has been no activity on this feature request for
5 months and it is unlikely to be implemented.
It will be closed 6 months after the last non-automated comment.
For more information on how the project manages
feature requests, please consult the
[feature request management document](https://github.com/nodejs/node/blob/HEAD/doc/contributing/feature-request-management.md).
If there is no additional activity/discussion on the feature request in the next month, the following comment is added to the issue and the issue will be closed:
There has been no activity on this feature request
and it is being closed. If you feel closing this issue is not the
right thing to do, please leave a comment.
For more information on how the project manages
feature requests, please consult the
[feature request management document](https://github.com/nodejs/node/blob/HEAD/doc/contributing/feature-request-management.md).