18:00:42 <colindixon> #startmeeting tws
18:00:42 <odl_meetbot> Meeting started Mon Jan 25 18:00:42 2016 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:00:42 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:42 <odl_meetbot> The meeting name has been set to 'tws'
18:00:47 <colindixon> #topic agenda bashing
18:01:48 <colindixon> #link https://wiki.opendaylight.org/index.php?title=Tech_Work_Stream:Main&oldid=40317#Upcoming_Meeting_Agendas the propoed agenda for today
18:01:55 * dfarrell07 is ready to talk about election stuff
18:02:09 * dfarrell07 also thinks Boron is pressing
18:02:38 * dfarrell07 acknowledges that both are pressing
18:02:43 <colindixon> #Info the proposed topics are "best practices for avoiding/mitigating cross-project breakages", "TSC Makeup and Election Changes", and "Boron priorities and planning"
18:08:01 <colindixon> https://lists.opendaylight.org/pipermail/tsc/2016-January/004552.html
18:08:19 <dfarrell07> #link https://lists.opendaylight.org/pipermail/tsc/2016-January/004552.html
18:08:26 <colindixon> #topic best practices
18:08:27 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2016-January/004552.html
18:08:27 <colindixon> #chair dfarrell07
18:08:27 <odl_meetbot> Current chairs: colindixon dfarrell07
18:09:19 <dfarrell07> #info Colin introduces best practice discussion, avoiding breaking builds, how to work up-and-down stream. Group has been off trying to make recommendations.
18:09:47 <dfarrell07> #info colindixon says there's a fair amount of agreement on the list, some details being worked out
18:10:21 <dfarrell07> #info (reviewing list of recommendations in linked email)
18:13:04 <dfarrell07> #action colindixon to add point about not perpetually block patches
18:14:37 <alagalah> colindixon: What does formal adoption mean? Will the release-police (affectionate term) police this ?
18:15:16 <colindixon> alagalah: my hope is that this will mostly not have to be enforced
18:16:54 <colindixon> alagalah: but at the end of the day, a combination of the releaset engineering people, integration group and TSC would be responsible for policing things
18:17:27 <dfarrell07> alagalah: (off-hand, but with my TSC hat on) It's the kind of thing that I could see coming up in Graduation/Promotion reviews
18:17:31 <colindixon> #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
18:17:32 <alagalah> colindixon: Excellent. All good. And I like Robert's FAQ idea...
18:18:25 <dfarrell07> and with my Integration hat on, imho we don't mind dropping and re-adding project
18:19:39 <colindixon> #topic TSC election changes and make-up
18:19:40 <alagalah> colindixon: FYI that was 11min
18:19:40 <alagalah> :)
18:19:46 <colindixon> alagalah: I know
18:19:48 <colindixon> :-/
18:19:54 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal TSC Election Proposal collaborative wiki
18:20:16 <dfarrell07> #topic Background and Principles
18:20:47 <colindixon> dfarrell07: I can link and summarize
18:20:50 <dfarrell07> #link https://lists.opendaylight.org/pipermail/tsc/2015-October/004026.html Initial waver rejection discussion
18:20:56 <dfarrell07> #link https://lists.opendaylight.org/pipermail/tsc/2015-November/004101.html Parent-esque message a for long initial mail thread
18:21:01 <dfarrell07> #link https://lists.opendaylight.org/pipermail/tsc/2015-December/004298.html Another parent-esque message a for long initial mail thread
18:21:05 <dfarrell07> #info I turns out most/all of the ideas we came up with on the initial very long threads
18:21:10 <dfarrell07> could be represented in terms of {voters, candidates, max seats, min seats}.
18:21:16 <dfarrell07> #info 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}.
18:21:33 <colindixon> #undo
18:21:33 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x21a9dd0>
18:21:43 <colindixon> #info could be represented in terms of {voters, candidates, max seats, min seats}.
18:21:48 <colindixon> #info 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}.
18:21:55 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Representation_of_Constituencies
18:22:12 <dfarrell07> #info RGs allow something like "local representation" of a community, which allows election by peers for many ODL sub-communities
18:22:19 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Election_by_Community_Peers
18:22:58 <dfarrell07> #info The Max Seats RG value and the associated resolution mechanics prevent domination by a constituency
18:24:34 <colindixon> #topic framework and represented groups
18:25:12 <colindixon> #Info 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
18:28:07 <colindixon> #info alagalah notes that he agress that dropping platinum designates is the right thing to do (dfarrell07 agrees)
18:28:36 <colindixon> #info for what it's worth this is actually baked into the TSC charter, they were always meant for bootstrapping, explicitly
18:28:57 <colindixon> #topic election mechanics
18:29:28 * alagalah is very familiar with this system, its how elections in Australia are done
18:29:28 <colindixon> #Info dfarrell07 explains single transferrable vote elections
18:30:38 <colindixon> #Info the idea is that there is one election per represented group
18:31:30 <colindixon> #Info 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
18:32:40 <colindixon> #info 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
18:33:17 <colindixon> #info then it repeats until the number of seats are filled
18:34:22 <colindixon> #info 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
18:34:50 <colindixon> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Over-Max_Resolution_Through_Scaled_Popularity
18:36:41 <colindixon> #info 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)
18:36:41 <colindixon> #topic represented group proposals
18:36:48 <colindixon> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Represented_Group_Proposals
18:36:59 <colindixon> #Info there are a bunch of examples from here that we could choose between
18:38:41 <colindixon> #info 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
18:38:52 <colindixon> #info phrobb- asks if we have tools to do this election?
18:39:29 <colindixon> #Info dfarrell07 says he has a preliminary set of tools do simulate ODL elections for teaching, but it's not production-ready yet
18:41:14 <colindixon> #info edwarnicke notes that there are likely lots of good STV tools, but the scaled popularity and caps would be new
18:41:39 <colindixon> #info dfarrell07 asks if people have opinions on differnet representted types
18:42:07 <colindixon> #Info colindixon says he prefers All Types, All Lifecycle States
18:42:52 <colindixon> #info 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
18:42:52 <alagalah> colindixon: dfarrell07 edwarnicke Doesn't kernel / protocol/ app align almost perfectly with offset-0, 1, 2 to the point that there isn
18:43:03 <alagalah> 't as much value is drawing a distinction around TSC seats ?
18:43:12 <colindixon> alagalah: yes
18:44:20 <alagalah> colindixon: dfarrell07 "All Types, Mature Lifecycle States " makes the most sense to me
18:45:00 <colindixon> #info alagalah says "All Types, Mature Lifecycle States" makes the most sense to him
18:45:15 <dfarrell07> #info dfarrell07 will dump links he couldn't add while talking
18:45:21 <dfarrell07> #info Many discussions about how to avoid excluding people/groups, or how to do it fairly
18:45:41 <dfarrell07> #info 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
18:45:53 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Fairness_of_Exclusion
18:45:59 <dfarrell07> #info We want to take advantage of modern election tools whenever possible, not reinvent things, use systems with well-understood properties
18:46:07 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Modern_Election_Tools
18:46:15 <dfarrell07> #info The goal is to build a framework that can be adjusted/calibrated over time
18:46:20 <dfarrell07> #info As new RGs exist, they can be defined and seats can be allocated without changes to the framework of the election system
18:46:27 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Flexibility_over_Time
18:46:34 <dfarrell07> #topic Framework
18:46:47 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Framework The core of the proposal
18:46:48 <colindixon> #info ChrisPriceAB had said project types didn't work out for OPNFV, and encouraged us to do the same
18:46:53 <dfarrell07> #info Set of multi-winner elections, one election per RG
18:46:58 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Overview_2
18:47:04 <dfarrell07> #info The outgoing TSC determines the set of RGs and seat allocation
18:47:10 <dfarrell07> #info "Represented Groups are typically Constituencies with systematically competing interests that the TSC wants to ensure have voices (in the form of votes)"
18:47:10 <colindixon> #info edwarnicke adn colindixon say that maybe types will work out better for us because they grew out organically
18:47:18 <dfarrell07> #info RGs are define by {voters, candidates, max seats, min seats}
18:47:23 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Seat_Allocation
18:47:31 <dfarrell07> #info STV elections because of desirable properties they provide
18:47:36 <dfarrell07> #info Candidates are ranked by preference 1...n
18:47:41 <dfarrell07> #info For all elections, the set of candidates is notified and asked to self-nominate
18:47:45 <dfarrell07> #info 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
18:47:51 <dfarrell07> #info Ballots are prepared (details on wiki), distributed to electorate for each RG
18:47:59 <dfarrell07> #info The number of votes required to win a seat in each election is determined (see Droop quota on wiki)
18:48:05 <dfarrell07> #info "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
18:48:05 <dfarrell07> eliminated and those votes are distributed. This process continues until all of the seats for the election are filled."
18:48:09 <dfarrell07> #info 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
18:48:14 <dfarrell07> #info Elections are re-run with those candidates excluded (and their second-choice votes distributed proportionally)
18:48:22 <dfarrell07> #info Repeat until no RG is over-max
18:48:28 <dfarrell07> #info Notify the winners - you're done :)
18:48:29 <edwarnicke> #info slides to talk about Fast Phased Boron and Branching Strategy: https://docs.google.com/presentation/d/1IKI8DV3oqb1snJLCaK6lLvvCXCnpEolQ6Xp_Qlk6E8M/edit#slide=id.p
18:48:47 <dfarrell07> #link https://wiki.opendaylight.org/view/tsc:election_proposal#examples examples
18:48:52 <dfarrell07> #info We still need to figure out frequency
18:48:56 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Election_Frequency
18:48:59 <colindixon> #action phrobb- or case to link in the webex recording from last boron release planning TWS on 1/11
18:49:00 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Election_Frequency
18:49:04 <dfarrell07> #link https://wiki.opendaylight.org/view/TSC:Election_Proposal#Represented_Group_Proposals
18:49:08 * dfarrell07 is done dumping links
18:49:57 <colindixon> #topic boron faster release planning
18:50:34 <colindixon> #link 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
18:51:20 <colindixon> #link https://wiki.opendaylight.org/view/New_workflow_proposal rovarga and and skitt tried to do a writeup on this here
18:51:32 <colindixon> #link https://lists.opendaylight.org/pipermail/release/2015-October/003849.html mailin list thread on this here
18:52:15 <colindixon> #link https://docs.google.com/presentation/d/1IKI8DV3oqb1snJLCaK6lLvvCXCnpEolQ6Xp_Qlk6E8M/edit#slide=id.g826776a72_0_5 edwarnicke talks to this branching picture
18:53:59 <colindixon> #info 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
18:54:37 <skitt> #info the point isn't quite to track if anything has broken, it's to allow upstreams to prepare fixes for downstreams
18:55:16 <alagalah> #info alagalah asks: Are there examples of other opensource communities using this strategy ?
18:55:42 <alagalah> skitt: ? edwarnicke ?
18:56:04 <skitt> #info possibly Gnome
18:56:13 <alagalah> skitt: Thank you.
18:56:22 <skitt> #info and Ubuntu
18:56:38 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2016-January/004565.html the advisory group had some input about boron
18:56:40 <skitt> the latter was the one I tried to map our process to as an example
18:57:54 <alagalah> colindixon: unfortunately I have to bounce.... I think in reality this will likely mean that some projects may skip a release (off top of my head I'd consider it) ...
18:58:07 <alagalah> colindixon: ... which I don't think is a BAD thing
18:58:44 <skitt> alagalah, +1 as long as it doesn't make life harder for the other projects
19:00:16 <colindixon> #info 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
19:00:58 <colindixon> #info 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
19:02:50 <colindixon> #info colindixon says in his experience people are asking for features in SRs because the lift between SRs is much smaller than than between release
19:05:18 <colindixon> #info edwarnicke notes that might be because there's ~4x more time to change things in a long release which makes the lift harder
19:05:57 <colindixon> https://lists.opendaylight.org/pipermail/tsc/2016-January/004565.html
19:06:49 <colindixon> #endmeeting