20:03:41 #startmeeting tc 20:03:41 Meeting started Tue Jun 3 20:03:41 2014 UTC and is due to finish in 60 minutes. 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:51 Here is our agenda for today: 20:03:56 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:04:11 the markmcs are coming 20:04:24 #topic Designate incubation request 20:04:33 #link http://lists.openstack.org/pipermail/openstack-tc/2014-May/000679.html 20:04:39 (connectivity may be spotty for me, sorry) 20:04:40 Kiall: o/ 20:04:45 o/ 20:04:47 Hi ttx :) 20:04:51 We have a work document at: 20:04:56 #link https://etherpad.openstack.org/p/DesignateIncubationQ&A 20:05:03 also Kiall just posted a corresponding programs.yaml change at: 20:05:05 Same for me too 20:05:09 #link https://review.openstack.org/#/c/97609/ 20:05:18 So let's work from the etherpad 20:05:50 ttx: should we discuss the program application at the same time? 20:06:01 Should Q's be answered in the etherpad, or here? 20:06:06 devananda: yes 20:06:16 hi 20:06:23 can't really accept one without the other 20:06:57 right 20:07:04 Kiall: i think we should discuss here, and take notes in etherpad 20:07:10 Really I think that we can accept the project and then discuss the home program 20:07:17 there were a few questions posted in the etherpad inline 20:07:19 russellb: OK 20:07:56 markmcclain: the project application includes wording that it should join the designate program. so we can't accept the application as-is without discussing the program as well 20:08:02 someone asked " What is the plan for deprecating DNS support in nova?" 20:08:08 That's me 20:08:08 would the designate team be willing to lead the effort to do that nova work? 20:08:20 it's not going to happen otherwise, i suspect 20:08:26 Okay - mikal: Ideally, nova's in-built DNS features will be deprecated, with a plugin provided to proxy API calls until it can be removed. 20:08:43 Kiall: yes, but who will do that work? 20:08:56 Kiall: I think its a good thing to do, but we need someone to sign up 20:09:01 Kiall: and will you provide an upgrade/migration path? 20:09:02 (see above question, heh) 20:09:17 Kiall: I would be surprised if anyone is using the current DNS support, but we need to treat it like any other deprecated feature 20:09:21 mikal, do you consider it required in order to graduate designate, or ? 20:09:28 mikal: We're (designate-core) happy to take on the work of building the proxy etc 20:09:37 mikal: agreed - I know of nobody actively using the feature. 20:09:47 markmc: i think it fits under our deprecation of duplicated functionality clauses in our requirements 20:09:49 markmc: I think we do need to do this to graduate 20:09:51 Kiall: could you explain why you ended up needing a V2 ? 20:10:14 (mostly curious) 20:10:14 if we think no-one is using it, I think we're doing the process-for-the-sake-of-process thing again 20:10:23 if no-one is using it, deprecate it and later just remove it 20:10:34 markmc: how do we prove no one is using it though? 20:10:42 markmc: I know people who have _wanted_ to use it 20:10:47 i think someone replaced half the etherpad with the letter 'c'. 20:10:48 I'd agree with markmc - if noone is using... 20:10:52 markmc: they might have succeeded without me realizing 20:10:53 ttx: Sure - So we have a few things we wanted to do in V2 - First are foremost was to have an API that didn't allow end-users to violate the DNS RFCs, so it's introduced the RecordSet concept. 20:11:01 jeblair: lol. 20:11:09 mikal, warn in the deprecation notice that it will be removed, wait for someone to scream 20:11:20 ttx / Kiall: can we stay on the nova thing for a bit longer please? 20:11:26 ttx: The second was wanting to have a place to store information related to groups of records for future features such as GeoIP, Weighted round robin etc 20:11:32 jeblair: I trust you'll restore a complete version :) 20:11:45 ttx: i'll try 20:11:45 mikal: Sure 20:11:58 it was sarob 20:12:07 could have him just hit undo ... 20:12:10 mikal: sure -- was just parallelizing 20:12:14 markmc: because users lag trunk, we still risk people discovering their favourite feature is gone ell after its too late 20:12:15 jeblair: there is an admin api query to get the data from an older version 20:12:20 jeblair: you can then splat that in 20:12:37 okay, now all the type just got huge 20:12:40 time slider works too 20:12:41 mikal: designate-core are happy to take on the work of implementing the shim inside of Nova 20:12:41 Kiall: ok, thx! 20:12:44 Sigh 20:12:57 Kiall: that's what I want to hear, and I'm now completely happy with that element 20:13:00 Kiall: thanks 20:13:04 No problem 20:13:13 Is it safe to edit the etherpad to put that there? 20:13:18 if we're going to require deprecation plans as policy when replacing features, we should do that for dns as well. "we dont know if anyone is using it" is not a valid reason 20:13:20 it was already there i thought 20:13:39 russellb: the etherpad keeps changing on me as they revert 20:13:49 yeah ... it *was* there ... 20:13:51 sigh 20:13:55 devananda: agreed, even if there are 0 people using it, the standard policy of removal over several releases should always apply. 20:14:03 devananda:+1 20:14:05 (Yeah, that was the sigh before. Its an etherpad sign, not a designate sigh) 20:14:11 someone is ethertrolling us 20:14:21 ttx or using internet explorer 20:14:53 Okay next Q was: Kiall: could you explain why you ended up needing a V2 ? 20:14:57 Other concerns on the project side ? 20:15:13 So we have a few things we wanted to do in V2 - First are foremost was to have an API that didn't allow end-users to violate the DNS RFCs, so it's introduced the RecordSet concept. 20:15:18 just a general, how would you summarize how the project has evolved and matured since the previous application? 20:15:22 so regardless of the etherpad, comments in looking at designate. Activity and diversity are currently better than 2 of 3 of our incubated projects (only Ironic is higher) 20:15:27 This was very breaking change, so needed a version bump. 20:15:39 The second was wanting to have a place to store information related to groups of records for future features such as GeoIP, Weighted round robin etc - RRSet's give us that place. 20:16:04 For example, RRSet 1 for EU users, RRSet 2 for US users, RRSet 3 for everyone else. 20:16:09 Kiall: makes sense, thx 20:16:12 Kiall: in reading the code this morning, i spotted a few things i consider shortcomings -- it's not using common db code (neither oslo.incubator nor oslo.db), and it's not using alembic yet. also, there are some "objects" that look like a very early version of the nova rpc object code. 20:16:13 in general, things look better all around from what i see so far 20:16:29 Kiall: do you have plans to move to common db code, alembic, etc? 20:16:39 sdague: I believe the biggest thing is more groups and developers involved. 20:16:54 Kiall: actually, that was a compliment :) 20:16:56 does the nova dns code even work? 20:16:58 devananda: Yes - oslo.db is something we haven't had cycles for yet, but ekarlso has been itching to do it :) 20:17:11 you guys are already performing above some of our incubated projects, so that's goodness 20:17:14 I suspect as part of that, we'll move to the oslo migrate code. 20:17:16 vishy: ask the guy who wrote it. Oh wait 20:17:18 vishy: not sure, doubt it 20:17:25 vishy: I had it working a year or so ago 20:17:25 well, I can volunteer to switch to alembic and o.db 20:17:31 Kiall: glad to hear it. ya'll have good integration with many other oslo utils, so that one stood out to me :) 20:17:32 it should be *hopefully* a trivial change... 20:17:34 vishy: I don't know if its drifted since then 20:17:42 ekarlso: famous last words 20:17:48 ekarlso: that would be a graduation requirement, not an incubation prerequisite anyway 20:18:00 indeed 20:18:08 * jaypipes has concerns about designate-core pushing reviews through after legitimate review -1 comments about not having unit tests for added code. 20:18:10 ttx: are these libraries ready yet ? last when I checked they where still in beta ish state ? 20:18:16 what happened? 20:18:25 ekarlso: what ttx said ^ -- I was checking to see where it was on your plans 20:18:32 devananda: ok boss 20:18:32 jaypipes: that is concerning 20:18:44 jaypipes: I do agree, and I know I was among them 20:19:00 and me 20:19:18 so .. why'd you do that? :) 20:19:23 jaypipes: The current method of implementing backends is currently undergoing change, significantly simplifying them, and hopefully making them much easier to test. 20:19:38 or are you saying "yeah we screwed up, we agree, and we'll do better" ? 20:19:42 Our current backends pretty much all lack test - It's literally the biggest gap in out testing. 20:20:03 looks like we identified another key area for improevement 20:20:16 Kiall: understood. It's a concern of mine that sounds like you're aware of it and are tightening your core review requirements, which is great to hear. 20:20:25 jaypipes: you have an assessment of where designate stands on test coverage relative to other projects? 20:20:28 russellb: yes - "yeah we screwed up, we agree, and we'll do better" is accurate 20:20:35 I don't think that's an incubation blocker as long as everyone agrees that was bad practice and will correct it 20:20:36 sdague: no, sorry I do not. 20:20:38 k, fine with me then :) 20:20:43 russellb: and hopefully something the current cycle of changes can improve on 20:20:47 ttx: agreed 20:20:49 ttx: yes, agree completely. 20:20:58 ttx: I was just raising it as a concern I had had. 20:21:01 ttx: agreed, but maybe we need a note to follow-up for the graduation review 20:21:16 jaypipes: I'd be surprised if it wasn't raised :) 20:21:20 jaypipes: thanks for raising it -- I for one did not look deep enough to uncover that 20:21:26 * jaypipes readily acknowledges early Glance review frontiers were similarly gnarly ;) 20:21:26 the devstack job proposed looks like it's sufficient for our incubation threshold. I'd like to see it land and run before we actually vote. 20:21:44 sdague: the same devstack plugin run as a 3rd party test 20:21:46 Kiall: when it lands will you stand down the 3rd party test rig? 20:21:54 Kiall: ah, pointer to results? 20:22:07 Yes, it will be shutdown straight away 20:22:13 wfm 20:22:19 sdague: http://15.126.220.179:8080/job/designate-devstack-mysql/447/ and http://15.126.220.179:8080/job/designate-devstack-postgresql/448/ 20:23:04 Have any Q's been missed? 20:23:08 Kiall: what's the approximate coverage of your API by the proposed tempest tests? 20:23:12 Kiall: I don't think the exercises are actually running there? 20:23:18 devananda: there are not tempest tests 20:23:20 devananda: that's more of a graduation requirement 20:23:22 sdague: so shall we delay until the devstack job is landed ? 20:23:39 sdague: ah ... that explains why i couldn't find it :) 20:23:40 devananda: tempest, last I looked, didn't support plugins and won't accept non-incubated project tests 20:24:00 One of the HP QA guy's has offered to implement tests once they will be accepted. 20:24:08 ttx: we vote offline now right? I'll just put my -1 until we get the job landed 20:24:14 sdague: ok 20:24:15 from what I see, it's all basically there 20:24:24 just want all the parts to come together 20:24:27 OK, let's switch to the program discussion 20:24:31 sdague: the exercises are ran, search for "designate domain-create" in the logs. 20:24:37 I support the creation of a separate program, personally 20:24:38 console logs* 20:24:52 ttx: same here 20:24:54 ttx: +1 20:25:02 since I don't see overlap with the networking/neutron crew 20:25:09 +1 20:25:20 no point in forcing them to live under the same roof and delegate decisions to neutron PTL 20:25:35 neutron has enough to deal with right now, too 20:25:41 Any other questions on the Designate topic ? 20:25:42 neutron doesn't need more meetings 20:25:48 heh 20:25:51 ttx: Agreed, merging of the two teams seems unlikely to succeed in the near team 20:25:55 term* 20:26:12 ttx +1 20:26:16 And - I don't personally believe there is scope overlap between Designate and Neutron. 20:26:28 ttx: +1 20:26:31 Kiall: i agree with that as well 20:26:38 was anyone arguing the opposite? 20:26:40 the closest thing to Designate in OpenStack is actually the Keystone catalog, not Neutron 20:26:50 If no more questions - the concile will retreat and vote on gerrit. Expect white smoke soon 20:26:51 russellb: there was a brief discussion on the ML 20:26:55 dhellmann: OK 20:26:56 honestly, after thinking about it more, I actually think one of the neutron challenges might be that there is too much in that one program. 20:27:02 sdague: +1 20:27:13 sdague: +1 20:27:13 The scope creep is that designate and neutron have L7 services 20:27:35 isn't trove also L7 ? 20:27:56 personally I think designate fits a very sizable hole that we've had for a long time, and am happy to see it coming forward 20:27:57 maybe we should address that by restricting the layers that are part of neutron's scope through a change to the mission statement? 20:28:09 sdague: +1 20:28:21 dhellmann: +1 20:28:30 sdague: it's the last thing the infra team is using proprietary apis for 20:28:41 sdague: the idea has been floated spinning out a few services once the internal apis are fixed 20:28:58 OK, we need to move on 20:29:07 Let the final discussion happen on the review 20:29:17 Thanks all :) 20:29:20 #topic Election stats and review discussion 20:29:29 #link http://lists.openstack.org/pipermail/openstack-tc/2014-May/000678.html 20:29:37 anteaya: want to introduce the topic ? 20:29:40 sure 20:29:48 there are a few more links as well 20:29:51 +1 to writing down some general policy and guidance about this 20:29:53 I'll post them 20:29:58 thanks 20:30:05 the first is the numbers etherpad 20:30:06 #link https://etherpad.openstack.org/p/electoral-discussion-May-2014-numbers 20:30:12 #link https://etherpad.openstack.org/p/electoral-discussion-May-2014-email-summary 20:30:15 it has the history of all of our elections 20:30:38 you can see the ptl elections are healthy with 43% or better participation 20:30:49 the tc elections need some examination 20:31:03 we were at 33% and we are dropping 20:31:10 29.7% last tc election 20:31:17 I disagree wit hno election on Sept 2012 20:31:21 we need a strong participation rate 20:31:30 * ttx digs data 20:31:35 ttx: great, I got that from the wikilinks 20:31:35 BTW it's hard to quantify the effect on average turnout of the uncontested PTL elections 20:31:38 please do update 20:31:47 eglynn: I didn't try 20:32:07 any comments on the numbers? 20:32:10 anteaya: though as you point out, the absolute numbers are increasing 20:32:11 i wonder how well the ATC community understands the role and ongoing activities of the TC? 20:32:13 have I made any errors? 20:32:17 eglynn: +1 20:32:18 agree the low turnout for TC election is concerning 20:32:20 jeblair: yes, they are 20:32:31 if people don't really understand what we do, they're certainly not going to care enough to vote 20:32:33 I think that with a little targeted marketing we could increase turnout 20:32:36 russellb: good point, I have no data on this 20:32:43 TC Sept 2012 election = http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_019fda1f0dd037a2 20:32:54 russellb, or perhaps understand our role, but don't think it's important 20:32:55 anteaya: any data on how the voter turnout % compares to the % of contributors who have done only one patch? 20:32:56 52% 20:33:00 ttx, thank you, I will add after the discussion 20:33:01 markmc: yes or that 20:33:22 I don't see the turnout as a problem with the election, but as a problem with how the TC is perceived in the community, like russellb said 20:33:24 devananda: good question 20:33:28 devananda: I don't have those numbers, but with fungi's help can try to get something next week 20:33:50 zaneb, curious; based on what? gut instinct? anecdotes? own opinion? 20:33:57 we could probably do better with communicating the topics we're working through more broadly 20:34:05 mine is gut instint 20:34:14 I attend the TC meetings, so *I* know what is going on, but I've never seen e.g. an announcement of something that was decided by the TC 20:34:18 ever 20:34:18 I think we engage foundation staff to help raise awareness... The timing in the cycle means it can get lost in shuffle 20:34:25 unless I went looking for it 20:34:28 so.. we used to post summaries 20:34:29 ... anyone else think the staggered terms may be lowering interest/turnout in TC elections? 20:34:31 zaneb, russellb: +1 20:34:41 minutes of the TC meeting to the openstack ML 20:34:44 zaneb: good point, and that's an complaint we had for the board at one point, too 20:34:45 eglynn: we will get to that next 20:34:57 but since we switched to gerrit, there is no more decisions at the meeting 20:34:59 ttx: something less formal than minutes might be better 20:35:00 zaneb: agreed, summaries would be good 20:35:04 would blog posts like my board summaries help, I wonder? summary, with some commentary 20:35:07 i think it's more than minutes that's needed ... but an occasional blog about what we've been covering, and why it's important 20:35:10 markmc: +1 20:35:12 eglynn: I don't feel that the staggered election has any impact on that, but i have no real data on that opinion 20:35:15 markmc: that! 20:35:20 markmc: that! indeed 20:35:20 ttx: it would still be a good idea to publish decisions after they merge 20:35:21 markmc: yeh, definitely 20:35:22 markmc: ++ 20:35:22 markmc: I like your blog posts 20:35:28 markmc: ++ 20:35:29 * ttx delegates markmc 20:35:30 dhellmann: agreed 20:35:31 markmc: +1 20:35:32 heh 20:35:34 uh 20:35:40 in general, people don't know what the TC does, and they don't know who the candidates are outside of their own project 20:35:41 that wasn't me volunteering :) 20:35:42 * russellb thinks ttx should :) 20:35:46 Mr chair 20:36:00 can give it a shot, though 20:36:01 we could do a rotation. I can volunteer to rotate in on the blog posts, if that's ok with folks. 20:36:03 * ttx evacuates chair 20:36:03 maybe we could rotate it 20:36:04 look at the number of ballots where there are only ~5 candidates ranked, for example 20:36:14 should we set up a TC blog for it, so the messages aren't on someone's personal site? 20:36:14 markmc: jinx :) 20:36:14 yeah, rotate is fine with me 20:36:27 dhellmann: yup, that works. 20:36:28 in theory there is an openstack blog ... 20:36:30 right? 20:36:33 anteaya: i can imagine a two-dimensional plot of voter turnout vs. commits 20:36:36 dhellmann: or we could post to the openstack blog 20:36:38 russellb, the chair already has a lot to do ... 20:36:39 www.openstack.org/blog/ 20:36:42 fungi: awesome, thank you 20:36:43 markmc: true 20:36:52 ttx: that works, too 20:36:59 anteaya: it would be interesting to see stats on how many candidates get ranked on how many ballots 20:37:01 a blog is fine, but this should also go to the dev list i think 20:37:09 dhellmann: that would help giving that post visibility 20:37:10 jeblair: +1 20:37:11 jeblair: agreed 20:37:14 jeblair, yes 20:37:22 zaneb: I think that is something ttx likes to do up, when he has the time to do the math 20:37:44 jeblair: although we already have problems with people missing messages on the list, so I think we should do both 20:37:51 I still don't think that blogging actually fixes the problem... I think that the election itself needs more awareness 20:37:52 zaneb: so is that an issue in the fact that our community is large enough that people have no familiarity beyond their projects? 20:37:52 dhellmann: wfm 20:38:06 is our governance repository being published somewhere as html, yet? 20:38:09 fungi: we'll have to look te details of giving TC members an author account on that wordpress 20:38:10 sdague: that's another thing 20:38:21 but we could address that with some more Q&A stuff in the election 20:38:26 markmcclain: how would you address that? 20:38:27 sdague: I think you're onto another reason here. 20:38:35 it's time for our openstack foreign exchange program 20:38:40 anteaya: I'll redo my analysis soon 20:38:42 I'm open to that 20:38:51 OK so... actions 20:38:53 ttx great, it will be an awesome blog post 20:38:57 how about an election debate? 20:38:58 ttx: yeah, i'm not real familiar with how it's currently configured 20:39:01 dhellmann: it's not yet being published 20:39:05 markmc: yeah, pretty much 20:39:10 #action ttx to redo election analysis for last round 20:39:20 markmc: or at least a bit more prompting of candidates to dig into key issues 20:39:22 more than just our election platforms 20:39:27 but make us debate some difficult issues 20:39:28 sdague: it's an issue if the projects are becoming siloed and nobody ever hears anything from outside their own project, and in particular from the TC 20:39:29 #action ttx/fungi to sort out publication of TC blogposts to www.o.o 20:39:30 markmc: I like the idea of a debate 20:39:31 ask people to submit questions 20:39:44 markmc: +1 20:39:57 #action TC members to rotate writing blogposts reporting on TC decisions 20:40:10 anteaya: I kind of don't 20:40:19 mikal: okay, why? 20:40:23 anteaya: it seems too confrontational for a body that attempts concensus 20:40:30 fair enough 20:40:33 yeh, I have the same concerns as mikal on that 20:40:34 anteaya: it also presumes that we disagree on things, which often, we dont 20:40:38 anteaya: I know its playing with words, but I think a panel works better for us 20:40:41 but isn't that based on the style it is moderated? 20:40:41 mikal, stuff needs to be debated to reach consensus 20:40:46 anteaya: and we've done at least two of those in the past 20:40:48 also debates are better geared toward small numbers of candidates in an election 20:40:52 dhellman: I think we can target atcs w candidate profiles and look into ways to remind folks who haven't cast ballots 20:41:01 i think we should expect and require a more in depth post than just "i want to run for the TC and ... well you all know me so thanks!" 20:41:02 I do like the idea of having some questions to address in nomination messages. 20:41:11 mikal: oh have we? this I didn't know 20:41:21 anteaya: the last two summits at the least 20:41:21 mikal: how can I access the history 20:41:23 russellb: +1 20:41:32 a debate at teh summits? 20:41:34 anteaya: I don't think they were recorded, although perhaps HK was 20:41:37 what about a curated list of community-submitted questions, geared to give the projects' members a way to express their concerns for cross-project issues and find out the candidate's views? 20:41:41 anteaya: the panel at the summit 20:41:43 anteaya: a "meet the TC" panel discussion 20:41:50 panel isn't really related to the election ... 20:41:51 yes, yes the panel 20:41:51 yeah, HK panel was recorded 20:41:53 I think one of the reasons why there isn't so much debate is that the TC election happens at a busy time 20:41:54 mikal: I didn't really view that as a debate, though 20:41:54 devananda: I like that. 20:41:57 I think the panel was great 20:42:17 dhellmann: sure... I'm mooting that its better than a debate, not a debate itself 20:42:18 devananda: Perhaps summaries of the answers can form part of the candidates' platform? 20:42:22 devananda: +1 20:42:31 mikal: ah, I misread 20:42:49 anteaya: how about, at hte same time we do self-nominations of candidates, people can post questions that every candidate will have to answer ? 20:42:53 * jaypipes doesn't remember seeing any posts with "well you all kow me, so thanks..." 20:42:54 mikal: but it doesn't give voice for people not on the tc 20:42:54 I do think more depth in nomination emails is a good idea 20:43:02 ttx: with some reasonable limit 20:43:04 Or at least _some_ discussion in their threads after annuncement 20:43:09 ttx: I like having everyone post, and someone curating 20:43:21 russellb: sure - election officials can make a final list of questions 20:43:29 wfm 20:43:30 ttx yes something like that, but I picture me chasing folks for answers 20:43:30 anteaya: were there other issues related to elections you wanted to raise? 20:43:31 ttx: ++ 20:43:36 so I would like something real time 20:43:38 that will trigger interest and participatio 20:43:40 so there is an end 20:43:51 anteaya: no, you don't chase -- you just mark them as not responsive 20:43:53 anteaya: it would be up to candidates to respond in their nomination email, right? 20:43:54 anteaya: if people don't answer, it will look bad and hopefully they will not receive as many votes 20:43:56 i think we've identified some good ideas to run with, should we jump to other parts of this topic? 20:44:06 dhellmann: yes 20:44:15 #action election officials to call for questions at the same time they call for self-nominations, and curate a list of questions candidates will answer 20:44:28 other parts 20:44:34 i think there's some timing logistics there to work out, but we can figure it out later 20:44:37 let's look at the email summary: https://etherpad.openstack.org/p/electoral-discussion-May-2014-email-summary 20:44:39 jeblair: agreed 20:44:47 let's start with item two 20:44:59 needed some messaging around campaigning 20:45:02 line 70 20:45:10 since we seem to have some ideas for item one so far 20:45:25 anteaya, when you say messaging, you mean some sort of code of conduct right ? 20:45:33 markmc: sure that is a good term 20:45:36 i.e. how we expect people to campaign 20:45:40 expectations of behaviour 20:45:42 yes exactly 20:45:52 (was just confused at first, "we need more messaging" == "we need more campaigning") 20:45:56 there were some questions I couldn't answer this last election 20:46:01 I think recommending campaigning in the open is a good idea 20:46:03 (though we do have a code of conduct, so that could be confusing http://www.openstack.org/legal/community-code-of-conduct/ ) 20:46:13 and some people didn't know if they should report things or not, so nothing got reported 20:46:22 folks, including me, should know what is expected 20:46:29 anteaya: i think all of your suggestions are in the spirit of the code of conduct, which is nice. i think they are good suggestions. 20:46:32 It should be open methods which is not covered by code 20:46:45 jeblair, anteaya : +1 20:47:07 yeah, a code should include how to deal with reports of abuse 20:47:09 note the code of conduct does mention elections specifically in at least one point: 20:47:10 Respect the election process. Members should not attempt to manipulate election results. Open debate is welcome, but vote trading, ballot stuffing and other forms of abuse are not acceptable. 20:47:15 anteaya: how about you draft a election expectations of behavior, and propose it as a resolution on gerrit ? 20:47:19 do we just want to expand the repect elections part of code of conduct? 20:47:24 we can iterate on wording there 20:47:28 markmc: thank you, yes, that is what this is aiming for 20:47:49 ttx I can do that 20:47:53 what directory? 20:48:06 i believe CoC violations are grounds for termination of membership status which means no voting or running in elections 20:48:09 #action anteaya to propose a resolution on election expectations of behavior 20:48:13 sdague: the existing code of conduct appears to be an appendix of the bylaws; would we need the board to change that? 20:48:14 changing http://www.openstack.org/legal/community-code-of-conduct/ will mean a wider debate 20:48:19 since it applies to board of director elections 20:48:25 slightly different values may apply? 20:48:29 (debatable) 20:48:30 ok, fair 20:48:32 anteaya: that would end under resolutions/ in the governance repo 20:48:39 right, I think we can start with some focus on the PTL and TC elections and possibly move it to the CoC later 20:48:40 jeblair: I didn't know that was there, so perhaps I am failing in my role as election official 20:48:53 dhellmann: sounds reasonable 20:48:53 dhellmann: that sounds like a good strategy 20:48:58 +1 20:49:01 dhellmann: ^ 20:49:05 ttx I will head for resolutions 20:49:09 anteaya: I wuld definitely mention the CoC in that "behavior reminder" 20:49:15 +1 20:49:29 great I will mention 20:49:34 OK, we need to move on - anything else on that topic ? 20:49:40 thanks all 20:49:40 I think we captured a number of actions 20:50:36 anteaya: thanks for raising that topic! 20:50:41 yep, good one 20:50:50 #topic Incubation/Integration requirements 20:50:51 * anteaya nods gratefully 20:50:59 * Add Ceilometer requirements (https://review.openstack.org/85978) 20:51:23 looks like we have a winner here 20:51:36 \o/ 20:51:50 * ttx +2s 20:52:33 * add upgrade expectations (https://review.openstack.org/87234) 20:53:14 we've been beating on this for a while 20:53:17 heh, so we actually tried to go folksy with examples intentionaly 20:53:19 there is a -1 from russellb ... sdague do you stand by your current version, or plan to address them ? 20:54:02 Since this change affects the consensual reqiurements, we need consensus on that one 20:54:09 ttx: I think there are some nits from eglynn that are fixable, but I really don't think spinning back around to writing code in english for our test conditions is a good tact 20:54:27 that was actually what we were trying to get away from 20:54:30 russellb: as I read that section (within points in master) it would be fine for a project to require a series of upgrades 20:54:32 (this document reflects the basic requirements we all agree on, everything else is covered by our vote) 20:54:46 devananda: fair point 20:54:50 let's just follow up on gerrit 20:54:52 the commits in master are in master where people do assume it's newer than stable branch 20:55:19 OK, i'll approve when it gets 7+ +1s and has no more -1s 20:55:49 #topic Housekeeping changes 20:56:12 A little ton of trivial changes which I'll directly approve asap 20:56:23 * Add project mission statement for Ceilometer (https://review.openstack.org/87526) 20:56:50 being the only exception I think 20:57:05 but that one has enough +1s 20:57:14 the others are: 20:57:20 * Add cinder-specs to block storage program (https://review.openstack.org/95893) 20:57:26 * Add swift-specs to object storage program (https://review.openstack.org/95895) 20:57:30 * Add sahara-specs to data processing program (https://review.openstack.org/95897) 20:57:36 * Add keystone-specs to identity program (https://review.openstack.org/95891) 20:57:42 * Add ceilometer-specs to telemetry program (https://review.openstack.org/95890) 20:57:46 * Add ironic-specs to bare metal program (https://review.openstack.org/95892) 20:57:52 * Add glance-specs to image service program (https://review.openstack.org/95898) 20:58:01 * Add tripleo-specs to tripleo program (https://review.openstack.org/95888) 20:58:05 * Add heat-specs to orchestration program (https://review.openstack.org/95889) 20:58:13 #topic Open discussion 20:58:20 mordred: I don't think you worked on the draft binary proposal for the "TC direction" column scores ? 20:58:31 I'm glad to see concensus on the ceilometer mission statement -- thanks to eglynn and jogo for discussing that with me several times 20:58:38 in other news I submitted our proposed K names to the cursory name collision review 20:58:39 devananda: +1 20:58:42 I should be able to start the public poll soon 20:58:45 SergeyLukjanov: thanks for making all of those changes and dealing with all those details 20:58:50 Anything else, anyone ? 20:58:54 ttx: glance catalog mission should make it to next week right? 20:58:57 ttx: i will be out next week 20:59:07 markwash: yep, it's on the backlog 20:59:19 ttx: should i note that in the wiki, send an email to the tc list, and nominate a proxy? 20:59:47 jeblair: am confused. what will be out next week? 21:00:05 ttx: (i'll be in the wilderness for a week and might miss a vote) 21:00:06 oh. you 21:00:27 they don't have gerrit where i'm going 21:00:29 jeblair: wiki, + optionally name a proxy 21:00:42 just a reminder: there's a DefCore meeting tomorrow at 2100 UTC (this exact time), mikal is attending but wanted to advise the TC too. Agneda: https://etherpad.openstack.org/p/DefCoreLighthouse.2 21:00:47 jeblair: we can totally install a gerrit out there 21:00:57 i'll make sure to vote on everything pending 21:00:57 jeblair: although proxy less necessary with our gerrit based voting 21:01:31 ttx: it's now through the end of next week so if something came up quickly, it could happen 21:01:49 #action mordred still to prepare draft binary proposal for the "TC direction" column scores 21:02:05 OK, time is up 21:02:15 #info DefCore meeting tomorrow at 2100 UTC (this exact time), mikal is attending but wanted to advise the TC too. Agneda: https://etherpad.openstack.org/p/DefCoreLighthouse.2 21:02:25 #endmeeting