20:02:01 #startmeeting tc 20:02:02 Meeting started Tue Jun 24 20:02:01 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:03 annegent_: ping 20:02:05 The meeting name has been set to 'tc' 20:02:09 Agenda for today: 20:02:17 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:28 markwash: you're available now ? 20:02:35 I'm here! 20:02:36 :-) 20:02:38 #topic Glance gap coverage plan 20:02:41 jeblair: pong 20:02:50 Two weeks ago a single gap was raised against Glance in the integrated requirements gap analysis: 20:02:54 o/ 20:02:56 - Lack of testing a binary image in integration tests 20:03:03 markwash posted the following plan to address it: 20:03:09 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Glance_Gap_Coverage 20:03:18 Pretty simple, looks good to me 20:03:31 yeah, we targeted j-2 and feel good about it 20:03:42 tried to get it done this past week but couldn't quite find the immediate manpower 20:03:46 Unless someone has an issue with it, I'll add it to the TC wikipage for tracking 20:04:01 seems good to me 20:04:12 and we'll haunt markwash back about this targeting in a few weeks time 20:04:24 when we review gap coverage progress post-j2 20:04:27 wfm 20:04:35 #action ttx to add Glance gap coverage plan to TechCommittee wiki page for tracking 20:04:55 #topic Other governance changes in review 20:05:04 * Modify Images mission to fit Artifact Repository (https://review.openstack.org/98002) 20:05:10 thanks dhellman for the wording 20:05:22 markwash: glad I could help :-) 20:05:23 This one is Glance territory too 20:05:27 A new wording was proposed, hopefully it will please enough people. 20:05:35 The marketing folks approached me about the change from "image service" to "artifact repository" 20:05:44 I have a call with them tomorrow 20:05:46 they want to have a chance to discuss that name and weigh in on the review before this is finally approved 20:06:00 Nobody suggested something better yet, though 20:06:14 but that name leaks into the "official naming" so I think that request is fair 20:06:15 it means docs changes too 20:06:26 I would also like a little time for some other glance folks to respond to the latest patch, if that's okay 20:06:27 we use Image Service currently 20:06:47 so yes, I'll stall this until at least next meeting 20:07:28 ttx: markwash: can I get in on that call? 20:07:39 * annegent_ is not a marketer 20:07:50 annegent_: i'm not on that call, but maybe markwash can include you 20:07:54 annegent_: I'll ask to have you included 20:07:57 thanks markwash 20:08:00 yes 20:08:02 * Add translation support requirement (https://review.openstack.org/97872) 20:08:20 Requirements changes need consensus, as they reflect the base set of requirements we all agree on 20:08:27 I'm not sure this one is ready to gather that consensus 20:08:39 Looks like policy could mature a bit and the technical result could be tested 20:08:42 The i18n team has been trying for 2 summits to move ahead on this. 20:09:00 I'd like to at least be able to go back to them with specific instructions about what they need to do. 20:09:15 dhellman_: that's fair 20:09:17 we have a lot of the tooling in place already 20:09:28 including the CI jobs 20:09:30 dhellman_: personally I think of two things 20:09:36 and a few projects are accepting changes 20:09:43 (1) we need to somehow test that what we do is usable 20:09:53 because I know of at least two releases where it wasn't the case 20:09:58 ok 20:10:03 dhellmann: where are the CI jobs? I guess that's something I'm not aware of. 20:10:07 because there is no automated test around that 20:10:15 sdague: jobs to extract the messages, not to run tests 20:10:29 heh, literally "continuous integration" :) 20:10:33 unlike most of the jobs we run 20:10:37 ok, fair :) 20:10:42 unit tests exist, so what other tests do we want? a full d-g job with an alternate translation? 20:10:45 but that's not the jobs we know we need 20:10:49 sdague: ++ 20:10:49 dhellmann: yeh 20:10:57 (2) I would like to clarify end-user facing vs. operator-facing messages. The plan was to enable two separate translation domains to be able to prioritize one over the other 20:11:14 do we have the resources to run a d-g job with translations? we're already talking about combining some gate jobs 20:11:16 markmc: do we have support for multiple translations domains now ? 20:11:23 * ttx lost track of that 20:11:23 ttx, dhellman has written some nice docs clarifying some of this in the last week 20:11:24 dhellmann: even nightlies are fine 20:11:42 ttx: we now have several domains, one for API and other user messages and a bunch of others for different log levels for operators 20:11:51 dhellmann: ttx: and documentation 20:12:07 honestly, I'm totally happy to have the i18n jobs be nightlies, but we do need to actually see if that works for reals 20:12:10 ttx: yeah, if that's something we want to do, we should standardize that (2 domains) at the tc level 20:12:11 docs are waiting for the requirements issue to clear up so they can merge: https://review.openstack.org/#/c/96961/ 20:12:19 the current wording places end-user-facing and operators-facing on the same level though. 20:12:22 ttx, http://docs-draft.openstack.org/61/96961/7/check/gate-oslo.i18n-docs/c4074a7/doc/build/html/guidelines.html#log-translation 20:12:31 docs haven't been merged yet 20:12:46 ttx, jeblair : there are 5 different domains 20:12:57 that's what the translators wanted 20:13:04 dhellmann: user + 4 logs? 20:13:07 they actually wanted 6, but we agreed not to translate debug messages 20:13:07 yes 20:13:11 https://review.openstack.org/#/c/96961/7/doc/source/guidelines.rst 20:13:17 dhellmann: ok, so it looks like we could iterate on the current proposal 20:13:24 I think this is progressing well, but we do need the policy to link to these guidelines 20:13:30 and then there's the testing issue 20:13:31 i'll get my feedback in 20:13:51 ok, I think we can land the doc changes ^^ this week, and I can update the policy 20:14:06 I'll tell the i18n team they need to find someone to work on the test job before we can approve the policy 20:14:10 was that the only objection? 20:14:24 it felt like we were farther away from a solution, reading the comments 20:14:34 * dhellmann thought so too 20:14:51 i'm optimistic 20:15:01 #action dhellmann talk to i18n team about finding someone to create a test job with translations 20:15:15 dhellmann: we have a doc gate test for translation job on japanese 20:15:18 dhellmann: if it helps 20:15:32 annegent_: yes, that may help as an example 20:15:38 OK, let's iterate a bit more on this, if it's not blocked 20:15:57 no, it sounds like they have more work to do, and that's fine now that we know what it is 20:15:57 next topic... 20:15:59 dhellmann: with those doc changes, I think my concern is addressed. 20:16:08 devananda: ok, thanks 20:16:20 nice doc 20:16:38 #topic Defcore 20:16:48 We have two resolutions covering the recent requests for technical input from Defcore: 20:16:57 * Resolution requesting designated sections from projects (https://review.openstack.org/100675) 20:17:12 Still missing input from Swift, Glance, keystone, Horizon, Neutron and Cinder 20:17:19 So we talked about this one last week 20:17:22 ttx: well, not really 20:17:23 I informed all those PTLs during the 1:1 sync points today 20:17:24 does anyone here have the link to the original etherpad? 20:17:36 My proposal was that we merge this, and then take patches from those projects on top 20:17:48 mikal: ah. hmm 20:17:50 #link https://etherpad.openstack.org/p/openstack-designated-sections 20:17:56 ty 20:18:06 ttx: hence the TODOs 20:18:09 mikal: the trick is we'd merge (i.e. approve) a partial thing 20:18:11 I like that. I think I would have preferred to have the nova stuff in a separate patch, but there's probably not much to discuss about the header of the resolution itself. 20:18:24 mikal: I thought people would just propose further changesets 20:18:25 dhellmann: I wanted an example to help PTLs work out what to write 20:18:29 ttx, mikal: was there a -dev list thread for these? 20:18:33 mikal: I thought that's probably what you were doing. 20:18:39 further changesets might get frustrating, fragmenting discussion 20:18:41 ttx: well, I wanted to allow the TC to discuss each project indivisually 20:18:58 i.e. if we dig into a thing on neutron, we should not block say glance 20:18:58 they can submit patches on top of this patch, too, it doesn't have to merge first 20:19:04 mikal: right, I just fear that will push us past "end of month" 20:19:06 mikal: +1 20:19:17 ttx: well, it means we can do them in parallel 20:19:19 zehicle_at_dell: is backporting test coverage to tempest:stable/havana an option at this stage for a project that's not currently included in these designated sections? 20:19:24 But I agree that I've sat on this too long 20:19:56 jeblair: no specific thread on that specific request, no 20:20:06 eglynn, it's not required 20:20:12 jeblair: it's been documented through all the defcore posts 20:20:26 we agreed with the Tempest team that we could test Havana using trunk branchless 20:20:40 also input was already provided in an etherpad before 20:20:41 since Havana is advisory, it's OK 20:20:43 we could add a designated sections template and ask each project to complete it 20:20:55 don't need all projects in one file 20:21:00 markmc: +1 20:21:09 zehicle_at_dell: ok, interesting ... I though branchless tempest only applied to stable/icehouse not before 20:21:13 zehicle_at_dell: branchless tempest doesn't work on havana 20:21:16 markmc: that's true, I hadn't thought of that 20:21:22 it's icehouse and forward 20:21:26 We could for example build a little directory tree or something 20:21:29 markmc: we could add that to the programs.yaml file, too 20:21:30 zehicle_at_dell: i.e. wot sdague said 20:21:32 eglynn, we're testing the stable APIs. It's a pretty good test of the ones we are most interested in 20:21:34 there were too many API breaks between havana and icehouse 20:21:35 mikal: maybe make a directory under resolutions 20:21:41 * dhellmann still needs to work on turning programs.yaml into html 20:21:51 eglynn: well, except it will change over time and the historical values matter 20:22:02 Would people like me to refactor this into a directory and see what it looks like? 20:22:07 sdague, it they are breaks in "core" APIs then we want to know that 20:22:08 mikal: +1 20:22:09 +1 20:22:17 I could do that now and we could circle back in a few minutes 20:22:39 mikal: also redirect people to doing their own change, because I told them all to changeset your original change 20:22:52 mikal: so you can add a note on the commit message to redirect them 20:22:55 zehicle_at_dell: well, it's more complicated, because of the way tempest used to coevolve with projects, the APIs could slip over time 20:22:59 mikal: do i understand correctly that your nova change means a public cloud can run nova with a proprietary compute driver, scheduler, and database, and declare that they are running "OpenStack"? 20:23:12 jeblair: correct. 20:23:13 sdague, it really makes it easier if we focus on the forward direction of Tempest instead of trying to make it work for a release that we're not really enforcing 20:23:15 jeblair: OMG, can we decouple that for just a moment? 20:23:28 I'm happy to discuss it, but I want to unblock the process first 20:23:28 jeblair: well, potentially. 20:23:31 and we looked at what it would take to get havana in line, and it really was more work than anyone was willing to sign up for 20:23:34 jeblair: well, they would need to run a few other openstack pieces :) 20:23:37 zehicle_at_dell: agreed 20:23:42 sdague, happy to discuss it more. would want to involve davidlenwell_ 20:23:46 that's why our focus is icehouse forward 20:23:59 mikal: okay sure -- i thought we were good on the process. :) 20:24:18 plus it gets rid of backport burden 20:24:20 jeblair: also I don't think they would run "openstack". They would maybe run "an openstack compatible cloud" or "an openstack interoperable cloud" 20:24:24 jeblair: well, except I have to do this refacotr 20:24:26 trademarks to be defined 20:24:27 mikal: it's the first time we're seeing this whole thing converge and i'm just sanity checking my understanding 20:24:32 mikal: carry on! 20:25:04 ttx, nope, this would be an OpenStack cloud 20:25:04 * ttx wants to decouple "openstack" the thing we work on from the trademark programs 20:25:08 ttx, the specific trademarks are "powered" and "compatible" as defined by the Foundation 20:25:19 but compatible does not mean quite what you may thing - it's not about APIs 20:25:20 zehicle: right 20:25:23 ttx, OpenStack Compatible (if such a TM existed) would be where you're not running the designated sections 20:25:58 markmc: so.. "OpenStack powered" ? 20:26:02 ttx, yeah 20:26:06 markc, we'd have to use a different name but the API only mark is still a ways off. We've deliberately NOT done that 20:26:26 zehicle_at_dell, that's why I said "(if such a TM existed)" 20:26:28 markc, and it's not clear that we will at this time 20:26:39 and it's markmc not markc 20:26:50 markc, I understand. the trick is that there IS a compatible mark. 20:27:17 mikal: these all look like reasonable plugin spots in nova. I assume there are designated sections that call all of these things listed as exceptions? 20:27:29 markmc: I still think we should prefix whatever technical input we produce for Defcore with clear warnings that we do not encourage substituting pieces of openstack code 20:28:02 dhellmann: well, all of those things have well defined plug in layers, and existing out of tree extensions (to the best of my knowledge) 20:28:10 mikal: like, you say "scheduler driver" but that implies the scheduler service is still considered designated? 20:28:12 because I want to just designate areas of code that are desogned to be extensible 20:28:13 ttx, as in, that would be the TC's consensus input to the board's TM policy decision making ? 20:28:18 ttx: i think that may be in conflict with the actual content of that change 20:28:28 dhellmann: agreed. You run the service, but you can plug in your own algorithm 20:28:31 cool 20:28:52 Is https://review.openstack.org/#/c/100675/4 closer? 20:28:58 that seems like exactly what we want to be doing when we specify designated sections -- specifying the bits we think should and should not be replaceable 20:29:13 ttx: i don't know why we'd list anything if we felt you shouldn't actually replace code 20:29:17 dhellmann: noting that we have already passed a set of guidelines which basically say that 20:29:22 jeblair: on one side, we the TC are the ultimate technical representation, and we are asked to provide a technical input, which is basically which parts of the code allow plugins 20:29:26 i.e. we're being consistent over time which is a nice feeling 20:29:30 mikal: you have extra content in 'instructions.rst' 20:29:38 jeblair: doh 20:29:44 mikal: you probably want a file in the resolutions/ dir to point to all of those little files so they render properly. I can help you with that offline. 20:29:57 jeblair: on the other, we are the representation of the contributors of the project, and as mordred said last week, we should not encourage building proprietary products on top of openstack 20:29:59 ttx: we can't pretend to be ignorant to the purpose of why we're providing this list ... 20:30:00 dhellmann: ta 20:30:16 dhellmann: perhaps instructions.rst should be up a dir level? 20:30:28 dhellmann: and include the sub files? 20:30:36 jeblair: fix uploaded 20:30:40 russellb: the alternative would be what ? To refuse to produce that information, so that they have to make their own idea ? 20:30:41 mikal: that would work, maybe using a toctree 20:30:49 dhellmann: got an example I can copy? 20:30:50 I prefer to provide a conservative version 20:31:13 ttx: i lean toward very conservative. 20:31:14 at least we cna make sure that it follows technical lines 20:31:26 mikal: let me whip one up 20:31:28 ttx: to say that what we support is getting involved and contributing to the project, and that what we deliver is OpenStack, not intended to be replaced by outside code, even if technically possible 20:31:32 dhellmann: thanks man 20:31:36 * zehicle_at_dell would like to have a follow-up from last week to review the process and clearify how designated sections and capabilities become core 20:31:39 jeblair: we approved guidelines before -- do you still agree with them ? 20:31:41 dhellmann: Or just upload a new version of that review with it done... 20:31:46 dhellmann: we don't need too much process for that 20:32:00 jeblair: http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20140402-defcore-designated-sections-guidelines.rst 20:32:20 mikal: ok, doing that now 20:32:50 dhellmann: :) 20:33:17 If we follow those guidelines we previously approved, we can provide a technical answer 20:33:43 ttx, the important point IMHO is that we should not be in a position where it looks like the TC is the ones pushing a TM policy that allows drivers to be replaced with proprietary alternatives 20:33:53 markmc: +100 20:33:55 markmc: that I agree on 20:34:10 ttx, we can provide technical input (perhaps policy opinions too), but ultimately the board is the one making this policy decision 20:34:15 we need to be able to provide that etchnical info without endorsing the policy that might be driven from it 20:34:19 markmc: ++ 20:34:25 ttx: i abstained from that vote. i'm still trying to understand the ramifications of this; thus my question earlier. 20:34:25 markmc: do you feel we're doing that now though? 20:34:35 markmc: we're effectively just listing the areas we think plugins are ok 20:34:45 i feel we're being roped in as accomplices by generating this list, yes. 20:34:59 and the more i think about it, the less I like this whole thing. 20:35:23 ttx: i will vote on the actual resolutions, however. 20:35:25 mikal, I've seen language in the etherpads that suggests we have full control over this aspect of the TM policy 20:35:26 OTOH, we should not be in a position where we prevent folks from making necessary customizations for their environment (eg, changing scheduler filters, or adding hardware drivers, etc) 20:35:33 Picking on the nova example, I think that horse has bolted for all these examples 20:35:35 mikal: updated 20:36:01 mikal: oops, should update the instructions, too 20:36:11 devananda: i'm not sure we have the power to prevent that sort of thing. what we may have the power to prevent is people doing that sort of thing and calling their work ours. 20:36:15 dhellmann: yeah, just noticed that 20:36:40 russellb, "roped in" - we're trying to have Board & TC collaboration FWIW 20:37:05 mikal: fixed 20:37:06 zehicle_at_dell: *nod* and that much is appreciated 20:37:08 dhellmann: am I fixing or you? 20:37:09 Ok, cool 20:37:10 markmc: is your statement just in reference to the TM? because the projects being apache licensed do kind of explicitly allow for proprietary mix. 20:37:28 (note: mostly playing devil's advocate there, because I want people upstream as much as possible) 20:37:33 sdague, yeah, it's just about the TM 20:37:35 hmm 20:37:44 sdague, we can value people's freedom to mix with proprietary 20:37:49 so I think we should have a lot of discussions about this this week 20:37:56 markmc: ok, sure, I agree with that 20:37:56 this meeting won't be enough 20:37:57 sdague, we don't have to value it so much that they should be able to call it OpenStack 20:38:41 markmc: indeed 20:38:53 ttx: agreed 20:38:59 sdague, OTOH, I do like the idea of an OpenStack Compatible Cloud TM 20:39:11 * zehicle_at_dell repeats that a single topic meeting on this may be helpful to resolve concerns and help collaboration. I don't want to hijack TC meetings with concerns over the broader process 20:39:20 Ok, so... 20:39:24 zehicle_at_dell: ++ to separate meeting 20:39:37 dhellmann and I now have https://review.openstack.org/#/c/100675 ready for people to take another look please 20:39:38 we've spent a ton of a lot of meetings on this 20:39:51 markmc: sure. Though I think we've got a lot of internal technical work to make that meaningful. /me stares at how optional the nova api is, for instance. 20:40:02 could at least move to the ML after this to keep it moving 20:40:03 russellb, yes and likely many more to come. there's a lot at stake and we're taking it slow 20:40:08 zehicle: right, I'd like to see if i can find a middle path first 20:40:13 sdague, we can value people with products that are compatible with OpenStack; but we likely value them less than OpenStack products 20:40:24 but then we can certainly do a single-topic meeting 20:40:33 could even be a TC meeting dedicated to the issue 20:40:36 it seems like this derails the TC every time it comes up -- which should tell us something about the topic 20:40:52 yes, we need to clarify our positions 20:41:10 * zehicle_at_dell is in the Bay area this week. happy to also meet 1x1 with people if they'd like. 20:41:21 ok, so I'll be in touch via IRC with various members soon 20:41:34 and will consider dedicating a full meeting to that issue, maybe next week 20:41:48 thanks, ttx. 20:41:57 ttx, please let me know so I can include DefCore members 20:41:57 zehicle_at_dell: I would actually prefer that you not meet 1:1 with anyone. Having separate in person meetings that we can't all attend is in part why some of us are confused. 20:42:29 zehicle: you can already warn them, that would be 20:00 UTC on Tuesday 20:42:44 dhellmanm, hmmm. not sure I agree 20:42:57 The other review is: 20:43:03 * Propose scores for DefCore capabilities (https://review.openstack.org/100721) (https://review.openstack.org/100722) 20:43:10 I think it's in the same bag though. 20:43:12 zehicle_at_dell: the DefCore team has produced a lot of written stuff that I personally have had trouble wading through because I don't have the context from the meetings. 20:43:21 #topic Election behavior guidelines 20:43:44 We have two competing proposals now: 20:43:48 * Adds a resolution addressing expected election behaviour (https://review.openstack.org/98675) 20:43:52 * A resolution on standards of behavior during elections (https://review.openstack.org/100445) 20:43:52 zehicle_at_dell: that's not a knock on your work, just a thing I've been struggling with as I review the output 20:43:59 Both describe expected behavior from candidates in a way that will reach the intended goal IMHO 20:44:03 ttx, heh, which is which :) 20:44:07 They differ in the way they suggest issues are to be handled: 20:44:17 First one describe a process to report issues privately, which then may escalate to the Community Code of Conduct violation process 20:44:28 Second one suggests to report issues publicly and let voters be influenced (or not) by the publicly reported issue 20:44:38 Personally I prefer the first one because (1) not everybody is comfortable with reporting issues publicly 20:44:49 and (2) I fear that without independent investigation imaginary claims would have the same impact as real issues in the public forum 20:44:58 BUT it's worth noting that whichever we choose to explicitly promote, both options are always present: 20:45:01 dhellmann, that's why we create summaries. don't know how to have a transparent process with less clutter. the 1x1 helps me have better back and forth with people who have strong opinions 20:45:03 ttx: i agree, and i believe the second one does not address the actual problems we've seen 20:45:03 - you can always report a CoC violation 20:45:08 - you can always publicly shame behavior in an attempt to influence voters 20:45:20 A third proposal would be to not promote any specific way issues are to be handled. 20:45:27 and just adopt Anita's draft line 1-21 or Eoghan's draft lines 1-12 + 30-42 20:45:31 The third way sounds like a cop out to me 20:45:33 i'd like to find out what people think the reporting mechanism should be, and fix up the first one. 20:45:40 so I'd be fine with the private reporting, though I do like the pledge in the 2nd one 20:45:56 to me, the reporting mechanism should be the same as a violation of code of conduct 20:45:59 * anteaya would like to know what people think will happen if someone loses foundation membership 20:46:00 because I actually think that, by itself, is a powerful deterant 20:46:03 easier to explain and remember 20:46:19 sdague: i don't like the pledge -- i think forced pledges are insincere and we've seen no objectionable behavior from actual candidates 20:46:20 as was pointed out, the pledge wouldn't have solved the issue we had last cycle because the candidate wasn't acting "badly" 20:46:33 anteaya: can't vote, can't be elected to TC (can still be PTL I think) 20:46:35 sdague: i think that fundamentally, it's the communication that's the deterrent, and that's what we should do 20:46:47 txx can't get summit passes 20:46:53 and we essentially have the "no clear reporting guidelines" now, and so we have this issue that no one wants to talk about publicly 20:47:05 hmm no, can't be elected PTl either 20:47:06 so what is wrong with losing voting previledges and summit passes? 20:47:15 and not being able to stand for election 20:47:17 anteaya: tat we can easily fix 20:47:21 (the pass) 20:47:25 right 20:47:25 I'm also a bit concerned about the pledge and any legal ramifications for poor wording or definitions that aren't crisply legal 20:47:33 so all the lose is the right to vote and lead 20:47:51 I dont' think that is excessive for violations of fair elections 20:47:52 what if the candidate herself is not the bad actor? Has that already been discussed? 20:48:08 and to be fair, i think anteaya's inclusion of language about the existing CoC is helpful -- it already exists, says what it says and has penalties; nothing about this can or should change that. 20:48:28 we could not mention it, but that won't change that it exists 20:48:45 jeblair: right, that's my point about the choice not being that much relevant anyway, both options exist already 20:49:05 ttx: yeah 20:49:30 rather than focus on punishment, maybe it should be on correcting our culture 20:49:43 mostly this gives me the right to investigate, if someone makes a report, and says who I report to 20:49:47 e.g. in the cases in the last cycle, it might have been enough to talk about the concrete issues without naming names 20:49:48 jeblair: which is why a 3rd proposal where you just reaffirm the behavior and link to the CoC would be sufficient 20:50:16 I'm not sure the people involved realized they were necessarily doing anything terribly wrong 20:50:19 markmc: i'm not sure eglynn's proposal achieves "correcting our culture" better, though 20:50:20 that's what needs correcting 20:50:37 ttx, it talks about culture, and reinforcing it 20:50:38 really? 20:50:44 I fear that public shaming is not the solution we shoud encourage either 20:51:04 ttx, "talk about the concrete issues without naming names" 20:51:10 you think people in opensource dint' know that circualteing private emails was not a good idea 20:51:20 i.e. not quite publich shaming, but at least publicly discuss the behavior 20:51:22 and using the voters list for the emails? 20:51:29 (or private campaign events) 20:51:43 I don't buy they didn't know 20:51:49 anteaya, I was a recipient of that email, saw how the recipients responded to it and felt the sender's apology was sincere 20:52:00 anteaya, people can get carried away with their enthusiasm 20:52:05 okay well you know more than I 20:52:09 because I never saw it 20:52:11 So, I think it might be harder than we realize to draw the line by the way 20:52:14 becaue noone filed a report 20:52:19 anteaya, that's what concerns me about all of this - it lacks empathy for people making genuine mistakes 20:52:24 anteaya: besides, legally, if I RSVP to a Summit party, how do I know I haven't opted in to being on a mailing? 20:52:27 So... Is a summit party "hosted" by a person intending to run for election inappropriate for example? 20:52:37 markmc: so as a receiptent do you think this was a genuine mistake? 20:52:39 markmc: yes, me too 20:52:46 is it really the job of the resolution to show empathy? 20:52:47 anteaya, very much so, yes 20:52:50 and do you think if I read the email, I would reach the same conclusion? 20:52:54 anteaya, poorly judged, I'd say 20:53:05 do you think I would conclude the same as you 20:53:06 anteaya, where the sender realized the error when it was pointed out 20:53:09 markwash: not empathy but fairness and rights 20:53:23 russellb, would you agree ? 20:53:33 i think the apology was sincere, yes 20:53:39 so yes, agreed 20:53:47 mikal: good question, and I'd like to think if there was some formal way to raise the issue an attendee who was uncomfortable would at least have a way to get an answer. 20:53:47 it wasn't acceptable behavior, that's not the point 20:53:48 so the email and using teh voters list was one incident 20:53:49 markmc: i think the existing proposal in 1 is quite fair -- it does not rely on the election inspector to make significant judgements -- it does rely on the ED to do so, but he or she is already empowered by the bylaws and coc to do exactly that 20:53:51 very poorly judged mistake, with a sincere apology after it was calledo ut 20:53:57 the other was the private meeting 20:54:05 dhellmann: but we have a reporting structure already 20:54:05 i don't know if it was a single incident or not, but markmc were on the same one 20:54:13 markmc and I* 20:54:13 annegent_: do we? what is it? 20:54:26 I could go with a new version of eglynn's proposal that would at least mention that the CCoC covers election behavior, and does not go into such great lengths to encourage public shaming 20:54:35 annegent_: yes, I too would like to know 20:54:42 markmc: i feel like we could drop the second part of the first proposal and we would have a lot more agreement, however, i'm not sure it would actually change any of the facts 20:54:43 annegent_ : I thought anteaya said she didn't receive any complaints? 20:54:44 since i didn't and noone else did 20:54:51 dhellmann: http://www.openstack.org/legal/code-of-conduct/ << possibly we need a tc resolution for our elections that enhances this, but this document is well tested and clear 20:54:53 whom I consulted while this was going on 20:54:53 or with a new version of Anita's that would not feel like empathy is not an option 20:55:09 annegent_: yes, that is what my proposal references 20:55:10 dhellmann: but anyone could report the violation, does it have to go through election officials? 20:55:23 I had many questions during this situation 20:55:25 ttx: I could draft something of that ilk, keeping the original "ethos" of the proposal 20:55:26 annegent_: technically, not 20:55:28 and zero reports 20:55:31