Daniel Farrell
Software Engineer, Red Hat SDN Team
Appointed to Elected: Evolving Technical Community Leadership
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
- 1,685
