Node.js TSC charter change

[Trott]

Node.js charter changes require CPC approval. The TSC has consensus for the change in nodejs/TSC#1345 which removes a minimum meeting attendance requirement to be a TSC member. Can we get CPC approval for this?

[Trott]

Adding the meeting agenda label, but my hope is to get sufficient approval to do this before the next meeting in two weeks.

[Trott]

I guess it's obvious, but I'm +1 on this change.

[Trott]

Pinging CPC voting members. (We don't seem to have a team of just the voting members, or if we do, it doesn't show up for me in auto-complete....)

@imurchie @Jonahss @dylans @erickzhao @bnb @dmethvin @timmywil @Trott @joesepi @TheLarkInn @sokra @eemeli @tobie @mhdawson @ljharb

[joesepi]

+1

[mcollina]

Approved, +1

[ljharb]

+1

[ljharb]

Made @openjs-foundation/voting-members; hopefully that’s easier next time :-)

[eemeli]

What is the frequency of "TSC votes", and what's the longest gap between such so far?

As currently worded, if there's ever a 3 month period with no such vote, all TSC members are automatically removed. If there's just one vote, then anyone not participating in it is removed.

[tobie]

OK, so I was originally +1 because I don’t think it should be the CPC’s role to police the way projects handle their day to day. That said, it feels from comments on the issue itself that given the few times the TSC votes, this risks arbitrarily removing people from the TSC that would otherwise be considered in good standing. Has this been thought through properly?

[timmywil]

Perhaps it could be based on a percentage of votes rather than votes within a time period? What if...

1. There are no votes in 3 months
2. There are only one or two votes in that time period. Is it intended that missing such a small number results in removal?

[Trott]

What is the frequency of "TSC votes", and what's the longest gap between such so far?

As currently worded, if there's ever a 3 month period with no such vote, all TSC members are automatically removed. If there's just one vote, then anyone not participating in it is removed.

We've talked about this in the TSC in the past and determined that if there are no votes, then no one gets removed, as that is the only sensible interpretation. Admittedly, that's an inference. We can change the text to make that explicit in the text if that is required by the CPC.

[Trott]

There are only one or two votes in that time period. Is it intended that missing such a small number results in removal?

Yes, that is definitely intended. There is typically only one or two votes in a 90 day period. Votes are usually held open for at least a week, abstentions are considered participating, and if someone gets removed, the TSC can vote to add them back right away if they deem it appropriate (which is something we have done in the past).

[Trott]

OK, so I was originally +1 because I don’t think it should be the CPC’s role to police the way projects handle their day to day. That said, it feels from comments on the issue itself that given the few times the TSC votes, this risks arbitrarily removing people from the TSC that would otherwise be considered in good standing. Has this been thought through properly?

Yes. The TSC can vote to re-add people immediately as appropriate. Speaking for myself only and not the rest of the TSC, it would be a feature, not a bug, if the rule erred on the side of removing people a bit too often rather than not often enough.

[timmywil]

Fair enough. Then I’ll add my +1, but is there already language somewhere in the charter about adding someone back?

[Trott]

Fair enough. Then I’ll add my +1, but is there already language somewhere in the charter about adding someone back?

Not specific language beyond the indication that the TSC has a mostly free-hand in adding people at any time:

TSC memberships are not time-limited. There is no maximum size of the TSC. The size is expected to vary in order to ensure adequate coverage of important areas of expertise, balanced with the ability to make decisions efficiently. The TSC must have at least four members.

There is no specific set of requirements or qualifications for TSC membership beyond these rules. The TSC may add additional members to the TSC by a standard TSC motion.

[tobie]

I'm not going to block this.

I just want to spell out that creating rules that could imply removing someone from a governing body who just missed one vote is by definition non-inclusive to folks with health issues, care responsibilities, disabilities, or in maternity leave, just to name a few. The fact that those folks can be voted back-in doesn't change the underlying impact and feeling of loss of agency that such a policy creates. I would strongly suggest finding a different way of dealing with the underlying issue.

[Trott]

I just want to spell out that creating rules that could imply removing someone from a governing body who just missed one vote is by definition non-inclusive to folks with health issues, care responsibilities, disabilities, or in maternity leave, just to name a few. The fact that those folks can be voted back-in doesn't change the underlying impact and feeling of loss of agency that such a policy creates. I would strongly suggest finding a different way of dealing with the underlying issue.

