Proposing Organizational Changes

[jasnell]

There were extensive discussions at the Vancouver Collaborator Summit around the various operational, governance, and structural issues we've been having within the project. I have distilled those conversations into a proposal for a revised membership structure.

See: https://gist.github.com/jasnell/6eca206dcadd3c3d74fbedf504ff42b0

ping @nodejs/tsc @nodejs/collaborators @nodejs/community-committee @dshaw

[richardlau]

Is the cap on the number/proportion of TSC members from the same employer dropped?

[joyeecheung]

Some thoughts:

• The name "Member" is a bit confusing to me at first, I think this is closer to the "Contributor" Github status, and I find "Contributor" to be less confusing
• The difference between a TSC member and a TSC advisor is whether they have left the TSC. The difference between a Member and a Advisor is much more. This looks a bit confusing.

Advisors are Collaborators that have demonstrated advanced or specific knowledge over multiple areas of the project. Advisors have all the privileges of Collaborators but also participate in all Core Team meetings.
Advisor status is scoped to specific GitHub Repositories.

So advisors are promoted based on their activity in a repo (not necessarily the core repo) but they still need to participate in all core team meetings?

[joyeecheung]

Also, regarding the requirement of an Advisor:

Be a primary reviewer for at least 10 substantial PRs to the codebase
Have authored and landed at least 30 substantial PRs to the codebase

If they primarily work on repos other than core, which are much less active than core, then the numbers here may be too high. And thinking about working group repos, does these PRs have to be about code? Can they be PRs about the work they have done, outside of the Node.js organization but still related to collaboration of the project?

[joyeecheung]

We had a brief discussion about the TSC agenda item champion thing during the collaboration summit, maybe that idea can be incorporated into this proposal? At the moment it mentions the core team meeting and the TSC meeting several times in the "Responsibilities and privileges" sections, but does not describe what those meetings are about. I think this is a good opportunity to review our process of adding items to the meeting agenda, and how the meetings are going to handle them.

[addaleax]

This is generally moving in a good direction, imho

Membership status is scoped to the entire Node.js GitHub Organization.

That’s immediately going to conflict with the CommComm, right? It should be all repositories that are part of the TSC’s responsiblity, right?

I also dislike the use of fixed thresholds for # of PRs/# of issues/time frames here… not all parts of the code base, and not all contributions, are created equal. I think all of these could and should be replaced by “softer” terms?

[jasnell]

@richardlau

Is the cap on the number/proportion of TSC members from the same employer dropped?

Yes. Given that the TSC membership would (a) roll over annually and (b) be nominated by the collaborator base, the likelihood of any single company gaining too much of a power position is significantly lessened. Of course, it would be something to watch out for.

@joyeecheung

The name "Member" is a bit confusing to me at first, I think this is closer to the "Contributor" Github status, and I find "Contributor" to be less confusing

GitHub uses the term Member to describe this particular role. These are literally members of the GitHub organization. I'm fine with renaming if it means moving the proposal forward, but I do prefer the "Member" term.

@joyeecheung

The difference between a TSC member and a TSC advisor is whether they have left the TSC. The difference between a Member and a Advisor is much more. This looks a bit confusing.

I agree but I was struggling to come up with a better name for the "Advisor" role.

@joyeecheung

If they primarily work on repos other than core, which are mush less active than core, then the numbers here may be too high.

@addaleax

I also dislike the use of fixed thresholds for # of PRs/# of issues/time frames here… not all parts of the code base, and not all contributions, are created equal. I think all of these could and should be replaced by “softer” terms?

The numbers are really just to get the point across. I'm open to tweaking these requirements to whatever folks feel is most appropriate.

@joyeecheung

We had a brief discussion about the TSC agenda item champion thing during the collaboration summit, maybe that idea can be incorporated into this proposal? At the moment it mentions the core team meeting and the TSC meeting several times in the "Responsibilities and privileges" sections, but does not describe what those meetings are about. I think this is a good opportunity to review our process of adding items to the meeting agenda, and how the meetings are going to handle them.

