20:03:13 <ttx> #startmeeting tc
20:03:14 <openstack> Meeting started Tue Jun 17 20:03:13 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:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:17 <openstack> The meeting name has been set to 'tc'
20:03:22 <ttx> Agenda for today:
20:03:32 <vishy> o/
20:03:43 <anteaya> jgriffith: ping
20:03:47 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:50 <ttx> NB: Agenda was a bit too busy so I pushed back Glance gap coverage plan to next week, with markwash's blessing
20:03:59 <ttx> #topic Use of the word "certified"
20:04:01 <markmcclain> o/
20:04:07 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036933.html
20:04:14 * zehicle making some popcorn for this one
20:04:17 <ttx> I think that thread reached conclusion that using "tested" or "CI tested" would be more accurate.
20:04:27 <anteaya> that was my take on it as well
20:04:34 <ttx> anteaya: Not sure we need to discuss that any further, unless a specific outcome is desired and not obtained yet ?
20:04:50 <anteaya> well just to support cinder in their deprecation of using the word
20:04:54 <anteaya> if they require that
20:05:08 <anteaya> the mostly needed to ensure the topic got airtime on the ml, which it did
20:05:27 <ttx> jgriffith: your last post seems to agree to phase out "certified" in favor of some variation of "tested"
20:05:28 <jgriffith> anteaya: there's only a handful of folks that cared, but they're willing to yield
20:05:46 <anteaya> jgriffith: hey
20:05:50 <ttx> ok, so I don't think we have a problem left to solve
20:05:54 <anteaya> no
20:05:58 <jgriffith> ttx: nope
20:06:00 <annegentle> agreed
20:06:03 <russellb> great, thanks jgriffith
20:06:03 <markmc> agree
20:06:05 <jgriffith> ttx: I'll play along
20:06:07 <anteaya> jgriffith: did you need any support for transition?
20:06:09 <markmc> nice consensus reaching thread :)
20:06:13 <jgriffith> anteaya: nah
20:06:14 <russellb> markmc: +1
20:06:15 <jgriffith> thanks though
20:06:16 <anteaya> k
20:06:27 <anteaya> so I'm done on this one
20:06:34 <ttx> #agreed Cinder will phase out use of term "certified" for some variation around "tested" that is not as heavily loaded
20:06:53 <ttx> next topic, then!
20:06:55 <ttx> #topic Review j-1 progress on gap covering plans
20:07:20 <ttx> When we did the gap coverage plans we said we'd go back and check that everything goes as planned, after each milestone
20:07:32 <ttx> So I used the 1:1 syncs today to get a picture of progress in gap coverage plans
20:07:48 <ttx> i'll report on behalf of al PTLs now
20:08:00 <ttx> although those that are around should feel free to correct me
20:08:06 <ttx> * Ceilometer (https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage)
20:08:14 <ttx> #info Ceilometer is on track, still targeting j2 for fully covering the gap
20:08:27 <ttx> * Horizon (https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage)
20:08:37 <mordred> o/
20:08:41 <ttx> #info Mostly on track. Horizon mission statement is late, but that should be a quick one
20:08:52 <ttx> * Neutron (https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage)
20:09:03 <ttx> #info Neutron: Work on all gaps has started. Gap 4 is a bit late (was planned for j1), but it's also been determined to just be one API call. Overall, still on track.
20:09:27 <ttx> markmcclain: feel free to comment on that one from your first-hand perspective
20:09:38 <ttx> * Trove (https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Trove_Gap_Coverage)
20:09:43 <ttx> #info Trove coverage plan is on track, work started on all items
20:09:50 <ttx> More details available in the ptl_sync logs:
20:10:07 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-06-17-08.00.html
20:10:22 <markmcclain> ttx: correct… in aggregate we're still on target just a few items that are ahead/behind schedule
20:10:25 <sdague> Neutron Gap 2 I remain concerned on, as we don't yet have neutron -> neutron upgrade, so n-net -> neutron probably is not possible in the next 5 weeks
20:10:32 <ttx> So overall I was pleased to see that most gaps were in progress
20:11:02 <markmcclain> sdague: I expect that finalizing gap0 should make the fix for 2 quick
20:11:06 <russellb> sdague: yeah, i was wondering how the upgrade procedure was coming ... hadn't seen anything
20:11:34 <russellb> n-net -> neutron in particular
20:12:05 <markmcclain> russellb: there is WIP code for n-net -> neutron
20:12:14 <markmcclain> doesn't handle sec groups yet
20:12:16 <russellb> cool, good to hear.
20:12:43 <ttx> All the gap work seems to be priotized correctly, even if some work takes longer than hoped (as always)
20:12:52 <ttx> +ri
20:13:00 <markmcclain> #link https://review.openstack.org/#/c/100265 n-net ext
20:13:14 <ttx> Other questions on that?
20:13:49 <ttx> I think juno-2 objectives will be a lot harder to meet
20:13:53 <ttx> and will be the real test
20:13:56 <sdague> agreed
20:13:58 <jogo> a reliable open source default driver isn't on the neutron gap list?
20:14:01 <sdague> good checkpoint though
20:14:03 <markmcclain> ttx: +1
20:14:08 <ttx> because a lot of the gap work is being targeted at it
20:14:14 <annegentle> ttx: for https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage#Gap_3:_Document_Gaps_between_Horizon_and_CLIs could David update with links to the wiki pages ongoing?
20:14:30 <markmcclain> jogo: the default driver is ML2 and we have several folks working to improve it
20:14:48 <jogo> markmcclain: ack, just thought that would be on the gap coverage list
20:14:54 <ttx> annegentle: david-lyle is in vacation at the moment, so I didn't push too much on his substitutes
20:15:10 <ttx> annegentle: we can certainly ask for more details when he is back (next week)
20:15:19 <annegentle> got it
20:15:20 <annegentle> thanks
20:16:00 <ttx> #topic Defcore update: Swift designated sections & capabilities score process
20:16:07 <ttx> zehicle: o/
20:16:12 <ttx> #link https://etherpad.openstack.org/p/DefCoreLighthouse.F2F
20:16:32 <zehicle> o/
20:16:35 <ttx> zehicle: floor is yours
20:16:40 <zehicle> thanks!
20:16:53 <zehicle> a few topics to cover from our last DefCore meeting
20:17:18 <zehicle> will dig up link to minutes
20:17:20 <ttx> zehicle: as an aside, I don't think mordred made progress on the scoring proposal, so if it's still needed, we might want to find another volunteer to drive that
20:17:30 <notmyname> ..???..
20:17:38 <zehicle> items 1) timing, 2) designated sections for swift 3) process for core
20:17:40 * notmyname just saw "swift" mentioned
20:17:42 <mordred> yeah - sorry, my schedule totally fell apart
20:17:53 <ttx> notmyname: I confirm, it was mentioned.
20:18:06 <zehicle> we did a pass to complete the unscored items (object was the only one left)
20:18:20 <zehicle> since we're there, we can do #2 first
20:18:26 <ttx> mordred: not blaming you, I couldn't have done it if I had it assigned to me either :)
20:18:51 <zehicle> our scores had 2 capabilities in swift as core and a few as close but not in
20:19:31 <zehicle> hmmm....
20:19:34 <markmc> ok, well we've lost our chair
20:19:41 <anteaya> I'm listening
20:19:42 <mikal> Sigh
20:19:48 <zehicle> turned out to be pretty easy to score - NOTE, there's still a question about IF the capabilities need to change
20:19:53 <zehicle> but that's ok for now
20:20:26 <markmcclain> did we lose our quorum too?
20:20:27 <markmc> #link http://lists.openstack.org/pipermail/defcore-committee/2014-May/thread.html#173 <- some context
20:20:51 <anteaya> we are still logged
20:20:51 <dhellmann> should we call role again or something? I can't tell who's still here
20:21:03 <russellb> we're back!
20:21:03 <ttx> ah.
20:21:06 <ttx> ok, we are back
20:21:06 <sdague> :)
20:21:12 <annegentle> welcome back!
20:21:17 <ttx> that was the shortest netsplit in history
20:21:18 <zehicle> https://etherpad.openstack.org/p/DefCoreLighthouse.F2F
20:21:22 <zehicle> #link https://etherpad.openstack.org/p/DefCoreLighthouse.F2F
20:21:25 <markmc> <zehicle> turned out to be pretty easy to score - NOTE, there's still a question about IF the capabilities need to change
20:21:25 <markmc> <-- sombrafam has quit (Quit: Connection closed for inactivity)
20:21:25 <markmc> <zehicle> but that's ok for now
20:21:30 <markmc> that's all you missed
20:21:38 <zehicle> right now, the DefCore committee has the position that these capabilities SHOULD BE Core
20:22:10 <zehicle> however, there's a problem with in field implementations of designated sections if Swift is 100% designated
20:22:12 <dhellmann> zehicle: you mentioned 2 groups of capabilities, which do you mean?
20:22:32 <zehicle> dhellman_, must-pass (core) and the rest
20:22:39 <dhellmann> ok
20:22:43 <zehicle> in the rest, there are some that are clearly out and some are on the bubble
20:22:53 <zehicle> the other capabilities for Swift were "on the bubble"
20:23:05 <markmc> #link https://docs.google.com/spreadsheet/ccc?key=0Av62KoL8f9kAdFo4V1ZLUFM0OHlrRnFpQUkxSHJ5QWc&usp=drive_web#gid=6
20:23:15 * zehicle reminds everyone that this is subject to review
20:23:23 <dhellmann> I see objectstore-container and objectstore-object as scoring green
20:23:34 <zehicle> we're happy to discuss scores, but we will make best effort to keep this moving
20:23:47 <zehicle> dhellman_, yes, those did not chnage
20:23:48 <dhellmann> yeah, I'm just trying to make sure I understand what all the pronouns mean :-)
20:23:58 <zehicle> no worries, I want to be clear
20:24:11 <ttx> zehicle: so what do you need from us? You still need clarification on those 0.5 scores in TC direction, right
20:24:23 <zehicle> so we're asking the TC to move forward on designated sections for swift
20:24:49 <zehicle> BUT if you say 100% then we will have to re-evaluate the 2 core designations
20:24:57 <mikal> I still need to ask the other projects for their designated sections as well, I lost my way on that last week
20:25:02 * ttx would like to hear notmyname's opinion on it first
20:25:08 <zehicle> ttx, yes we are still asking TC to resolve the .5s
20:25:10 <russellb> ttx: +1
20:25:18 <mordred> ++
20:25:32 <zehicle> ttx, it's not blocking us since we did not think it would swing any capabilities into other sections
20:25:33 <markmc> totally
20:25:38 <notmyname> umm..I'm missing a lot of context here. (and I have another meeting in 5 minutes)
20:25:56 <zehicle> ttx, we were NOT trying to close the issue here.  just bring it to the TC so you had the ball
20:26:08 <ttx> OK, I'll take the action to reach to notmyname when we both have more time
20:26:14 <markmc> thanks ttx
20:26:22 <zehicle> and understood DefCore would have to response if the answer if 100%
20:26:31 <notmyname> what happened to the core capabilities list I sent to the defcore list? also, i've never said anything about 100% of Swift being "designated sections". in fact I've been very clear on the opposite, both in-person and from conference stages
20:26:40 <zehicle> I'm happy to be a resource for that discussion as needed
20:26:46 <notmyname> also, Ihave no idea where a score of "83" comes from
20:27:00 <markmc> zehicle, what's this about?
20:27:00 * markmc > Rob to take to TC that if Swift has any designated sections then the DefCore committee will likely recommending omitting the "object-*" capabilities from core.
20:27:02 <zehicle> notmyname, that needs further review & discussion w/ Troy
20:27:15 <zehicle> yy
20:27:26 <zehicle> markmc, that's exactly this topic
20:27:46 <russellb> basically, you need the designated sections opinion from our side on swift
20:27:48 <russellb> and then we go from there
20:28:00 <zehicle> russellb, yes.  exactly
20:28:01 <russellb> and to get that, ttx will sync with notmyname later
20:28:02 <markmc> if the TC says swift has designated sections, the defcore committee will remove all swift capabilities from core?
20:28:06 <dhellmann> It sounds like defcore is saying if we call any of swift designated, they're just going to remove the capabilities. Is that right, or am I reading too much into this?
20:28:08 <ttx> zehicle: so if swift is not 100% designated, it's out of core capabilities ? Bit confursed too
20:28:18 <zehicle> markmc, depends on how the opinion comes out
20:28:30 <markmc> zehicle, I don't understand the logic behind it
20:28:31 <zehicle> ttx, the opposite
20:29:03 <ttx> "if Swift has any designated sections then the DefCore committee will likely recommending omitting the "object-*" capabilities from core"
20:29:03 <dhellmann> I think I'd like to see some of that discussion written up then, because we shouldn't be making technical decisions about what we designate as core to change the capabilities list. That' *EXACTLY* why we split those 2 decisions in the first place.
20:29:05 <zehicle> in DefCore, concerns were raise that if Swift has core capabilities AND is 100% designated then it creates issues for implmentations
20:29:07 <sdague> zehicle: I'm sufficiently confused. Can you restate the thing that needs a decision?
20:29:16 <markmc> "defcore committee thinks swift should capabilities should not be required in openstack clouds"
20:29:22 <russellb> zehicle: but nobody has said 100%
20:29:27 <markmc> "if the TC thinks swift code should be required, ..."
20:29:28 <russellb> and notmyname just said that's not his opinion either
20:29:29 * markmc still lost
20:29:39 <zehicle> We do think Swift capablities are required
20:29:43 <markmc> (to be clear - the quotes are me trying to paraphrase)
20:29:50 <zehicle> that's why 2 of them are in the core list
20:29:52 <mordred> right. I think we're talking about a hypotehtical which we've already disproven
20:29:57 <russellb> mordred: yes.
20:29:58 <markmc> zehicle, then why say you'll remove them if there are designated sections?
20:29:58 <dhellmann> notmyname: do you have anything written about designated sections for swift?
20:30:00 <zehicle> BUT we have a challenge if the code is 100% designated
20:30:06 <mordred> let's stop talking about that
20:30:08 <russellb> zehicle: but it's not
20:30:10 <mordred> it's a non issue
20:30:14 <mordred> so let's move on
20:30:14 <ttx> zehicle: ok
20:30:28 <zehicle> yes, I'm ok to move on.
20:30:30 <notmyname> dhellmann: I emailed a rough draft to defcore I think. zehicle has a copy of what I sent
20:30:37 * notmyname has to leave
20:30:39 <dhellmann> notmyname: ok, thanks, I'll look at the list archives
20:30:41 <russellb> notmyname: thanks
20:30:42 * mordred waves at notmyname
20:31:00 <ttx> #action ttx to reach to notmyname to get proposed designated sections
20:31:15 * zehicle knows that this is a difficult topic.  trying to break it into smaller pieces for discussion
20:31:19 <ttx> zehicle: you still that that 0.5 scoring clarified, right ?
20:31:20 <markmc> the list notmyname sent was capabilities, not designated sections
20:31:25 <markmc> (to be clear)
20:31:26 <zehicle> yes, that will help
20:31:52 <zehicle> we're trying to have community input meetings last week of June
20:31:55 <dhellmann> markmc: ok, so it sounds like we still need a discussion about designated sections
20:31:57 <ttx> TC: do we have a new volunteer to propose a scoring to the governance repo for us to iterate on ?
20:32:08 <zehicle> Matrix input from Community (2 meetings 25 & 26 of June)
20:32:15 <markmc> dhellman, right
20:32:23 <zehicle> it would be good to have all 0 or 1 before those meetings
20:32:40 <zehicle> and we'll use that as the basis for Icehouse scoring
20:32:52 <ttx> ok, so we really need a volunteer now :)
20:33:04 <markmc> "DefCore agrees that the TC is the deciding body for designated sections."
20:33:10 * markmc thinks that's just plain wrong
20:33:21 <markmc> it's a TM policy issue, the board is the deciding body
20:33:33 <mordred> markmc: I disagree
20:33:33 <russellb> markmc: +1
20:33:41 <annegentle> heh
20:33:42 <mordred> the board is the deciding body for the TM issues
20:33:48 <markmc> and it is a TM issue
20:33:50 <mordred> I do NOT want the board deciding designated sections
20:33:53 <ttx> markmc: I think we propose designated sections (actually, we make sure PTLs propose them)
20:33:55 <mordred> because that's a code org issue
20:34:01 <zehicle> markmc, happy to discuss more but that position is a surprise given pass dialogs
20:34:02 <ttx> then the BoD does what it wants with them
20:34:04 <dhellmann> "deciding body" seems strong, but I thought they were asking us to help figure out what parts of the code shouldn't be swapped out
20:34:11 <mordred> I don't want eileen, for instance, making decisions on which chunks of code do anything
20:34:13 <markmc> mordred, the choice of which ones required is the TM policy issue
20:34:14 <mikal> ttx: that's a thing I am meant to be working on but haven't progresses as much as I should
20:34:26 <mikal> I'm drafting something for the TC to take to PTLs requesting designated sections
20:34:27 <markmc> mordred, what the list of potential required sections are can be something the TC produces
20:34:35 <mordred> markmc: the choice of technical communities intent for how the code works and is used is us
20:34:40 <ttx> mikal: think you can have a try at it ?
20:34:52 <mikal> ttx: I have a draft, its lacking some detail though
20:34:57 <mikal> I can upload a WIP now if you want me to
20:35:09 <ttx> markmc: the BoD still very much has control over what it does with designated sections and whether it applies them to trademark rules
20:35:09 <markmc> dhellman, right
20:35:16 <mordred> ttx: ++
20:35:18 <zehicle> I don't think the Board is the right agency to pick code sections, unless you want us to say 0% (Apache style)
20:35:28 <ttx> so we are the deciding body on a technical input
20:35:32 <markmc> ok, we're just mixed up on terminology
20:35:36 <mordred> I think ttx sums up my view
20:35:38 <markmc> AIUI "designated" means "required"
20:35:39 <ttx> which they use or not use in trademark rules
20:35:50 <zehicle> Board does pick required capabilities as defined by tests
20:35:53 <dhellmann> yeah, is "deciding body" some magical legalese, or does it just mean "the TC is going to tell us"
20:35:58 <markmc> you guys are saying "designated" is "sections the board can choose to require"
20:36:09 <mordred> dhellmann: none of these words ACTUALLY have meaning - just the ones we've invented
20:36:09 <ttx> dhellman_: my understanding is 'the TC will tell us"
20:36:15 <zehicle> We're trying to document that at the bottom of that page, the bylaws changes "in plain english" section
20:36:20 <dhellmann> markmc: right, the intersection of code (TC) and capabilties (board)
20:36:38 <zehicle> dhellman +1
20:36:40 <dhellmann> mordred: no wonder we have so much trouble talking about this :-)
20:36:44 <mordred> the TC picks the sections. the board can use or not use that information to inform its choice of capabilities
20:36:55 <mordred> the sections are only an input into a decision matrix
20:37:00 <mordred> so the sections ARE 100% us
20:37:05 <dhellmann> mordred: yes, except I am a little surprised to hear the thing about swift
20:37:12 <mordred> but their application towards trademark policy is the board
20:37:14 <dhellmann> well, a *very* little surprised
20:37:25 <markmc> right and the sections the board chooses are called "designated sections"
20:37:29 <markmc> no the list the TC picks
20:37:31 <mordred> no
20:37:31 <markmc> not
20:37:38 <mikal> ttx: https://review.openstack.org/#/c/100675/ is what I have so far
20:37:40 <mordred> the board does not pick sections
20:37:44 <mordred> the board picks capabilities
20:37:53 <mordred> sections are a way to help choose capabilities
20:37:55 <zehicle> clearly, this has not reached the level of clarity I'd hoped.  My appologies
20:37:59 <markmc> so the board takes our list of designated sections, or throws it away
20:38:04 <mordred> the board takes it
20:38:06 <markmc> binary? no selective choosing from our list?
20:38:07 <mordred> it is input
20:38:13 <mordred> to the list of capabilites
20:38:25 <markmc> it's totally separate from the list of capabilities!
20:38:32 <zehicle> mordred, yes but there's a nuance because we expect the capabilities to be defined by the projects
20:38:38 <markmc> TM requirements are capabilities + designated sections
20:38:40 <markmc> AIUI
20:38:40 <ttx> mikal: that's designated sections -- I'm looking for a volunteer to push scoring proposals for the "Tc direction" column
20:38:44 <zehicle> The board is really picking WHICH ones are core
20:38:44 <dhellmann> markmc: if the board sees that a capability is defined by a section of code we're not designating, then it won't be a core capability. And vice versa.
20:38:53 <ttx> mikal: I think you have enough on your plate with that first one
20:39:00 <mikal> ttx: ahhh, ok. We're talking about different things then
20:39:09 <mikal> ttx: agreed, I think the designated section thing shows I'm too busy at the moment
20:39:22 <markmc> dhellman, oooh, I don't think so ...
20:39:23 <mordred> ok. I'm three seconds from ragequitting my fourth thing of the day. the complexity of what we're working on to decide which things we make people can ignore is mind boggling
20:39:32 <mordred> we make software
20:39:32 <zehicle> dhellman_, if the code's not designated but the capability is core that's OK
20:39:36 <markmc> dhellmann, AIUI capabilities can be required even if the code isn't a designated section
20:39:37 <mordred> people shold be lining up at the door to use it
20:39:41 <dhellmann> zehicle: that makes no sense at all
20:39:49 <markmc> dhellmann, which I think is behind this statement about swift
20:39:54 <mordred> and we should stop spending so much time working on giving them lists of stuff they can ignore
20:39:56 <mordred> BUT
20:39:59 <mordred> if we're going to do that
20:40:04 <zehicle> it just means that the vendor can substitute
20:40:06 <mordred> then the parts related to CODE should be from us
20:40:10 <dhellmann> how can the board require a deployer to use code the technical community won't stand behind, or thinks should be swapped out with a driver?
20:40:40 <dhellmann> "an OpenStack cloud must do this thing we're not going to give you supported code to do"? that's odd.
20:40:41 <mordred> dhellmann: the board isnt' looking to reuqire extra things. it's looking to let people use the openstack name even if they don't use stuff we like
20:40:41 <markmc> it would be foolish to do so, but they are the final deciding body on trademark requirements
20:40:49 <russellb> mordred: i certainly can relate to your sentiment about the complexity of all this ...
20:40:54 <mordred> bceause there are people with vested interests in being allowed to do that
20:40:55 <zehicle> I'm thinking a single topic meeting may be in order.  I think the context of this is getting lost
20:41:32 <mordred> whereas all of us here actually just want people to use the lovely code we're writing them and are confused as to why people want to be able to delete some of it
20:41:33 <zehicle> we specifically do NOT want the board adding extra stuff.
20:41:35 <markmcclain> I'm still wondering why this is so hard… can we not split the question?
20:41:50 <markmc> mordred, totally agree on the rage, btw
20:42:10 <ttx> let's concentrate on the inputs, we can discuss the machinery that will consume them at another meeting
20:42:13 <markmcclain> determine capabilities that have to exist and then decide on code that has to be used and what can be driver/plugin based?
20:42:16 <dhellmann> ttx: +1
20:42:22 <devananda> ttx: +1
20:42:30 <mordred> I mean, if it weren't for the people who aren't participating technically but still wanting to buy their way into using the name, this would be VERY easy
20:42:32 <mordred> RAGE RAGE RAGE
20:42:39 <ttx> so if there is no volunteer to propose a scoring, I'll take it
20:42:43 <ttx> yeepee
20:42:52 <devananda> i've been trying to follow the confusion to see if I could help settle it ... but no. I think mordred has stated it in ways that match my understanding.
20:43:00 <markmc> ttx, you don't have to be the default volunteer :(
20:43:20 <dhellmann> ttx: do we just need to turn those 0.5s in column G to 1 or 0?
20:43:21 <ttx> markmc: well, someone has to do it
20:43:26 <ttx> dhellman_: yes
20:43:46 <ttx> and mind you, just propose something that we will iterate on review
20:43:52 <ttx> It's not that much work
20:43:57 <dhellmann> I'll do it
20:44:02 <ttx> cool!
20:44:07 <markmc> thanks dhellmann
20:44:08 <ttx> thanks dhellmann
20:44:11 <russellb> mordred: so, yes, we want you to use the code wrote, so 100%, moving on?  :)
20:44:28 <russellb> else it's not our software
20:44:30 <ttx> #action dhellmann to pick up the scoring proposal for the "TC direction" column
20:44:31 <russellb> that was easy
20:44:42 <ttx> ok, let's move on
20:44:47 <annegentle> thanks dhellmann (and ttx for being willing)
20:44:52 <ttx> but we need to have that discussion again
20:45:07 <zehicle> my final item was that we're going to Gerrit to manage changes to the scores & capabilities going forward
20:45:10 <ttx> As I expect we won't be happy with what will come out of the machine we are feeding the required inputs to
20:45:16 <zehicle> I can hold that till next week
20:45:19 <dhellmann> zehicle: do you have the link to the definitions of those capabilities handy? I'm sure I have it somewhere...
20:45:23 <ttx> zehicle: ack
20:45:47 <ttx> OK, let's move on to the governance changes in review
20:45:52 <zehicle> #link https://wiki.openstack.org/wiki/Governance/CoreCriteria
20:46:00 <ttx> #link https://wiki.openstack.org/wiki/Governance/CoreCriteria
20:46:01 <zehicle> #link https://wiki.openstack.org/wiki/Governance/DefCoreLexicon
20:46:11 <zehicle> #link https://wiki.openstack.org/wiki/Governance/CoreDefinition
20:46:20 <dhellmann> zehicle: there was a json file somewhere with mappings to test names?
20:46:32 * zehicle glad that our meeting notes are helpful
20:47:05 <zehicle> dhellmann, yes.  in refstack github.  It's about to change based on last meeting but I'll share the link
20:47:18 <dhellmann> zehicle: thanks, an email is fine if you don't have it handy here
20:47:25 * anteaya hears lightening close, could lose power any moment
20:47:38 <ttx> ok moving on
20:47:40 <ttx> #topic Adds a resolution addressing expected election behavior
20:47:42 <zehicle> #link https://github.com/stackforge/refstack/tree/master/defcore/havana
20:47:44 <ttx> #link https://review.openstack.org/98675
20:47:55 <ttx> There seems to be general agreement on expected behavior, which is good
20:48:01 <ttx> But two different approaches when it comes to enforcing that behavior
20:48:12 <ttx> One (the original proposal by anteaya) based on report and investigation of questionable behavior, with potential punishment in the end (institutional pressure)
20:48:23 <ttx> One (recent counter-thread by eglynn) based on assuming voters will punish questionable behavior once we clearly set what is acceptable and what is not (reputational pressure)
20:48:39 <ttx> As a sidenote, I don't think we (as the TC) can wield the threat of removing Foundation membership (and/or ability to vote or be elected)
20:48:46 * russellb likes the eglynn approach
20:48:52 <russellb> set expectations, and call people out
20:48:53 <ttx> Bylaws say that individual membership may be terminated for violation of the community Code of Conduct (Secretary+Executive Director decision, or Board of Directors asking then to)
20:49:07 <ttx> It may be within the board's power to pass a decision to exclude someone, but clearly it's not under our own power
20:49:16 <ttx> So we (as the TC) can't threaten to remove Foundation membership, we can at best report what we think is a violation of the CoC to the Board
20:49:24 <sdague> yeh, I'm honestly more into eglynn's idea. I think shame is pretty powerful, especially if people have to affirm a thing.
20:49:29 <ttx> An institutional pressure that relies on an indirect threat may be less efficient than a reputational pressure
20:49:39 <jeblair> ttx: so with that in mind, i think that anteaya's approach is the better one
20:49:45 <markmc> I think I saw something about bringing miscreants to the ED for punishment
20:49:53 * anteaya notes Rob Ford is due back on the job after leaving rehab
20:49:56 <mikal> markmc: that's the most recent draft
20:49:57 <markmc> which would make me sad - we don't need the Foundation staff to enforce our culture
20:50:28 <ttx> markmc: by the way, who is the secretary?
20:50:37 <jeblair> anteaya's proposal handles establishing the expected behavior and communicating it to people
20:50:37 <markmc> ttx, good question
20:50:38 <markmcclain> my only concern about using reputation for pressure is that we still have to have some kind of structure
20:50:45 <jeblair> i believe that is the core thing we need to do
20:50:54 <ttx> (more bylaws fun, every time I read it I learn something new)
20:50:56 <dhellmann> yeah, I'm not sure I like the idea that the TC completely abdicates responsibility for its elections to the foundation staff
20:50:58 <jeblair> whereas eglynn's proposal actually seeds to have a lot red tape
20:51:09 <jeblair> dhellmann: i don't think the proposal is to abdicate --
20:51:27 <jeblair> i think the issue is that when we get into things like "code of conduct violations" that's the purveiew of the foundation
20:51:29 <dhellmann> jeblair: the current draft no longer mentions the TC being involved in abuse reporting
20:51:32 <jeblair> because it's the foundation's code of conduct
20:51:40 <dhellmann> I do agree that the foundation should enforce its code of conduct
20:51:57 <markmcclain> well don't all members of the foundation have the right to refer a code of conduct violation to foundation staff?
20:51:59 <jeblair> cool, and its coc says "respect the election process"
20:52:06 <dhellmann> I just think the TC should be aware of issues, and I would like to see some option for making them public.
20:52:07 <jeblair> markmcclain: yep
20:52:19 <annegentle> yes I think anyone should be able to report problematic behavior
20:52:20 <ttx> So it seems we need to have a longer discussion on that subject. My suggestion is... each party should refine its proposal using a gerrit review
20:52:28 <markmcclain> so the question is lets say that someone violates the code the conduct
20:52:43 <markmcclain> should we as the TC assert that we have the right to re-run an election?
20:52:43 <ttx> and we'll compare the merits of both proposals (once complete) at another meeting
20:52:55 <eglynn> two separate codes of conduct BTW ... community: http://www.openstack.org/legal/community-code-of-conduct and foundation: http://www.openstack.org/legal/code-of-conduct
20:53:12 <jeblair> fundamentally, i think the issue is that we need to state expectations and communicate them.
20:53:15 <ttx> eglynn: one is for foundation officers
20:53:21 <ttx> the other for foundation members
20:53:23 <markmcclain> jeblair:  +1 to expectations
20:53:29 <dhellmann> jeblair: +1
20:53:36 <russellb> re-running election is a good question
20:53:47 <ttx> I think everyone agrees on acceptable behavior
20:53:54 <markmcclain> it is just that the breakdown is that we don't have any procedures for when someone violates those expectations
20:53:58 <ttx> nobody questioned that first part of anteaya's draft
20:54:19 <dhellmann> ttx: true
20:54:29 <ttx> I still would like the alternate view to crystallize into its own proposal (rather than trying to turn anteaya's proposal into theirs
20:54:31 <jeblair> ttx: cool, so i think we can refine the second part, and it sounds like it's getting pretty miniminal
20:54:39 <markmc> markmcclain, do you feel the issues in the previous election were bad enough to warrant formal procedures to redress?
20:54:40 <ttx> and then compare the two when they are deemed ready
20:54:45 <markmc> markmcclain, serious question
20:55:03 <sdague> so everyone here does. But at the same time I don't think anyone here would have violated that spirit anyway. I guess the question is do we feel those are shared values in the community already?
20:55:06 <anteaya> I would have liked to have been allowed to investigate them
20:55:12 <markmcclain> markmc: in some respects yes, but it's hard to formally address anything since we didn't have any written policy
20:55:12 <jeblair> i just want one that solves the communication problem without establishing a huge amount of extra red tape (committees or required email footers)
20:55:18 <zaneb> I thought anteaya's draft was pretty good right up to the last bit about breaching the ideals being equivalent to breaching the code of conduct
20:55:21 <anteaya> I wasn't, I had no report filed
20:55:36 <zaneb> 'we have these ideals' <- good
20:55:52 <jeblair> i think it's ultimately up to the foundation to decide whether the CoC has been violated
20:55:55 <zaneb> 'you really don't want to breach the foundation's CoC' <- good
20:55:59 <markmcclain> jeblair: +1
20:56:01 <jeblair> so our proposals should not try to overstep that
20:56:05 <ttx> jeblair: it is yes
20:56:05 <anteaya> I was told that we needed a process for someone to be willing to file a report
20:56:09 <zaneb> ideals == CoC <- dangerous
20:56:26 <anteaya> I just need to ensure we have what is required for people to file
20:56:51 <jeblair> anteaya: i think we should leave that up to the foundation
20:57:03 <jeblair> anteaya: if there is feedback that the coc is unclear on reporting instructions
20:57:06 <jeblair> anteaya: we should ask them to fix that
20:57:10 <ttx> OK, I think we need to let that overflow to another meeting. Please each party refine your proposals, but separately
20:57:14 <anteaya> I can agree with that
20:57:23 <sdague> do we have a person in the foundation that we think is willing to take this up.
20:57:25 <devananda> it sounds like the question is: do we need a formal process for redress? or just better communication of expectations while allowing the commmunity to self-correct?
20:57:31 <ttx> and we can continue discussing it when we ahve two proposals to choose from
20:57:35 <anteaya> I talked with Jonathan today
20:57:37 <zehicle> zaneb, there is a foundation ombudsperson (right now it's Jonathan B)
20:57:39 <eglynn> ttx: fair enough, will do
20:57:43 <anteaya> I left a comment in my patch
20:57:46 <sdague> I get uncomfortable with "that's the foundations responsibility" without knowing they think it is as well
20:57:59 <anteaya> sdague: me too
20:58:09 <dhellmann> sdague: +1
20:58:17 <devananda> ttx: +1 for gerrit reviews for both
20:58:24 <ttx> OK, moving on quickly
20:58:29 <ttx> #topic Add translation support requirement
20:58:31 <zehicle> devananda, the board also has this in process via the transparency committee (just so people know there's a Board action related to this discussion)
20:58:34 <ttx> #link https://review.openstack.org/97872
20:58:39 <ttx> I think two good points were raised -- scope of translation and absence of testing
20:58:43 <markmc> also think about a potential future where we don't all trust the foundation so much
20:58:43 <ttx> Which make this a bit... early
20:58:45 <markmc> could happen
20:58:56 <ttx> I agree with markmc that deployer-facing messages may be considered out of policy scope
20:59:00 <ttx> I agree with sdague that without testing, it will (as it has in the past) stopped working without anyone knowing
20:59:11 <ttx> We generally discover how broken it is post-release, which is an embarassment.
20:59:18 <devananda> ttx: i recall a discussion last year as to whether or not we should translate certain strings
20:59:25 <ttx> right
20:59:26 <devananda> ttx: because of difficulty in gogole searching to find help
20:59:35 <devananda> i'd like tos ee that clarified before we make any policy on it
20:59:41 <devananda> maybe it was and I missed it
20:59:43 <ttx> we still ahven't a good story there, so personally I think this requirement is a bit early
20:59:51 <dhellmann> the whether or not to do it question was settled by the translation team who is doing the work, and their users, and I am happy to leave it in their hands
21:00:19 <dhellmann> (some) users want translated log files and the tools now support it
21:00:29 <ttx> ok, let's continue the discussion on the review :)
21:00:37 <ttx> #topic Modify Images mission to fit Artifact Repository
21:00:40 <ttx> #link https://review.openstack.org/98002
21:00:46 <ttx> Still needs some work, so I'll pass
21:00:56 <ttx> we can discuss it next week
21:00:57 <markmc> dhellmann, yeah I couldn't find the translations team decision on that
21:01:01 <ttx> #topic Housekeeping items
21:01:05 <ttx> * Adds openstack/training-guides repo to Documentation program (https://review.openstack.org/99408)
21:01:08 <ttx> * Adds the openstack/security-guide repo to the Documentation program (https://review.openstack.org/99171)
21:01:21 <ttx> Both will be approved after the meeting unless someone -1s
21:01:27 <ttx> #topic Open discussion
21:01:28 <annegentle> ttx: great!
21:01:35 <ttx> and we are out of time
21:01:42 <ttx> Thanks everyone!
21:01:46 <russellb> just a quick thanks to those that attend weekly from time zones where this isn't a good time
21:01:47 <russellb> thanks!
21:02:04 <ttx> #endmeeting