Maintaining a project board to manage feature requests

[targos]

Refs: #41113

I started experimenting with it in https://github.com/orgs/nodejs/projects/4

I think that if done well it will be beneficial for us collaborators and for users.
Now if other people agree with me, the next steps would be:

• Determine the fields (and their possible values) that we need to filter and organize the issues efficiently.
• Determine the views that we want to make available.
• Add all existing open feature requests to the project.
• Setup a GitHub action that adds an issue to the project when it is labeled "feature request" and removes it from it when the label is removed.
• Update the feature-request-management document

/cc @nodejs/tsc

[mcollina]

go ahead, I like the proposal!

[mmarchini]

It's been a while since I've used GH projects, but I think we can automatically assign issues with feature request label to the project without a GitHub action. Also +1 this seems like a good way to organize things

[targos]

It's been a while since I've used GH projects, but I think we can automatically assign issues with feature request label to the project without a GitHub action. Also +1 this seems like a good way to organize things

Automated workflows for GH projects are quite limited right now. I don't see anything related to labels: https://github.com/orgs/nodejs/projects/4/workflows/

[mhdawson]

+1 to the suggestion from me.

In terms of:

Determine the views that we want to make available.

A few thoughts to kick off the discussion:

• New feature requests this month - we would schedule to review this once/month in the TSC meeting
• Feature requests with more than 20 thumbs up
• Feature requests marked with never stale

[targos]

New feature requests this month - we would schedule to review this once/month in the TSC meeting

I like that idea. I don't know if we can filter using the creation date, though.

Feature requests with more than 20 thumbs up

Not sure we can do that out of the box.
Maybe we could do an action (cron) that maintains a label on these issues.

Feature requests marked with never stale

SGTM. I added the view, but there is no issue with this label at the moment.

[targos]

About the "Status" field, here are the values I put for now:

• Pending triage: initial temporary status
• Todo: we agree that it should be done, but are waiting for someone to work on it
• In Progress: someone is actively working on it
• Done: the feature has landed
• Closed: we agree that it should not be done

Did I miss anything?

[targos]

Did I miss anything?

With the future stale bot closing feature requests after a period of inactivity, we probably need a status for those, because they are not necessarily something that we don't want in core.

[mhdawson]

@targos I think they would have the tag stale on them, but we can confirm after I get the closing working.

[targos]

I added a "Stale" status for those.