Appointed to Elected: Evolving Technical Community Leadership

Daniel Farrell
Red Hat SDN Team


@dfarrell07

My relevant background

Daniel Farrell
Software Engineer, Red Hat

MY RELEVANT BACKGROUND

Wrote OpenDaylight's election system, advised OPNFV/Fd.io

MY RELEVANT BACKGROUND

OpenDaylight: Committer, PTL, TSC, Board, TAC
OPNFV: Committer, PTL

Observed lifecycle

OBSERVED LIFECYCLE

Open Source project created

OBSERVED LIFECYCLE

Project may be seeded with closed code contributions

OBSERVED LIFECYCLE

Project is off and running, growing

OBSERVED LIFECYCLE

Community emerges, community leaders emerge

OBSERVED LIFECYCLE

Leaders = people stepping up to do actual leadership work
Leaders != managers

OBSERVED LIFECYCLE

Now?!
(for your project)

OBSERVED LIFECYCLE

Start appointed->elected discussion

OBSERVED LIFECYCLE

Long process, some novelty required, reuse when possible

OBSERVED LIFECYCLE

Common intermediary state: partly elected governance

OBSERVED LIFECYCLE

Fully elected governance! w00t!

Case: OpenDaylight

CASE: OPENDAYLIGHT

Project bootstrapped with some core code from Cisco

CASE: OPENDAYLIGHT

TSC bootstrapped with one seat per Platinum Company

CASE: OPENDAYLIGHT

Community developed, leaders emerged

CASE: OPENDAYLIGHT

Committer at Large seats added
(committer elected by other comitters)

CASE: OPENDAYLIGHT

Committer at Large seats gradually increased

CASE: OPENDAYLIGHT

Community consensus to move away from Platinum Designates

CASE: OPENDAYLIGHT

>1 year of intense discussion, consensus building
parliament_fight.gif

CASE: OPENDAYLIGHT

Fully elected governance
wiki.opendaylight.org/view/TSC:Election_Proposal

Election Principles

ELECTION PRINCIPLES

Representation of Constituencies

ELECTION PRINCIPLES

"OpenDaylight is made up of groups that sometimes want different things from the TSC. These Constituencies should be represented at the TSC."

ELECTION PRINCIPLES

Representation of Constituencies
  • Need everyone relevant to a decision at the table
  • Need to balance competing interests

ELECTION PRINCIPLES

Election by Community Peers

ELECTION PRINCIPLES

"Representatives to the TSC should be elected by their peers in the OpenDaylight community on the basis of merit."

ELECTION PRINCIPLES

Election by Community Peers
  • Voters should be community members
  • Merit over managers

ELECTION PRINCIPLES

Protection from Dominance by a Constituency

ELECTION PRINCIPLES

"No single Constituency should be able to dominate the TSC."

ELECTION PRINCIPLES

Protection from Dominance by a Constituency
  • Company caps
  • Mechanics for other caps, currently turned off

ELECTION PRINCIPLES

Fairness of Exclusion

ELECTION PRINCIPLES

"Candidates should be excluded from the possibility of holding a TSC seat they would have otherwise won as infrequently as possible, and only for the sake of trade-offs with other key principles. When some candidates must be excluded from holding seats, the selection should be done as fairly as possible (consensus, merit, random, not power over career)."

ELECTION PRINCIPLES

Fairness of Exclusion
  • If company cap is hit exclusions should be fair, not managers-win

ELECTION PRINCIPLES

Modern Election Tools

ELECTION PRINCIPLES

"When possible, OpenDaylight's election process should make use of high-quality existing election primitives. For example, proportional representation voting systems for multi-seat constituencies that use ranked voting, like Condorcet or Single Transferable Vote, have well-understood good properties that are helpful for our use-case."

ELECTION PRINCIPLES

Modern Election Tools
  • There is a science of elections
  • Some systems are objectively bad (USA Elections)
  • Good: Ranked preference

ELECTION PRINCIPLES

Flexibility over Time

ELECTION PRINCIPLES

"We have an imperfect understanding of what governance structures are best for OpenDaylight and we expect the governance needs of OpenDaylight to change over time. The election system we adopt should enable a clear path for adjustments over time, especially for aspects that are most likely to be dynamic (like seat allocations to Constituencies)."

