Jump to: navigation, search

Difference between revisions of "TC Membership Models"

("6 categorized PTLs + 7 directly-elected" model)
(Adding markmc's goals)
Line 16: Line 16:
 
* '''Caring''': Obviously everyone cares about OpenStack, but some people are more interested by specific project issues. The TC membership selection system should favor people that are actually interested in cross-project issues and judging the merits of new integrated projects, because that's what the TC discussions are about.
 
* '''Caring''': Obviously everyone cares about OpenStack, but some people are more interested by specific project issues. The TC membership selection system should favor people that are actually interested in cross-project issues and judging the merits of new integrated projects, because that's what the TC discussions are about.
 
* '''Resistant''': Given a sufficiently-motivated opponent, all democratic selection systems can be gamed, although some systems are harder to game than others. Bonus points for a model that is intrinsically harder to game.
 
* '''Resistant''': Given a sufficiently-motivated opponent, all democratic selection systems can be gamed, although some systems are harder to game than others. Bonus points for a model that is intrinsically harder to game.
 +
* '''Simple & Collaborative''': The more emphasis we place on voting structures and representation, the more bureaucratic our governance becomes, the more the focus drifts from collaborating based on trust and shared interests towards a combative model based on mistrust and competing interests.
 +
* '''Flexible''': No governance is ever perfect and we must assume that our governance model will need to evolve over time as the challenges we face
 +
change. This is true not only for the top-level OpenStack project governance, but also for the governance of individual projects, programs and teams.
  
  
We will evaluate proposals below with these goals as criteria.
+
We will evaluate proposals below with these goals as criteria. Depending on how much you care about each goal (and weigh each criteria) you are likely to end up with a different preferred system.
  
 
== Models ==
 
== Models ==

Revision as of 09:52, 3 June 2013

Background

In the middle of the Grizzly cycle, as we were considering adding new projects, we started a discussion on how the composition of the Technical Committee ("TC") should evolve. This was motivated by the fear of the TC growing to an unmanageable size, the risk of that fear factor influencing the (technical) decision to reject or accept new projects, and the fact that letting the TC grow more would only make it more difficult to pass such a change in the future.

Having this important discussion under the time pressure of upcoming graduation reviews proved to be difficult, so we decided to take the time to have this discussion during the Havana cycle. It started with a session at the Design Summit and continues now with a -dev ML thread and this wiki page.

For more information on the Technical Committee, see the Charter and current membership.

Goals

The system we want to move to should make its best to fill a number of goals:

  • Representative: The TC membership needs to be seen as a fair representation of the technical contributors to the project. In open source projects, when the divide grows between the contributors and the instances chosen to make decisions and calls, you face the risk of forks. Maintaining a transparent and fair representation of the group of current contributors is therefore critical to the long-term success of the project
  • Diverse: The TC membership needs to represent a variety of opinions. There is little value in having three people in the TC always voicing the same opinions. It's also important to get multiple functions represented: horizontal tasks (like QA or CI folks) as well as horizontal tasks (developers from specific projects)
  • Small: It's difficult to organize meetings, have productive online discussions and reach consensus in large groups. There is a balance to strike with the need for diversity, but groups above 11 become difficult, and groups above 15 become unmanageable and unproductive.
  • Caring: Obviously everyone cares about OpenStack, but some people are more interested by specific project issues. The TC membership selection system should favor people that are actually interested in cross-project issues and judging the merits of new integrated projects, because that's what the TC discussions are about.
  • Resistant: Given a sufficiently-motivated opponent, all democratic selection systems can be gamed, although some systems are harder to game than others. Bonus points for a model that is intrinsically harder to game.
  • Simple & Collaborative: The more emphasis we place on voting structures and representation, the more bureaucratic our governance becomes, the more the focus drifts from collaborating based on trust and shared interests towards a combative model based on mistrust and competing interests.
  • Flexible: No governance is ever perfect and we must assume that our governance model will need to evolve over time as the challenges we face

change. This is true not only for the top-level OpenStack project governance, but also for the governance of individual projects, programs and teams.


We will evaluate proposals below with these goals as criteria. Depending on how much you care about each goal (and weigh each criteria) you are likely to end up with a different preferred system.

Models

"PTLs+5" (current model)

Each integrated project elects its Project Technical Lead (PTL), which gets a seat on the TC for the duration of their mandate (6 months). In addition, an open staggered election is held to fill the remaining 5 seats. This model was used for the Fall 2012 election (13 members) and Spring 2013 election (15 members). Given the number of projects filing for incubation, the Fall 2013 election may result in the election of 15 to 19 members.

Scorecard:

  • Representative: -1 (double election system gives, in effect, multiple votes to developers touching every project, while a developer involved with QA only gets one vote. Additionally, as we add more projects, the share of horizontal functions representation gets further reduced)
  • Diverse: +1 (giving PTLs for every project a seat creates diversity)
  • Small: -2 (each integrated project has a PTL, so this will inevitably grow to unsustainable sizes as we add more projects in the future)
  • Caring: -1 (some PTLs might not be that interested in cross-project issues, there is no opt-in)
  • Resistant: +1 (including elected PTLs to the mix makes it slightly harder to flood openstack with contributors and get all elected positions)

"Best 7 PTLs + 6" model

Run an open election every 6 months, but give the 7 best PTLs a seat automatically, even if they ranked inferior to someone else. Everyone would be elected every 6 months to catch corner cases.

Scorecard:

  • Representative: +0 (double election system gives, in effect, multiple votes to developers touching every project, while a developer involved with QA only gets one vote)
  • Diverse: +1 (giving some PTLs a seat ensures a minimum of diversity, and the system freezes the mix of vertical vs. horizontal representation)
  • Small: +1 (limited by design to 13 members)
  • Caring: +1 (Only PTLs interested in TC would opt to participate in the TC election)
  • Resistant: +1 (including elected PTLs to the mix makes it slightly harder to flood openstack with contributors and get all elected positions)

"All-directly-elected 11" model

Run a staggered election (6 seats in Spring, 5 seats in Fall) and elect the winners for a one-year term.

Scorecard:

  • Representative: +2 (simple and demonstrably "fair": one person, one vote)
  • Diverse: -1 (Risk of over-representation of popular projects, and may favor cross-project figures)
  • Small: +2 (limited by design to 11 members)
  • Caring: +1 (Only people interested in TC issues would opt to participate in the TC election)
  • Resistant: +0 (Anyone with 51% of the single corpus of voters controls all seats, unless some proportional variant of Condorcet is used)

"Core PTLs + x" model

Each integrated project elects its Project Technical Lead (PTL), but only the ones that are labeled "core" by the Board of Directors get a seat on the TC for the duration of their mandate (6 months). In addition, an open staggered election is held to fill the remaining x seats.

Scorecard:

  • Representative: -1 (double election system gives, in effect, more importance to developers working on core project(s), while the TC affects all integrated projects. By controlling what is "core" and what is not, the Board of Directors also ends up influencing the composition of the TC, while the two bodies were designed to be completely distinct)
  • Diverse: +0 (Core project representation ensures a minimum of diversity, although only from core projects)
  • Small: +0 (initial size depends on choice of "x", but size will increase if we add core projects)
  • Caring: +0 (some PTLs might not be that interested in cross-project issues, there is no opt-in... although "core" PTLs have a higher chance of caring)
  • Resistant: +1 (including elected core PTLs to the mix makes it slightly harder to flood openstack with contributors and get all elected positions)

"Category" model

Define a set of categories, each with its own voters body. Each "category" elects one person to the TC.

Note: this may differ from the "PTL" since multiple projects would certainly share the same category. It may be difficult to determine the set of voters for some categories that don't go through Gerrit reviews for contribution.

Scorecard:

  • Representative: -1 (Some groups would inevitably be over or under-represented)
  • Diverse: +2 (Forcing categories would inevitably enforce diversity)
  • Small: +0 (risk of bloat as we add more "categories" to reflect the evolving mix of functions within the project)
  • Caring: +0 (depending on how the representative is selected (and if we reuse PTLs for this), he may or may not care)
  • Resistant: +1 (have each subgroup elect their representative makes the whole thing harder to game)

"no-PTL" model

Suggested during the Design Summit session, this model is like the "All directly elected 11", but PTLs can't be elected. The idea is that when a decision affects specifically some projects, the affected PTL would be invited to participate in the decision/vote.

Scorecard:

  • Representative: +1 (one person, one vote, but some persons just can't be elected)
  • Diverse: -1 (Risk of over-representation of popular projects, and may favor cross-project figures)
  • Small: +1 (limited by design to 11 members, although the group size would be increased when you add "affected PTLs" to discussions)
  • Caring: +0 (Only people interested in TC issues would opt to participate in the TC election, but the most caring people might be prevented from joining)
  • Resistant: +0 (Anyone with 51% of the single corpus of voters controls all seats, unless some proportional variant of Condorcet is used)


"6 categorized PTLs + 7 directly-elected" model

Suggested by mordred in the ML discussion. Combines the "7 PTLs + 6 directly-elected" approach with the "Category" approach.

Scorecard:

  • Representative: +1 (single TC election means one person has one vote, although the seat allocation algorithm gives people voting for multiple PTLs more influence in the end results)
  • Diverse: +1 (giving categorized seats ensures a minimum of diversity, and the system freezes the mix of vertical vs. horizontal representation)
  • Small: +1 (limited by design to 13 members)
  • Caring: +1 (Only PTLs interested in TC would opt to participate in the TC election)
  • Resistant: +1 (including elected PTLs to the mix makes it slightly harder to flood openstack with contributors and get all elected positions)