Simplify & Adjust CPC Voting Member Tiers and Process

[bensternthal]

This PR fixes #1677 and #1243 , note changes were discussed in the Nov 11 CPC call.

Highlights Include

• Outlined a new structure for 2026
• Charter updated so that Impact projects appoint representatives that are not term limited
• Charter updated so that Non-impact and regular voting members are now one tier "Community Voting Members" with 5 seats (based on recent #of folks who self nominate)
• Updated the election calendar
• Updated the README to note this difference
• Clarified elections process in the governance doc

Please Note
A challenge with an update like this is ensuring how we operate until the next round of elections is still documented. My approach to this is specifying which policies kick in during the next election cycle. A downside of this approach is that we will want to update the charter again this time next year to remove the old information. I am open to other approaches.

@tobie and @joesepi

[tobie]

Since we’re already doing a bunch of changes, could we rename the “voting members” to anything that doesn’t contain the word “voting” in them? Eg “elected members”

[ctcpip]

Members of the Collaboration spaces at the Core stage may nominate a candidate for one of the voting seats on the CPC which represents the Collaboration spaces. Currently there are no spaces at the Core stage and therefore no representative.

This is in the CPC readme, but for some reason was missed in updating the CPC charter at the time it was done.

I think it seems most appropriate to match the language used for impact projects, e.g. each core collaboration space can appoint one voting member.

Edit: added a suggested change to reflect

[ctcpip]

Suggested change

* Each Impact project may nominate up to two members through a process of their choosing. Once appointed, ratification occurs by opening an issue in the CPC repository announcing the appointment and following the [guidelines for merging PRs](./governance/GOVERNANCE.md#merging-prs-into-this-repository). Impact project voting members serve until they voluntarily step down, until their project appoints a replacement, or if they are removed by a CPC vote.

* Each Impact project may nominate up to two Voting members through a process of their choosing. Once appointed, ratification occurs by opening an issue in the CPC repository announcing the appointment and following the [guidelines for merging PRs](./governance/GOVERNANCE.md#merging-prs-into-this-repository). Impact project voting members serve until they voluntarily step down, until their project appoints a replacement, or if they are removed by a CPC motion.

If the CPC has consensus to remove someone, then there is no need for a vote to be called.

[ctcpip]

Suggested change

	* Each Impact project may nominate up to two members through a process of their choosing. Once nominated the member must be ratified by the CPC Voting members before becoming a Voting member.
	* Up to two Voting members may be nominated by the non-Impact projects based on a process set by the CPC.
	* Each Impact project may nominate up to two Voting members through a process of their choosing. Once nominated, the member must be ratified by the CPC Voting members before becoming a Voting member.
	* Each Core collaboration space may nominate one Voting member through a process of their choosing. Once nominated, the member must be ratified by the CPC Voting members before becoming a Voting member.
	* Up to two Voting members may be nominated by the non-Impact projects based on a process set by the CPC.

[tobie]

We haven't ever used the collab space progression mechanism. I think we should decide what we want to do with it, before adding a dependency on it elsewhere.

[ctcpip]

Suggested change

	* Up to five Community Voting Members may be elected through a process defined in [Section 7. Elections](#section-7-elections). Community Voting Members must be Regular members of the CPC and must not currently be serving as a voting representative for an Impact project.
	* Each Core collaboration space may nominate one Voting member through a process of their choosing. Once appointed, ratification occurs by opening an issue in the CPC repository announcing the appointment and following the [guidelines for merging PRs](./governance/GOVERNANCE.md#merging-prs-into-this-repository). Core collaboration space voting members serve until they voluntarily step down, until their collaboration space appoints a replacement, or if they are removed by a CPC motion.
	* Up to five Community Voting Members may be elected through a process defined in [Section 7. Elections](#section-7-elections). Community Voting Members must be Regular members of the CPC and must not currently be serving as a voting representative for an Impact project.

[ctcpip]

The plot thickens... just got done speaking with Joe. I was going to create an issue for this but I think this is the place where we will need/want to resolve it anyway so am just going to comment here.

I think we messed up our regular voting member election this year. No blame to anyone involved -- it's easy to see how this happened.

The gist of it is that regular voting members are meant to be elected/chosen by the regular members. Instead what happened was the regular voting members were elected by the current voting members. (I believe that includes all of the voting members: impact, at-large/incubating, and regular.)

At-large/incubating voting members are similarly meant to be elected by a electorate composed of voters from at-large/incubating projects, but since that election was not contested, ballots did not go out, so no issues there.

Part of the root cause seems to be that sometimes information has been removed regarding these processes. For example, Ben's PR here includes a link to a now-removed section of the governance doc, which appears to have been removed erroneously, mistakenly thinking that the removed information was duplicated and existed elsewhere, which was not the case. No shade -- I'm certain everyone was acting in good faith.

In any case, we should look to get this clarified and sorted out as part of this PR.

As such, my initial thought since we are collapsing the non-impact project voting members along with the regular voting members into one unified group of Community Voting Members, we just need to state that they should be elected by the CPC as a whole, and not just the (current) voting members.

Thanks to Ben for initiating this! 🙏

[ljharb]

is this list missing collab space voting members?

[tobie]

@ctcpip wrote:

Part of the root cause seems to be that sometimes information has been removed regarding these processes. For example, Ben's PR here includes a link to a now-removed section of the governance doc, which appears to have been removed erroneously, mistakenly thinking that the removed information was duplicated and existed elsewhere, which was not the case. No shade -- I'm certain everyone was acting in good faith.

The information removal wasn't accidental, it did remove duplicate information which is in the charter's section on voting members. Unfortunately, the link to the election section of the charter didn't make that clear.

So the info still exists. If the voting was indeed organized incorrectly, we should file a separate issue to decide what to do about this for this time. And most importantly we should simplify things as much as possible so that things are manageable from an operations' perspective.

[ljharb]

up to two Voting members may be nominated by the Regular members. Once nominated these members must be ratified by the CPC Voting members before becoming a Voting member.

This suggests that, since nominations weren't limited to voting members, the election was conducted correctly?

[ctcpip]

I am all for simplifying and deduplicating. And some duplicate information may have been removed but also there was removed information that does not appear anywhere else. Specifically the process by which non-impact project voting members are elected, the process mentioned only in the charter defined as "a process set by the CPC".

we should file a separate issue to decide what to do about this

I have little appetite for redoing the election, but would also not block it if folks want to do that. I agree that should be a separate issue if that is desired. But in this PR we should make sure that the process for electing voting members is clear and accurate.

since nominations weren't limited to voting members, the election was conducted correctly

I don't believe so. The point of electing representative voting members is so those members can represent their constituencies.

• In the case of impact projects, they are able to directly appoint, so that's clear.
• In the case of at-large and incubating projects, they vote amongst themselves to determine which two voting members will collectively represent their projects.
• In the case of regular members, they vote amongst themselves to determine which two members will collectively represent the regular members. The readme and charter are not ambiguous about this. The charter mentions ratifying the regular voting members in the same exact way that it mentions ratifying the impact project voting members. Which is to say, they are not the ones who initially decide, or elect, whom those individuals are.

[tobie]

but also there was removed information that does not appear anywhere else. Specifically the process by which non-impact project voting members are elected, the process mentioned only in the charter defined as "a process set by the CPC".

Yes, this was removed on purpose, because the process written in the governance wasn't being followed. We decided that it was more sound to figure how we wanted to do things, then document them, rather than keep incorrect information around.