ELECTION PRINCIPLES

Flexibility over Time
  • Some components, like seat allocations, should be easy to edit

ODL's Elections

ODL'S ELECTIONS

Overview

ODL'S ELECTIONS

Seats allocated to Represented Groups*

ODL'S ELECTIONS

Eligible Candidates* self-nominate, provide data

ODL'S ELECTIONS

Voters* in each RG rank their Candidates by preference

ODL'S ELECTIONS

If caps are exceeded, resolve by Scaled Popularity*

ODL'S ELECTIONS

Elections happen yearly

ODL'S ELECTIONS

Details

ODL'S ELECTIONS

Represented Group details

ODL'S ELECTIONS

"Represented Groups are typically Constituencies with systematically competing interests that the TSC wants to ensure have voices (in the form of votes)"

ODL'S ELECTIONS

Represented Group schema:
{Min Seats,
Max Seats,
Candidates,
Voters,
Duplicate Voter Strategy}

ODL'S ELECTIONS

  RG: Kernel Project PTLs
  Min Seats: 2
  Max Seats: 100% (no cap)
  Candidates: PTLs of Kernel projects
  Voters: PTLs of Kernel projects
  Duplicate Voter Strategy: Vote-per-Interest

ODL'S ELECTIONS

  RG: Committers-at-Large
  Min Seats: 5
  Max Seats: 100% (no cap)
  Candidates: Committers to ODL projects
  Voters: Committers to ODL projects
  Duplicate Voter Strategy: Vote-per-Person

ODL'S ELECTIONS

Every company is an RG

ODL'S ELECTIONS

"For purposes of avoiding dominance from a particular company, also define any given company as an Represented Group with no seats (and thus no need to define voters)"

ODL'S ELECTIONS

for company_var in <the set of all companies>:
  RG: company_var 
  Min Seats: 0
  Max Seats: 33% (cap of 4)
  Candidates: Works for company_var
  Voters: None

ODL'S ELECTIONS

Over-cap resolution via Scaled Popularity details

ODL'S ELECTIONS

Scale a candidate's votes based on RG size
A: 2 of 4 votes, 50%
B: 4 of 10 votes, 40%

ODL'S ELECTIONS

Drop the candidate with lowest scaled vote from their RG election

ODL'S ELECTIONS

Next highest ranked person from that RG is new winner

ODL'S ELECTIONS

Re-check if over any caps, repeat if necessary

ODL'S ELECTIONS

If can't get under-cap, recruit  more diverse candidates or increase caps

Tips

TIPS

Need a few key stakeholders to drive, but...

TIPS

Community must be deeply involved in design to feel invested

TIPS

Do absolutely everything in public

TIPS

Be sensitive to stakeholders feeling like they're losing influence

TIPS

Docs in version control, code review tools to collab

TIPS

Gerrit as collaborative doc-writing tool
  • Inline comments
  • Full history of comments, intermediary patchsets
  • Everyone can access
  • Render to HTML (readthedocs)
  • Linting
  • Teach higher-ups to use dev tools
  • Open source

TIPS

Don't use Google Docs
  • Not accessible in China
  • Not as usable history
    • Resolved comments go away
    • Very hard to track patchset-like changes
  • Closed source

TIPS

Don't use wikis
  • No inline comments

TIPS

Clear Principles enable interpretation in unexpected situations

TIPS

Don't mix with other efforts
(release process, quality requirements, project lifecycle)

Other Communities

OTHER COMMUNITIES

OPNFV
  • Added good work to define "active contributors"

OTHER COMMUNITIES

Fd.io
  • Not using RGs, think they are too small

OTHER COMMUNITIES

Linux Foundation Networking Umbrella
  • Brand new, mostly appointed
  • Waiting for maturity, then I'll start adding elected seats

OTHER COMMUNITIES

Yours?

Contact

Daniel Farrell
Twitter: @dfarrell07
Email: dfarrell@redhat.com
IRC: dfarrell07

Appointed to Elected: Evolving Technical Community Leadership

By Daniel Farrell

Appointed to Elected: Evolving Technical Community Leadership

Talk for Open Source Summit North America 2018

  • 391
Loading comments...

More from Daniel Farrell