meta: include a minimal CTC removal policy

[Trott]

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

meta

Description of change

Add a sentence identifying a request for voluntary resignation as the
typical mechanism for addressing inactive CTC members.

@nodejs/ctc

[rvagg]

nicely done, lgtm

[ChALkeR]

LGTM

[bnoordhuis]

LGTM

[indutny]

LGTM

[Fishrock123]

may or will?

[rvagg]

I like will, it holds us to account I think

[Fishrock123]

LGTM minus a question

[evanlucas]

LGTM

[misterdjules]

What is meant by "CTC matters"? Is that attending CTC meetings, reviewing code, contributing changes, helping others in nodejs/node issues/PRs, etc.? Is not doing one of these "CTC matters" enough to be "respectfully asked to resign"?

What is considered "minimal" and "a sustained period of time"?

In other words, this seems a bit too vague.

It also seems to be in contradiction with this line above:

There is no specific set of requirements or qualifications for CTC membership beyond these rules

[Trott]

In other words, this seems a bit too vague.

In my opinion, that's a feature, not a bug. Attempting to codify too much specificity in advance invites low-value bike-shedding now and gaming of the system later. It provides little benefit beyond specificity-for-specificity's sake. The statement as it stands may be vague in terms of metrics, but I think it's also clear in terms of expectations: CTC members are expected to participate.

It also seems to be in contradiction with this line above:

these rules in that line would include this text. Regardless, that line is about prerequisites. This new material is about expectations of standing members. I don't see a contradiction. (Perhaps there is room for improving phrasing to make things a bit more clear.)

[Trott]

Since it was part of the question, I guess i should also put out my opinion of what constitutes CTC matters (responsibilities of CTC members) as distinct from working on the Node.js project (responsibilities of all Collaborators).

To participate meaningfully in the CTC, one might:

• routinely attend the weekly meeting
• regularly provide valuable comments on the weekly CTC meeting issue (the one that Rod opens that contains the agenda ahead of the meeting) and/or on issues labeled ctc-agenda
• participate meaningfully on CTC email threads
• take on action items (that is, volunteer for tasks) that come out of CTC discussions (meeting discussions, email threads, etc.)

That list is probably not exhaustive. It is also subject to some hair-splitting. (Is it enough to "attend" the weekly meeting, or should one be expected to "participate" in the meeting?) Nonetheless, it is hopefully indicative of the types of things I have in mind, and I hope it generally conforms to what others have in mind, even if there are some specifics that may vary.

In contrast, the follow work, while absolutely essential to the project and of extremely high value, is not particular to the CTC and is in fact work that is ideally done by all Collaborators:

• comments on issues
• comments on PRs
• helping other users and/or novice contributors
• contributing code and/or documentation changes to improve the project
• participation in working groups
• landing PRs

Again, doing all that stuff is hugely valuable. However, it's not CTC work. Not all acts of awesomeness constitute CTC work. (If things are going well, chances are CTC work will be distinctly unglamorous, in fact.)

[misterdjules]

@Trott Everything that you mentioned above seems like it would be very useful to clarify what's expected from CTC members and collaborators. As far as I know, that information is not present in any of the organization's repositories, and so it can be left to interpretation.

I agree that I don't think that we want to go into details such as:

Is it enough to "attend" the weekly meeting, or should one be expected to "participate" in the meeting?)

and that's not what I was suggesting.

For instance, my perception of the role and responsibilities of CTC members is maybe biased by how the pre-foundation node "core team" was operating: it was expected that core team members attend core team meetings, but some members would not attend almost all of them. However because there was no distinction between collaborators and members of the core team, they were still considered to fulfill their responsibilities as contributors with a lot of expertise in different areas.

Writing down a shared understanding of what precisely the role of a CTC member is seems like it would only help everyone understand their responsibilities. Not doing so leaves a lot of room for interpretation, and thus confusion.

[Trott]

Writing down a shared understanding of what precisely the role of a CTC member is seems like it would only help everyone understand their responsibilities. Not doing so leaves a lot of room for interpretation, and thus confusion.

@misterdjules You raise a valid and important point. While I think my categorization is shared by most others on the CTC, I don't actually know that, so let's find out: #7744

[misterdjules]

@Trott Thank you for creating #7744!

[Fishrock123]

There is no specific set of requirements or qualifications for CTC membership beyond these rules

