20:03:13 #startmeeting tc 20:03:14 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:17 The meeting name has been set to 'tc' 20:03:22 Agenda for today: 20:03:32 o/ 20:03:43 jgriffith: ping 20:03:47 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:50 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 #topic Use of the word "certified" 20:04:01 o/ 20:04:07 #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 I think that thread reached conclusion that using "tested" or "CI tested" would be more accurate. 20:04:27 that was my take on it as well 20:04:34 anteaya: Not sure we need to discuss that any further, unless a specific outcome is desired and not obtained yet ? 20:04:50 well just to support cinder in their deprecation of using the word 20:04:54 if they require that 20:05:08 the mostly needed to ensure the topic got airtime on the ml, which it did 20:05:27 jgriffith: your last post seems to agree to phase out "certified" in favor of some variation of "tested" 20:05:28 anteaya: there's only a handful of folks that cared, but they're willing to yield 20:05:46 jgriffith: hey 20:05:50 ok, so I don't think we have a problem left to solve 20:05:54 no 20:05:58 ttx: nope 20:06:00 agreed 20:06:03 great, thanks jgriffith 20:06:03 agree 20:06:05 ttx: I'll play along 20:06:07 jgriffith: did you need any support for transition? 20:06:09 nice consensus reaching thread :) 20:06:13 anteaya: nah 20:06:14 markmc: +1 20:06:15 thanks though 20:06:16 k 20:06:27 so I'm done on this one 20:06:34 #agreed Cinder will phase out use of term "certified" for some variation around "tested" that is not as heavily loaded 20:06:53 next topic, then! 20:06:55 #topic Review j-1 progress on gap covering plans 20:07:20 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 So I used the 1:1 syncs today to get a picture of progress in gap coverage plans 20:07:48 i'll report on behalf of al PTLs now 20:08:00 although those that are around should feel free to correct me 20:08:06 * Ceilometer (https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage) 20:08:14 #info Ceilometer is on track, still targeting j2 for fully covering the gap 20:08:27 * Horizon (https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage) 20:08:37 o/ 20:08:41 #info Mostly on track. Horizon mission statement is late, but that should be a quick one 20:08:52 * Neutron (https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage) 20:09:03 #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 markmcclain: feel free to comment on that one from your first-hand perspective 20:09:38 * Trove (https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Trove_Gap_Coverage) 20:09:43 #info Trove coverage plan is on track, work started on all items 20:09:50 More details available in the ptl_sync logs: 20:10:07 #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-06-17-08.00.html 20:10:22 ttx: correct… in aggregate we're still on target just a few items that are ahead/behind schedule 20:10:25 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 So overall I was pleased to see that most gaps were in progress 20:11:02 sdague: I expect that finalizing gap0 should make the fix for 2 quick 20:11:06 sdague: yeah, i was wondering how the upgrade procedure was coming ... hadn't seen anything 20:11:34 n-net -> neutron in particular 20:12:05 russellb: there is WIP code for n-net -> neutron 20:12:14 doesn't handle sec groups yet 20:12:16 cool, good to hear. 20:12:43 All the gap work seems to be priotized correctly, even if some work takes longer than hoped (as always) 20:12:52 +ri 20:13:00 #link https://review.openstack.org/#/c/100265 n-net ext 20:13:14 Other questions on that? 20:13:49 I think juno-2 objectives will be a lot harder to meet 20:13:53 and will be the real test 20:13:56 agreed 20:13:58 a reliable open source default driver isn't on the neutron gap list? 20:14:01 good checkpoint though 20:14:03 ttx: +1 20:14:08 because a lot of the gap work is being targeted at it 20:14:14 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 jogo: the default driver is ML2 and we have several folks working to improve it 20:14:48 markmcclain: ack, just thought that would be on the gap coverage list 20:14:54 annegentle: david-lyle is in vacation at the moment, so I didn't push too much on his substitutes 20:15:10 annegentle: we can certainly ask for more details when he is back (next week) 20:15:19 got it 20:15:20 thanks 20:16:00 #topic Defcore update: Swift designated sections & capabilities score process 20:16:07 zehicle: o/ 20:16:12 #link https://etherpad.openstack.org/p/DefCoreLighthouse.F2F 20:16:32 o/ 20:16:35 zehicle: floor is yours 20:16:40 thanks! 20:16:53 a few topics to cover from our last DefCore meeting 20:17:18 will dig up link to minutes 20:17:20 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 ..???.. 20:17:38 items 1) timing, 2) designated sections for swift 3) process for core 20:17:40 * notmyname just saw "swift" mentioned 20:17:42 yeah - sorry, my schedule totally fell apart 20:17:53 notmyname: I confirm, it was mentioned. 20:18:06 we did a pass to complete the unscored items (object was the only one left) 20:18:20 since we're there, we can do #2 first 20:18:26 mordred: not blaming you, I couldn't have done it if I had it assigned to me either :) 20:18:51 our scores had 2 capabilities in swift as core and a few as close but not in 20:19:31 hmmm.... 20:19:34 ok, well we've lost our chair 20:19:41 I'm listening 20:19:42 Sigh 20:19:48 turned out to be pretty easy to score - NOTE, there's still a question about IF the capabilities need to change 20:19:53 but that's ok for now 20:20:26 did we lose our quorum too? 20:20:27 #link http://lists.openstack.org/pipermail/defcore-committee/2014-May/thread.html#173 <- some context 20:20:51 we are still logged 20:20:51 should we call role again or something? I can't tell who's still here 20:21:03 we're back! 20:21:03 ah. 20:21:06 ok, we are back 20:21:06 :) 20:21:12 welcome back! 20:21:17 that was the shortest netsplit in history 20:21:18 https://etherpad.openstack.org/p/DefCoreLighthouse.F2F 20:21:22 #link https://etherpad.openstack.org/p/DefCoreLighthouse.F2F 20:21:25 turned out to be pretty easy to score - NOTE, there's still a question about IF the capabilities need to change 20:21:25 <-- sombrafam has quit (Quit: Connection closed for inactivity) 20:21:25 but that's ok for now 20:21:30 that's all you missed 20:21:38 right now, the DefCore committee has the position that these capabilities SHOULD BE Core 20:22:10 however, there's a problem with in field implementations of designated sections if Swift is 100% designated 20:22:12 zehicle: you mentioned 2 groups of capabilities, which do you mean? 20:22:32 dhellman_, must-pass (core) and the rest 20:22:39 ok 20:22:43 in the rest, there are some that are clearly out and some are on the bubble 20:22:53 the other capabilities for Swift were "on the bubble" 20:23:05 #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 I see objectstore-container and objectstore-object as scoring green 20:23:34 we're happy to discuss scores, but we will make best effort to keep this moving 20:23:47 dhellman_, yes, those did not chnage 20:23:48 yeah, I'm just trying to make sure I understand what all the pronouns mean :-) 20:23:58 no worries, I want to be clear 20:24:11 zehicle: so what do you need from us? You still need clarification on those 0.5 scores in TC direction, right 20:24:23 so we're asking the TC to move forward on designated sections for swift 20:24:49 BUT if you say 100% then we will have to re-evaluate the 2 core designations 20:24:57 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 ttx, yes we are still asking TC to resolve the .5s 20:25:10 ttx: +1 20:25:18 ++ 20:25:32 ttx, it's not blocking us since we did not think it would swing any capabilities into other sections 20:25:33 totally 20:25:38 umm..I'm missing a lot of context here. (and I have another meeting in 5 minutes) 20:25:56 ttx, we were NOT trying to close the issue here. just bring it to the TC so you had the ball 20:26:08 OK, I'll take the action to reach to notmyname when we both have more time 20:26:14 thanks ttx 20:26:22 and understood DefCore would have to response if the answer if 100% 20:26:31 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 I'm happy to be a resource for that discussion as needed 20:26:46 also, Ihave no idea where a score of "83" comes from 20:27:00 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 notmyname, that needs further review & discussion w/ Troy 20:27:15 yy 20:27:26 markmc, that's exactly this topic 20:27:46 basically, you need the designated sections opinion from our side on swift 20:27:48 and then we go from there 20:28:00 russellb, yes. exactly 20:28:01 and to get that, ttx will sync with notmyname later 20:28:02 if the TC says swift has designated sections, the defcore committee will remove all swift capabilities from core? 20:28:06 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 zehicle: so if swift is not 100% designated, it's out of core capabilities ? Bit confursed too 20:28:18 markmc, depends on how the opinion comes out 20:28:30 zehicle, I don't understand the logic behind it 20:28:31 ttx, the opposite 20:29:03 "if Swift has any designated sections then the DefCore committee will likely recommending omitting the "object-*" capabilities from core" 20:29:03 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 in DefCore, concerns were raise that if Swift has core capabilities AND is 100% designated then it creates issues for implmentations 20:29:07 zehicle: I'm sufficiently confused. Can you restate the thing that needs a decision? 20:29:16 "defcore committee thinks swift should capabilities should not be required in openstack clouds" 20:29:22 zehicle: but nobody has said 100% 20:29:27 "if the TC thinks swift code should be required, ..." 20:29:28 and notmyname just said that's not his opinion either 20:29:29 * markmc still lost 20:29:39 We do think Swift capablities are required 20:29:43 (to be clear - the quotes are me trying to paraphrase) 20:29:50 that's why 2 of them are in the core list 20:29:52 right. I think we're talking about a hypotehtical which we've already disproven 20:29:57 mordred: yes. 20:29:58 zehicle, then why say you'll remove them if there are designated sections? 20:29:58 notmyname: do you have anything written about designated sections for swift? 20:30:00 BUT we have a challenge if the code is 100% designated 20:30:06 let's stop talking about that 20:30:08 zehicle: but it's not 20:30:10 it's a non issue 20:30:14 so let's move on 20:30:14 zehicle: ok 20:30:28 yes, I'm ok to move on. 20:30:30 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 notmyname: ok, thanks, I'll look at the list archives 20:30:41 notmyname: thanks 20:30:42 * mordred waves at notmyname 20:31:00 #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 zehicle: you still that that 0.5 scoring clarified, right ? 20:31:20 the list notmyname sent was capabilities, not designated sections 20:31:25 (to be clear) 20:31:26 yes, that will help 20:31:52 we're trying to have community input meetings last week of June 20:31:55 markmc: ok, so it sounds like we still need a discussion about designated sections 20:31:57 TC: do we have a new volunteer to propose a scoring to the governance repo for us to iterate on ? 20:32:08 Matrix input from Community (2 meetings 25 & 26 of June) 20:32:15 dhellman, right 20:32:23 it would be good to have all 0 or 1 before those meetings 20:32:40 and we'll use that as the basis for Icehouse scoring 20:32:52 ok, so we really need a volunteer now :) 20:33:04 "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 it's a TM policy issue, the board is the deciding body 20:33:33 markmc: I disagree 20:33:33 markmc: +1 20:33:41 heh 20:33:42 the board is the deciding body for the TM issues 20:33:48 and it is a TM issue 20:33:50 I do NOT want the board deciding designated sections 20:33:53 markmc: I think we propose designated sections (actually, we make sure PTLs propose them) 20:33:55 because that's a code org issue 20:34:01 markmc, happy to discuss more but that position is a surprise given pass dialogs 20:34:02 then the BoD does what it wants with them 20:34:04 "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 I don't want eileen, for instance, making decisions on which chunks of code do anything 20:34:13 mordred, the choice of which ones required is the TM policy issue 20:34:14 ttx: that's a thing I am meant to be working on but haven't progresses as much as I should 20:34:26 I'm drafting something for the TC to take to PTLs requesting designated sections 20:34:27 mordred, what the list of potential required sections are can be something the TC produces 20:34:35 markmc: the choice of technical communities intent for how the code works and is used is us 20:34:40 mikal: think you can have a try at it ? 20:34:52 ttx: I have a draft, its lacking some detail though 20:34:57 I can upload a WIP now if you want me to 20:35:09 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 dhellman, right 20:35:16 ttx: ++ 20:35:18 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 so we are the deciding body on a technical input 20:35:32 ok, we're just mixed up on terminology 20:35:36 I think ttx sums up my view 20:35:38 AIUI "designated" means "required" 20:35:39 which they use or not use in trademark rules 20:35:50 Board does pick required capabilities as defined by tests 20:35:53 yeah, is "deciding body" some magical legalese, or does it just mean "the TC is going to tell us" 20:35:58 you guys are saying "designated" is "sections the board can choose to require" 20:36:09 dhellmann: none of these words ACTUALLY have meaning - just the ones we've invented 20:36:09 dhellman_: my understanding is 'the TC will tell us" 20:36:15 We're trying to document that at the bottom of that page, the bylaws changes "in plain english" section 20:36:20 markmc: right, the intersection of code (TC) and capabilties (board) 20:36:38 dhellman +1 20:36:40 mordred: no wonder we have so much trouble talking about this :-) 20:36:44 the TC picks the sections. the board can use or not use that information to inform its choice of capabilities 20:36:55 the sections are only an input into a decision matrix 20:37:00 so the sections ARE 100% us 20:37:05 mordred: yes, except I am a little surprised to hear the thing about swift 20:37:12 but their application towards trademark policy is the board 20:37:14 well, a *very* little surprised 20:37:25 right and the sections the board chooses are called "designated sections" 20:37:29 no the list the TC picks 20:37:31 no 20:37:31 not 20:37:38 ttx: https://review.openstack.org/#/c/100675/ is what I have so far 20:37:40 the board does not pick sections 20:37:44 the board picks capabilities 20:37:53 sections are a way to help choose capabilities 20:37:55 clearly, this has not reached the level of clarity I'd hoped. My appologies 20:37:59 so the board takes our list of designated sections, or throws it away 20:38:04 the board takes it 20:38:06 binary? no selective choosing from our list? 20:38:07 it is input 20:38:13 to the list of capabilites 20:38:25 it's totally separate from the list of capabilities! 20:38:32 mordred, yes but there's a nuance because we expect the capabilities to be defined by the projects 20:38:38 TM requirements are capabilities + designated sections 20:38:40 AIUI 20:38:40 mikal: that's designated sections -- I'm looking for a volunteer to push scoring proposals for the "Tc direction" column 20:38:44 The board is really picking WHICH ones are core 20:38:44 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 mikal: I think you have enough on your plate with that first one 20:39:00 ttx: ahhh, ok. We're talking about different things then 20:39:09 ttx: agreed, I think the designated section thing shows I'm too busy at the moment 20:39:22 dhellman, oooh, I don't think so ... 20:39:23 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 we make software 20:39:32 dhellman_, if the code's not designated but the capability is core that's OK 20:39:36 dhellmann, AIUI capabilities can be required even if the code isn't a designated section 20:39:37 people shold be lining up at the door to use it 20:39:41 zehicle: that makes no sense at all 20:39:49 dhellmann, which I think is behind this statement about swift 20:39:54 and we should stop spending so much time working on giving them lists of stuff they can ignore 20:39:56 BUT 20:39:59 if we're going to do that 20:40:04 it just means that the vendor can substitute 20:40:06 then the parts related to CODE should be from us 20:40:10 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 "an OpenStack cloud must do this thing we're not going to give you supported code to do"? that's odd. 20:40:41 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 it would be foolish to do so, but they are the final deciding body on trademark requirements 20:40:49 mordred: i certainly can relate to your sentiment about the complexity of all this ... 20:40:54 bceause there are people with vested interests in being allowed to do that 20:40:55 I'm thinking a single topic meeting may be in order. I think the context of this is getting lost 20:41:32 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 we specifically do NOT want the board adding extra stuff. 20:41:35 I'm still wondering why this is so hard… can we not split the question? 20:41:50 mordred, totally agree on the rage, btw 20:42:10 let's concentrate on the inputs, we can discuss the machinery that will consume them at another meeting 20:42:13 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 ttx: +1 20:42:22 ttx: +1 20:42:30 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 RAGE RAGE RAGE 20:42:39 so if there is no volunteer to propose a scoring, I'll take it 20:42:43 yeepee 20:42:52 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 ttx, you don't have to be the default volunteer :( 20:43:20 ttx: do we just need to turn those 0.5s in column G to 1 or 0? 20:43:21 markmc: well, someone has to do it 20:43:26 dhellman_: yes 20:43:46 and mind you, just propose something that we will iterate on review 20:43:52 It's not that much work 20:43:57 I'll do it 20:44:02 cool! 20:44:07 thanks dhellmann 20:44:08 thanks dhellmann 20:44:11 mordred: so, yes, we want you to use the code wrote, so 100%, moving on? :) 20:44:28 else it's not our software 20:44:30 #action dhellmann to pick up the scoring proposal for the "TC direction" column 20:44:31 that was easy 20:44:42 ok, let's move on 20:44:47 thanks dhellmann (and ttx for being willing) 20:44:52 but we need to have that discussion again 20:45:07 my final item was that we're going to Gerrit to manage changes to the scores & capabilities going forward 20:45:10 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 I can hold that till next week 20:45:19 zehicle: do you have the link to the definitions of those capabilities handy? I'm sure I have it somewhere... 20:45:23 zehicle: ack 20:45:47 OK, let's move on to the governance changes in review 20:45:52 #link https://wiki.openstack.org/wiki/Governance/CoreCriteria 20:46:00 #link https://wiki.openstack.org/wiki/Governance/CoreCriteria 20:46:01 #link https://wiki.openstack.org/wiki/Governance/DefCoreLexicon 20:46:11 #link https://wiki.openstack.org/wiki/Governance/CoreDefinition 20:46:20 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 dhellmann, yes. in refstack github. It's about to change based on last meeting but I'll share the link 20:47:18 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 ok moving on 20:47:40 #topic Adds a resolution addressing expected election behavior 20:47:42 #link https://github.com/stackforge/refstack/tree/master/defcore/havana 20:47:44 #link https://review.openstack.org/98675 20:47:55 There seems to be general agreement on expected behavior, which is good 20:48:01 But two different approaches when it comes to enforcing that behavior 20:48:12 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 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 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 set expectations, and call people out 20:48:53 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 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 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 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 An institutional pressure that relies on an indirect threat may be less efficient than a reputational pressure 20:49:39 ttx: so with that in mind, i think that anteaya's approach is the better one 20:49:45 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 markmc: that's the most recent draft 20:49:57 which would make me sad - we don't need the Foundation staff to enforce our culture 20:50:28 markmc: by the way, who is the secretary? 20:50:37 anteaya's proposal handles establishing the expected behavior and communicating it to people 20:50:37 ttx, good question 20:50:38 my only concern about using reputation for pressure is that we still have to have some kind of structure 20:50:45 i believe that is the core thing we need to do 20:50:54 (more bylaws fun, every time I read it I learn something new) 20:50:56 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 whereas eglynn's proposal actually seeds to have a lot red tape 20:51:09 dhellmann: i don't think the proposal is to abdicate -- 20:51:27 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 jeblair: the current draft no longer mentions the TC being involved in abuse reporting 20:51:32 because it's the foundation's code of conduct 20:51:40 I do agree that the foundation should enforce its code of conduct 20:51:57 well don't all members of the foundation have the right to refer a code of conduct violation to foundation staff? 20:51:59 cool, and its coc says "respect the election process" 20:52:06 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 markmcclain: yep 20:52:19 yes I think anyone should be able to report problematic behavior 20:52:20 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 so the question is lets say that someone violates the code the conduct 20:52:43 should we as the TC assert that we have the right to re-run an election? 20:52:43 and we'll compare the merits of both proposals (once complete) at another meeting 20:52:55 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 fundamentally, i think the issue is that we need to state expectations and communicate them. 20:53:15 eglynn: one is for foundation officers 20:53:21 the other for foundation members 20:53:23 jeblair: +1 to expectations 20:53:29 jeblair: +1 20:53:36 re-running election is a good question 20:53:47 I think everyone agrees on acceptable behavior 20:53:54 it is just that the breakdown is that we don't have any procedures for when someone violates those expectations 20:53:58 nobody questioned that first part of anteaya's draft 20:54:19 ttx: true 20:54:29 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 ttx: cool, so i think we can refine the second part, and it sounds like it's getting pretty miniminal 20:54:39 markmcclain, do you feel the issues in the previous election were bad enough to warrant formal procedures to redress? 20:54:40 and then compare the two when they are deemed ready 20:54:45 markmcclain, serious question 20:55:03 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 I would have liked to have been allowed to investigate them 20:55:12 markmc: in some respects yes, but it's hard to formally address anything since we didn't have any written policy 20:55:12 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 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 I wasn't, I had no report filed 20:55:36