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

Community Voting Members - make project and community representation simpler #1243

Open
joesepi opened this issue Jan 30, 2024 · 10 comments
Open

Comments

@joesepi
Copy link
Member

joesepi commented Jan 30, 2024

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:

@tobie
Copy link
Contributor

tobie commented Jan 30, 2024

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
Copy link
Member

ljharb commented Jan 31, 2024

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
Copy link
Member Author

joesepi commented Jan 31, 2024

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
Copy link
Contributor

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
Copy link
Contributor

tobie commented Apr 16, 2024

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
Copy link
Member

ljharb commented Apr 17, 2024

1 and 3 seem contradictory.

@tobie
Copy link
Contributor

tobie commented Apr 17, 2024

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
Copy link
Member

mhdawson commented Apr 19, 2024

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
Copy link
Contributor

tobie commented Apr 19, 2024

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
Copy link
Member Author

joesepi commented Jul 9, 2024

Meeting notes:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants