Simplify election process

[tobie]

There's a lot of complexity and bureaucracy involved in electing voting members, and it seems that being a voting members is essentially useful for three things:

1. voting on who gets to be a voting member (yes, that's kind of absurd),
2. voting on a decision when the CPC is unable to reach consensus (I don't think that ever happened), and
3. looking good on a resume (I don't want to dismiss that altogether, it actually allows people to carve out time on their day job to participate).

This seems suboptimal.

What if you got a nice title after joining the CPC for a little while ("Active Member" or something) and all active members would get to vote in case of a consensus issue (maybe with a per project or per company cap) and we can get rid of elections altogether?

[mcollina]

While I agree on the sentiment, I disagree on the solution.

The CPC is structured to

1. have no barrier to entry, enabling whoever wants participate to join
2. give stability guarantees to impact projects

The system was designed to avoid a takeover of the CPC. The voting members guarantee such stability, more or less giving impact projects a veto on policies they would go against their interests.

I'm happy to provide a bit more context in private.

---

The model that @tobie is describing looks a lot like the TSC model of Node.js, which we wanted to avoid when defining how the CPC would work.

[tobie]

I’m totally open to other solutions, btw. I literally made that solution up yesterday, as I was filing the issue.

That said, a hostile takeover is highly improbable and the board could overrule it by changing the bylaws.

[ovflowd]

Agree with @mcollina I could see potential situations where if non-voting members get to elect strangers altogether to the CPC (Because the voting process for adding regular members is vulnerable to that), it could create risks for a takeover of the CPC.

This is something that kinda "happened" on the GNOME Foundation Board of Directors when they voted that non-Foundation members can be elected to become part of the Board of Directors (a little bit different, yet similar).

It feels like the current mechanisms are in place to protect this from happening.

[tobie]

This is something that kinda "happened" on the GNOME Foundation Board of Directors when they voted that non-Foundation members can be elected to become part of the Board of Directors (a little bit different, yet similar).

Yeah, I do want to point out, that there's a board sitting on top of the CPC who owns the bylaws and could essentially kill the CPC or remove it altogether if necessary, so there's already a pretty solid (if cumbersome) backstop measure in case of a real crisis.

[ovflowd]

Yeah, I do want to point out, that there's a board sitting on top of the CPC who owns the bylaws and could essentially kill the CPC or remove it altogether if necessary, so there's already a pretty solid (if cumbersome) backstop measure in case of a real crisis.

But that be an extreme action. I think if we can prevent it from reaching there, then we should keep mechanisms that allow us to self-moderate so that such circumstances don't happen... imho.

[tobie]

It seems there's agreement on what we're trying to achieve: remove red tape while keeping the CPC protected from hostile takeover.

Would y'all be willing to attempt to define the threat mechanisms and suggest solutions that would mitigate those while allowing us to reduce the bureaucracy?

[tobie]

But that be an extreme action. I think if we can prevent it from reaching there, then we should keep mechanisms that allow us to self-moderate so that such circumstances don't happen... imho.

This is a classic impact/probability risk assessment problem. You want to reduce the impact of rare but critical events, but not to the point that doing so creates more important risk elsewhere (such as reducing operational agility by making everything too cumbersome for example).

Maybe this bureaucratic layer is the right tradeoff. Maybe its over-conservative and there's a more nimble tradeoff that reduces our overall risk, not just this one.

[mcollina]

I would consider getting the Board involved in projects matter would be a massive failure for the CPC.

Here is an alternative setup: keep the voting members from Impact projects but drop the at-large project representative and the one elected by regular members, essentially removing all the elections from within the CPC.

[eemeli]

Here is an alternative setup: keep the voting members from Impact projects but drop the at-large project representative and the one elected by regular members, essentially removing all the elections from within the CPC.

This would disenfranchise at-large projects completely, which I do not support.

My alternative proposal here would be to drop the elected at-large project and regular-member voting representatives, and instead allow all at-large projects to nominate one voting representative each. This would similarly remove all voting-member elections from the CPC.

[tobie]

I would consider getting the Board involved in projects matter would be a massive failure for the CPC.

That's a great risk upper bound to work with.

My alternative proposal here would be to drop the elected at-large project and regular-member voting representatives, and instead allow all at-large projects to nominate one voting representative each. This would similarly remove all voting-member elections from the CPC.

I really like @eemeli's proposal for its potential of increasing involvement of project in the foundation's activities.

However, it does dramatically change the balance between Impact and At Large projects compared to what it is now.

Currently the ratio is of 11 voting members for Impact projects for 2 At Large reps. @eemeli's proposal would change that Impact:At Large ratio from 11:2 to 11:29 (if we count incubating projects), or more roughly from a 5:1 ratio to a 1:3.

That's quite a dramatic change and feels undesirable. What if we tied voting to projects rather than representatives and gave Impact projects more weight. Giving each Impact project 5 votes, for example would gives us the following Impact:At Large ratio currently: 30:29, which I find quite appealing, actually.

We could even imagine that the number of voices of Impact projects could be tuned on a regular basis to obtain an agreed-upon equilibrium.

[ovflowd]

@tobie would it make sense to increase the amount of voters per impact project if we increase the participation of at large projects?

[mcollina]

I like the direction we are going but I'm afraid we would fail to have a quorum most of the time, and we should adjust our rules somehow to lower the quorum requirements.

@eemeli you have a bit more pulse on the at-large projects than me: what's the appetite for more involvement?

As a side note, collecting 60 votes is hard work. Maybe we can have 1 representative per project, but the impact representatives have a 5x weight?

[ovflowd]

Yeah in that sense consensus can definitely be hard. +1 then for impact projects having 5x weight

[joesepi]

Honestly, I think this is a non-issue. I think it maybe it felt like an issue because this year was very bumpy and got confusing at times because of a few somewhat large errors in the process.

We essentially have three voting occasions. (see below) Those occasions are separated into three so that people could focus on one of the three higher level positions individually (CPC chair, CPC Board Seat and Community Board Seat) and we grouped the At large and Regular member vote with Secondary Board seat at one time to maximize awareness around OpenJS world in 2021.

Personally, I dont think this is too much voting. And I dont think this is too many or two little voting members. I think the representation is fair and makes sense to me.

What I do think is that folks who run for At large voting member positions (up to 2) and regular member voting positions (up to 2) should be expected to do more to represent their constituencies and thus validating the positions. This is not a knock on current or previous members. I just think these roles could be defined a bit better and expectations could be set a bit better.

And I agree with others in saying that we set the structure up for good reasons. There have been issues in the community in the past that we are guarding against but again, I dont really think there is too much voting :)

Voting schedule

• APR 1 - CPC Chair election - term ends April 30
• FEB 1 - Director 1 election - term ends February 28
• JUL 1 - Director 2 election - term ends July 31
• JUL 1 - CPC At Large voting member election - term ends July 31
• JUL 1 - CPC Regular member voting member election - term ends July 31

[tobie]

As a side note, collecting 60 votes is hard work. Maybe we can have 1 representative per project, but the impact representatives have a 5x weight?

Yes. That was what I had in mind.

[tobie]

@joesepi we meet roughly 25 times a year. Each election requires at the very least the following:

• announcing that the nominations are opened during a call,
• announcing the nominees during a second call and kickstarting voting, and
• announcing the result of the elections.

So at the very minimum we have 9 calls out 25 were we are actively dealing with voting. That's more than one out of three calls. That's a lot. And frankly feels mostly unnecessary; it's pretty much always the same people in the same roles anyway.

Your point about At Large reps interacting more with the community is well taken, and as you know has been a real concern of mine (see: #761). It is telling, imho, that both @eemeli and myself (the current At Large reps) are trying to find a solution with At Large maintainers being involved directly. To make the current solution work would require At Large reps to become community managers, and that's too big an ask from volunteers.

[eemeli]

@mcollina:
I like the direction we are going but I'm afraid we would fail to have a quorum most of the time, and we should adjust our rules somehow to lower the quorum requirements.

Umm, I don't think we have an explicit definition of quorum for voting members? The only textual reference to a quorum is here:

cross-project-council/governance/GOVERNANCE.md

Lines 200 to 201 in 88d5e39

	* The PR has been open for at least 14 days OR consensus is reached in a meeting
	with quorum of voting members.

The context for how we ended up with that is #205 (comment), which doesn't really make it clear what the quorum definition actually is. That was in June 2019, and going back a step further we weren't sure at least in October 2018 what that definition was:

cross-project-council/meetings/2018/2018-10-22.md

Lines 89 to 92 in 88d5e39

	* Process for landing things to the repo?
	* When do we believe it is consensus?
	* Myles, for example core repo 72 hours then can land, modules needs consensus in a meeting
	* Also we don’t have quorum rules for this group yet, so it’s unclear if we’re at consensus.

It would seem that in #204 there's an implicit expectation that quorum means "half the voting members", but do we have that codified anywhere? If so, I can't find it.

@mcollina:
@eemeli you have a bit more pulse on the at-large projects than me: what's the appetite for more involvement?

Very little active interest. The CPC doesn't really do much that affects our at-large projects; the main benefit it brings is to have some of the processes and preparations ready in case Bad Things happen. I rather hope that with e.g. #953 we'll be able to do more for our projects, which might of course change this state of affairs.

@tobie:
So at the very minimum we have 9 calls out 25 were we are actively dealing with voting. That's more than one out of three calls. That's a lot. And frankly feels mostly unnecessary; it's pretty much always the same people in the same roles anyway.

I agree. We spend so much time on meta-level things in the CPC that we're limiting the scope of actual work that gets done. Each of us only has a limited bandwidth to give to OpenJS work, so reducing the baseline management tasks could have an outsized impact on our ability to deliver actual benefits to people and projects.

[tobie]

@eemeli wrote:

We spend so much time on meta-level things in the CPC that we're limiting the scope of actual work that gets done. Each of us only has a limited bandwidth to give to OpenJS work, so reducing the baseline management tasks could have an outsized impact on our ability to deliver actual benefits to people and projects.

👆 THIS 👆

[dylans]

I don't have a solid idea on how to change this without introducing unintended consequences.

I understand that the CPC work is often mundane, but maybe that should be the case, with other things in the foundation (e.g. the collaboration groups) being more interesting. 🤷‍♂️

Adding more members probably makes it more difficult to get the simple things done. So that of course leads to the question of, can we streamline the CPC to make it more efficient to increase participation, which led to this issue.

But I'm not sure voting is the primary problem for lack of engagement. A few things that work against it for me:

• I cannot remember when we meet. I have a stale calendar entry that I can't seem to remove. And the meeting time is often in the prime time slot for meetings between teams in the US and Europe, which often causes conflicts.
• I get so many github notification emails that I rarely see the ones related to the CPC. For the calls I do make I rarely see the agenda prior to the call.
• We use a Google Doc for each call to track notes, which links to various GitHub issues, but I rarely remember where that Google Doc lives to see what I missed in a meeting.

These are mostly me problems probably, but they're probably pretty indicative of the bigger problem as a whole of why we struggle with participation.

[joesepi]

Hey @dylans - I just wanted to reply to your

• I cannot remember when we meet. I have a stale calendar entry that I can't seem to remove. And the meeting time is often in the prime time slot for meetings between teams in the US and Europe, which often causes conflicts.

Let me know if I can get you an updated calendar invite or you can do what I do and subscribe to the public calendar: https://calendar.openjsf.org. To your other point, perhaps we should look at other time slots to be more accommodating.

• I get so many github notification emails that I rarely see the ones related to the CPC. For the calls I do make I rarely see the agenda prior to the call.

My routine is to jump into the github issues to quickly find the meeting issue with the agenda on Tuesday mornings.
https://github.com/openjs-foundation/cross-project-council/issues

• We use a Google Doc for each call to track notes, which links to various GitHub issues, but I rarely remember where that Google Doc lives to see what I missed in a meeting.

The goal is always to get these meeting notes (google doc) committed to the repo. I'm trying to get better at doing that in a more timely manner. They live here: https://github.com/openjs-foundation/cross-project-council/tree/main/meetings

I hope this is helpful for you and anyone else who finds this comment. :)