Update charter to address membership challenges

[Trott]

Change "TSC Member" to "TSC Voting Member", and change "TSC Emeritus Member" to "TSC Member". This lets the TSC somewhat mirror the CPC, where only about 1/3 of the members actually vote (and most of the other members aren't in fact active, but it doesn't adversely affect the CPC).

EDIT: Once this is approved, we would:

• Change TSC emeriti that are current collaborators to TSC members.
• Leave TSC emeriti that are not current collaborators as emeriti.

[Trott]

@nodejs/tsc

[aduh95]

If we make this change, we need first to discuss the org admin aspect of being a TSC member, if we have TSC members who are inactive they don’t need to be org admins (not sure about HackerOne, and the TSC mailing list, worth discussing as well), and keeping their access is just added risk for Node.js to have one of its admin account compromised. The easiest solution would be to restrict this to TSC voting members; another solution would be to have another subset of the TSC that would be appointed as org admin for e.g. one year.

[Trott]

If we make this change, we need first to discuss the org admin aspect of being a TSC member,

My intention was that only voting members would be org admins, HackerOne members, email recipients (although we can have two separate TSC mailing lists--one for all members and one for voting members), etc. You are right that we'll want to figure that all out ahead of time. (And don't forget the TSC private Slack channel!) I think everything (except for maybe the TSC Slack channel) is probably covered in the TSC onboarding/offboarding docs so that's a good place to look to see if we are forgetting about anything.

[Trott]

Without getting into details about whether or not this particular text is good or not, can current TSC members who are strongly in favor or opposed to changing the titles like this weigh in? I want to get an idea if there is support or not for the general concept, regardless of whether I've done a good enough job editing the charter here.

[GeoffreyBooth]

I want to get an idea if there is support or not for the general concept

Yes, I support the general concept. We might want to use this as an opportunity to reconsider the name of the TSC, as we’re really the executive committee or leadership committee of the project and responsible for more than just “technical steering.” Regardless of the name of “_ Committee / _ Committee Voting Member” I think the proposed structure will be a significant improvement.

[Trott]

@tobie @eemeli You two had especially good/thoughtful comments on the last proposed charter change. Any chance you can take a look at this before we pass it on to the CPC voting members for approval?

[mcollina]

lgtm

[eemeli]

This looks much better!

[jasnell]

eh, I'm really not all that convinced this is worthwhile, to be honest. Yes, I understand we've had some issues here but I think we need to do a better job of encouraging no-longer active TSC members to just not be TSC members anymore. I'm not going to block, however, if the majority of TSC members want this. Just consider my vote to be -0.

[Trott]

I believe #1350 (comment) addresses this line of thinking.

[nschonni]

I'm having a hard time seeing the difference between a non-voting TSC member and the existing Collaborator role. Possibly the only one might be that they'd be invited to in-camera TSC meetings, while Collaborators wouldn't?

[Trott]

I'm having a hard time seeing the difference between a non-voting TSC member and the existing Collaborator role. Possibly the only one might be that they'd be invited to in-camera TSC meetings, while Collaborators wouldn't?

Yes, the differences are small and possibly non-existent. The charter as proposed here doesn't require it, but I imagine that non-voting members would be invited to the meetings and also that we might choose to create one or more communication channels specifically for TSC members (both voting and non-voting) such as an email list or a Slack channel. But strictly speaking, we might do neither of those things and it is just a title in that case, with no additional privileges or responsibilities.

[tobie]

That's a great improvement on the previous proposal, and simplifies things quite a bit.

I do agree with @jasnell, however that the distinction between the two kinds of members does still feel like a lot of governance in order to avoid just asking people to step down. Have you tried for the chair to reach out to folks that stop showing up in order to understand what's going on, help address possible issues, and suggest stepping down otherwise, or being on "pause" for a while?

I've also heard mentioned that reaching quorum could be an issue. If so, have y'all considered calculating quorum against the set of folks who had voted in the last three votes (for example) rather than against the whole membership?

Overall, I understand that this is a sensitive topic and that spelling out what the underlying issues is might be unpleasant, but I'm also wary of coming up with solutions to problems that are not clearly specified.

That said, this is still a great improvement of the previous proposal and the existing solution, and as I said from the get-go, the role of the CPC isn't to dictate how projects run, but to make sure that they do so in a way that is compatible with the values of the OpenJSF (which all of those different propositions absolutely are), and to offer suggestions/guidance when prompted. My bias is towards simplifying things as much as possible and getting to the desired outcomes through communication, culture, and values rather than policy, so I'd encourage you to explore that direction further. But this is also good enough, and moving ahead with this (and revisiting down the line if necessary)is also a completely sound approach.