This is still correct, but if CTC members don't participate in meetings there is no point in being on the CTC.

[shigeki]

LGTM

[chrisdickinson]

To clarify the purpose of this: is the problem we're running into an inability to reach quorum due to regularly absent members, or an inability to add new CTC members due to limits on companies? If it's the former, I'd lean towards defining quorum as a function of "attendance must be at least N CTC members" (vs. "attendance must be at least N% of the CTC.")

[Trott]

@chrisdickinson As the person who proposed the text, my goal is to reduce or eliminate the appearance of the CTC as an insider's club and a static body.

In my estimation, that means two things: making it easier for valuable people to get on, and making it easier for inactive people to be removed (hopefully in an agreeable fashion). That second part is the more difficult and delicate issue, of course.

[mhdawson]

LGTM

[chrisdickinson]

@Trott I agree that making the process of matriculating to the CTC more repeatable is a good goal. I suppose I don't follow the connection between graduating old members and reducing the insider's club nature of the CTC. Even if we reduce the set of people on the CTC, the CTC is still the body that ultimately decides which new members to admit and when, so unless we change that aspect of it, it's always going to be something of an insider's club. Could you expand on how you see automatic graduation of CTC members affecting this?

[Trott]

I don't follow the connection between graduating old members and reducing the insider's club nature of the CTC. Even if we reduce the set of people on the CTC, the CTC is still the body that ultimately decides which new members to admit and when, so unless we change that aspect of it, it's always going to be something of an insider's club. Could you expand on how you see automatic graduation of CTC members affecting this?

