Community-committee: advertise node-core's feature requests backlog

[refack]

I've curated a list of feature requests submitted to core, that don't have objections, but no one has picked up:
https://github.com/nodejs/node/projects/13

I think it would be beneficial to advertise this list to the wider Node.js community, and invite people to adopt and contribute.

Note: These are different from "good-first-contribution" issues since they have a wider scope and are not as well defined. But they do offer an opportunity for new people to make a significant code contribution to core.

[bnb]

@refack I was considering including additional scopes like this for my good-first-issue CLI, which I expressly built for good-first-issues. Specifically I was thinking about Code and Learn, but I'd ❤️ to also include this.

I have a couple questions:

• Would it be worth standardizing on a label like orphan? I've seen issues like this across all our repositories. This would also help ensure discoverability org-wide.
• What kind of person are we looking to solve these problems? Defining that would be helpful in actually getting the correct people connected to them.

[refack]

• Would it be worth standardizing on a label like orphan? I've seen issues like this across all our repositories. This would also help ensure discoverability org-wide.

I'm +1 on a standard. The current label in core is stalled (orphan might be a too loaded word). The meaning is: conversation did not finish, but idea was not rejected.

• What kind of person are we looking to solve these problems? Defining that would be helpful in actually getting the correct people connected to them.

I think a non-novice developer, that has some FOSS experience, and who is comfortable grokking other people's code. Someone who can take some requirements, do a little bit of design, and implement it.
Good text communication skill is important (as in most FOSS work).
Tasks require decent level of JS knowledge, and some C++ understanding.

[amiller-gh]

FWIW, I like needs-champion as a label. Makes it sound more appealing for folks to pick up.

Love the concept. How can we best surface it to contributors?

[bnb]

@amiller-gh I believe pinging @nodejs/tsc would be a good first step to see if they'd be willing to have the label – not sure if there's a reason to not have it 👍

[mcollina]

There is no roadmap, and what is being developed depends entirely on the collaborators. Therefore, there could no such thing as a curated feature request list.

Moreover, I would not advertise those as good-first-issue, because if they where easy, they would have been already done. Or tagged as such.

[refack]

I would not advertise those as good-first-issue, because if they where easy, they would have been already done.

I totally agree. I think this is a list of things that require an experienced developer.
The list is curated only in the sense that it only has items that during the discussion did not raise explicit objections.
As always there are no guarantees this will not be pushed back, but IMHO it's a decent list of ideas for those who want to contribute something more complex.

[Trott]

A bunch of things:

• "Curated" is probably not precisely what happened, but close enough. If you dislike that word, replace it with "collected" or something. @refack collected up all the stalled feature requests that were older than a certain amount of time, labeled them as stalled, closed them, and put them in the project so that there could be a backlog. It is, IMO, a good effort to try to make our issue tracker more useful and manageable while also not losing track of feature requests that weren't outright rejected but did not get any traction either.

• These are not good first issues generally, but they are fine issues for newcomers if they are relatively experienced in working in decent-sized open source projects. I would not label them "good first issue". You could label them "help wanted" or whatever, but don't bother because they're closed. They won't attract attention in the tracker no matter how you label them. We need to attract attention to the _project board_. If someone wants to adopt one of them because they believe them to be valuable, then we can re-open the issue.

• We do not, as far as I am aware, have a policy around creating labels in the org or in the core repo. However, I believe involving TSC in such matters is probably not practical. Collaborators can create labels and I'd prefer they feel empowered to do so. Labels that are unused or duplicates can always be removed. My opinion only, but there it is.

• I will add a link to the project board at https://www.nodetodo.org/next-steps/. I might put it an "advanced" section for people who are feeling ambitious (or folks who have a lot of experience and are just kinda looking for an entry into Node.js and don't need a gentle onramp). Feel free to PR that change directly into https://github.com/Trott/nodetodo if you're feeling it, but no worries if not. I'll do it myself later.

[keywordnew]

Hey folks, thread ping to check if there has been progress on this that hasn't been captured in the issue 💛

[Trott]

Hey folks, thread ping to check if there has been progress on this that hasn't been captured in the issue 💛

Thanks to the ping, I just added a link to the project board at https://www.nodetodo.org/next-steps/.

I notice that there is one card in the "in progress" column that is closed. Perhaps it should be removed or moved back to the backlog/orphan column?

[refack]

I notice that there is one card in the "in progress" column that is closed.

IIRC I put it there since it has _some_ partial work already done, but I probably won't get to it anytime soon. Might be easier for someone to follow up on (i.e. no fear of blank page) 🤷‍♂

[bnb]

There has seemingly been no traction on this in quite some time. Happy to re-open if it's something that we'd like to focus on and can't be discussed in a new issue.