charter: revised membership rules

[jasnell]

@nodejs/tsc:

• Remove expected target size
• Clarify that TSC member is not limited to core project maintainers
• Clarify that the TSC Chairperson is permitted to select delegates to run
  regular meetings.
• Add an attendance rule for TSC membership.

Current TSC member vote counts:

• @rvagg
• @bnoordhuis
• @piscisaureus
• @mscdex
• @nebrius
• @cjihrig
• @indutny
• @jasnell
• @Fishrock123
• @shigeki
• @trevnorris
• @joshgav

/cc @williamkapke

[joshgav]

@jasnell

Clarify that TSC member is not limited to core project maintainers

What is the basic criteria then? I think it should relate to actual contributions and perhaps demonstrated expertise, though perhaps not only through code.

The Foundation bylaws put much technical decision-making power in the hands of the TSC and don't mention the CTC at all. How do we ensure we have the needed technical and business expertise on the TSC to make such decisions? How do we ensure its members have our project's interests at heart?

To help concretize this, what would happen if the TSC and CTC disagree in the future?

/cc @nodejs/ctc

[jasnell]

What is the basic criteria then?

That the TSC selects it's own membership based on it's own priorities. This gives us the flexibility to pull in others who may have relevant expertise but who may not be considered "Maintainers" of a core project.

[jasnell]

what would happen if the TSC and CTC disagree in the future?

The TSC delegates authority to the CTC so any disagreements that come up would be handled in the usual way -- by opening an issue in the TSC repo and putting in on the TSC agenda.

[nebrius]

What is the basic criteria then? I think it should relate to actual contributions and perhaps demonstrated expertise, though not only through code.

We could say that TSC candidates should be Foundation members. This is something of a proxy for "being involved" in some way that isn't necessarily just code, but also leaves what that thing is very vague.

We could also add a blurb on "Candidates should bring skills to the TSC that it is currently lacking" or something similarly generic. The idea is that we need expertise on a wide variety of topics, and it's hard to predict what those will be in advance. So, having any sort of specific criteria will probably end up being too narrow, but I think we can all agree that the goal for bringing on new candidates is to fill some sort of gap in skills (even if that skill is "I have time").

[nebrius]

Is there any specific meaning behind the 60% number, or is it a ballpark number? It sounds like a good amount to me, but it would be nice if we could say "60%, and here's why" even if it's not mentioned explicitly in the charter

[jasnell]

ballpark figure that is greater than half.

[nebrius]

Last question for now: since this modifies the charter, does this mean we need to get the board to recharter us?

[jasnell]

Yes, if the TSC approves the change, then it would need to go to the board for ratification. The specific rules are detailed in the charter itself.

[ChALkeR]

I am not a native English speaker, and this is unclear to me: does this mean «(fails to attend) 60%» (≥60% missed) or «fails to (attend 60%)» (<60% visited)?

[ChALkeR]

I understand this as the second variant from above (<60% visited), but perhaps this needs a rewording to be more clear.

[jasnell]

You're right, that's not clear. It means, if the TSC member misses at least 60% of the meetings.

[Starefossen]

So hypothetically, if for some reason there were only one meeting in a six month period, any member missing this meeting would automatically be removed?

[jasnell]

hypothetically yes, but I would argue that having only one meeting every six months would violate the requirement for having "regular" meetings. That scenario would be quite unlikely and if things started in that direction we'd have the option of revising this again later.

[rvagg]

The question of how the TSC remains responsive to the CTC and representative of its interests is one I'd like to focus on trying to solve. It's not hard to imagine the two groups diverging from each other and causing unnecessary tension. The TSC stands between the CTC and the Foundation, yet the CTC is intended to be somewhat independent of the TSC. Given that we are all (the Board and everyone(?) here) agreeing that our focus as a technical group should be on "Node core", it's vital that we ensure that the TSC exists to serve that, which means serving the CTC. If membership diverges too much and the TSC wants to pull the technical organisation in a direction that the CTC does not want to go then we have a problem. Being "self-selecting" and given the nature of the work done in the TSC and how it's not attractive to many people on the CTC and in the Collaborator group, it's really not hard to imagine how unhealthy divergence could happen.

So, one possible solution to this is to build into the rules a mandated overlap between the two bodies. We could make a requirement of TSC composition be that a certain % of its members also sit on the CTC. I'm not sure what that percentage is but I'll suggest 50% as a starting point. I'm also not sure whether it should be the CTC that is responsible for filling its % or the TSC for selecting individuals to fill that %. Perhaps it's both, in a nomination -> acceptance pattern.

