It’s hard to believe that the end of the year is already peaking around the corner and we’re starting to talk about OpenOakland leadership elections!

Green-tinged photo of OpenOakland members seated around tables in City Hall overlaid with the words 'Steering Committee' in white.

This has absolutely been a year of reflection for our brigade, even as we’ve welcomed in new volunteers who are helping to shape our future vision. Steering Committee meetings have become a place where we can have honest conversations about the challenges of wrangling so many different perspectives and experiences. We still have a lot of learning to do together, and it’s exciting to think about the possibilities. While October’s meeting tackled the logistical realities of running our upcoming election cycle and managing project requirements, we also continued to explore the practice of democratic decision making and how that impacts the work we do.

If you’re interested in learning more about OpenOakland leadership opportunities, email or join us at an upcoming meetup.

Jump to:
Brigade announcements | Vote: Election kick-off | Discussion: Moving the election cycle | Discussion: Democratic participation processes | Discussion: Councilmatic project status

Brigade announcements

Vote: Election kick-off

OpenOakland’s Bylaws stipulate that annual leadership elections need to happen November-December. The first official step to kicking off the cycle is appointing two trusted parties to administrate the election process. SC voted unanimously to appoint Jonathan M. and Ronald P. Both accepted the role. SC approved the following timeline for the 2022 term:

  • 11/2-15: Nominations open at start of hack night (2 hack nights)
  • 11/16-29: Trusted parties finalize candidates (over T-day, allowing plenty of time if we don’t get enough nominees)
  • 11/30-12/6: Campaigning (1 hack night)
  • 12/7-17: Voting (2 hack nights)
  • 12/21: 2022 co-leads announced

See calendar view >

Discussion: Moving the election cycle

The approved 2021 timeline is imminent and most present acknowledged concern about how realistic it is. In general, the Nov/Dec elections cycle as outlined in the Bylaws is extremely challenging, making full engagement and participation of candidates, administrators, and voters difficult.

  • Ronald raised the question of whether the Nov-Dec timing was even appropriate overall, given its consistent challenges with timing each year.
  • This prompted a discussion about amending the bylaws to move elections to Q1:
    • To avoid any potential conflict of interest in extending this year’s leadership terms, Jess suggested the 2022 leadership term could be extended by 3 months. This would allow them to oversee elections in Q1 2023.
    • Several members indicated they didn’t see an extension of this year’s leadership term to be problematic, if it meant addressing the elections challenge sooner.
    • Current co-leads agreed to discuss their willingness/ability to serve through Q1 2022 and return to the group with a response. If co-leads are willing to serve in order to support a Q1 2022 election, a proposal would be put to SC to that effect.

Discussion: Democratic participation processes

In addition to the discussion around the impact of a rushed elections cycle on member participation and representation, we explored a couple of other issues around how best to ensure members can engage and participate to the degree they’re comfortable.

Moving toward consensus: Fist to Five

We experimented using the Fist to Five voting method when trying to move the group closer to a consensus vote. This process is a relatively quick “gut check” to understand the degrees of dissent or agreement with a given proposal or decision. Someone reads out the proposal (typically a yes/no decision), and everyone holds up (or types out) the number of fingers representing how they feel:

Illustration of six hands of different skin tones, one as a fist and the others each holding up one, two, three, four, and five fingers.

  • 0 fingers (fist): I want to block this from going forward (opposed to the fundamental principle of the proposal)
  • 1 finger: I object but defer to the group (would prefer to see major changes)
  • 2 fingers: I can live with it as-is (would prefer minor changes)
  • 3 fingers: Okay with me
  • 4 fingers: I support this
  • 5 fingers: I’m all in/strongly support this

The range of votes tells us how much consensus there is and whether further discussion or an amendment to the proposal is needed. The group does need to explicitly decide its threshold for tabling a formal vote. For really important decisions, for example, we might require further discussion or amendment of the proposal if anyone throws two fingers or below. For incidentental decisions, we might choose to move forward only if no fists are thrown, replacing a formal vote entirely.

We found that the process was surprisingly successful at keeping the conversation moving forward and identifying where people’s sticking points were. While there’s certainly potential for overuse, in general it would be good to see this adopted more widely across the brigade. It’s important that the proposal be stated clearly prior to voting and that voters are able to see the definitions while voting. We accomplished this by having the chair read the proposal and definitions, while another co-lead pasted the voting definitions into the Zoom chat. Sharing a visual slide of the definitions is recommended, too.

We were first introduced to this method through Bonnie Wolfe of Hack for LA, another example of powerful learnings we can glean from the wider brigade network.

Ensuring new voting reps feel equipped to participate

Two members abstained from voting on the upcoming election schedule. These two members also happened to be first-time Steering Committee voters (each project team is expected to send a voting rep to the Steering Committee, and these particular members had been nominated by their teams for the first time). When asked about the reasoning for their abstention (rather than a No vote), they indicated a lack of certainty around brigade processes and feeling a little “too new” to feel comfortable making big election-related decisions. This begs the question: how do we onboard new voting members so they feel equipped, informed, and empowered to serve in the role?

Given that people’s attendance at our meetups is unpredictable, our hope—and need—is that people feel they can hit the ground running and participate to their full ability and desire without a lot of onboarding. But clearly, folks sometimes feel thrown into the deep end. Some approaches that might help improve the voting experience:

  • Clearly define the role and expectations and post them somewhere accessible.
  • Provide the Steering Committee agenda a full week prior to the meeting; this doesn’t always happen but striving for enough lead time is key for members to feel prepared.
  • Recap the voting guidelines and share a visual slide that recaps them at the top of every meeting. This formality often gets overlooked in the interest of speed, but that can make it very confusing for newcomers. Even for regulars, it’s helpful to repeat the expectations to ensure continued alignment.

Discussion: Councilmatic project status

Following last month’s discussion of project requirements, co-leads reached out to Councilmatic’s project lead to request that the team focus on meeting project requirements by the October Steering Committee meeting. Those requirements included:

  • Ensuring the current live production build is hosted in OpenOakland’s repo.
  • Updating the repos’ ReadMe files to include basic instructions for how to contribute to the project and how to contact the brigade or project team.
  • Providing the Steering Committee with a link to up-to-date project documentation.
  • Providing the Steering Committee with account credentials for any platforms or accounts used to manage the project, including the Councilmatic Twitter account.

Unfortunately, these requirements weren’t met as of October’s meeting and Councilmatic’s project lead was not present due to illness. Co-leads expressed concern that the team was not making a good faith effort to keep the project open and accessible and under the control of the full brigade, and discussion ensued about how best to handle the situation.

The Steering Committee discussed some potential approaches such as:

  • Extending the timeline to give the Councilmatic team more time to meet these requirements.
  • Moving the project into Idle status and removing the current team as repo contributors. This doesn’t solve the issue that the Steering Committee still doesn’t have full access to the current project, though.
  • Escalate to Code for America, given that a brigade project is currently not being shared with the brigade itself. Co-leads felt this might be premature and agreed to huddle and follow up with the Steering Committee on next steps between now and the Nov. 16 SC meeting.

Steering Committee meets the Third Tuesday of each month and is open to all OpenOakland members. Read more about how Steering Committee works and how to participate. Our next meeting is November 16.