Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta: move one or more TSC members to regular member #46985

Merged
merged 1 commit into from Mar 20, 2023

Conversation

nodejs-github-bot
Copy link
Collaborator

This PR was generated by tools/find-inactive-tsc.yml.

@nodejs/tsc @danielleadams @fhinkel

Since 3 months ago, danielleadams attended 1 out of 10 meetings and voted in 0 of 0 votes. Since 3 months ago, fhinkel attended 1 out of 10 meetings and voted in 0 of 0 votes.

@nodejs-github-bot nodejs-github-bot added meta Issues and PRs related to the general management of the project. doc Issues and PRs related to the documentations. labels Mar 7, 2023
@RafaelGSS
Copy link
Member

Does the email vote counts? I'm pretty sure @fhinkel and @danielleadams voted there.

@Trott
Copy link
Member

Trott commented Mar 7, 2023

Does the email vote counts? I'm pretty sure @fhinkel and @danielleadams voted there.

That wasn't a vote. That was a discussion. There was no call for a vote or tallying of votes or people abstaining or anything like that.

There is, however, nothing stopping anyone on the TSC from immediately re-nominating both people and the TSC voting them both back onto the group. (The charter says the move to emeritus is automatic so they'd have to be voted back on.)

I've come to the conclusion that the correct thing to do is to make TSC membership effectively permanent and have a smaller subset of the TSC as active appointments for a year that get to vote and whatnot, basically similar to what the CPC is in the OpenJS Foundation. (There are 15 voting members but 44 members total, most of whom have not been involved in any significant way for years. Rather than deal with the whole awkward interpersonal and inclusivity issues around moving people to emeritus, they simply let people stay forever. ) The main obstacles right now are writing up the changes required to the TSC charter, and figuring out how to determine who the voting members are. I have a lot of ideas for that second part. Unfortunately, none of my ideas are good ideas.

@Trott
Copy link
Member

Trott commented Mar 7, 2023

The main obstacles right now are writing up the changes required to the TSC charter, and figuring out how to determine who the voting members are. I have a lot of ideas for that second part. Unfortunately, none of my ideas are good ideas.

I think I have a workable PR change for the charter. nodejs/TSC#1350

If we don't call it "emeritus" but just continue to call folks "members", then it hopefully eliminates a lot of the sting and/or stigma. What we now call "members" can be "voting members". People who want to be re-admitted as voting members have a pretty straightforward path--participate! Come to meetings, or comment on relevant TSC issues, or whatever. (Or, you know, be a Releaser and a security triager. Like Danielle does right now! Those are solid indications of investment in the project in my book!)

It effectively changes nothing from a practical perspective, but it (hopefully) removes (or at least reduces) the obstacle of "being on the TSC is a career boost" (OK, you get to stay on the TSC!) or "this is a punishment/demotion" (it's hard to argue with "you haven't voted the last 3 votes, so we're going to stop including you when we vote").

@mscdex
Copy link
Contributor

mscdex commented Mar 7, 2023

I've come to the conclusion that the correct thing to do is to make TSC membership effectively permanent

Can you explain a bit why that would be the correct thing to do?

I would think having two types of "TSC" members would potentially make things more awkward by incorporating inequality.

Honestly, I think the current rules are fine and that they represent the fairest solution (everyone is judged exactly the same and everyone has a path to rejoining the TSC if they so desire), but I do wish we'd actually follow those rules better rather than regularly dismissing these automated PRs when the affected people think they should stay on "because".

@Trott
Copy link
Member

Trott commented Mar 7, 2023

Can you explain a bit why that would be the correct thing to do?

I would think having two types of "TSC" members would potentially make things more awkward by incorporating inequality.

That's a great question, and a totally fair one.

There already are two types of "TSC" members. There is an "emeritus" role and a "regular" role. Right now, there is tremendous resistance to even temporarily being emeritus. The OpenJS Cross Project Council (CPC) has a similar setup, but has "regular" members and "voting" members. The "regular" members are free to attend meetings and participate in conversations.

While I would love to see a culture where moving to emeritus is not seen as a demotion and being a TSC member is seen less as a status symbol or an indication of influence and more as a service role, I don't see much progress on that culture change after years of trying. The CPC doesn't seem to have these same issues as far as I can tell, and I think that is because there's no pressure to remove "regular" members so people who just want to be members "because" can easily do so.

It also has the benefit of not suggesting that folks are "retired" from the group. You're still part of the group. You just don't vote. Most of the time, people will just...not do anything. And that's fine. But for people who really want to be involved/engaged, there's no sense that they'd be crashing TSC meetings if they showed up, or that they would be unwelcome if they commented in the TSC repo or whatever. They're still members, even if they aren't making decisions via votes anymore. And the idea that people can move easily from voting member to regular member and back again is implicit in the structure, which it isn't right now when we call those things "regular" and "emeritus".

@bnoordhuis
Copy link
Member

That waters down what it means to be a TSC member though. I also don't think it's fair that someone who hasn't been active for a long time has a vote with the same weight as someone who is involved daily.

Maybe the current rules should be relaxed a bit, maybe they shouldn't, but if you don't have time or inclination to meet the requirements, then stepping down is the right thing to do.

@GeoffreyBooth
Copy link
Member

That waters down what it means to be a TSC member though. I also don't think it's fair that someone who hasn't been active for a long time has a vote with the same weight as someone who is involved daily.

By definition, someone who's inactive and not voting wouldn't be a TSC voting member.

I don't consider TSC membership to be a reward for someone who's put in a significant amount of effort. It's a team with a specific function, which is to manage the project: both the technical and personnel aspects. The TSC needs people who can help it perform that function, and the skills involved with that don't necessarily correspond with contributor activity.

Maybe the current rules should be relaxed a bit, maybe they shouldn’t, but if you don’t have time or inclination to meet the requirements, then stepping down is the right thing to do.

Perhaps it is, but that’s not what’s currently happening. To the contrary, we’ve been going in the other direction of relaxing the requirements so as to exclude fewer people. It seems clear that we’d rather have a larger group of less-active people than a smaller group of more-active people, so long as the smaller group can make decisions and take actions (which it currently can). The argument for the larger/less-active committee is that it includes more diversity of experiences and viewpoints, so that when questions are raised the debate is more likely to include people with relevant expertise.

@bnoordhuis
Copy link
Member

By definition, someone who's inactive and not voting wouldn't be a TSC voting member.

:eye roll:

It seems clear that we’d rather have a larger group of less-active people than a smaller group of more-active people

It's what currently happens, yes, but it's because individual TSC members are reluctant to step down "because", not due to some concerted group effort.

The argument for the larger/less-active committee is that it includes more diversity of experiences and viewpoints

I won't "by definition" you but inactive members don't contribute so... no.

@GeoffreyBooth
Copy link
Member

By definition, someone who's inactive and not voting wouldn't be a TSC voting member.

:eye roll:

The point of @Trott’s proposal was to make it easy to have a subset who vote on things, without needing to “demote” anyone. Do you think people would fight to retain the “voting member” title specifically, if they could be on the TSC no matter what and retain the overall TSC Member title without needing to do anything?

I won’t “by definition” you but inactive members don’t contribute so… no.

How do you define “contribute”? In my experience, the people who don’t attend meetings frequently are often still active in their areas of interest. Basically, I want them to be “there when we need them”—as in, when there’s a TSC decision to be made that involves their area of expertise, I would hope that they speak up. They’re more likely to do so if they’re still in the TSC in some capacity, as a nonvoting member.

Again, I don’t consider the TSC to be the honor roll of biggest code contributors. That’s not what membership is for, and it’s not what we need from the TSC.

@bnoordhuis
Copy link
Member

Do you think people would fight to retain the “voting member” title specifically

Definitely. People are people. :-)

How do you define “contribute”? In my experience, the people who don’t attend meetings frequently are often still active in their areas of interest.

Are they? I'm willing to concede the point, maybe they're not very visible to me, but I do look almost daily at the bug tracker and open pull requests so I feel like I ought to have a pretty good picture of who does what.

TSC members are decision makers (that's the whole point of the TSC after all) and you can't be a good decision maker if you check in maybe once a month.


As a parenthetical aside: I don't really understand the reluctance of people to step down. When I realized I wouldn't have time anymore going forward, I resigned. No big thing.

For the same reason I don't plan on rejoining, because I'm sure I won't be able to meet the requirements in the future either. But hey, if we're relaxing the rules...

@Trott
Copy link
Member

Trott commented Mar 8, 2023

At the TSC meeting today, Matteo moved to convert Danielle (who was in attendance at the meeting) to active membership. There were no objections, many +1s, and 15 out of 20 members in attendance. The charter indicates that members can be added by a standard motion so no vote is required. So Danielle is active. I'll push a fixup commit to this PR.

@Trott Trott added the commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. label Mar 8, 2023
@Trott Trott closed this Mar 8, 2023
@Trott Trott reopened this Mar 8, 2023
Copy link
Member

@richardlau richardlau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving under the current rules:

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.

There's a current discussion over in nodejs/TSC#1350 about changing the charter, but this PR is valid for the charter as it stands.

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Trott
Copy link
Member

Trott commented Mar 20, 2023

With the recent change to the charter, Franzi should be moved to the regular member section. I'll update this.

@Trott Trott changed the title meta: move one or more TSC members to emeritus meta: move one or more TSC members to regular member Mar 20, 2023
@Trott Trott added commit-queue Add this label to land a pull request using GitHub Actions. and removed commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. labels Mar 20, 2023
@nodejs-github-bot nodejs-github-bot removed the commit-queue Add this label to land a pull request using GitHub Actions. label Mar 20, 2023
@nodejs-github-bot nodejs-github-bot merged commit bc0aa35 into main Mar 20, 2023
13 checks passed
@nodejs-github-bot nodejs-github-bot deleted the actions/inactive-tsc branch March 20, 2023 16:24
@nodejs-github-bot
Copy link
Collaborator Author

Landed in bc0aa35

RafaelGSS pushed a commit that referenced this pull request Apr 5, 2023
PR-URL: #46985
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
@RafaelGSS RafaelGSS mentioned this pull request Apr 6, 2023
RafaelGSS pushed a commit that referenced this pull request Apr 7, 2023
PR-URL: #46985
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
danielleadams pushed a commit that referenced this pull request Jul 6, 2023
PR-URL: #46985
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants