Community Committee and OKRs

[bnb]

Recently, I had the opportunity to attend the Electron Collaborator Summit. Their structure in many parts of the project is largely based on the structure of Node.js.

One thing I've never experienced within the Node.js project before, though, was how the Electron team sets goals to enable their working groups and initiatives for success. Specifically, they implemented Objectives and Key Results (OKRs) as a way to set current goals and measure the ability to meet those goals – without judgment – in order to help set future goals so working groups and initiatives can meet them.

From what I've seen, their approach is effective – it's a really good way for the group of collaborators to be critical and set reasonable and attainable goals, and then have a fraemwork to re-evaluate when their self-defined expectations don't match up to what ended up happening.

In the context of CommComm, we're a bit unique: we don't have very straightforward issues to solve and core features to add. While going through the entire process of building out OKRs with the Electron folks for each of their initiatives, I kept thinking how a similar framework could become very useful for CommComm to help define success for its initiatives, and move the needle toward material goals that are well defined and ubiquitously understood.

To be blunt, I'd like to propose that we consider moving toward implementing OKRs for CommComm. One of the challenges that I've seen in CommComm is people have great ideas for initiatives, but once they get started, the direction to move is less clear. Alternatively, some initiatives have a great start and then fizzle out because they achieved the goals that they set out to achieve but don't have a plan for what to do beyond those initial steps, and it's not particularly awesome to shutter something because of a lack of direction.

Additionally, CommComm itself doesn't seem to have a particularly strong sense of direction – we all have things we'd like to accomplish, but there's not really been a North Star for us to align to. Even the current charter for the Community Committee asserts that we do substantially different work than what we actually do.

My hope is that we could implement something along the lines of the following:

• Set and publish committee OKRs:
  • We, as a committee, should have something we want to accomplish and a defined path to accomplishing it.
  • Objectives: What do we as a committee want to achieve?
  • Key Results: How do we, as a committee, achieve those objectives?
• Set and publish initiative OKRs:
  • Once we've implemented committee OKRs, initiatives should also have OKRs. This both allows them to have their own explicit definitions of what their goals are, hopefully making it simpler to find people who are also interested in accomplishing the same goals in addition to providing a framework to iterate iniative direction more rapidly and more effectively over time.
  • Objectives: What does the initiative want to accomplish?
  • Key Results: How does the initiative achieve those objectives?

I'd love to raise a discussion about this with our community, and see what others think. ❤️

If you're interested in more context around OKRs, here's some resources:

• Examples of Electron's OKRs:
  • https://github.com/electron/governance/tree/master/wg-releases#current-objective-and-key-results
  • https://github.com/electron/governance/tree/master/wg-outreach#current-objective-and-key-results
• Content explaining OKRs:
  • Video: Why the Secret to Success is Setting the Right Goals
  • PDF: Google's OKR Playbook
  • Webpage: Beginner's Guide to OKRs

[mhdawson]

Seems like a good thing to try out.

[codeekage]

As this is a brilliant and something we should adopt. I think before the year runs out we should have some OKRs that we can agree upon and work towards implementation by 2020.

[keywordnew]

+1 I've experienced OKRs add value to teams, individuals, and their goals. I support this process experiment/upgrade.

a fraemwork to re-evaluate when their self-defined expectations don't match up to what ended up happening

A relevant factor here would be when these re-evaluations happen ie timeframe for OKR review/reset/updates/setting.

Electron doesn't specify what they use. My experience with OKRs are in the corporate space and these are done every 3 months ie every quarter. The needs of a company are very different from an open source project and I don't think doing OKR setting every quarter is necessary or even sustainable.

I'd propose setting OKRs twice annually at most and at least once per year.

[MarshallOfSound]

Electron doesn't specify what they use. My experience with OKRs are in the corporate space and these are done every 3 months ie every quarter.

We should definitely define this, but for clarity, Electron reviews these at our summits which happen twice a year, so every 6 months.

[bnb]

Here s the OKR document that we worked on at the Summit: https://hackmd.io/@fkkCqfodSGeY8O1r4AjMbA/BkU3kNZRB

I will PR this in today.

[keywordnew]

Pinning as "to be discussed" from CommComm meeting:

• [ ] Whether it's to be implemented at Initiative level. OKRs are likely to be at least implemented at CommComm level.

[bnb]

I believe this can be closed since the PR has been merged, as long as @keywordnew's comment has been addressed.