More clear indicator of key stakeholders and gatekeepers of features.

[jdalton]

While this document exists, I've seen some confusion over which individuals or groups have the power to make calls on Node features (e.g. ES module support).

So when those active in Node discussions/proposals say they'll object to something, observers may not know why, or if, that objection matters. From the outside, the observer sees the objecting user is active in a lot of Node threads and on social media, but they're not Node core, not Node TSC, not the lead of a project with major ecosystem impact, and may or may not have their employer's blessing to work on Node-land things. To add to the confusion, the objecting user may be on one or more standards bodies in similar or overlapping realms.

It would be great to have a listing of scenarios and features, with owners clearly documented. If the owners aren't Node core or Node TSC, they should be made so, so that they are under Node 's official umbrella. I think this would go a long way in clearing up which groups or individuals folks should appeal to for feature requests, questions, or proposals.

Update:

There's a Node collaborator designation, not to be confused with GitHub's contributor badge,
which makes --all-- collaborators potential blockers for any feature.

Update Update:

Part of the confusion is Node "collaborators" may not have their Node org membership public, which means they aren't seen by users as part of the organization and GitHub does not change their badge to "member". The onboarding docs should be updated to ensure "collaborators" mark their membership as "public" so GitHub will apply the appropriate badges and UI signals.

[mhdawson]

I'd like to discuss to better understand what the documentation might look like. Generally the TSC has the final decision if there are objections/lack of consensus within the body of collaborators. The TSC does rely on advice/recommendations from those involved in the discussions and I'm guessing you might be asking for more information on who those people might be.
@jdalton would you have time to discussion tomorrow at 2:30 EST ?

[jdalton]

would you have time to discussion tomorrow at 2:30 EST

Yes!

[Trott]

Asking people to make their membership public seems like a pretty good idea. I'm not sure about the specifics of how that works or if I'm able to see everyone's membership simply because I'm an org owner or something like that. The information should be added to the onboarding doc, in case anyone informed and/or motivated wants to put together a pull request to add that info.

[mhdawson]

@Trott I'll look at a PR to update the onboarding doc after my discussion with @jdalton

[mhdawson]

PR to request making membership public. Must default to private and it was set to private for me: nodejs/node#17688

[mhdawson]

Had a good discussion with @jdalton today. I'd capture the discussion as follows:

• there is a need for more information about participants in the Node.js community so that it is possible to better understand:

  • Whether an individual is a collaborator or not. Collaborators have the ability to make a blocking
    objection so knowing this is important. The list is already here
    https://github.com/nodejs/node#collaborators. Based on the discussion here
    we will also ask collaborators to make the membership in the org public (see doc: instructions on how to make membership public node#17688).
    Not sure if we need to anything more on this front.

  • Which individuals are the 'experts' in a given areas. These are the people that are active and
    contributing to an effort or have past contributions that results in the TSC (and others)
    giving added weight to their opinions. Some options we discussed:

    • Adding them to the strategic initiatives list
      https://github.com/nodejs/TSC/blob/master/Strategic-Initiatives.md in addition to the Champion
    • Adding areas against people's names in the collaborator list
      https://github.com/nodejs/node#collaborators.
    • Adding a new page somewhere to show collaborators with an expertise in each area. This might
      feed into some of the other discussions around having people identify as experts as part of a
      "leveling up" path.

    Interestingly we already have a start of this list in
    https://github.com/nodejs/node/blob/master/doc/onboarding-extras.md. Once option might be to
    just formalize that a bit more and ensure its more public. In some cases though it only includes an
    alias so we'd have to expand that.

  • The general decision making process so that people can understand how to build the
    required consensus and who they need as part of that consensus (which needs the info from
    the 2 earlier points)

[mcollina]

I think the starting point would be to document the decision making process, and then add the relevant information on demand.

The rest is good data to have also for us: we can track if there are areas with lower partecipation.

[Trott]

I think the starting point would be to document the decision making process,

I think @jdalton's primary concern is decision making around pull requests. (And if I'm wrong, he can correct me! :-D )

In that case, the process itself is pretty clearly documented IMO but it's not particularly discoverable. (Who looks in a GOVERNANCE.md doc?) I'd welcome a PR that:

• Adds a header to the change review and approval process material in that doc so that we can link directly to it. Above, I had to link to the Collaborators section, but the change stuff doesn't show up until after three paragraphs and a bulleted list.

• Adds a link to that material in README.md. (There is a link to the GOVERNANCE doc overall, so maybe all that needs to be added is some text to that sentence along the lines of including the change review and approval process and then link to the new header.)

[mcollina]

@Trott I do not think this is relevant to what is being discussed here. That is an internal explanation, not an external one.

The question we should ask is: "I want to change something in Node.js, what is the process that I need to follow to have my change landed".
Something along the lines of:

1. if you are not comfortable on how to do the change, and you need some guidance, open an issue on nodejs/node.
2. Contact some of the people in this list, they might be willing to help
3. After you are comfortable on what you want to achieve, then do the change following our guidelines and open a PR.
4. tag the same people in the new issue, and also paste the URL of your PR in the original issue.
5. collaborators will review your code and then ask to make changes, engage with the process as it might take several days
6. a collaborator will land your pull request.
7. rinse and repeat, after some landed PRs you will be a collaborator yourself!

I do not think we have a document like this anywhere.

[Trott]

@mcollina So perhaps a "first time contributor's guide" that is a lot more focused (and honestly, hopefully a lot more concise) than the current CONTRIBUTING.md? I like that idea. Especially if it means a lot of stuff from CONTRIBUTING.md can be replaced with links.

[mcollina]

It can even be in the CONTRIBUTING.md, but as the first thing.

[jasnell]

Discussion here appears to have stalled out. Is there a next step or can we close this?

[jdalton]

Nothing stalled. The issue should probably have been closed because the necessary actions were taken (as referenced in the many PR links).

[jasnell]

@jdalton +1