@chrisdickinson To me, keeping people on the body even though they've been inactive on the body sends a signal that there may be factors other than doing valuable CTC work at play. Perhaps you don't see it that way, which is fine. You (and @misterdjules and many others) may have a historical view of how we got here that I may lack. To me, it makes the CTC look like a benevolent-oligarchy-for-life model of governance has been adopted. (I don't think there's actually anything going on there more than simply following the path of least resistance. The easiest thing for the CTC to do about anyone not being involved is to do nothing, but it's not necessarily the best thing to do.)

You don't have to agree with me on the appearances point to think this is a good idea. Ultimately, having a slowly growing mass of people on the CTC who actually aren't doing much or any CTC work creates various problems and is likely to create more different problems going forward.

[Fishrock123]

is the problem we're running into an inability to reach quorum due to regularly absent members

This is a not entirely frequent but an increasingly existent problem, fwiw.

[rvagg]

To be absolutely clear to anyone reading this if it isn't obvious: this is about the CTC, not the TSC, the CTC is the bubble-up group that helps make difficult technical decisions and is charged with keeping the technical machine of Node.js core oiled and functioning, the TSC handles the less glamorous work of keeping everything else we do as a technical arm of the Node.js Foundation oiled and functioning. This PR does not impact on TSC membership, that's a different matter and we're still trying to work toward a more meaningful structure where the TSC and CTC have more clearly defined functions and relationships.

The problems that I see us trying to address right here are:

• Making the CTC a little more fluid so we can have expertise come and go over time and make it less of a club to attain and retain
• Improve the relevance of the CTC such that we don't have people able to make big decisions who are not involved actively with the project — it's OK to move on, to have your interests or priorities elsewhere, but it's not OK when we're trying to exercise a model of those who do the work get to guide the project when we have a peak body containing people who aren't part of the do the work crew. I absolutely don't want to suggest that this is a big problem now, but I see it becoming a problem in our near future.
• The quorum problem, although tbh I don't see this as a big problem right now but I imagine it could be if we let things evolve as they are now with no mechanism to at least suggest to members that they might move on.

The language of this PR should be such that it's flexible and suggests a gentle approach to having a revolving membership door. Perhaps we've gone too far by reinforcing the "the CTC may remove people by vote" because it kind of reads "we'll ask people to resign but if the don't do it voluntarily the CTC can vote you out." but as we're not dealing with an actual problem that we're facing now with people refusing to resign, perhaps we're reaching too far.

Perhaps this doesn't change it a whole lot but it might provide a framework around why this happens and help ensure that it's not about politics (not that we'll ever be able to fully remove that, we're humans afterall!):

In order to remain relevant and connected with the Node.js project, and to retain its ability to effectively govern the Node.js project, the CTC will, from time to time, review its membership and assess the participation of individual members according to the typical activities of a CTC member listed below. When it is assessed that a CTC member's participation in CTC matters has become minimal for a sustained period of time, the CTC will respectfully invite that member to resign from the CTC or provide a justification to the CTC for their continued membership and how that membership assists the relevance of the CTC as a group. If other members of the CTC do not find such justification satisfactory they may move for a vote to remove that member from the CTC via the standard CTC decision-making process.

[geek]

We have a removal process in hapi. https://github.com/hapijs/contrib/blob/master/Governance.md#lead-maintainers

If we do adopt a removal process we should be clear about the length of time and process involved in being removed. If someone takes a break for a week are they removed, what about 2 weeks, a month? We should also be direct in reaching out to the person and making sure everything is ok, and trying our best to get them involved again.

[chrisdickinson]

My preference would be to mark CTC members inactive after 1-2 months, but note that they're welcome back to meetings at any point in the future. Inactive members won't count towards quorum or company limits. We want to preserve the knowledge that they hold and make sure it's possible for them to re-engage and share that perspective.

[Trott]

My preference would be to mark CTC members inactive after 1-2 months, but note that they're welcome back to meetings at any point in the future. Inactive members won't count towards quorum or company limits. We want to preserve the knowledge that they hold and make sure it's possible for them to re-engage and share that perspective.

In this situation, the difference between "inactive member" and "observer" seems to be minimal. Maybe we can merge those two categories into a more descriptive "non-voting participant" designation.

I would prefer that there be a minimal barrier (e.g., simple vote of the CTC) to re-entry as a voting member just to avoid the potential for the CTC equivalent of court-packing when the occasional contentious issue arises.

[Trott]

Also: Clearly I need to find some synonyms for "minimal" because I apparently use that word a lot.

[chrisdickinson]

In this situation, the difference between "inactive member" and "observer" seems to be minimal. Maybe we can merge those two categories into a more descriptive "non-voting participant" designation.

My thinking is that inactive members should retain the ability to vote — if the matter is relevant enough to them to bring them back to the meeting, they should probably be able to vote on it.

Edit: (In particular, I'm not too worried about the potential for court-packing — most of the events that draw former CTC members back in seem to relate to breakage of APIs near their expertise, vs. contentious issues like promises — which seem to get redirected back to the issue tracker in most cases.)

[bnoordhuis]

That's making it a position for life. I'm with Rich here, if someone no longer has the time or the inclination to participate, he or she should step back and make place for someone new.

I don't expect to work on node for the rest of my career, so when the time comes I will graciously step aside, and I expect other CTC members to do the same.

Most times it will be pretty obvious when someone has moved on so I personally don't feel a strong urge to codify a time limit. But if others feel differently, then 3-6 months seems like a reasonable time frame, with exceptions for things like long-term illness.

[jasnell]

Hmm... I would soften this a bit:

... the CTC will respectfully request that member to either downgrade their status
on the CTC to observer or to resign their position. In addition to voluntary action,
a CTC member may be downgraded to observer status or removed by a standard
CTC motion and vote.

[Trott]

Thanks, @jasnell! I intend to change it to say that the letter will request that the member either indicate an intention to increase participation or convert to observer status. I imagine that would achieve the same thing you're going for. Let me know if not.

I'm not doing a whole lot with this until #7744 either lands or is closed. This one is the touchiest of the three recent (one already landed) proposed governance clarifications, so I'm leaving it for last. So...#7744 next, I guess...

[jasnell]

Works for me.

[Trott]

I'm optimistic that this new version will be uncontroversial. The prior version had 8 LGTMs, but also some significant objections. I'm hoping this new version will be more amenable to consensus. With apologies to people who have already given this an LGTM, please take a look and comment or LGTM (again) or whatever. Thanks! @nodejs/ctc

Hopefully this sails through and we move on, but just in case, I'm labeling it ctc-agenda so we can hopefully get resolution there if there isn't resolution before then.

[mscdex]

LGTM

[misterdjules]

Typo in the anchor #ctc-activites -> #ctc-activities.

[misterdjules]

LGTM once the link to the "CTC activities" section is fixed.

[Trott]

Typo fixed: activites -> activities

[jasnell]

LGTM

[evanlucas]

LGTM

[ChALkeR]

LGTM

[jasnell]

Landed in 1495053