charter: remove meeting attendance requirement

[cjihrig]

This commit removes the requirement for TSC meeting attendance. After this change, there is currently only one item in the list of TSC member requirements. I decided to leave the list in place under the assumption that other list items may be added in the future.

Fixes: #1338

[cjihrig]

Converted to draft because this cannot land yet.

[Trott]

Since we're reducing the list to one item, maybe inline it?

Suggested change

	A TSC member is automatically removed from the TSC if, during a 3-month period,
	all of the following are true:
	* They attend fewer than 25% of the regularly scheduled meetings.
	* They do not participate in any TSC votes.
	A TSC member is automatically removed from the TSC if they do not participate
	in any TSC votes during a 3-month period wherein there is at least one TSC vote.

[apapirovski]

I believe that wording would mean that anyone who didn't vote in the previous vote would be then removed from the TSC automatically as soon as this PR lands? I don't believe that's what you're intending.

Similarly, given infrequency of votes, is missing a single vote a reasonable grounds for someone being automatically removed?

[Trott]

Similarly, given infrequency of votes, is missing a single vote a reasonable grounds for someone being automatically removed?

I think it is reasonable. The TSC can vote people back on immediately if it is appropriate. Votes are kept open typically for a week or so. Sometimes, people will be on vacation or whatever, and that's fine. The TSC can act on those on a case-by-case basis. Being removed isn't punishment.

[Trott]

CPC issue requesting approval: openjs-foundation/cross-project-council#1016

[mcollina]

lgtm

[apapirovski]

Landing this before the end of February would result in the removal of the following members:

@ChALkeR
@RafaelGSS

[RafaelGSS]

Landing this before the end of February would result in the removal of the following members:

@ChALkeR @RafaelGSS

Why? We haven't had any TSC votes in the time I'm in the TSC AFAIK

[mhdawson]

The challenge I see with using only votes as the criteria is that they occur infrequently.

How about we change it to:

TSC members are expected to regularly participate in project and TSC activities.

A TSC member is automatically removed from the TSC if, during a 3-month period they do not participate in at least 12 issues or prs in the repositories within the Node.js organizations.   

That would require commenting, or otherwise being involved in on average 1 issue per week across the Node.js organization.

[RafaelGSS]

Perhaps including an alert, 1 week before the automatic removal would be great. Just to not remove someone without previous notice.

[Trott]

Why? We haven't had any TSC votes in the time I'm in the TSC AFAIK

It wouldn't remove you. Only Chalker. The tooling (and policy) does not go into effect if you haven't been on the TSC for the entire 90-day period in question.

[Trott]

The challenge I see with using only votes as the criteria is that they occur infrequently.

How about we change it to:

TSC members are expected to regularly participate in project and TSC activities.

A TSC member is automatically removed from the TSC if, during a 3-month period they do not participate in at least 12 issues or prs in the repositories within the Node.js organizations.   

That would require commenting, or otherwise being involved in on average 1 issue per week across the Node.js organization.

IMO, this just replaces the existing loophole with a new one.

[Trott]

Perhaps including an alert, 1 week before the automatic removal would be great. Just to not remove someone without previous notice.

I appreciate the sympathy toward your fellow TSC members this shows, but it would just enable another loophole making it impossible to ever remove anyone. Wait until you get the alert, leave a bunch of "+1" comments or rubber-stamp PR approvals, go away for another 90 days.

[Trott]

Being moved to emeritus is not a punishment and it isn't permanent. People can be voted back on immediately, or in a week, or a month, or three months, or whatever. We should be unconcerned about moving someone to emeritus inappropriately. It's not a problem and our current problem is that moving people to emeritus effectively never happens. (Or you can argue that isn't a problem, but we've had this discussion before and I think the "it's a problem" side had the more convincing arguments.)

[GeoffreyBooth]

The challenge I see with using only votes as the criteria is that they occur infrequently.

How about we change it to:

I think adding a new membership requirement is a separate question from removing the meeting attendance one. Let’s just remove the meeting attendance requirement as requested first, on its own. If people want to propose a new requirement afterward, that should be a separate discussion.

[apapirovski]

Why? We haven't had any TSC votes in the time I'm in the TSC AFAIK

I just did a diff of last vote and current member list. Sorry 😅

We should be unconcerned about moving someone to emeritus inappropriately.

I think changing the rules, effective immediately, such that someone is suddenly deemed to not have participated over the past 3 months isn't particularly great.

[GeoffreyBooth]

I think changing the rules, effective immediately, such that someone is suddenly deemed to not have participated over the past 3 months isn’t particularly great.

Let’s just do a formal vote for removing the meeting attendance requirement.

[Trott]

Let’s just do a formal vote for removing the meeting attendance requirement.

I'd prefer to just wait one week, when all votes will be outside the 90 day window and there will be no one subjected to this rule until we have a vote in the future (at which point the expectation is that everyone will participate in the vote--a happy outcome in my opinion--in the rare event that someone is on holiday or whatever for the entire duration of a vote or whatever, we can vote them back on the TSC).

[Trott]

I think @tobie's comment is sufficiently worth reading that I'm going to reproduce it here:

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.

My reply:

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.

[GeoffreyBooth]