What think ye about that?

[joshgav]

@jasnell

The TSC delegates authority to the CTC

@rvagg

it's vital that we ensure that the TSC exists to serve that, which means serving the CTC

Seems that we have things backwards in the current arrangement of CTC reporting to TSC; that is, the TSC as currently composed should instead be subservient to the CTC.

To achieve that, an option could be for the CTC to take back the "TSC" title and create a "Process" or some such sub-committee (which could include non-CTC members) to handle what the "current TSC" does.

Not the prettiest to make such a change, but perhaps best for us in the long run.

[bnoordhuis]

I think I agree with that. The role of the TSC isn't completely useless but I don't think we'd miss out on much if we disbanded it. I'm in favor of folding it back into the CTC.

[williamkapke]

RE: Combining the CTC & TSC...
If that is going to be a possibility, can someone open a new issue to hash it out?

[williamkapke]

Thanks for taking this on @jasnell.

AFA Who can be on the TSC

Changing the charter is only part of the task however. We also need to amend the by-laws. Here's the section:

Section 5.4 Committees of the Members
(b) A Technical Steering Committee (the “TSC”) of the Foundation shall be established, with membership in the TSC consisting of the maintainers of each top level technical Project. Members of the TSC need not be Members of the Foundation. [snip] The operation of the Technical Steering Committee shall be governed by the rules of process of such Committee as from time to time approved by the Board. The initial TSC shall be initially comprised of Node.js codebase maintainers, committers or contributors approved by the Board. [snip]

I recommend we ask the board to have this section changed to simply:
"A Technical Steering Committee (the “TSC”) of the Foundation shall exist whose operation shall be governed by the rules of process as from time to time approved by the Board."
^{Plus the parts I snipped about the Chair and Director}

@nebrius RE: Having a requirement that people are Members; In addition to the part above, there is also this:

Section 2.8 Participation
Participation in the Technical Steering Committee (as described in Section 5.4(b) below) and development projects sponsored by the Foundation shall not be limited to Members, [snip]

This could make it pay-to-play: Someone would need to kick in the $100 if they're not a "collaborator".

AFA Attendance

I am not in favor of defining a percentage. This means someone will need to keep track of attendance!... like accurately. Then, someone will need to tally up everyone's numbers 😐. It seems unlikely for this to happen in a non-judgemental way IMO.

My solution to "ensure that seats on the TSC are held by active, contributing individuals" ^{(text taken from by-laws)} is to use the bot. It works like this: Each TSC member gets a start date and a non-expiring renewable term. Each month the bot creates an issue asking expiring members if they'd like to stay on. Then those members just need to give a thumbs up to the OP to be renewed for another term. This provides automation and removes judgement. I suggest 6 month terms.

[nebrius]

This could make it pay-to-play: Someone would need to kick in the $100 if they're not a "collaborator".

🤔

My first thought is that if people are a collaborator, then they become foundation members for free. So, if there's someone we want to bring on who currently isn't a member, we can follow these steps:

1. Add them as a collaborator (AFAICT there are no restrictions on who can become a collaborator)
2. Have them sign up for the free Foundation membership
3. Add them as a TSC member

Now, this could be viewed as exploiting a loophole, or taking advantage of a process that may not always exist. Maybe this is reason enough to not go with that requirement?

[Fishrock123]

If we do this I think it technically needs to have a clause that it cannot drop below 3 people.

Also, I feel 6 months could be a bit short? Unsure.

[Fishrock123]

ping @jasnell

[jasnell]

@nodejs/tsc ... I've updated to refine the language and reboot this discussion. PTAL

[joshgav]

Does this include the private section? That's ambiguous for current observers.

[jasnell]

Good point

[mhdawson]

Yes there have been cases were observers have been asked to leave for the private section, if this is the expectation then its likely good to document.

[joshgav]

Attendance at meetings is important to making efficient progress on issues and reaching quorum and consensus, so I think 20% (5 meetings a year) is too low. I suggest 50%, which means attendance at least about once per month.

A corollary could be that if a member misses 5 consecutive meetings (2.5 months) they lose membership/voting status.

[jasnell]

50% is a bit steep given the current scheduling of TSC meetings. The current time guarantees that the meeting is at a positively awful time for potential international participants.

[nebrius]

I agree that 50% is a bit steep. Perhaps 25%? I could also get behind adding "missed x number of consecutive meetings," although I also think 5 is also a bit steep. Maybe 8, which would be 4 months?

[joshgav]

