Skip to content

doc: clarify status of feature request issues #61505

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
aduh95 wants to merge 1 commit into
base: main
Choose a base branch
from
+10 −8
Open

doc: clarify status of feature request issues #61505

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 10 additions & 8 deletions doc/contributing/feature-request-management.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,13 +1,15 @@
# 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
Feature requests are not a valuable source of input for the project.
Copy link
Contributor

@MikeMcC399 MikeMcC399 Jan 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Feature requests are not a valuable source of input for the project.
Feature requests have a relatively limited value as a source of input for the project.

Tones down the message a little, whilst still discouraging feature requests as primary sources of input.

It is usually more productive to first send the Pull Request implementing the
feature, even imperfectly, and let the discussion happen during code review.
Comment on lines +4 to +5
Copy link
Contributor

@MikeMcC399 MikeMcC399 Jan 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It is usually more productive to first send the Pull Request implementing the
feature, even imperfectly, and let the discussion happen during code review.
It is usually more productive to first send a Pull Request implementing a
feature, even imperfectly, and let the discussion happen during code review.

Copy link

@tats-u tats-u Jan 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the implemented feature is what you really don't want to, which will end up with great-pains-but-all-in-vain?

That being said, the project still welcomes feature request issues, either for
features you cannot and/or won't implement yourself, or if you need more input
from the community before starting the work.

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.

Expand Down
Loading