Arguably we should remove the voting requirement too. And at that point, it begs the question why we need or want any culling of TSC membership at all. This is a good discussion to have, but probably not on this thread. I kicked it off with #1338 (comment), but it should get its own thread.

[Trott]

openjs-foundation/cross-project-council#1016 (comment)

This is worth considering, IMO.

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.

[cjihrig]

This is worth considering, IMO.

I really like the idea of not being removed from the TSC for potentially missing a single vote. I'm assuming that adding anything to this PR beyond removing the meeting requirement would require another TSC conversation though?

[Trott]

This is worth considering, IMO.

I really like the idea of not being removed from the TSC for potentially missing a single vote. I'm assuming that adding anything to this PR beyond removing the meeting requirement would require another TSC conversation though?

I think you should go for it. Make all the changes we want in a single PR. It can be this one, or you can close it and open a new one for a fresh conversation. The CPC feedback happened quickly, in my opinion, and I don't think a second CPC conversation would take very long. (The CPC didn't take this up at a meeting. It's all been asynchronous so far.)

[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 CPC 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.

[mcollina]

Given that we are a more diverse group now with people all around the globe, we should move away from making decisions in meetings as our bylaws say and move to making decisions asynchronously.

The TSC shall meet regularly using tools that enable participation by the community (e.g. weekly on a Google Hangout On Air, or through any other appropriate means selected by the TSC). The meeting shall be directed by the TSC Chairperson. Responsibility for directing individual meetings may be delegated by the TSC Chairperson to any other TSC member. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings.

The TSC will elect from amongst voting TSC members a TSC Chairperson to work on building an agenda for TSC meetings...

The TSC follows a Consensus Seeking decision making model. When an agenda item has appeared to reach a consensus the moderator will ask "Does anyone object?" as a final call for dissent from the consensus.

If an agenda item cannot reach a consensus a TSC member can call for either a closing vote or a vote to table the issue to the next meeting. The call for a vote must be seconded by a majority of the TSC or else the discussion will continue.

It does not mention making decisions in any other way.

Note that this is not how we have been operating in the last while. Most of our recent votes have been asynchronous to encourage maximum participation and diversity of opinions.

I think we should remove the meeting obligation altogether and have asynchronous decision-making instead.

[BethGriggs]

I think we should remove the meeting obligation altogether and have asynchronous decision-making instead.

+1. Although, I feel some occasional topics may benefit from a more synchronous conversation - but they're probably a small subset of what typically ends up on the agenda.

I do not think our current approach of having a TSC Agenda label combined with mandatory meeting attendance rules encourages asynchronous input. For now, we're required to attend the meetings anyway, and that's when the topic is scheduled to be discussed, so the discussion often gets deferred until the meeting. And then, we may be missing some key members for that topic so we defer again.

Maybe it's just semantics for some, but I wonder if our approach would change if we had a label to indicate that TSC input is requested (TSC Review*) rather than the TSC Agenda label which implies 'wait for a meeting for it to be discussed'. Involvement in TSC Review labelled issues might then become an appropriate metric to consider along with participation in votes.

(I suppose we do already get notifications from the GitHub TSC team - but I am guessing these are easily missed and it could be useful to have a distinction between FYIs and explicit requests for TSC input.)

^{*Label name to be bikeshed! TSC Review / TSC Input / etc.}

[GeoffreyBooth]

I wonder if our approach would change if we had a label to indicate that TSC input is requested (TSC Review*) rather than the TSC Agenda label

I've been thinking lately, like after reading last week's agenda, how I wish I knew what was being asked of the TSC for each of these items. Most of last week's agenda items seemed to be "for TSC visibility" which is fine, but it also begs the question: why do they need to be meeting topics? For items where we need to make a decision, it would help if the question to be answered was written down ahead of time, ideally with pros and cons like an executive summary. And yes, when all that's desired is a TSC member's code review, it would be nice to have a label to explicitly request that.

So yes, 👍 on more focused labels.

[aduh95]

if we had a label to indicate that TSC input is requested (TSC Review*)

I think we used to have that, and it was removed because it was ineffective – the TSC meeting agenda on the other hand is very effective to add visibility to a PR/issue.

I wish I knew what was being asked of the TSC for each of these items

Maybe we could have a rule that for an item to be on the agenda, @nodejs/tsc must have been pinged on the issue and asked a specific question?

[BethGriggs]

I think we used to have that, and it was removed because it was ineffective – the TSC meeting agenda on the other hand is very effective to add visibility to a PR/issue.

Ah, I don't remember that. I do suspect a lot of the visibility comes from having a weekly generated issue with the list of issues to review - if they were added to a specific TSC Review section in the weekly TSC issue perhaps it would have been more effective. With meeting attendance rules being relaxed, I do think we should consider new approaches that encourage out-of-meeting inputs/resolutions somehow.

Maybe we could have a rule that for an item to be on the agenda, @nodejs/tsc must have been pinged on the issue and asked a specific question?

Similar to the proposal in nodejs/Release#821, perhaps once the TSC Agenda label is added the bot could add a comment asking the labeller for the reason it was added? Maybe there are concerns that would be too noisy, though.

[cjihrig]

Closing this in favor of #1350