Community Voting Members - make project and community representation simpler

[joesepi]

TL;DR

Proposal:

• Replace "At-Large Project Voting Members" and "Regular Member Voting Members" with "Community Voting Members"
• increase the number of "Community Voting Members" from 4 (current) to 6 (based on 2 members per number of active and graduated projects, which is currently 30)

Note: sometimes "At-Large Project Voting Members" may be referred to as "Non-Impact Voting Members". This is a relic from when we had 3 active project types: Impact, At-Large and Growth.

In today's CPC working session, we worked on election cycles and such.

In that discussion we touched on a topic that has come up many times in the past -- a topic that causes confusion even for people who wrote the governance and charter docs -- the distinction between "At-Large Project Voting Members" and "Regular Member Voting Members"

There has been some talk in the past about combining these into a "Community Voting Member" role as those two distinctions above really didn't have any difference in practice.

Instead of having At-Large and Regular Member voting members, we propose electing 2 Community Voting Members per every 10 projects (At-Large + Impact) in the foundation. This keeps it simple and the voting members would be representing the community, the projects, and CPC members.

With 30 active and graduated projects in the foundation, that would give us 6 Community Voting Members. Since there has also been discussion that the number of voting members is currently small (15) this would increase the community representation from 4 to 6 and expand our voting pool up to 17.

This is a change we would like to consider alongside our updates to voting/election cycles. Both efforts will likely change Governance, Charter and/or bylaws so to have them decided in parallel and implemented together would be ideal. Thanks for your consideration!

Refs:

• Voting Members listed in README
• Voting Member details in Charter which includes the current 3 different types of Voting Members (the third type being Impact project voting members)
• Election process for Non-Impact Voting CPC members in the Governance (Note: I can't find a place where we define election process for Regular Member Voting Members 🤦 )

[tobie]

I’m concerned that we’ll effectively loose smaller-project representation if we’re not careful about how we frame this.

I’m a huge +1 on the overall simplification effort, though.

[ljharb]

I definitely agree with the simplification; but I agree with @tobie's concern as well.

Perhaps, just like often boards have a restriction like "there can't be more than 2 seats from the same company" or something, we could have a restriction like "at least N voting members must be affiliated with non-impact projects, and at least M voting members must be affiliated with impact projects"?

[joesepi]

Yeah, I understand the concern here as it ends up being two classes of voting members:

• Impact Voting Members representing specific Impact projects and
• Community Voting Members

Perhaps some wording in the implementation of Community Voting Members could make clear that the expectations are that these voting members should give special consideration to the needs of At-Large projects when voting since Impact projects have their own direct representation.

[PaulaPaul]

I like where we are landing on this from the CPC discussion but did not want to lose the potential benefit of expanding the voting pool while we simplify the language. Is there an opportunity to expand the voting pool as mentioned above?

[tobie]

So my proposal in a nutshell is to:

1. call every CPC voting member a voting member
2. have impact projects be allowed to each elect 2 voting members (just like they currently do)
3. have an similar number of voting members elected by the CPC
4. have all CPC voting members be responsible for the good health of projects big and small, collab spaces, and the broader JS community.

[ljharb]

1 and 3 seem contradictory.

[tobie]

I'm trying to separate who elects you from who you represent. FWIW, the charter already mostly does this. It's the README that's making unnecessary (imho) distinctions.

Current status

Name	Number of seats	Elected by	Represents
Impact Project Representatives	12	Each Impact project selects 2 voting members	Their Impact Projects
At-Large Project Representatives	2	At-Large projects voting	At-Large projects
Regular Voting Members	2	CPC voting members	Unspecified
Collaboration space representatives	0	Each Collab space at the "core" stage (I didn't know collab spaces had stages too)	Their collab space

Proposed option

Name	Number of seats	Elected by	Represents
Voting member	12	Each Impact project selects 2 voting members	All foundation projects, collab spaces and the broader JS and FOSS communities
Voting member	11	The CPC members elect 1 less voting members than there are Impact project seats.	All foundation projects, collab spaces and the broader JS and FOSS communities

[mhdawson]

The only thing that does not match what I thought was discussed earlier in the propossal is this section.

The CPC members elect 1 less voting members than there are Impact project seats.

What I'd understood would translate to

Proposed option

Name	Number of seats	Elected by	Represents
Voting member	12	Each Impact project selects 2 voting members	All foundation projects, collab spaces and the broader JS and FOSS communities
Voting member	2	The non-impact projects collectively select 2 voting members	All foundation projects, collab spaces and the broader JS and FOSS communities
Voting member	2	The CPC members elect 2 voting members	All foundation projects, collab spaces and the broader JS and FOSS communities

I agree we might increase the number of voting members, but I think that is optional for the initial simplification proposed.

[tobie]

The idea of the proposal I made above is to remove all different complex and confusing selection processes of voting members besides impact one to simplify voting, while at the same time making joining the CPC more attractive by offering more voting seats to CPC members.

The message is essentially that if you're interested in being represented, just show up you might even fairly easily get elected.

[joesepi]

Meeting notes:

• Will work on this in an upcoming working session; removed agenda label

[mcollina]

I'm supportive on the goal of the current proposal, but I'm -1 on the actual representation. One goal of the CPC was to make it a relatively low barrier to entry group. To achieve this, we introduced voting members to prevent takeovers, and the imbalance was designed so that impact projects would have the ultimate say. I think making N-1 voting seats available is too close to the limit I would be ok for N/2 or N/3 voting seats allocated to all projects and collab spaces.

[ovflowd]

Have we had time to work on this yet? I assume not? 🤔