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