20:03:40 #startmeeting tc 20:03:41 Meeting started Tue Jan 22 20:03:40 2013 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:44 The meeting name has been set to 'tc' 20:03:45 ttrifonov_zZzz: o/ 20:03:53 crap. 20:03:55 o/ 20:03:58 Agenda for today is: 20:04:03 #link http://wiki.openstack.org/Governance/TechnicalCommittee 20:04:28 (heckj, annegentle not on channel...) oh, jgriffith. 20:04:35 #topic Discussion: Voting procedure to decide the H release name 20:04:42 Super important 20:04:50 The most lightweight and relatively-painful-to-hack method remains to use Launchpad polls as we did in the past 20:05:01 The main issue with Launchpad polls are that they are single-choice 20:05:10 which doesn't work so well when there are 35 options. 20:05:18 So to reduce that problem my suggestion would be that the TC comes up with a shortlist of 4 names 20:05:27 then using single-choice polling is not so much of a problem. 20:05:35 If you agree with that, I can quickly setup a Condorcet vote for the TC 20:05:44 so that we efficiently pick the 4 best options out of http://wiki.openstack.org/ReleaseNaming 20:05:51 Thoughts ? 20:05:54 why not a codorcet vote globally? 20:06:09 notmyname: my question as well, but i'm guessing ttx has a reason :) 20:06:20 notmyname: two reasons... we would change who gets to vote compared to previous polls... 20:06:48 and we would have to send emails, while I don't want people to feel like they are constantly asked to participate in elections 20:07:18 well, we're going to have to ask them to participate in electoins whether it's 4 choices or 35 20:07:18 hence the lightweight "polling" on the ~openstack LP group announced via various low-touch social media 20:07:26 4 seems just a little low, might take some of the fun out of it 20:07:40 I do not support low-touch social media announcement only 20:07:45 mordred: not really. We'll annoucne the vote on the ML, not send them all personal emails 20:07:52 Halfway, lol ... 20:07:59 the Halfway release ... 20:08:08 i don't see either of the two reasons for not using codorcet are that critical. what is the difference in the set of people who would vote? 20:08:08 ok. well, honestly, I'd rather get a vote email than a mail to ~openstack mailing list, which I regularly ignore 20:08:37 danwent: we'd have to pick between technical contributors or foundation members 20:08:42 (I'll know about the election from being in here, but I'm imagining I'm not the only person) 20:08:51 mordred: +1 (most people I know filter the ML pretty heavily too) 20:08:58 is this a board or a TC call? 20:09:05 also IT'S NOT VERY IMPORTANT :) 20:09:17 because if it's a TC call, then the vote comes from the Tech contribs quite clearly, since they are our constituents 20:09:21 ttx, *nod* 20:09:28 if it's a board call, then the vote needs to come from the foudation membership 20:09:48 ttx: I think you might underestimate how much people care about the name 20:09:50 I don't really want to get caught in setting up a 6K voters condorcet 20:10:06 was grizzly what was voted for last time? 20:10:10 yes 20:10:16 * markmc recalls something about going with something different from the vote 20:10:23 the Waldon exception 20:10:23 my mistake 20:10:29 there had to be an exception to get grizzly to be a valid choice 20:10:36 ah 20:10:43 it was campaigned for, heh 20:10:47 Hamlet, Harbor, Homestead, Hood 20:10:49 anyway, I'm fine with all condorcet, but then someone else shoudl volunteer to irganize it 20:10:52 vishy: ++ 20:10:53 there are the four choices. done. 20:10:57 :) 20:11:04 if we go with 4, I support vishy's four 20:11:15 mordred: TC-level condorect is easy to set up, I've it ready to go 20:11:24 ttx: then why don't we just do that? 20:11:39 OR - just do your original suggestion with vishy's four :) 20:11:49 * mordred is being useful and agreeing with everyone 20:12:04 mordred: do what ? A 13-viters condorcet to pick the 4 other people will vote on ? 20:12:08 voters* 20:12:11 oh 20:12:21 or something else ? 20:12:21 I thought you meant you had an ATC condorcet set up already 20:12:48 mordred: well, not really 20:12:57 it's a tad more difficult to set up 20:13:08 given the numbers of people involved 20:13:16 ok. well, I don't have time to set it up either ... so I think that's an excellent point 20:13:26 I bet non contributors would bitch about not being able to say something 20:13:36 Hatfield: http://en.wikipedia.org/wiki/Hatfield-McCoy_feud 20:13:38 someone is always going to bitch 20:13:54 mordred: not if you don't change the system 20:14:04 ttx: someone is ALWAYS going to bitch 20:14:11 and continue to use the same system... just select the set of possible answers 20:14:15 s/Harbor/Hatfield/ 20:14:21 (which we did the other times as well) 20:14:33 harbor will ellicit silly spelling issues from our harbour-spelling uk friends 20:14:37 I can just suggest something arbitrary again, if that helps 20:14:43 So to ask it differently, are you OK with what I propose or are you going to run the election yourself ? 20:14:54 bcwaldon: I've already suggested the waldon-exception invoking choice for this cycle 20:14:55 heh, nice 20:14:58 I'm fine either way 20:14:58 Harbor, *because* it will elicit silly spelling issues 20:15:03 russellb: hehe 20:15:24 bcwaldon: hood isn't technically a town, there's a mount hood, a hood river and it's (barely) on the flag 20:15:40 bcwaldon: but it's a really big mountain, and it's 4 letters, so - you know 20:16:07 Hood it is 20:16:12 * russellb really just doesn't care on this topic ... 20:16:19 hehehe 20:16:30 ttx: I think russelb just suggested that we decide by fiat and just tell people :) 20:16:37 done 20:16:44 done and done 20:17:01 ok, CIVS sent :P 20:17:29 then we can decide if we poll people on first 4, or just pick ourselves 20:17:52 We can get back to it at the end of the meeting, time permitting 20:18:06 #topic Discussion: Evolution of the TC membership to support potential growth 20:18:19 We started that discussion at the last meeting two weeks ago. 20:18:27 Since then I started a ML thread detailing options at: 20:18:32 #link http://lists.openstack.org/pipermail/openstack-dev/2013-January/004513.html 20:18:42 So far the general feedback is that people prefer option (3), but could accept (4) if that's where consensus was 20:18:49 (potentially with a 7 guaranteed PTLs instead of 8) 20:18:58 They generally prefer (3) because (4) adds complexity in election setup for no obvious gain. 20:19:05 * jaypipes could go either way 20:19:09 Anne hinted that she would prefer some per-theme representation but that option is still very much on the drawing board 20:19:09 with the outlier proposal from anne about categories 20:19:24 We need to make a decision quick as it affects the upcoming elections we have to start setting up 20:19:34 So if there is opposition to option (3), I'd like to hear it (especially on the thread) 20:19:47 And if people prefer detailed alternate options, they should add them to the thread as well. 20:19:59 Otherwise I'll just draft a motion based on (3) for us to vote on at next meeting. 20:20:07 Comments ? 20:20:10 I second a motion based on (3) 20:20:16 thirded 20:20:30 * markmc checks what (3) was :) 20:20:41 yeah, that one 20:20:48 with a poison pill added that if that results in absolute chaos, a unanimous decisions by all standing PTLs can trigger a re-election :) 20:20:53 I'm all for (3), just thought (4) would be where lazy consensus would lie 20:21:08 * mordred is kidding - just do 3 20:21:14 I think 3 was the least-bad of the options given, but I prefer the category approach 20:21:38 I think at some point we should explore the idea of project categories in general 20:21:42 notmyname: I'm fine with exploring the category approach further, but for the Fall election 20:21:51 but I think we might need some beer at the summit to really sort that one out 20:22:13 since I think it will take time to come up with something good, balanced and practical to organize 20:22:36 s/take time/be near impossible/ 20:22:38 have we discussed any kind of limitation about people serving on both the board and the tc? 20:22:57 vishy: we haven't, you think we should ? 20:23:04 I am concerned that small projects will not get good respresentation, but worry that categories won't be flexible enough as the set of projects evolve. I still like the idea of having PTLs elect a set of PTLs to represent all PTLs on the board. That way, several small projects could decide on one person that will represent them all. 20:23:22 BUT, i don't have the cycles to push this, so am up for going with 3 as the other least bad :) 20:23:32 danwent: you shouldn't think of it as representation for everyone, but more about electing wise people that care about everything openstack 20:23:52 danwent: sounds like a consensus government 20:23:57 and provide a variety of opinions 20:24:21 is anyone against #3? 20:24:31 ttx: that's true no matter what method is chosen. you always want to have good people. the trick is making sure you have a system that handles when you don't have a good person 20:24:36 ttx: its really more about awareness to me…. its not that the wise people aren't wise, its just hard to know everything that's happening in all of the projects, no matter how wise you are :) 20:24:48 seems like general agreement on 3 being the best/least bad 20:25:10 I guess a PTL can always show up and plead their case, as long as they keep an eye on the agendas and understand their potential impact on their project. 20:25:41 danwent, notmyname - this stuff would make for really good discussion on the list 20:25:50 I thought that was the idea with starting a thread on the list 20:26:00 give people a chance to consider each others in-depth opinions a bit more 20:26:05 yeah, I was suprised to see almost direct consensus 20:26:37 ok, so I fucked up the CIVS thing, let me retry that 20:28:26 I guess the question is whether more discussion on list will change the consensus on what to do in the short term? 20:28:33 allow the discussion to be more about the best thing to do for future elections? 20:29:04 why does something need to change in the short term? the proposed changes are to protect against future problems 20:29:57 that's a fair point indeed 20:30:09 well, we have 2 projects in incubation, i guess that's the pressing issue? 20:30:19 what happens if they are brought into the coordinated release 20:30:21 russellb: yes 20:30:23 does that push us over some tipping point? 20:30:28 heh 20:30:31 oh, if they graduated, they'd be automatically granted seats 20:30:32 15 is a pretty big board 20:30:44 which could happen at the start of the H cycle 20:31:12 right, the idea is to pick a mechanism for next elections before that becomes a problem 20:31:26 OK, poll sent ok this time 20:32:09 your poll email is in French 20:32:09 so 13 members today (and with the 4 proposed options) is ok, but 15 members for the next 6 months (until fall elections) is too much? 20:32:13 ttx: lol, poll in French :) 20:32:23 I do not speak your jibberish! 20:32:31 ARRh, not that again 20:32:45 stupid sticky language support 20:32:57 I can redo it in english 20:33:11 * russellb was just trolling 20:33:14 * ttx is about to delegate that fun thing 20:33:17 i could google translate if necessary :) 20:33:47 notmyname, would we aim to reduce back to 13 again in future ? 20:33:49 CIVS creates the poll with the language set in the browser you use to create it, which is rather lame 20:33:54 * markmc thinks 15 is getting too big 20:34:11 I think 13 is already big, personally 20:34:17 but I can live with that 20:34:19 markmc: if that's the decision we come to 20:34:57 I also don't want the dilution to affect people's decision on accepting new projects 20:35:12 ++ 20:35:16 i.e. people rejecting projects because a 15-people board would be too much in their opinion 20:35:38 we should accept on technical grounds 20:35:47 not because our current membership setup makes it a problem 20:35:51 or reject 20:35:59 yah 20:36:14 so the only way would be to fix the membership BEFORE we discuss those 20:36:18 and they are quickly coming 20:36:27 hence me raising this thread now. 20:37:10 but yeah, I'm fine with someone pushing the alternate option on the thread: "just accept to potentially have a 15-member TC" 20:37:20 I'm still happier to go with (3) now 20:37:25 same 20:37:26 ++ 20:37:29 not convinced this isn't just kicking the can down the road 20:37:53 markmc: of course it is :-) 20:38:05 ok, so if you care and don't like (3), please comment on thread... next topic 20:38:14 #topic Update on the "Future of Incubation / core" joint committee 20:38:24 We had meetings on January 10 and 17... 20:38:27 markmc: quick update ? 20:38:28 well, sometimes the can needs kicking 20:38:31 there's not much to report 20:38:35 2 meetings 20:38:45 both got into discussing "use cases" for OpenStack users 20:38:50 types of OpenStack users 20:39:00 one class are the users of our core APIs 20:39:10 now, I understood the purpose of the discussion was .. 20:39:25 ... to come up with a way of deciding what should be core, based on satisfying the needs of those users 20:39:48 and the other types of users we were considering was for potentially other categories, for other types of trademark programs 20:39:54 so real board territory stuff 20:40:05 (we said we wanted the TC to avoid getting into trademark stuff) 20:40:15 but there was some disagreement about the purpose of the use cases 20:40:20 so ... not sure, really 20:40:27 that was it 20:40:35 #link https://etherpad.openstack.org/IncUp 20:40:43 the consensus still seems to be that 20:40:52 Core vs "Integrated" 20:41:02 hopefully it should start moving forward again this week, or the next 20:41:08 (where "Integrated" is "part of the OpenStack release" may have a different name" 20:41:20 Core is the board's domain, Integrated is the TC's domain 20:41:26 in time for us to be able to tell the incubated projects what they may apply to (or not) 20:42:13 markmc: done ? 20:42:17 yep 20:42:28 OK, since we have a bit of time left... 20:42:32 #topic H name campaigning 20:42:44 So you should all have the link to vote in your email 20:42:58 in the diplomatic tongue of the 19th century 20:43:04 Time to convince people to place your favorites toward the top in the poll 20:43:13 ha, and 17 minutes to do it 20:43:24 Personally I like Havana 20:43:37 I request that Halfway be voted 35th 20:43:43 that's terrible. 20:43:53 russellb: careful what you wish for 20:44:20 :) 20:44:37 Hood is pretty good 20:44:46 because we can talk about features 'in the Hood' 20:45:10 I also like Heppner and Helvetia 20:45:39 a harbor is a safe, calm place. reliable and trusted 20:45:40 Hood is short too 20:45:44 we'll be typing it a lot 20:45:55 helvetia is too close to the font name 20:46:06 notmyname: good point 20:46:13 * ttx downgrades it 20:46:24 Hood! 20:46:24 hood is a mountain in the clouds 20:46:38 mordred: nice 20:46:39 Hamlet is good too. To be or not to be... 20:47:22 isn't mt hood a dormant volcano that may explode and take part of the NW with it? 20:47:33 notmyname: even better 20:48:49 Helix sounds cool http://www.theus50.com/oregon/city.php?cityName=Helix 20:49:35 iccha: it was removed because it's the name of an openstack distro 20:49:43 http://www.opb.org/programs/ofg/segments/view/1260 20:49:57 http://www.morphlabs.com/products/ 20:50:04 ttx: why isnt Helix on the list? 20:50:17 bcwaldon: because "openstack helix" already exists 20:50:19 seems like a good reason 20:50:23 son of a beesting 20:50:26 a shame though, that's a good name 20:50:28 ah darn 20:50:33 yeah, was my favorite 20:50:37 creiht: openstack hell hole? I love it :-) 20:50:40 iccha: +1 for digging it up :) 20:50:58 goes well with some of the other names chosen in the past 20:51:30 * russellb wants to get his feature in the Hell Hole 20:51:35 doesn't have a good ring to it 20:52:22 http://en.wikipedia.org/wiki/File:Mount_Hood_reflected_in_Mirror_Lake,_Oregon.jpg 20:53:09 go Hood 20:53:34 so, please cast your vote before the end of the day, and i'll create the LP poll with the first 4 options we collectively pick, to be started Thursday 20:53:54 and on that note let's close the meeting 20:53:58 #endmeeting