I think a solution for international participants could be to stagger the meetings as we do for CTC. Somehow we need to facilitate everyone's participation, that's the point of their membership 😄 .

In fact, attendance at meetings is standing in here as a bellwether and prod for active participation, as it does in many other orgs. Perhaps there are other indicators (GitHub comments?) which would also be appropriate to consider within Node.

[mhdawson]

Id' favor being a bit conservative in the number. 25% seems more reasonable, but I'm also ok with a secondary measure like "and must attend at least 1 meeting every 3 months) so that if people just stop participating at all it raises a flag. I see the case were we have not seem somebody for 3 months as quite different than the case were we see that person only 1/4 meetings but they are there for at least one every month.

[joshgav]

I don't think proactive communication helps much since the purpose of requiring attendance is to achieve quorum and ensure continuing progress on issues. Even taking into consideration personal needs and extenuating circumstances, members should still be able to attend most meetings; there are only 2 per month.

We could also allow substitutes or written messages re agenda items in extenuating circumstances, but that also seems that it shouldn't happen more than once or twice in a row.

[jasnell]

I disagree on the proactive communication bit. I think that if a member weighs in on issues on github proactively but is unable to make the actual meetings due to various constraints, then it shouldn't count against them.

[joshgav]

One year of non-participation seems too long for a rapidly evolving project like Node. A non-participating member makes it harder for others to achieve quorum and consensus and slows progress on issues.

I suggest we make the 50% of past 6 months as above a hard limit. This isn't so bad when we consider that removed members can continue to attend as observers and can be renominated at any time.

[joshgav]

Should Foundation membership be a requirement?

[williamkapke]

That would contradict the By-Laws:

Members of the TSC need not be Members of the Foundation.

[joshgav]

Thanks @williamkapke, clearer now that I read your comment above :)

[joshgav]

Perhaps add: "Members are expected to speak and act in the best interests of the Node.js Foundation and open source projects."

[jasnell]

That's something that I think is better left to a separate PR.

[joshgav]

Perhaps: Nominations for TSC membership should be... as any other agenda item by any member of the community (i.e. not just current TSC members).

[williamkapke]

I think this is saying that any collaborator can suggest adding someone to the TSC by adding the tsc-agenda label to an issue (anywhere in the org) stating such desire.

[joshgav]

That's what I understand too, but was suggesting perhaps we might state it more clearly.

Note that only repo admins can label issues. Or at least I can't label issues in the TSC repo at the moment 😄 .

[williamkapke]

The TSC must have at least three members

Maybe a good thing to have... but it begs the question of what happens if this minimum isn't met?

[nebrius]

A good question indeed. I would guess board intervention of some sort, perhaps dissolution of the remaining TSC?

Thinking out loud here, I don't think this is likely to happen, but if it were, I suspect that would mean something has gone really wrong and the project would be without leadership. I'm not saying that the TSC is itself project leadership, but that many people leaving the TSC would probably be because of some sort of exodus on a larger scale. In other words, I think it's really unlikely for this event to occur in a vacuum.

[jasnell]

Indeed, it's exceedingly unlikely. If the membership were to even get close to falling below that number, I would suspect that the separate CTC and TSC bodies would remerge into one. If that were to fall below 3 members, then we'd really be in trouble.

[williamkapke]