[Trott]

Have you tried for the chair to reach out to folks that stop showing up in order to understand what's going on, help address possible issues, and suggest stepping down otherwise, or being on "pause" for a while?

We can do that in addition to these charter changes, but I would not want to do that instead.

I've done that kind of outreach in the past and it has never yielded results. People always want to stay on the TSC, typically because "Node.js TSC member" helps people's careers and conference-speaking prospects and other things. By allowing them to keep the title, this change will (hopefully) make the process easier. (I have already had one person tell me they would probably move to the "regular member" status if this change goes through, which is certainly an indication that this change might make the whole role-change less challenging for everyone.)

And to preempt a potential question: "Won't that make the title of 'TSC member' less valuable or even worthless?" My answer is that would be a feature and not a bug. If this change makes TSC (voting) member less of a symbol of status or power to be pursued, and more of a duty, volunteer function, or perhaps even a calling, that would be good.

[tobie]

We can do that in addition to these charter changes, but I would not want to do that instead.

That sounds reasonable.

And to preempt a potential question: "Won't that make the title of 'TSC member' less valuable or even worthless?" My answer is that would be a feature and not a bug. If this change makes TSC (voting) member less of a symbol of status or power to be pursued, and more of a duty, volunteer function, or perhaps even a calling, that would be good.

Can't agree more.

[tniessen]

We would also have to update docs within the main repository based on this change. For example, if TSC emeriti become "TSC members", my understanding is that their approvals should still not count as TSC approvals on semver-major PRs.

[Trott]

We would also have to update docs within the main repository based on this change. For example, if TSC emeriti become "TSC members", my understanding is that their approvals should still not count as TSC approvals on semver-major PRs.

Yes. My thinking is:

1. Get TSC consensus on this change.
2. Get CPC approval for this change.
3. Update all the docs in the main repo.
4. Land this PR.

I suppose there's nothing stopping me or someone else from pulling together a PR for step 3 right now, as it seems likelier-than-not that this has consensus. On the other hand, maybe I (or someone else) should wait until there are more than 4 current TSC members (including me) indicating they support this change.

[aduh95]

Suggested change

	issue. The TSC voting members should serve as the final arbiter where required.
	issue. A decision voted by the TSC should serve as the final arbiter where required.

Maybe we should introduce something called TSC voting team and replace most use of TSC voting members with TSC voting team. wdyt?

Suggested change

	issue. The TSC voting members should serve as the final arbiter where required.
	issue. The TSC voting team should serve as the final arbiter where required.

(another option is to stick with the previous version, which is still correct IIUC, albeit a little more vague)

[bnb]

Commenting as I'm reading, but wanted to get ideas out:

This is cool and I'm happy to see this change. Overall I think this will be a healthy change for the project. IMO this will dramatically reduce the barrier to people feeling like they belong, which I think is likely a good move for the project and how it's rather uniquely governed.

I've done that kind of outreach in the past and it has never yielded results. People always want to stay on the TSC, typically because "Node.js TSC member" helps people's careers and conference-speaking prospects and other things. By allowing them to keep the title, this change will (hopefully) make the process easier. (I have already had one person tell me they would probably move to the "regular member" status if this change goes through, which is certainly an indication that this change might make the whole role-change less challenging for everyone.)

I'll 100% +1 this - IMO this is a result of the extremely relaxed membership approach that io.js took, which defined the culture of participation in Node.js to this day. I had a very similar experience as the CommComm chair - people would just say yes they wanted to be a member then never show up again. Every time I asked they were just about to be able to contribute again. I've definitely ended up in this position myself a few times - though in those situations in the past year or two, I've tried to recognize it and step back to evaluate if my response is the most accurate one I can give.

Adding Emeritus with a low barrier in CommComm did help with this, and I'm guessing the model proposed here is going to be even more helpful.

And to preempt a potential question: "Won't that make the title of 'TSC member' less valuable or even worthless?" My answer is that would be a feature and not a bug. If this change makes TSC (voting) member less of a symbol of status or power to be pursued, and more of a duty, volunteer function, or perhaps even a calling, that would be good.

This is a good take and I'm happy to hear it.

In general, I have been worried about stagnation in the project's leadership. We used to see a lot more faces cycling through higher leadership positions, but that has dramatically slowed. I'm hopeful that this is a healthy step that will enable more people grow into leadership in the project.

[Trott]

Landing as-is, as this text was approved by CPC and TSC, and comments remaining are listed as non-blocking. Feel free to open another PR if we want to revise the text further and thank you, everyone, for your patience with all of this.