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.

[jasnell]

@jasnell instead of trying to solve everything at once let's break this into incremental improvement

I'm not trying to solve everything all at once. From the proposal text: "What is intended here is an end result, not necessarily the incremental steps necessary to get to that result."

Is this more an issue with our Collaborator documentation?

Sure. The documentation is not clear what a Collaborator is, what the expectations are, what the requirements are, what the privileges are, or how one advances in the project. We can address that problem by clearly articulating all of those things the way I do in the proposal text, with modifications based on whatever makes the most sense.

All of this was discussed extensively at the Collaborator Summit.

[Trott]

What is intended here is an end result, not necessarily the incremental steps necessary to get to that result.

Suggestion: Don't use end result. Maybe use initial vision instead? I suspect you do not mean to suggest that we can get to a point and say, "Yay! We did it! We're done! We don't need to iteratively improve our governance anymore, or change anything in reaction to new challenges of scale, technology, external conditions, or anything else!" But end result sorta implies that.

[geek]

Are there notes from the summit? If so, do you mind linking to the specific bits that apply to each issue.

I created nodejs/node#16209 to handle the missing bits from the collaborator guide.

Any thoughts on the remaining questions above @jasnell?

[jasnell]

There are from the general session during day 2. There was much more discussed in a private TSC session, notes for which will not be published.

Apologies for the lack of formatting. Cut n paste from the phone doesn't work well. I'll apply formatting later.

https://gist.github.com/jasnell/2f1220da324f03e5378a61e857a8ecb8

[mcollina]

@geek

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?

The problem is that the TSC encompasses more projects that just nodejs/node. There are contributors that are only in the Build WG, streams, or the website. Are those Collaborators?
Should these people qualify for participation in the TSC?

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.

The move to the error codes was highly demotivating for everyone. It was grunt work, and it took a long time. On another case, it just took me close to 6 months to have an agreement on how to add some properties to streams. Some newcomers have complained about the amount of nit-picking in PRs. I can find out PR ids if you need more evidence.

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.

The major problem is outside of our community, as the current process is not transparent and clear. The question on "who lead the Node.js project" should be easy to answer. Part of the escalation in August derived from this lack of transparency and clarity.

[mhdawson]

This seems like good input to #383 along with other suggestions/comments people want to make as input if/when that working group forms.

[MylesBorins]

Finally had a chance to read the document and really enjoyed it.

Things I really liked:

• creating more growth opportunity for collaborators aside from the TSC
• Decentralizing the nomination process
• Rotating TSC is expected
• No limit to core technical group
• 🎉🎉🎉the welcoming committee 🎉🎉🎉

Things I'm excited to iterate on:

• the specific roles / ladder for collaborators
• how the promotion process works
• What parts of this process are owned by CommComm

[MylesBorins]

@jasnell is this still being worked on?

[jasnell]

I am not working on it, no. I do not intend to work on it further, either. Others may want to pick up the thread tho

[jasnell]

Apparently this is going no where.