This charter defines "Collaborators" and "Contributors" but not "Maintainers"... so let's avoid it.
^{Edit: Brain fail- it DOES define it at the VERY end. I'd like to remove that too.}

FYI: The By-Laws use "Maintainers" but doesn't define it either. My suggested change to the By-Laws would remove that term there too.

IMO, this paragraph doesn't bring any value. I'd just remove it and keep it simple since what it says above is adequate:

The TSC may add additional members to the TSC by a standard TSC motion and vote.

[mhdawson]

I agree that it would be better with the simpler statement William suggests. Why say it shall be X but then say unless we want to invite somebody that does not fit X.

[mikeal]

@piscisaureus meetings are used to settle tie-breakers when there isn't a consensus. If there is a consensus then a vote isn't even needed.

While I don't think people should be in all meetings, and meetings should be not be used for most of the work that happens, attendance is required to work through issues that don't find an easy consensus and there isn't a good way to factor them out entirely.

[jasnell]

Based on the conversation in the TSC meeting today, we landed on revising the PR so that this becomes a "participation rule" as opposed to an "attendance rule". We will need to define what all TSC participation requires. I'll take a first stab at it over the next couple of days.

@nodejs/tsc ... we will have a vote on the updated PR in exactly two weeks from today at the next TSC call.

[jasnell]

@nodejs/tsc ... per the TSC discussion yesterday, I have revised the PR to focus on participation rather than just attendance in the meetings. Please take a look. A vote will be called at the next TSC meeting so please make sure you've taken the time to look this over before then

[bnoordhuis]

(b) is superfluous, it's a weaker version of (a).

[ChALkeR]

@bnoordhuis But it's not. E.g., per month: 3/4, 4/4, 0/4, 0/5, 0/4, 0/5, 3/4 — (a) is not fullfilled, (b) is. The same for 1/2, 1/2, 0/2, 0/2, 0/2, 1/2.

[bnoordhuis]

In a six month period we have 13 meetings. If you attend 25% of those, that's 3 meetings. If you only attend one meeting every three months, that's 2 meetings in that same period. Ergo, if you meet requirement (a), you by definition also meet (b).

Unless (b) covers the hypothetical scenario of attending 25% of the meetings in the first 3 months, then zero in the second 3 months. That seems needlessly confusing though, just say "25% attendance per 3 months" and leave it at that.

[bnoordhuis]

As well, this section could be clearer if the TSC member needs to meet any or all of the requirements. There is an "and" buried in there but it's rather subtle and it could be interpreted as combining only (c) and (d).

[jasnell]

I'm good with simplifying this. +1 to 25% every three months.

[williamkapke]

Food(s) for thought:
-- Meetings do get canceled
-- The frequency might change

[bnoordhuis]

I think it's weird and hard to defend that you can get in on a hypothetical 51% majority but expulsion requires 66%. It should either stay the way it is or it should be 51% for both.

[jasnell]

The idea is to intentionally make the bar higher for removing and for adding. I highly doubt there will ever actually be a need to officially vote someone off the island, but should it happen, the bar should be high.

[bnoordhuis]

I agree, but vice versa, how likely is it that someone is nominated that gets 51% but not 66% approval? And if that ever did that happen, does that person really belong on the TSC? Votes have always been unanimous so far.

I'd stick with the current 2/3rds majority for both just because it's more congruent.

[nebrius]

The motivation for lowering to 51% is that it's proven hard to get 66%. It's not that there are >33% "no" votes, but that there is usually >33% "didn't vote." It's currently really hard to get enough people to vote so that we have >66% "yes" votes, even when everyone who voted did vote "yes"

[bnoordhuis]

I see your point, but by that logic removal should be 51% too.

[mikeal]

If anything it makes less sense for removal to have a higher bar because most removals happen when it becomes difficult to make quorum, which would mean 66% is near impossible if you're having regular quorum issues.

I've said this many times but we should 1) try to never resort to votes and when we do have to vote 2) stick to simple majorities.

Raising the bar above a simple majority favors a lack of change and progress, makes it more difficult to get things done, and puts an undue burden on those who must convince their peers to enact changes compared to those who do not.

[nebrius]

Good points, upon further reflection, I can get behind making everything a simple majority, including member removal.

[mikeal]

Can we get this finalized by the end of the week? I'd like to get the changes up for board approval in our meeting on Monday.

[joshgav]

LGTM. The importance of participation is emphasized but not absolute since it only results in a request to resign, which could be met by a renewed commitment to participate. And we're covered by the six-month clause for people who really become unreachable.

Thanks @jasnell!

[mscdex]

LGTM

[nebrius]

Is this supposed to be a link? Something else? I think it would render as [Condorcet][] currently.

[williamkapke]

It's a shortcut to ref it at the bottom with the matching text. I clicked the "view" button to see it rendered and it works.

[nebrius]

Oh cool, I didn't realize you could leave the second entry blank and it would Just Work

[jasnell]

We needed a 2/3 vote... which is 8 or more TSC membrers. We're there finally. The change passes the TSC.

@mikeal @rvagg: this is ready to move on to Foundation board approval, I believe.

@nodejs/tsc ... the board meeting is monday afternoon. If any of you have any final objections, please speak up now!

[Fishrock123]

belated lgtm

[jasnell]

@mikeal @rvagg ... was this brought up and discussed at the board meeting? Where did we land on it?

[mikeal]

We didn't get it to the board to review in time but we're decided to get it out to the board via email this week to review and, barring any adjustments or objections, pass in an email resolution before the next meeting.

[jasnell]

Ping @mikeal ... any updates?

[mikeal]

@jasnell It's up for an email vote, will update once it is has resolved.

[jasnell]

@mikeal reports that the board accepted this change. I am landing the PR.
@mikeal: please add a comment indicating the day that the board approved the change... the activity rules will be active as of that date.