doc: feature management proposal

Refs: nodejs#40823
Refs: nodejs#41113

Signed-off-by: Michael Dawson <mdawson@devrus.com>

doc/guides/feature-request-management.md

@@ -0,0 +1,89 @@
+# 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` resource at 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 stives 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 fullfilled.
+
+This process tries to balance retaining the valuable input
+we get through feature requests and the overhead of
+maintaining open features requests that will never get
+implemented.
+
+## Creating feature requests
+
+A feature request can be created by adding the `feature request`
+lable to an issue. This may be done 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 this
+[query](https://github.com/nodejs/node/issues?q=is%3Aissue+is%3Aopen+label%3A%22feature+request%22).
+
+## 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 decided 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 suport
+though through the thumbs up emoji. 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:
+
+````text
+There has been no activity on this feature request for
+5 months and it is unlikely to be implemented.
+It will be closed after 6 months unless there is renewed
+discussion or collaborators advocating that it be kept
+open. For more information on how the project manages
+feature requests please consult
+[feature request management](https://github.com/nodejs/node/blob/master/doc/guides/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:
+
+```text
+There has been no activity on this feature request
+and it is being closed.  We value your input
+and if you feel closing this issue was not the
+right thing to do please re-open it.
+open.
+
+For more information on how the project manages
+feature requests please consult
+[feature request management](https://github.com/nodejs/node/blob/master/doc/guides/feature-request-management.md).
+````