FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

doc: feature management proposal · nodejs/node@c742a1c · GitHub

/ node Public

Commit c742a1c

Browse files
mhdawson
authored and
danielleadams
committed
doc: feature management proposal
Refs: https://github.com/nodejs/node/discussions/40823 Refs: #41113 Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #41420 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Mary Marchini <oss@mmarchini.me> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
1 parent 3f000a2 commit c742a1c

2 files changed

Lines changed: 92 additions & 0 deletions

File tree

‎.github/ISSUE_TEMPLATE/2-feature-request.yml‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,9 @@ body:
88
Thank you for suggesting an idea to make Node.js better.
99
1010
Please fill in as much of the following form as you're able.
11+
12+
For more information on how the project manages feature
13+
requests, see [Feature request management](https://github.com/nodejs/node/blob/HEAD/doc/guides/feature-request-management.md).
1114
- type: textarea
1215
attributes:
1316
label: What is the problem this feature will solve?

‎doc/contributing/feature-request-management.md‎

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

0 commit comments

Comments
 (0)
Back | FazBrowse Home | New Git URL