openoakland/brigadeops

Used for managing brigade operations. Submit an issue, request, or question about how OpenOakland runs.

Welcome to BrigadeOps

This repository is used to manage Brigade Operations projects for OpenOakland, a volunteer collective that bridges community and technology for a thriving and equitable Oakland. It's a work-in-progress, so if you have ideas for how it should be used, submit an issue.

Contributing

All contributors are expected to adhere to OpenOakland's Code of Conduct. This emphasizes a collaborative, participatory approach to project development. We're here to support each other as a community and we take this CoC seriously. We appreciate your understanding and shared commitment.

I have a question about how OpenOakland works.

1. Start by checking on https://openoakland.org for the answer to your question.
2. If you can't find what you're looking for, you can submit a Question issue (to be created).
3. If you need further help or want to reach someone directly, email [email protected].

I have an idea about how OpenOakland could work better.

This workflow requires the implementation of labels and Issue templates, then the removal of this note.

1. Start by checking issues labelled Suggestions to see if a similar suggestion has been added.
2. If a similar or related suggestion exists, please add a comment on that issue. We can also create a new one if your suggestion needs to be its own thing.
3. If you don't see a similar or related suggestion, submit a Suggestion issue.
4. Since our brigade believes in leaning into action, we encourage you to collaborate with others to build buy-in for your suggestion and shape it collectively. Try joining us at an upcoming Meetup to share your idea and request input/collaborators.

I want to know what BrigadeOps projects OpenOakland is working on.

This workflow requires the implementation of Project boards, then the removal of this note.

• See our full to-do list. These issues are all organized into various Project boards for status tracking.
• An easier view is to explore the current Project boards.

I'd like to work on an existing BrigadeOps project

TBD

brigadeops's Issues

Transfer VRooM Trello board to GitHub Projects

Description

The VRooM project management board is currently housed in a personal Trello account and should be moved over to issues assigned to the VRooM project board in this repo. That process would probably be a great opportunity to review and update the project roadmap, rather than just transfer everything over verbatim. I intend to maintain the Trello for the foreseeable future but likely not forever.

What needs to be transferred

• All open tasks
• Reference material/documentation/links (perhaps these could be housed in a dedicated Project column, or on a dedicated BrigadeOps wiki page).

Adopt a formal but flexible project life cycle

Description

Historically, OpenOakland has had various processes and standards for intaking and executing project work. Over time, those processes have become less formalized and more opaque to volunteers and leadership. Without a clear point of view on the project life cycle, an "anything goes" approach has taken root. The result is a lack of efficiency, oversight, accountability and, on occasion, harm to the community.

The goal

Define the project life cycle, including major phases and milestones, and required and recommended activities. This structure needs to balance flexibility and autonomy for volunteer teams with accountability to the public, and need to be accompanied by supportive resources that make the work both manageable and fun. We have an opportunity to help Oaklanders understand and define what equitable tech can look like in our city.

Reference material

• OO Project Life Cycle overview deck
• Project Life Cycle Exploration Google Drive folder

Track media mentions without a human

The issue we're tackling

Right now, OpenOakland media mentions are tracked by the Comms Lead (if they know to set it up):

• A Google Alert is created for the brigade and for each project name (which gets tricky for projects with generalized names like "open disclosure," a phrase often mentioned in other contexts).
• The Alert is tied to an individual's email address (generally the Comms Lead, if there is one).
• The Comms Lead then needs to decide whether or not to distribute the mention and/or add to the website.

Potential solution 1:

• Create the Alerts using the existing marketing@openoakland user address (or create a new dedicated one).
• Set up a Zapier trigger: when receiving an email from the Alerts address, post it to the Slack #oo-communications channel.
• Moderated: If someone marks that slack post with a specific emoji, trigger a zapier automation to open an issue in the OO.org github repo using a PR-specific issue template to add the article to the website.
• Unmoderated: open the issue when sending the email alert to slack (a parallel trigger/zap).

Risks

• Alerts can catch things that aren't relevant.
• We don't want to post negative mentions on the website (this is an argument in favor of moderating the Github issues from Slack).

Ritualize the definition of OpenOakland membership

Description

One of our Brigade Priorities, was to define what an OpenOakland member actually is, so people understand the expectations and know where they fit in, and to aid impact measurement. In November 2021, Steering Committee did so, codifying the following definition in our Bylaws:

An “active OpenOakland member” is defined as: someone who has contributed to an OpenOakland project and/or attended an OpenOakland event at least twice in the past six months, and who has no active Code of Conduct violations.

This is a good start that helps us measure active membership and conduct elections, but it doesn't do much to build the member relationship or help people understand where they fit in and what their role is. It would be helpful to "ritualize" membership to better support engagement.

Brainstormed ideas

• Develop a tiered membership structure that reflects degrees of engagement/involvement. Just an example:
  • Supporter: Email subscriber, meetup attendee
  • Member: Someone who's reported at least XX hrs of work in the past 12 months (including event attendance and project contributions)
  • Leader: Someone who's served on the Steering Committee or a Working Group for XX hrs in the past 12 months
  • Champion: Dues-paying member and/or donor
  • Eligible voter: All Members and Leaders
• Celebrate members who hit a specific level of engagement (with congratulations emails, social shout-outs, swag)
• Provide a welcome kit to formal members.
• Create a clear call-to-action to becoming a member on the website.

Develop a data management/privacy policy

Description

OpenOakland currently doesn't have a holistic, documented set of processes or policies for collecting, handling and communicating about member PII. This is also a technical requirement for the VRooM project.

Current situation

Currently, personally-identifiable information (PII) is collected and/or stored in following known channels:

• Meetup.com
• Slack
• OpenOakland forms
• Google Drive
• Individual member-volunteer computers (eg project lead docs)

Need

• Landscape analysis: what are others doing?
• PII data inventory (see Current Situation)
• Requirements development
  • Scope of policy
  • Definitions
  • Collection
  • Consent
  • Storage and retention
  • Access
  • Usage
  • Support request process
  • ???
• Draft policy
• Review policy w/ SC
• Revise and finalize and publish

Reference and further reading

• Example data policy
• CARE Principles for Indigenous Data Governance (PDF)

Advocate for more representation of historically marginalized groups in tech and local government.

Description

Per OpenOakland's Priority Areas, we should identify some specific goals and approaches to advocating for more representation of historically marginalized groups in tech and local government. When an idea below is committed to, it should get its own dedicated Issue for tracking purposes and crossed off the list below.

Brainstorm

Goal: Raise awareness among OO members of issues facing historically marginalized groups in tech and local government.

• Tactics
  • Host speakers and panel discussions
  • Screen documentaries
  • Create/participate in public advocacy campaigns with other community groups
  • Feature underrepresented voices and issues on OO communications channels

Goal: Build skills among OO members for centering marginalized voices and reallocating power to underrepresented groups.

• Tactics
  • Host skill-building workshops
  • Center underrepresented voices in the OO Project Life Cycle by building in specific processes and milestones
  • Develop resources, templates and tools for volunteers to use in their work
  • Center OO projects around power-sharing with underrepresented groups
  • Develop self-guided trainings

Record volunteer attendance without a human

The issue we're trying to address

We want to reduce manual overhead while improving brigade impact reporting. Volunteer attendance is key to understanding member engagement and retention.

What we want to track

For each meeting:

• Total attendees
• New attendees
• Returning attendees

Monthly, quarterly and/or annual roll-ups:

