1# Feature request management 2 3Feature requests are a valuable source of input to the project. 4They help our maintainers understand what additions will be of 5value to users of the Node.js runtime. 6 7At the same time, the project is volunteer run and does not 8have the ability to direct resources toward specific work. The 9features which are implemented are those for which volunteers 10are individually motivated to work on. The best way to ensure 11a feature gets implemented is to create a PR to add it. 12The project strives to support people who do that. 13 14An open feature request does not provide any indication that work 15on that feature will take place and after some period of time 16may be detrimental as it may result in an expectation that will 17never be fulfilled. 18 19This process tries to balance retaining the valuable input 20we get through feature requests and the overhead of 21maintaining open feature requests that will never get 22implemented. 23 24## Creating feature requests 25 26A feature request can be created by adding the `feature request` 27label to an issue. This may be done automatically when the issue 28is opened or at a later point (often when investigation of a bug 29report results in it being considered a feature request as opposed 30to a bug). 31 32The current list of feature requests can be found through the 33[is:issue is:open label:"feature request"](https://github.com/nodejs/node/issues?q=is%3Aissue+is%3Aopen+label%3A%22feature+request%22) query. 34 35## Triage of feature requests 36 37There is no set process for triaging/handling feature requests. 38Individual collaborators review issues marked as `feature request` 39along with other issues and may or may not decide to 40work on an implementation or advocate on their behalf. 41 42If a collaborator believes a feature request must be implemented 43they can add the `never-stale` label to the issue and it will 44be excluded from the automated feature request handling 45as outlined below. 46 47## Expressing support for a feature request 48 49If you come across a feature request and want to add your 50support for that feature please express your support 51with the thumbs up emoji as a reaction. At some point in the 52future we may use this as additional input in the automated 53handling of feature requests. 54 55## Automated feature request handling 56 57Our experience is that most feature requests that are 58likely to be addressed, will be addressed within the first 596 months after they are submitted. 60 61Once there has been no activity on a feature request for 625 months, the following comment will be added 63to the issue: 64 65```markdown 66There has been no activity on this feature request for 675 months and it is unlikely to be implemented. 68It will be closed 6 months after the last non-automated comment. 69 70For more information on how the project manages 71feature requests, please consult the 72[feature request management document](https://github.com/nodejs/node/blob/HEAD/doc/contributing/feature-request-management.md). 73``` 74 75If there is no additional activity/discussion on the 76feature request in the next month, the following 77comment is added to the issue and the issue will be 78closed: 79 80```markdown 81There has been no activity on this feature request 82and it is being closed. If you feel closing this issue is not the 83right thing to do, please leave a comment. 84 85For more information on how the project manages 86feature requests, please consult the 87[feature request management document](https://github.com/nodejs/node/blob/HEAD/doc/contributing/feature-request-management.md). 88``` 89