Again, speaking for myself and not the TSC:

That is a valid criticism. A better approach would be to create a culture where being moved to emeritus is not seen as a failure or a punishment or a demotion or something permanent. I'd like to think that people going on parental leave or having health issues would proactively move themselves to emeritus and perhaps announce that they hope/expect to be able to return in such-and-such a timeframe. Alas, I think that being emeritus is either sufficiently stigmatized or else otherwise seen as a potential pitfall in trying to rejoin that this mostly doesn't seem to happen. That is a cultural issue for the TSC to fix, and one that has been discussed a fair bit internally, but I don't actually think we're on track to changing it. One obstacle is that TSC membership is (correctly) seen as a boon for one's career in a lot of cases, and so people are loathe to give it up, even temporarily, perhaps for fear of not getting it back, but also perhaps for other reasons.

Maybe the right thing to do is to remove the minimum-participation rules entirely and actively manage the membership. That seems like the right and straightforward thing to do, but there are (possibly unspoken and not entirely identified) reasons that approach has never worked during the past 8 years or so.

[tobie]

Could it be just a naming issue? Would using TSC member and TSC active member change the dynamics?

Could folks self-reactivate their membership during a grace period?

Could the duration of inactivity triggering a status change be longer?

Taking a step back, what problem is this trying to address? What problem are inactive TSC members causing? Are there other, more inclusive ways to solve this problem?

[mcollina]

The problem is having quorum for votes and general decision making.

[tobie]

The problem is having quorum for votes and general decision making.

Oh! Change that then? Make quorum a function of members present or having sent their regrets for sync decision making, and a fixed number + deadline for async stuff?

[eemeli]

As currently worded, if there's ever a 3 month period with no such vote, all TSC members are automatically removed. If there's just one vote, then anyone not participating in it is removed.

We've talked about this in the TSC in the past and determined that if there are no votes, then no one gets removed, as that is the only sensible interpretation. Admittedly, that's an inference. We can change the text to make that explicit in the text if that is required by the CPC.

Yes, I would like that to be made explicit.

There are only one or two votes in that time period. Is it intended that missing such a small number results in removal?

Yes, that is definitely intended. There is typically only one or two votes in a 90 day period. Votes are usually held open for at least a week, abstentions are considered participating, and if someone gets removed, the TSC can vote to add them back right away if they deem it appropriate (which is something we have done in the past).

I am very concerned about this approach. Specifically, this sounds like it's setting up a potential way to get rid of unwanted TSC members, by timing a vote for a time when such a member is not available and then not voting them back. I'm sure that's not the intention, but that's still the effect of this change.

If the occurrence of TSC votes is this rare, it sounds like might be better to word the policy not based on calendar time, but on votes. Maybe something like this?

A TSC member is automatically removed from the TSC
if they do not participate in any of three consecutive TSC votes.

[Trott]

If the occurrence of TSC votes is this rare, it sounds like might be better to word the policy not based on calendar time, but on votes. Maybe something like this?

A TSC member is automatically removed from the TSC
if they do not participate in any of three consecutive TSC votes.

That is worth consideration.

[mcollina]

IMHO that would be a good change.

[tobie]

@eemeli that’s simple and effective. I like it. Nitpick: You want to make sure the votes are on three distinct dates.

[eemeli]

@tobie That should already be covered by "consecutive", as each vote is open for at least a week.

[Trott]

Longer term, I wonder if the Node.js TSC might be restructured to be more like the CPC: A relatively large group of members that don't have much (anything at all?) in the way of responsibility, and a smaller number of voting members who actually make the decisions (and who mostly have to be re-appointed annually). There are lots of people in the members list who seem to be completely uninvolved in CPC business, and maybe that's OK. And maybe the Node.js TSC can do something like that and dispense with rules and handwringing about whether and how to remove people. (Or at least the rules could be greatly simplified and made far more lenient: You are moved to TSC emeritus if and when you are also moved to collaborator emeritus.) If I understand correctly, the CPC has been around for 4 or 5 years and no regular member has ever been moved to emeritus for any reason other than Myles choosing to move himself to emeritus.

[Trott]

I'm going to close this and open a new issue for the changes in nodejs/TSC#1350. Thanks, everyone!