-
Notifications
You must be signed in to change notification settings - Fork 161
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
Comments
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. |
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"? |
Yeah, I understand the concern here as it ends up being two classes of 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. |
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? |
So my proposal in a nutshell is to:
|
1 and 3 seem contradictory. |
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
Proposed option
|
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
I agree we might increase the number of voting members, but I think that is optional for the initial simplification proposed. |
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. |
Meeting notes:
|
I'm supportive on the goal of the current proposal, but I'm -1 on the actual representation. |
Have we had time to work on this yet? I assume not? 🤔 |
TL;DR
Proposal:
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:
The text was updated successfully, but these errors were encountered: