Proposal: drop mandatory meeting attendance requirement

[cjihrig]

The TSC charter currently states:

TSC members are expected to regularly participate in TSC activities.

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.

I propose dropping the requirement for meeting attendance and making it optional. My reasoning is:

• It does not actually reflect participating in TSC activities. In a very hypothetical universe, someone could connect to the meeting and not participate or even pay attention.
• We have set a precedent for not really enforcing this - meta: move one or more TSC members to emeritus node#44957, meta: move one or more TSC members to emeritus node#44885, meta: move one or more TSC members to emeritus node#44802, meta: move one or more TSC members to emeritus node#44728.
• This is subjective, but IMO the meetings are usually low value. If there is an important discussion, vote, or private section then it makes sense to attend. We should do more on GitHub, Slack, etc. The private section in its current form is also problematic, but that's a topic for another issue.
• For people who are not paid to work on Node, these types of meetings during the workday can be problematic. Having these meetings outside of work hours is also not ideal.

[BethGriggs]

Thanks for starting this discussion. I have a few, potentially conflicting, opinions.

^(IMO) A TSC with active, engaged, and informed members is what should enable it to make appropriate, effective, and timely decisions for the project. I also do not feel an individual's ability to attend a meeting that may or may not conflict with their timezone, or personal or work commitments is a good gauge of that.

Also, it's probably not an efficient use of member's time to force them to attend meetings if they have no opinions on the subjects on the agenda for that week. (And it should also be okay not to have an opinion on every topic.)

Making the meetings optional does mean it is even less likely that we'll reach a quorum in a given meeting. That might not be a bad thing if it forces us to deal with things more asynchronously with better paper trails.

In another hypothetical universe, an individual could limit their engagement to just one uncontroversial (or not requiring significant context) TSC vote per quarter. I don't think either of the requirements is a particularly good gauge of TSC activity, but I'm equally not sure what metrics would be.

I generally think we need to define better proxy metrics for TSC activity or drop them altogether. Perhaps removing this one is a step towards figuring out what those better metrics would be, or even if they're necessary at all.

[apapirovski]

It's hard to say what the right answer here is. The meeting is sometimes the only way to resolve complex issues and raise awareness. I don't think we've found a good way to handle that async, otherwise we wouldn't end up with the number of topics on the agenda that we do.

That said, I also question whether after voting someone in, we actually should care about regulating the list of members. There's no real way for a non-participating member to suddenly become an obstacle to the overall process so what purpose does removing members actually serve? If it's about ensuring that we can reach consensus on votes then that can be done simply by applying the participation criteria to vote counts — i.e., the population of eligible votes is equal to the number of active members (and participating in the current vote would also add one to that list).

Just some top of mind thoughts. Will possibly, or probably, expand on these later.

[Trott]

This may surprise people given my past strong opinions on these kinds of things, but I don't have a strong opinion one way or the other on this. I just want to comment to say that this is a charter change and so we can't make a change like this without the approval of the CPC. (I don't think it will be a problem getting their approval.)

What won't surprise anyone is that despite saying I don't have strong opinions, I'm going to write a bunch of stuff anyway. Here we go:

I've come to the conclusion that the only real way to deal with inactive members is to have a culture where (a) people on the TSC are willing and motivated to take steps to have inactive members depart and (b) it is not seen as a punishment or permanent to be moved to emeritus but rather just a reflection of the natural ebb and flow of people's involvement. We have neither of those things on the TSC. I and others have looked for ways to change that. The result has been many, many lengthy private conversations and nothing to show for it.

That said, I would challenge (but only very sheepishly) the notion that we don't enforce this. We have a bad track record recently, but I (and I believe others) also recently committed to not voting people back on right away next time and enforcing three months of emeritus status before considering re-admittance. I suspect that probably around half the time, people won't want to come back after three months, but of course, that's totally a guess. Also, we do have at least one instance where this was enforced, albeit after 2 years of absence rather than 90 days. Let's not go back to that, at least. That instance was in 2020 and feels like forever ago but wasn't that long ago. nodejs/node@c3c64a1

[Trott]

By the way, just to get it out there, here's a proposal that came out of a conversation between @BethGriggs and me back in October. I don't know if she would endorse it or if it's just some rubbish that only I think might be a decent idea, but here it is, in case we want to think of other ways to measure engagement. The idea here is that there is a lot of unglamorous but highly valuable and necessary work and involvement in these areas is a sign of engagement with the larger project.

A TSC member must be active in one of the following ways:

• A releaser who has done a release in the last 12 months
• A security triager who has done a two-week shift in the last 12 months and acknowledged all H1 reports that came in during that period
• An active Build WG member (will need to workshop this one a bit, as there are definitely a lot of Build WG folks who are not active--including me!)
• An active Moderation Team member (might need to workshop this one a bit too but also maybe not)

We can add other things, but the list should consist of things that actually require an investment of time and effort, be critical to the project's success, and not be the types of things that everyone wants to do all the time. There's nothing wrong with people who simply don't have the inclination or time to spend on Node.js that way, but at the risk of sounding like a total jerk, I'm not sure there's much reason for such people to be on the TSC. Unfortunately, "being on the TSC" is a status symbol and helpful to people's careers, so taking someone off the TSC is seen as an attack rather than a neutral statement.

[aduh95]

we actually should care about regulating the list of members

I think we should, the longer the list of TSC members become, the more likely it becomes that someone account will get compromised; given that TSC members are org admin, and sometimes private things are shared on the TSC mailing list, that would be a huge problem.

If it's about ensuring that we can reach consensus on votes then that can be done simply by applying the participation criteria to vote counts

Being a TSC member is not only about voting though, if it was, I would agree that the bigger the sample of voters, the better. Another discussion would be: should we let emeriti vote, or have another type of membership limited to (public) votes? Maybe that would help communicate that removal from the TSC is not an attack.

[mcollina]

Overall I think we should remove the requirement for meetings because timezones are hard. Most of us can only attend 2/3 of the meetings by design.

Recently it happened that a decision was made in a meeting without giving the "other side" of the discussion space to express their point of view as they couldn't partecipate in the meeting. While there was quorum, this is not in line with our customs and it is in my opinion disrespectful. I don't want to open up this specific can of worm, but it's relevant. If you have questions about this please reach privately.

I think we should make more decisions asynchronously, and reserve decisions in meetings for urgent issues. This means we might call for more votes, and I think it's ok.

Would attendance drop if we remove the requirement? I'm not sure. I think those meetings are also very useful for people to know what the project is doing and they are watched by quite a few people on YT.

---

As a side note, being on the TSC helps with future job opportunities and/or carreer progression. It's hard for somebody to let it go.

[BethGriggs]

There's no real way for a non-participating member to suddenly become an obstacle to the overall process so what purpose does removing members actually serve?

As well as not keeping people with elevated access that's not needed (as @aduh95 mentioned), I also think there are some other subtle reasons why removing inactive members serves a purpose:

• The larger the TSC, the longer we need to wait for feedback, objections, or votes. This isn't a problem if it is both large and responsive, but having unresponsive or inactive members can unnecessarily slow decisions down.
• Because of the increasing size, we could subconsciously (or consciously) be raising the expectations on new members to be nominated to the TSC.
  • To me, it doesn't feel fair if we end up in a state where expect significantly more engagement and effort from nominees than we do of existing members.

[Trott]

I think @BethGriggs's most recent comment and the last thing written by @mcollina in his comment sort of combine to capture the problem. A TSC with a large percentage of mostly-inactive people is, in fact, bad for the health of the project. However, being a TSC member is good for people's career prospects (and probably enhances their ability to get accepted as a conference speaker and other things that also enhance one's profile and career prospects).

Of course, ideally, everyone would put the health of the project first. But in practice, no one wants to take something away from someone else without cause. And taking away a TSC membership hurts someone in real practical terms.

I don't know what the solution is. I and others on here have wrestled with this issue a lot and haven't really come to a good answer. It seems like automated metrics and removal would be the best solution, so it's not personal and it's metrics driven. But that has shown to have two huge weaknesses: 1. Inactive folks tend to worry about meeting the metrics more than actually staying engaged (or at least that's what I infer from behavior and conversations). 2. As @cjihrig points out in the original post here, we have actively undermined the automation making it basically worthless.

But this is all an aside. It does seem like nobody is arguing that we should keep the mandatory meeting attendance requirement.

[Trott]

But this is all an aside. It does seem like nobody is arguing that we should keep the mandatory meeting attendance requirement.

@nodejs/tsc Does anyone believe we should keep it? If so, let's have a vote. If not, let's open a PR, and I'll bring the proposed charter change to the CPC for approval.

[RafaelGSS]

I'm relatively new to the team, so I don't have a strong opinion here.

While I can concur that the TSC role affects career progression, I don't think it should be a thing to take into consideration, after all, TSC Emeritus is still an important role. That said, I also believe they should be able to vote whenever they want. Moving to Emeritus shouldn't mean they aren't relevant to the project anymore, it just means they don't have enough time to commit to the project (note: I'm not saying someone said that they aren't relevant, I'm just making sure this is clear).

IMO I think we should:

• Drop the mandatory meeting attendance
• Create a new issue to discuss how to manage non-active members and potentially, accept new ones.

[GeoffreyBooth]

I think the first question we need to answer is what do we want out of the TSC? And then does this change make it more or less likely that we’ll get what we want. In my mind, the TSC has a few main functions:

1. Make technical decisions for the project: should we add this feature or that, is this ready to be stable, etc.
2. Manage the people: what teams need forming or disbanding, any personnel issues that we need to address.
3. Manage the operations: ensure that releases get out as expected, that security issues are addressed, etc.

The latter two responsibilities make the name “TSC” somewhat of a misnomer, and I’ve suggested calling it the “Executive Committee” to address that. But regardless of naming, the fact that all of this is handled by one big team is part of the problem. We could follow a corporate model and have an executive committee that has no specific responsibilities of its own other than oversight of subcommitees that handle each of these three responsibilities. I doubt this would go over well, of course, because everyone would want to be on the executive committee because the prestige is part of the point.

But anyway, we don’t need to reform everything right now. Would dropping the meeting requirement improve the way the TSC handles any of these functions? I kind of doubt it; if anything, it might hurt the TSC by making it even easier to be a disengaged TSC member, and the more of those we have the less effective the TSC is at doing anything. On the other hand, would it significantly hurt the TSC? I doubt that too, because the meeting requirement hasn’t been all that effective in either improving attendance or in thinning the ranks of non-emeriti. So we could make this change to make our lives easier and on balance I’d guess it has a slightly negative effect on the TSC’s effectiveness. So then the follow-up would be, is the TSC effective enough or do we need to consider ways to improve its effectiveness? And that I don’t know.

[GeoffreyBooth]

Follow-up to my previous comment: let’s say we did rename the TSC to the Executive Committee, and created subcommittees for Technical Direction, Personnel and Operations (and any other core functions I’m forgetting). Everyone currently on the TSC would move over to the Executive Committee, and it would have ultimate authority over all decisions but no formal role in anything, and it would have no membership or activity requirements; it could take votes on things, it could meet or not, but it would be kind of like a company’s board of directors. The subcommittees, however, could have defined meeting attendance requirements and/or voting requirements and so on; and people could be on both the Executive Committee and any number of subcommittees (and we could potentially invite non-Executive Committee members to be on the subcommittees as well). The subcommittee membership requirements should be pretty strict: you really shouldn’t be serving on any of these if you don’t intend to be active. And along those lines, most decisions should be made at that level and would be considered final; there should rarely if ever be a need for the Executive Committee to step in or overrule a decision made by a subcommittee.

This way everyone gets the prestige of being on the ultimate decision-making authority of the project, but we have engaged and effective subteams. Yes if you squint, it’s like I’m renaming TSC Emeritus to Executive Committee and moving the current TSC one level down, but that’s the point: it lets us have effective teams of engaged members without needing to offend anyone with a loss of status. And smaller teams should make scheduling meetings easier, too, as there would be fewer schedules to need to coordinate.

[jasnell]

At the very least I think we should revisit and redefine the requirement. There's just simply no way that I'm going to join meetings that are in the middle of the evening local time and I suspect that's true for most. We should either remove this requirement or redefine it in some meaningful way.