• Total attendees
• New attendees
• Returning attendees
• Bonus: # members (total volunteers who've attended at least twice in the last six months)
• Bonus: Retention rate: (end # - new members onboarded)/start # source

What we'd like to automate

• Collection
• Calculation
• Reporting

Potential solution(s)

1. Leverage the existing Slack /checkin app

• Identify where checkins get recorded
• Create a calculation tab to maintain a running count
• Set up a Zap to push specific fields from the spreadsheet to a new #oo-brigade-impact channel in Slack

This approach depends on people remembering to /checkin in Slack, while some folks may not remember or may not join Slack the night they attend. One potential fallback that could work for both remote and in-person is for every meetup to start with assigning one person responsibility for recording attendance in the automated system.

2. Use Zoom sign-in as a baseline for attendance

• This approach is basically the same as above but uses Zoom sign-in as the source of attendance, which is a more accurate headcount as long as meetings remain remote-only.

3. Create a dedicated app using Zoom API

Example: https://medium.com/swlh/how-i-automate-my-church-organisations-zoom-meeting-attendance-reporting-with-python-419dfe7da58c

[Placeholder] Develop an impact measurement strategy

Description

We want to understand if our efforts are achieving the impact we intend. See: Priorities: Impact Measurement.

Things we might want to measure

• Overall brigade impact in Oakland
• Individual project impact on intended audiences
• Impacts on member-volunteers
• Impacts on partners

Relevant links and docs

• OpenOakland's Priority Areas
• Progress on OpenOakland’s Priority Areas
• OpenOakland GDrive > Governance > Project Oversight & Management
  • Brigade Impact Tracking Metrics
  • CfA Impact Cascade Pilot
• Embedding Equity Discussion Group attendance

Add Table of Contents to individual Ops Handbook sections

Description

The OO Ops Handbook is currently structured as a Google Doc containing links to individual sections. This is so that we can more easily convert to markdown when we're ready to migrate the content into a more appropriate format, such as a docs repo or website section. For now, individual sections don't contain ToCs, which makes it hard to tell what topics are covered and to navigate to them.

Solution

Add a bulleted list labeled "Contents" at the top of each section, linking to every H2 in the doc. Check off each section as the ToC is added:

• 1.0 Introduction and doc maintenance
• 2.0 Knowledge management
• 3.0 Account management
• 4.0 Meetings and events
• 5.0 Member engagement
• 6.0 External communications
• 7.0 Finance
• 8.0 Ops Initiatives
• 9.0 Leadership
• 10.0 Project Management

[Placeholder] Github Cleanup List

Description

The OO Github organization has been long neglected and needs a major cleanup. This issue is meant to capture a running list of to-dos as they're discovered.

Running list of to-dos

As each of the following is committed to by the brigade, they should be recreated as a dedicated issue in their appropriate BrigadeOps project, and crossed off the list below.

• Remove outdated teams (eg @openoakland/brigade)
• Update ReadMe content to indicate project status and how to get involved
• Remove contributors from all Idle, Delivered, and Decommissioned projects to ensure any revivals go through Steering Committee

Develop a project portfolio strategy or selection framework to help us focus our efforts.

Description

Per the Brigade Priorities, we should develop a project portfolio strategy or selection framework to help us focus our efforts.

Supporting materials

• Project Exploration Worksheet and next-gen Project Canvases.
• RADAR learnings

Create content strategy for OO blog

Description

Without a content strategy, the blog risks becoming over- or under-managed. Potential consequences include excluding underrepresented voices, lack of quality control, and lack of relevance.

Recommended priorities:

• Define an editorial purpose (eg "Create a shared and public space for learning out loud as OpenOakland explores how to bring tech and community together in service of a more equitable Oakland").
• Define the editorial content mix (see "Content Mix").
• Create a basic publishing workflow with clear roles and permissions that support quality control without gatekeeping.

Content mix

Since introducing the blog to the website, we've kept it pretty tightly focused on:

• Steering Committee recaps
• Project case studies and learnings
• Member interviews/profiles

Potential good additions:

• Project news, milestones, and requests for help
• Special OO event announcements
• Network roundup (recommend outweighing 3:1 by OO content)

Note

This issue has filed in the Culture, Process and Ritual project because it involves how the group works together and brigade strategy in significant ways. Once this issue is complete,a new one could be opened to reflect getting it codified in the OO Ops Handbook.

[Slack 101 update] Add account recovery instructions

Description

When people with existing Slack accounts can't get in, they sometimes resort to creating a new account. This creates inaccurate member data, makes it hard to find people, and discourages overall brigade continuity.

Proposed solution

• Add instructions in the Slack 101 google doc on how to recover your account.
• Add instructions in the OO Operations Handbook on how to:
  • Help someone recover their account (point them to Slack 101 guide)
  • Issue a one-time invite (via link/email)
  • Deactivate an account

Idea: Set up automation to encourage basic impact measurement/knowledge sharing

Context

Based on the latest brigade priorities, we'd like to be providing more learning opportunities and measuring our impact more directly.

But we currently don't have a set of defined success metrics or regular reporting cadence and beyond a monthly Demo Night (which is often treated as a way to orient newcomers), we don't have any structure for sharing learnings with each other.

Idea

Start with a very lightweight/low-overhead way to make data collection and knowledge sharing easier by implementing an automation that prompts members to share quick learnings and feedback that can be automatically routed, aggregated when necessary, and reported out in useful ways.

Potential workflows

1. Set up a weekly Slack reminder that prompts members to complete a form recording the amount of hours they contributed and any learnings and needs/requests/concerns/questions.
2. Member completes form, which saves to Google Sheet.
3. Some clever spreadsheet magic calculates the following (where possible):

• No. of returning volunteers
• No. of new volunteers
• Retention/attrition in the past week and month
• Total hrs volunteered last week/month-to-date by project
• Total hrs volunteered last week/month-to-date brigade-wide

4. Zap runs weekly and...
   4.1 Rolls the aggregated data into a report that pushes to Slack (and maybe even to email or social channels).
   4.2 Does something interesting with the qualitative learnings
   (maybe compiles them into a separate report and shares out, or randomly selects and posts them Slack and/or social channels).
5. Follow-up zaps could even report aggregate numbers and period-over-period changes on a monthly basis, how many learnings were shared amongst members, etc.

Caveats

• These measures don't measure direct impact per se, but they do measure activity/engagement, and can be used as early proxies for effort as we develop more robust measures. It's a way for us to take small steps towards bigger impact. If we keep waiting to collect perfect data, we risk neglecting to collect any data at all.
• There are probably all kinds of cool ways to use the "learning snippets" - maybe they get read at meetups, used as discussion/circle prompts, etc.
• There is a risk with the learning that they end up in a sort of black hole. How can we integrate the learnings shared into future work? How can we preserve any evergreen lessons shared so they resurface in the future? How do we ensure responsive to feedback and/or concerns?

Create Issues templates

Description

To make this repo useful, we want to create a set of Issue templates based on the ways people might want to interact with it:

• Suggestion: Have an idea for how OpenOakland can work better?
• Question: Have a question about how OpenOakland works?
• Bug: Something's broken!
• Help request: Need support or assistance for something brigade-related?

Open questions

• What info do we need to collect for each template to make it easy to process?
• Do we need to include an "Other issue" template as a catch-all?

Define who OpenOakland serves more specifically, and how we do so.

Description

Per the Brigade Priorities, we should be more clear about who OpenOakland serves. "All of Oakland" is a huge range of people, and doesn't necessarily center our work on underrepresented or historically marginalized groups that experience inequities in our city.

We don't necessarily need to "leave out" certain Oaklanders. We could tailor our activities for different groups based on the outcomes we want to see within those groups. For example:

• Low-tech Oaklanders: Help build skills or connect them to resources
• Community-based nonprofits and groups: Help build tech capacity and amplify their work
• Government agencies and staff: Help them center community feedback and make services more accessible to the people
• People underrepresented in tech/gov: Help connect them to opportunities and support systems, shift power to them
• Oakland tech workers: Build skills in equitable tech and raise awareness of tech's role in systemic racism and oppression

Formalize Community Commitments

Description

The Embedding Equity group developed a revised set of Community Commitments intended to foster better communication and collaboration. We recommend implementing these in the following way:

• Formally vote in SC to adopt them as part of the CoC.
• Publish them on the website.
• Review them together at the top of each OpenOakland meeting (see intro slide in deck).

Develop a set of off-the-shelf components that projects and teams can easily integrate into their work, so we’re not constantly reinventing the wheel.

Description

Per the Brigade Priorities, we should develop a set of project components to help teams work more effectively and efficiently.

Assumptions

• This should be completed in conjunction with #16.
• We should have specific criteria for prioritizing which components to build first.
• As each component is committed to, it should get its own dedicated issue and be crossed off the list below.

Potential components

• GitHub Repo template (with example Project board, Wiki structure, ReadMe template, and Issue template)
• Project Design System (defining UI, content, and code components and styles)
• Project Exploration Canvases
• User testing templates and training modules
• User research templates and training modules
• Impact definition and measurement templates and training modules

Hire an equity consultant to help with restructure

Description

OpenOakland has been given the advice of several consultants to engage a professional service provider experienced in DEIA (Diversity, Equity, Inclusion, Accessibility)/JEDI(Justice, Equity, Diversity, Inclusion), given our ongoing challenges with centering underrepresented voices. Since our initial training on restorative communication with SEEDS was received well, this seems like a really useful and important thing to prioritize.

We have a running list of potential vendors that can be used as a starting point. Based on research done to date, our current recommendation is to hire someone for an initial 1-2 hour consult, and get a quote for a workshop or three to help guide us through the specific actions needed to move forward.