Filename: ///usr/share/////doc////nodejs//contributing//feature-request-management.md

# 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"](https://github.com/nodejs/node/issues?q=is%3Aissue+is%3Aopen+label%3A%22feature+request%22) 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: ```markdown 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: ```markdown 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). ```

./Ninja\.