I agree, I just haven't thought all that through yet ;-)

@addaleax

That’s immediately going to conflict with the CommComm, right? It should be all repositories that are part of the TSC’s responsiblity, right?

Only if the CommComm does not adopt the same terminology.

[joyeecheung]

GitHub uses the term Member to describe this particular role. These are literally members of the GitHub organization. I'm fine with renaming if it means moving the proposal forward, but I do prefer the "Member" term.

I reread the description of Member again and yes, this seem to be closer to "Members of the Github Organization". I think I missed the "Membership status is scoped to the entire Node.js GitHub Organization." part before, sorry about the noise.

[jasnell]

:-) no worries at all! I'm super thankful you took the time to read it! :-) It was great seeing you again last week, btw

[Qard]

By this criteria, I don't have enough PRs of my own in core to qualify for the collaborator title, yet I've had that commit bit for years. 🤔

I can't say I've been the most active of contributors of late, but I think this could maybe be reworked a bit to better represent non-code contributions.

[rmg]

I'm in a similar situation to @Qard.

I'm not particularly active and I have commit access. However, the kinds of contributions I tend to make don't require commit access (code reviews, general help, etc.).

Personally, the main thing I get from the commit bit is credibility, which I suspect helps with mentoring and similar activities.

[Trott]

Personally, the main thing I get from the commit bit is credibility, which I suspect helps with mentoring and similar activities.

If it's useful for anyone, currently the commit bit is determined by membership in the nodejs/collaborators team. Membership in that team provides:

• ability to commit to the main repository
• ability to start CI jobs
• ability to approve or block PRs
• ability to apply labels in issues and PRs
• ability to close and re-open issues and PRs that aren't yours
• access to the moderation repo

I may have missed some other stuff, but those are all the big ones, I think.

[mcollina]

Definitely a good starting point. The names of various roles are a bit confusing, but their responsibilities are clear. I do not like the term Advisor, but I do not have a better one.

I would prefer for the Core Team to be a chartered working group, and I would say that it could approve semver-majors, more or less with the same rules TSC members do now (2 approvals). I would recommend that the Core Team has a chair/lead, and that chair sits in the TSC, similarly to how the WG leads sits in the Core Team, and how the TSC appoints a Director.

On the other side, all of this is complex. Much of this could be implemented in baby-steps, and I think the step we should introduce now is having clear criteria for being eligible for a TSC nomination.

[jasnell]

@Qard and @rmg ... Yeah, I get that for sure. So let's identify criteria that make more sense given our model. There should be some non-arbitrary threshold that makes sense.

[sebdeckers]

Newbie/transient collaborator here; FWIW...

TSC member cap is a function of collaborator count. Is there any reason to expect a decline in the total number of collaborators? Without a clear way to cull/discount/weight inactive or transient collaborators this could lead to the TSC becoming top-heavy. (e.g. an army with more generals than tanks)

Edit: Maybe I misunderstood "the total number of Collaborators at the time of each Selection Period" and it actually means only those who were active during that period?

[geek]

@jasnell instead of trying to solve everything at once let's break this into incremental improvements like we do with software. But before we get to that point, I'd like to see a clearer description/analysis of the issues you are reporting. I'm not sure that all of the issues can't be solved with smaller/simpler steps.

We have long had a very loose definition of "Collaborator" that has caused confusion.

Is this more an issue with our collaborator documentation? Should we clarify/fix anything in https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md?

There are currently no clearly defined paths for new contributors to "level up" within the organization.

Are active members of our community complaining about a lack of leadership opportunities or no clear way to take on responsibilities? If so, please provide evidence.

There are currently issues with the review and approval process that are highly demotivating to both new and existing contributors.

Please explain, provide evidence. Before we can make progress we need to understand the problem, take measurements if possible.

There are currently issues with a lack of Working Groups representation in Core discussions.

What issues are resulting from the lack of representation? Can you point to specifics?

---

I'd like to see us address all of these problems and possibly more. But before we do that we need to be clear and specific about the problems, why they are problems, and what damage they cause.