#opendaylight-meeting: tws

Meeting started by colindixon at 18:00:42 UTC (full logs).

Meeting summary

  1. agenda bashing (colindixon, 18:00:47)
    1. https://wiki.opendaylight.org/index.php?title=Tech_Work_Stream:Main&oldid=40317#Upcoming_Meeting_Agendas the propoed agenda for today (colindixon, 18:01:48)
    2. the proposed topics are "best practices for avoiding/mitigating cross-project breakages", "TSC Makeup and Election Changes", and "Boron priorities and planning" (colindixon, 18:02:43)
    3. https://lists.opendaylight.org/pipermail/tsc/2016-January/004552.html (colindixon, 18:08:01)
    4. https://lists.opendaylight.org/pipermail/tsc/2016-January/004552.html (dfarrell07, 18:08:19)

  2. best practices (colindixon, 18:08:26)
    1. https://lists.opendaylight.org/pipermail/tsc/2016-January/004552.html (colindixon, 18:08:27)
    2. Colin introduces best practice discussion, avoiding breaking builds, how to work up-and-down stream. Group has been off trying to make recommendations. (dfarrell07, 18:09:19)
    3. colindixon says there's a fair amount of agreement on the list, some details being worked out (dfarrell07, 18:09:47)
    4. (reviewing list of recommendations in linked email) (dfarrell07, 18:10:21)
    5. ACTION: colindixon to add point about not perpetually block patches (dfarrell07, 18:13:04)
    6. ACTION: colindixon will bring up where to add what expectations of being in the release around staying in autorelease are, e.g., if you go silent for weeks, you will be dropped (colindixon, 18:17:31)

  3. TSC election changes and make-up (colindixon, 18:19:39)
    1. https://wiki.opendaylight.org/view/TSC:Election_Proposal TSC Election Proposal collaborative wiki (dfarrell07, 18:19:54)

  4. Background and Principles (dfarrell07, 18:20:16)
    1. https://lists.opendaylight.org/pipermail/tsc/2015-October/004026.html Initial waver rejection discussion (dfarrell07, 18:20:50)
    2. https://lists.opendaylight.org/pipermail/tsc/2015-November/004101.html Parent-esque message a for long initial mail thread (dfarrell07, 18:20:56)
    3. https://lists.opendaylight.org/pipermail/tsc/2015-December/004298.html Another parent-esque message a for long initial mail thread (dfarrell07, 18:21:01)
    4. I turns out most/all of the ideas we came up with on the initial very long threads (dfarrell07, 18:21:05)
    5. could be represented in terms of {voters, candidates, max seats, min seats}. (colindixon, 18:21:43)
    6. I turns out most/all of the ideas we came up with on the initial very long threads could be represented in terms of {voters, candidates, max seats, min seats}. (colindixon, 18:21:48)
    7. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Representation_of_Constituencies (dfarrell07, 18:21:55)
    8. RGs allow something like "local representation" of a community, which allows election by peers for many ODL sub-communities (dfarrell07, 18:22:12)
    9. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Election_by_Community_Peers (dfarrell07, 18:22:19)
    10. The Max Seats RG value and the associated resolution mechanics prevent domination by a constituency (dfarrell07, 18:22:58)

  5. framework and represented groups (colindixon, 18:24:34)
    1. dfarrell07 says the two key parts (beyond motivation) are the framework which should be mostly static, and the list of represented groups that might be more dynamic (colindixon, 18:25:12)
    2. alagalah notes that he agress that dropping platinum designates is the right thing to do (dfarrell07 agrees) (colindixon, 18:28:07)
    3. for what it's worth this is actually baked into the TSC charter, they were always meant for bootstrapping, explicitly (colindixon, 18:28:36)

  6. election mechanics (colindixon, 18:28:57)
    1. dfarrell07 explains single transferrable vote elections (colindixon, 18:29:28)
    2. the idea is that there is one election per represented group (colindixon, 18:30:38)
    3. for now, the mechanics say that you can only run for election to represent one group and you get to choose among the ones where you're eligible (colindixon, 18:31:30)
    4. once votes are in, those that have a number of first-choice votes above the droop quota, they are elected, then the "extra votes" are redistributed to second choice votes (colindixon, 18:32:40)
    5. then it repeats until the number of seats are filled (colindixon, 18:33:17)
    6. it's possible that for some reason, we hit the maximum number of people elected from a give represented group even if they won in different elections, e.g., more people than allowed from a single company (colindixon, 18:34:22)
    7. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Over-Max_Resolution_Through_Scaled_Popularity (colindixon, 18:34:50)
    8. scaled-popularity helps you figure out who to drop from hitting the cap, basically drop the least populaur candidate, then recalculate the elections without them (but with no more voting required) (colindixon, 18:36:41)

  7. represented group proposals (colindixon, 18:36:41)
    1. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Represented_Group_Proposals (colindixon, 18:36:48)
    2. there are a bunch of examples from here that we could choose between (colindixon, 18:36:59)
    3. basically this is picking groups we think should have say on the TSC, then picking the number of seats they should have min and max, as well as who votes and who can stand for election (colindixon, 18:38:41)
    4. phrobb- asks if we have tools to do this election? (colindixon, 18:38:52)
    5. dfarrell07 says he has a preliminary set of tools do simulate ODL elections for teaching, but it's not production-ready yet (colindixon, 18:39:29)
    6. edwarnicke notes that there are likely lots of good STV tools, but the scaled popularity and caps would be new (colindixon, 18:41:14)
    7. dfarrell07 asks if people have opinions on differnet representted types (colindixon, 18:41:39)
    8. colindixon says he prefers All Types, All Lifecycle States (colindixon, 18:42:07)
    9. edwarnicke notes that he sees RGs as being there as needing to have some tensions and he sees lifecycle states has less of that than project types (colindixon, 18:42:52)
    10. alagalah says "All Types, Mature Lifecycle States" makes the most sense to him (colindixon, 18:45:00)
    11. dfarrell07 will dump links he couldn't add while talking (dfarrell07, 18:45:15)
    12. Many discussions about how to avoid excluding people/groups, or how to do it fairly (dfarrell07, 18:45:21)
    13. initial waver discussion was prompted by desire to avoid excluding low-ranking members of a company from committer-at-large tsc elections for implied fear of bumping high-ranking company person in platinum seat (dfarrell07, 18:45:41)
    14. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Fairness_of_Exclusion (dfarrell07, 18:45:53)
    15. We want to take advantage of modern election tools whenever possible, not reinvent things, use systems with well-understood properties (dfarrell07, 18:45:59)
    16. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Modern_Election_Tools (dfarrell07, 18:46:07)
    17. The goal is to build a framework that can be adjusted/calibrated over time (dfarrell07, 18:46:15)
    18. As new RGs exist, they can be defined and seats can be allocated without changes to the framework of the election system (dfarrell07, 18:46:20)
    19. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Flexibility_over_Time (dfarrell07, 18:46:27)

  8. Framework (dfarrell07, 18:46:34)
    1. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Framework The core of the proposal (dfarrell07, 18:46:47)
    2. ChrisPriceAB had said project types didn't work out for OPNFV, and encouraged us to do the same (colindixon, 18:46:48)
    3. Set of multi-winner elections, one election per RG (dfarrell07, 18:46:53)
    4. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Overview_2 (dfarrell07, 18:46:58)
    5. The outgoing TSC determines the set of RGs and seat allocation (dfarrell07, 18:47:04)
    6. "Represented Groups are typically Constituencies with systematically competing interests that the TSC wants to ensure have voices (in the form of votes)" (dfarrell07, 18:47:10)
    7. edwarnicke adn colindixon say that maybe types will work out better for us because they grew out organically (colindixon, 18:47:10)
    8. RGs are define by {voters, candidates, max seats, min seats} (dfarrell07, 18:47:18)
    9. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Seat_Allocation (dfarrell07, 18:47:23)
    10. STV elections because of desirable properties they provide (dfarrell07, 18:47:31)
    11. Candidates are ranked by preference 1...n (dfarrell07, 18:47:36)
    12. For all elections, the set of candidates is notified and asked to self-nominate (dfarrell07, 18:47:41)
    13. Candidates declare the set of RGs for which they match the Candidate description and as well as a single Represented Group under which they would like to run for a TSC seat (dfarrell07, 18:47:45)
    14. Ballots are prepared (details on wiki), distributed to electorate for each RG (dfarrell07, 18:47:51)
    15. The number of votes required to win a seat in each election is determined (see Droop quota on wiki) (dfarrell07, 18:47:59)
    16. "Any candidates that pass the Droop quota are considered elected. The extra votes for those candidates are distributed proportionally to their second-choice candidates. If any candidate passes the Droop quota, they are considered elected and the process repeats. Once no candidate passes the Droop quota, the candidate with the lowest vote count is (dfarrell07, 18:48:05)
    17. If any RG is over-max, the votes from the first elections are scaled (so candidates can be compared cross-RG) and the least popular candidates in the RG are eliminated (dfarrell07, 18:48:09)
    18. Elections are re-run with those candidates excluded (and their second-choice votes distributed proportionally) (dfarrell07, 18:48:14)
    19. Repeat until no RG is over-max (dfarrell07, 18:48:22)
    20. Notify the winners - you're done :) (dfarrell07, 18:48:28)
    21. slides to talk about Fast Phased Boron and Branching Strategy: https://docs.google.com/presentation/d/1IKI8DV3oqb1snJLCaK6lLvvCXCnpEolQ6Xp_Qlk6E8M/edit#slide=id.p (edwarnicke, 18:48:29)
    22. https://wiki.opendaylight.org/view/tsc:election_proposal#examples examples (dfarrell07, 18:48:47)
    23. We still need to figure out frequency (dfarrell07, 18:48:52)
    24. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Election_Frequency (dfarrell07, 18:48:56)
    25. ACTION: phrobb- or case to link in the webex recording from last boron release planning TWS on 1/11 (colindixon, 18:48:59)
    26. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Election_Frequency (dfarrell07, 18:49:00)
    27. https://wiki.opendaylight.org/view/TSC:Election_Proposal#Represented_Group_Proposals (dfarrell07, 18:49:04)

  9. boron faster release planning (colindixon, 18:49:57)
    1. https://wiki.opendaylight.org/view/Tech_Work_Stream:Main#Information_From_Past_Meetings see the January 11th meeting (wich will have the WebEx recording) if you want background (colindixon, 18:50:34)
    2. https://wiki.opendaylight.org/view/New_workflow_proposal rovarga and and skitt tried to do a writeup on this here (colindixon, 18:51:20)
    3. https://lists.opendaylight.org/pipermail/release/2015-October/003849.html mailin list thread on this here (colindixon, 18:51:32)
    4. https://docs.google.com/presentation/d/1IKI8DV3oqb1snJLCaK6lLvvCXCnpEolQ6Xp_Qlk6E8M/edit#slide=id.g826776a72_0_5 edwarnicke talks to this branching picture (colindixon, 18:52:15)
    5. edwarnicke notes that one key good idea from skitt and rovarga is that you need downstream branches for integration branches to track if anything has broken them as upstream projects do work (colindixon, 18:53:59)
    6. the point isn't quite to track if anything has broken, it's to allow upstreams to prepare fixes for downstreams (skitt, 18:54:37)
    7. alagalah asks: Are there examples of other opensource communities using this strategy ? (alagalah, 18:55:16)
    8. possibly Gnome (skitt, 18:56:04)
    9. and Ubuntu (skitt, 18:56:22)
    10. https://lists.opendaylight.org/pipermail/tsc/2016-January/004565.html the advisory group had some input about boron (colindixon, 18:56:38)
    11. most feedback was not relating to schedule, but the part about schedule that did exist said that most customers were adopting every other release, and so releasing faster might not help them, so we should do it for internal reasons over external reasons (colindixon, 19:00:16)
    12. edwarnicke says he believes in revealed preference, which is that people are asking for more features in SRs, which are effectively faster releases, even as they say they won't adopt full releases (colindixon, 19:00:58)
    13. colindixon says in his experience people are asking for features in SRs because the lift between SRs is much smaller than than between release (colindixon, 19:02:50)
    14. edwarnicke notes that might be because there's ~4x more time to change things in a long release which makes the lift harder (colindixon, 19:05:18)
    15. https://lists.opendaylight.org/pipermail/tsc/2016-January/004565.html (colindixon, 19:05:57)


Meeting ended at 19:06:49 UTC (full logs).

Action items

  1. colindixon to add point about not perpetually block patches
  2. colindixon will bring up where to add what expectations of being in the release around staying in autorelease are, e.g., if you go silent for weeks, you will be dropped
  3. phrobb- or case to link in the webex recording from last boron release planning TWS on 1/11


Action items, by person

  1. colindixon
    1. colindixon to add point about not perpetually block patches
    2. colindixon will bring up where to add what expectations of being in the release around staying in autorelease are, e.g., if you go silent for weeks, you will be dropped


People present (lines said)

  1. colindixon (59)
  2. dfarrell07 (57)
  3. alagalah (13)
  4. skitt (5)
  5. odl_meetbot (5)
  6. edwarnicke (1)


Generated by MeetBot 0.1.4.