20:02:01 <ttx> #startmeeting tc
20:02:02 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:03 <jeblair> annegent_: ping
20:02:05 <openstack> The meeting name has been set to 'tc'
20:02:09 <ttx> Agenda for today:
20:02:17 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:28 <ttx> markwash: you're available now ?
20:02:35 <markwash> I'm here!
20:02:36 <markwash> :-)
20:02:38 <ttx> #topic Glance gap coverage plan
20:02:41 <annegent_> jeblair: pong
20:02:50 <ttx> Two weeks ago a single gap was raised against Glance in the integrated requirements gap analysis:
20:02:54 <zehicle_at_dell> o/
20:02:56 <ttx> - Lack of testing a binary image in integration tests
20:03:03 <ttx> markwash posted the following plan to address it:
20:03:09 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Glance_Gap_Coverage
20:03:18 <ttx> Pretty simple, looks good to me
20:03:31 <markwash> yeah, we targeted j-2 and feel good about it
20:03:42 <markwash> tried to get it done this past week but couldn't quite find the immediate manpower
20:03:46 <ttx> Unless someone has an issue with it, I'll add it to the TC wikipage for tracking
20:04:01 <dhellmann> seems good to me
20:04:12 <ttx> and we'll haunt markwash back about this targeting in a few weeks time
20:04:24 <ttx> when we review gap coverage progress post-j2
20:04:27 <sdague> wfm
20:04:35 <ttx> #action ttx to add Glance gap coverage plan to TechCommittee wiki page for tracking
20:04:55 <ttx> #topic Other governance changes in review
20:05:04 <ttx> * Modify Images mission to fit Artifact Repository (https://review.openstack.org/98002)
20:05:10 <markwash> thanks dhellman for the wording
20:05:22 <dhellmann> markwash: glad I could help :-)
20:05:23 <ttx> This one is Glance territory too
20:05:27 <ttx> A new wording was proposed, hopefully it will please enough people.
20:05:35 <ttx> The marketing folks approached me about the change from "image service" to "artifact repository"
20:05:44 <markwash> I have a call with them tomorrow
20:05:46 <ttx> they want to have a chance to discuss that name and weigh in on the review before this is finally approved
20:06:00 <ttx> Nobody suggested something better yet, though
20:06:14 <ttx> but that name leaks into the "official naming" so I think that request is fair
20:06:15 <annegent_> it means docs changes too
20:06:26 <markwash> 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 <annegent_> we use Image Service currently
20:06:47 <ttx> so yes, I'll stall this until at least next meeting
20:07:28 <annegent_> ttx: markwash: can I get in on that call?
20:07:39 * annegent_ is not a marketer
20:07:50 <ttx> annegent_: i'm not on that call, but maybe markwash can include you
20:07:54 <markwash> annegent_: I'll ask to have you included
20:07:57 <annegent_> thanks markwash
20:08:00 <lsell> yes
20:08:02 <ttx> * Add translation support requirement (https://review.openstack.org/97872)
20:08:20 <ttx> Requirements changes need consensus, as they reflect the base set of requirements we all agree on
20:08:27 <ttx> I'm not sure this one is ready to gather that consensus
20:08:39 <ttx> Looks like policy could mature a bit and the technical result could be tested
20:08:42 <dhellmann> The i18n team has been trying for 2 summits to move ahead on this.
20:09:00 <dhellmann> 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 <ttx> dhellman_: that's fair
20:09:17 <dhellmann> we have a lot of the tooling in place already
20:09:28 <dhellmann> including the CI jobs
20:09:30 <ttx> dhellman_: personally I think of two things
20:09:36 <dhellmann> and a few projects are accepting changes
20:09:43 <ttx> (1) we need to somehow test that what we do is usable
20:09:53 <ttx> because I know of at least two releases where it wasn't the case
20:09:58 <dhellmann> ok
20:10:03 <sdague> dhellmann: where are the CI jobs? I guess that's something I'm not aware of.
20:10:07 <ttx> because there is no automated test around that
20:10:15 <dhellmann> sdague: jobs to extract the messages, not to run tests
20:10:29 <jeblair> heh, literally "continuous integration" :)
20:10:33 <jeblair> unlike most of the jobs we run
20:10:37 <sdague> ok, fair :)
20:10:42 <dhellmann> unit tests exist, so what other tests do we want? a full d-g job with an alternate translation?
20:10:45 <sdague> but that's not the jobs we know we need
20:10:49 <jeblair> sdague: ++
20:10:49 <sdague> dhellmann: yeh
20:10:57 <ttx> (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 <dhellmann> 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 <ttx> markmc: do we have support for multiple translations domains now ?
20:11:23 * ttx lost track of that
20:11:23 <markmc> ttx, dhellman has written some nice docs clarifying some of this in the last week
20:11:24 <sdague> dhellmann: even nightlies are fine
20:11:42 <dhellmann> 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 <annegent_> dhellmann: ttx: and documentation
20:12:07 <sdague> 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 <jeblair> ttx: yeah, if that's something we want to do, we should standardize that (2 domains) at the tc level
20:12:11 <dhellmann> docs are waiting for the requirements issue to clear up so they can merge: https://review.openstack.org/#/c/96961/
20:12:19 <ttx> the current wording places end-user-facing and operators-facing on the same level though.
20:12:22 <markmc> 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 <markmc> docs haven't been merged yet
20:12:46 <dhellmann> ttx, jeblair : there are 5 different domains
20:12:57 <dhellmann> that's what the translators wanted
20:13:04 <jeblair> dhellmann: user + 4 logs?
20:13:07 <dhellmann> they actually wanted 6, but we agreed not to translate debug messages
20:13:07 <dhellmann> yes
20:13:11 <dhellmann> https://review.openstack.org/#/c/96961/7/doc/source/guidelines.rst
20:13:17 <ttx> dhellmann: ok, so it looks like we could iterate on the current proposal
20:13:24 <markmc> I think this is progressing well, but we do need the policy to link to these guidelines
20:13:30 <markmc> and then there's the testing issue
20:13:31 <ttx> i'll get my feedback in
20:13:51 <dhellmann> ok, I think we can land the doc changes ^^ this week, and I can update the policy
20:14:06 <dhellmann> 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 <dhellmann> was that the only objection?
20:14:24 <ttx> it felt like we were farther away from a solution, reading the comments
20:14:34 * dhellmann thought so too
20:14:51 <jeblair> i'm optimistic
20:15:01 <dhellmann> #action dhellmann talk to i18n team about finding someone to create a test job with translations
20:15:15 <annegent_> dhellmann: we have a doc gate test for translation job on japanese
20:15:18 <annegent_> dhellmann: if it helps
20:15:32 <dhellmann> annegent_: yes, that may help as an example
20:15:38 <ttx> OK, let's iterate a bit more on this, if it's not blocked
20:15:57 <dhellmann> no,  it sounds like they have more work to do, and that's fine now that we know what it is
20:15:57 <ttx> next topic...
20:15:59 <devananda> dhellmann: with those doc changes, I think my concern is addressed.
20:16:08 <dhellmann> devananda: ok, thanks
20:16:20 <ttx> nice doc
20:16:38 <ttx> #topic Defcore
20:16:48 <ttx> We have two resolutions covering the recent requests for technical input from Defcore:
20:16:57 <ttx> * Resolution requesting designated sections from projects (https://review.openstack.org/100675)
20:17:12 <ttx> Still missing input from Swift, Glance, keystone, Horizon, Neutron and Cinder
20:17:19 <mikal> So we talked about this one last week
20:17:22 <mikal> ttx: well, not really
20:17:23 <ttx> I informed all those PTLs during the 1:1 sync points today
20:17:24 <markwash> does anyone here have the link to the original etherpad?
20:17:36 <mikal> My proposal was that we merge this, and then take patches from those projects on top
20:17:48 <ttx> mikal: ah. hmm
20:17:50 <zehicle_at_dell> #link https://etherpad.openstack.org/p/openstack-designated-sections
20:17:56 <markwash> ty
20:18:06 <mikal> ttx: hence the TODOs
20:18:09 <ttx> mikal: the trick is we'd merge (i.e. approve) a partial thing
20:18:11 <dhellmann> 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 <ttx> mikal: I thought people would just propose further changesets
20:18:25 <mikal> dhellmann: I wanted an example to help PTLs work out what to write
20:18:29 <jeblair> ttx, mikal: was there a -dev list thread for these?
20:18:33 <dhellmann> mikal: I thought that's probably what you were doing.
20:18:39 <russellb> further changesets might get frustrating, fragmenting discussion
20:18:41 <mikal> ttx: well, I wanted to allow the TC to discuss each project indivisually
20:18:58 <mikal> i.e. if we dig into a thing on neutron, we should not block say glance
20:18:58 <dhellmann> they can submit patches on top of this patch, too, it doesn't have to merge first
20:19:04 <ttx> mikal: right, I just fear that will push us past "end of month"
20:19:06 <dhellmann> mikal: +1
20:19:17 <mikal> ttx: well, it means we can do them in parallel
20:19:19 <eglynn> 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 <mikal> But I agree that I've sat on this too long
20:19:56 <ttx> jeblair: no specific thread on that specific request, no
20:20:06 <zehicle_at_dell> eglynn, it's not required
20:20:12 <ttx> jeblair: it's been documented through all the defcore posts
20:20:26 <zehicle_at_dell> we agreed with the Tempest team that we could test Havana using trunk branchless
20:20:40 <ttx> also input was already provided in an etherpad before
20:20:41 <zehicle_at_dell> since Havana is advisory, it's OK
20:20:43 <markmc> we could add a designated sections template and ask each project to complete it
20:20:55 <markmc> don't need all projects in one file
20:21:00 <ttx> markmc: +1
20:21:09 <eglynn> zehicle_at_dell: ok, interesting ... I though branchless tempest only applied to stable/icehouse not before
20:21:13 <sdague> zehicle_at_dell: branchless tempest doesn't work on havana
20:21:16 <mikal> markmc: that's true, I hadn't thought of that
20:21:22 <sdague> it's icehouse and forward
20:21:26 <mikal> We could for example build a little directory tree or something
20:21:29 <dhellmann> markmc: we could add that to the programs.yaml file, too
20:21:30 <eglynn> zehicle_at_dell: i.e. wot sdague said
20:21:32 <zehicle_at_dell> eglynn, we're testing the stable APIs.  It's a pretty good test of the ones we are most interested in
20:21:34 <sdague> there were too many API breaks between havana and icehouse
20:21:35 <ttx> mikal: maybe make a directory under resolutions
20:21:41 * dhellmann still needs to work on turning programs.yaml into html
20:21:51 <mikal> eglynn: well, except it will change over time and the historical values matter
20:22:02 <mikal> Would people like me to refactor this into a directory and see what it looks like?
20:22:07 <zehicle_at_dell> sdague, it they are breaks in "core" APIs then we want to know that
20:22:08 <ttx> mikal: +1
20:22:09 <dhellmann> +1
20:22:17 <mikal> I could do that now and we could circle back in a few minutes
20:22:39 <ttx> mikal: also redirect people to doing their own change, because I told them all to changeset your original change
20:22:52 <ttx> mikal: so you can add a note on the commit message to redirect them
20:22:55 <sdague> 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 <jeblair> 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 <russellb> jeblair: correct.
20:23:13 <zehicle_at_dell> 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 <mikal> jeblair: OMG, can we decouple that for just a moment?
20:23:28 <mikal> I'm happy to discuss it, but I want to unblock the process first
20:23:28 <russellb> jeblair: well, potentially.
20:23:31 <sdague> 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 <ttx> jeblair: well, they would need to run a few other openstack pieces :)
20:23:37 <sdague> zehicle_at_dell: agreed
20:23:42 <zehicle_at_dell> sdague, happy to discuss it more.  would want to involve davidlenwell_
20:23:46 <sdague> that's why our focus is icehouse forward
20:23:59 <jeblair> mikal: okay sure -- i thought we were good on the process.  :)
20:24:18 <sdague> plus it gets rid of backport burden
20:24:20 <ttx> 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 <mikal> jeblair: well, except I have to do this refacotr
20:24:26 <ttx> trademarks to be defined
20:24:27 <jeblair> mikal: it's the first time we're seeing this whole thing converge and i'm just sanity checking my understanding
20:24:32 <jeblair> mikal: carry on!
20:25:04 <markmc> 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 <zehicle_at_dell> ttx, the specific trademarks are "powered" and "compatible" as defined by the Foundation
20:25:19 <zehicle_at_dell> but compatible does not mean quite what you may thing - it's not about APIs
20:25:20 <ttx> zehicle: right
20:25:23 <markmc> ttx, OpenStack Compatible (if such a TM existed) would be where you're not running the designated sections
20:25:58 <ttx> markmc: so.. "OpenStack powered" ?
20:26:02 <markmc> ttx, yeah
20:26:06 <zehicle_at_dell> 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 <markmc> zehicle_at_dell, that's why I said "(if such a TM existed)"
20:26:28 <zehicle_at_dell> markc, and it's not clear that we will at this time
20:26:39 <markmc> and it's markmc not markc
20:26:50 <zehicle_at_dell> markc, I understand.  the trick is that there IS a compatible mark.
20:27:17 <dhellmann> 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 <ttx> 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 <mikal> 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 <dhellmann> mikal: like, you say "scheduler driver" but that implies the scheduler service is still considered designated?
20:28:12 <ttx> because I want to just designate areas of code that are desogned to be extensible
20:28:13 <markmc> ttx, as in, that would be the TC's consensus input to the board's TM policy decision making ?
20:28:18 <jeblair> ttx: i think that may be in conflict with the actual content of that change
20:28:28 <mikal> dhellmann: agreed. You run the service, but you can plug in your own algorithm
20:28:31 <dhellmann> cool
20:28:52 <mikal> Is https://review.openstack.org/#/c/100675/4 closer?
20:28:58 <dhellmann> 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 <russellb> ttx: i don't know why we'd list anything if we felt you shouldn't actually replace code
20:29:17 <mikal> dhellmann: noting that we have already passed a set of guidelines which basically say that
20:29:22 <ttx> 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 <mikal> i.e. we're being consistent over time which is a nice feeling
20:29:30 <jeblair> mikal: you have extra content in 'instructions.rst'
20:29:38 <mikal> jeblair: doh
20:29:44 <dhellmann> 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 <ttx> 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 <russellb> ttx: we can't pretend to be ignorant to the purpose of why we're providing this list ...
20:30:00 <mikal> dhellmann: ta
20:30:16 <mikal> dhellmann: perhaps instructions.rst should be up a dir level?
20:30:28 <mikal> dhellmann: and include the sub files?
20:30:36 <mikal> jeblair: fix uploaded
20:30:40 <ttx> russellb: the alternative would be what ? To refuse to produce that information, so that they have to make their own idea ?
20:30:41 <dhellmann> mikal: that would work, maybe using a toctree
20:30:49 <mikal> dhellmann: got an example I can copy?
20:30:50 <ttx> I prefer to provide a conservative version
20:31:13 <jeblair> ttx: i lean toward very conservative.
20:31:14 <ttx> at least we cna make sure that it follows technical lines
20:31:26 <dhellmann> mikal: let me whip one up
20:31:28 <russellb> 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 <mikal> 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 <ttx> jeblair: we approved guidelines before -- do you still agree with them ?
20:31:41 <mikal> dhellmann: Or just upload a new version of that review with it done...
20:31:46 <mikal> dhellmann: we don't need too much process for that
20:32:00 <ttx> jeblair: http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20140402-defcore-designated-sections-guidelines.rst
20:32:20 <dhellmann> mikal: ok, doing that now
20:32:50 <mikal> dhellmann: :)
20:33:17 <ttx> If we follow those guidelines we previously approved, we can provide a technical answer
20:33:43 <markmc> 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 <russellb> markmc: +100
20:33:55 <ttx> markmc: that I agree on
20:34:10 <markmc> ttx, we can provide technical input (perhaps policy opinions too), but ultimately the board is the one making this policy decision
20:34:15 <ttx> we need to be able to provide that etchnical info without endorsing the policy that might be driven from it
20:34:19 <devananda> markmc: ++
20:34:25 <jeblair> ttx: i abstained from that vote.  i'm still trying to understand the ramifications of this; thus my question earlier.
20:34:25 <mikal> markmc: do you feel we're doing that now though?
20:34:35 <mikal> markmc: we're effectively just listing the areas we think plugins are ok
20:34:45 <russellb> i feel we're being roped in as accomplices by generating this list, yes.
20:34:59 <russellb> and the more i think about it, the less I like this whole thing.
20:35:23 <jeblair> ttx: i will vote on the actual resolutions, however.
20:35:25 <markmc> mikal, I've seen language in the etherpads that suggests we have full control over this aspect of the TM policy
20:35:26 <devananda> 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 <mikal> Picking on the nova example, I think that horse has bolted for all these examples
20:35:35 <dhellmann> mikal: updated
20:36:01 <dhellmann> mikal: oops, should update the instructions, too
20:36:11 <jeblair> 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 <mikal> dhellmann: yeah, just noticed that
20:36:40 <zehicle_at_dell> russellb, "roped in" - we're trying to have Board & TC collaboration FWIW
20:37:05 <dhellmann> mikal: fixed
20:37:06 <russellb> zehicle_at_dell: *nod* and that much is appreciated
20:37:08 <mikal> dhellmann: am I fixing or you?
20:37:09 <mikal> Ok, cool
20:37:10 <sdague> 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 <sdague> (note: mostly playing devil's advocate there, because I want people upstream as much as possible)
20:37:33 <markmc> sdague, yeah, it's just about the TM
20:37:35 <ttx> hmm
20:37:44 <markmc> sdague, we can value people's freedom to mix with proprietary
20:37:49 <ttx> so I think we should have a lot of discussions about this this week
20:37:56 <sdague> markmc: ok, sure, I agree with that
20:37:56 <ttx> this meeting won't be enough
20:37:57 <markmc> sdague, we don't have to value it so much that they should be able to call it OpenStack
20:38:41 <russellb> markmc: indeed
20:38:53 <jeblair> ttx: agreed
20:38:59 <markmc> 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 <mikal> Ok, so...
20:39:24 <devananda> zehicle_at_dell: ++ to separate meeting
20:39:37 <mikal> dhellmann and I now have https://review.openstack.org/#/c/100675 ready for people to take another look please
20:39:38 <russellb> we've spent a ton of a lot of meetings on this
20:39:51 <sdague> 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 <russellb> could at least move to the ML after this to keep it moving
20:40:03 <zehicle_at_dell> russellb, yes and likely many more to come.  there's a lot at stake and we're taking it slow
20:40:08 <ttx> zehicle: right, I'd like to see if i can find a middle path first
20:40:13 <markmc> sdague, we can value people with products that are compatible with OpenStack; but we likely value them less than OpenStack products
20:40:24 <ttx> but then we can certainly do a single-topic meeting
20:40:33 <ttx> could even be a TC meeting dedicated to the issue
20:40:36 <devananda> it seems like this derails the TC every time it comes up -- which should tell us something about the topic
20:40:52 <ttx> 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 <ttx> ok, so I'll be in touch via IRC with various members soon
20:41:34 <ttx> and will consider dedicating a full meeting to that issue, maybe next week
20:41:48 <russellb> thanks, ttx.
20:41:57 <zehicle_at_dell> ttx, please let me know so I can include DefCore members
20:41:57 <dhellmann> 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 <ttx> zehicle: you can already warn them, that would be 20:00 UTC on Tuesday
20:42:44 <zehicle_at_dell> dhellmanm, hmmm. not sure I agree
20:42:57 <ttx> The other review is:
20:43:03 <ttx> * Propose scores for DefCore capabilities (https://review.openstack.org/100721) (https://review.openstack.org/100722)
20:43:10 <ttx> I think it's in the same bag though.
20:43:12 <dhellmann> 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 <ttx> #topic Election behavior guidelines
20:43:44 <ttx> We have two competing proposals now:
20:43:48 <ttx> * Adds a resolution addressing expected election behaviour (https://review.openstack.org/98675)
20:43:52 <ttx> * A resolution on standards of behavior during elections (https://review.openstack.org/100445)
20:43:52 <dhellmann> 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 <ttx> Both describe expected behavior from candidates in a way that will reach the intended goal IMHO
20:44:03 <markmc> ttx, heh, which is which :)
20:44:07 <ttx> They differ in the way they suggest issues are to be handled:
20:44:17 <ttx> First one describe a process to report issues privately, which then may escalate to the Community Code of Conduct violation process
20:44:28 <ttx> Second one suggests to report issues publicly and let voters be influenced (or not) by the publicly reported issue
20:44:38 <ttx> Personally I prefer the first one because (1) not everybody is comfortable with reporting issues publicly
20:44:49 <ttx> 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 <ttx> BUT it's worth noting that whichever we choose to explicitly promote, both options are always present:
20:45:01 <zehicle_at_dell> 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 <jeblair> ttx: i agree, and i believe the second one does not address the actual problems we've seen
20:45:03 <ttx> - you can always report a CoC violation
20:45:08 <ttx> - you can always publicly shame behavior in an attempt to influence voters
20:45:20 <ttx> A third proposal would be to not promote any specific way issues are to be handled.
20:45:27 <ttx> and just adopt Anita's draft line 1-21 or Eoghan's draft lines 1-12 + 30-42
20:45:31 <mikal> The third way sounds like a cop out to me
20:45:33 <jeblair> i'd like to find out what people think the reporting mechanism should be, and fix up the first one.
20:45:40 <sdague> so I'd be fine with the private reporting, though I do like the pledge in the 2nd one
20:45:56 <annegent_> 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 <sdague> because I actually think that, by itself, is a powerful deterant
20:46:03 <annegent_> easier to explain and remember
20:46:19 <jeblair> 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 <dhellmann> 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 <ttx> anteaya: can't vote, can't be elected to TC (can still be PTL I think)
20:46:35 <jeblair> sdague: i think that fundamentally, it's the communication that's the deterrent, and that's what we should do
20:46:47 <anteaya> txx can't get summit passes
20:46:53 <dhellmann> 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 <ttx> hmm no, can't be elected PTl either
20:47:06 <anteaya> so what is wrong with losing voting previledges and summit passes?
20:47:15 <anteaya> and not being able to stand for election
20:47:17 <ttx> anteaya: tat we can easily fix
20:47:21 <ttx> (the pass)
20:47:25 <anteaya> right
20:47:25 <annegent_> 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 <anteaya> so all the lose is the right to vote and lead
20:47:51 <anteaya> I dont' think that is excessive for violations of fair elections
20:47:52 <annegent_> what if the candidate herself is not the bad actor? Has that already been discussed?
20:48:08 <jeblair> 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 <jeblair> we could not mention it, but that won't change that it exists
20:48:45 <ttx> jeblair: right, that's my point about the choice not being that much relevant anyway, both options exist already
20:49:05 <jeblair> ttx: yeah
20:49:30 <markmc> rather than focus on punishment, maybe it should be on correcting our culture
20:49:43 <anteaya> mostly this gives me the right to investigate, if someone makes a report, and says who I report to
20:49:47 <markmc> 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 <ttx> jeblair: which is why a 3rd proposal where you just reaffirm the behavior and link to the CoC would be sufficient
20:50:16 <markmc> I'm not sure the people involved realized they were necessarily doing anything terribly wrong
20:50:19 <ttx> markmc: i'm not sure eglynn's proposal achieves "correcting our culture" better, though
20:50:20 <markmc> that's what needs correcting
20:50:37 <markmc> ttx, it talks about culture, and reinforcing it
20:50:38 <anteaya> really?
20:50:44 <ttx> I fear that public shaming is not the solution we shoud encourage either
20:51:04 <markmc> ttx, "talk about the concrete issues without naming names"
20:51:10 <anteaya> you think people in opensource dint' know that circualteing private emails was not a good idea
20:51:20 <markmc> i.e. not quite publich shaming, but at least publicly discuss the behavior
20:51:22 <anteaya> and using the voters list for the emails?
20:51:29 <jeblair> (or private campaign events)
20:51:43 <anteaya> I don't buy they didn't know
20:51:49 <markmc> 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 <markmc> anteaya, people can get carried away with their enthusiasm
20:52:05 <anteaya> okay well you know more than I
20:52:09 <anteaya> because I never saw it
20:52:11 <mikal> So, I think it might be harder than we realize to draw the line by the way
20:52:14 <anteaya> becaue noone filed a report
20:52:19 <markmc> anteaya, that's what concerns me about all of this - it lacks empathy for people making genuine mistakes
20:52:24 <annegent_> 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 <mikal> So... Is a summit party "hosted" by a person intending to run for election inappropriate for example?
20:52:37 <anteaya> markmc: so as a receiptent do you think this was a genuine mistake?
20:52:39 <annegent_> markmc: yes, me too
20:52:46 <markwash> is it really the job of the resolution to show empathy?
20:52:47 <markmc> anteaya, very much so, yes
20:52:50 <anteaya> and do you think if I read the email, I would reach the same conclusion?
20:52:54 <markmc> anteaya, poorly judged, I'd say
20:53:05 <anteaya> do you think I would conclude the same as you
20:53:06 <markmc> anteaya, where the sender realized the error when it was pointed out
20:53:09 <annegent_> markwash: not empathy but fairness and rights
20:53:23 <markmc> russellb, would you agree ?
20:53:33 <russellb> i think the apology was sincere, yes
20:53:39 <russellb> so yes, agreed
20:53:47 <dhellmann> 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 <markmc> it wasn't acceptable behavior, that's not the point
20:53:48 <anteaya> so the email and using teh voters list was one incident
20:53:49 <jeblair> 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 <russellb> very poorly judged mistake, with a sincere apology after it was calledo ut
20:53:57 <anteaya> the other was the private meeting
20:54:05 <annegent_> dhellmann: but we have a reporting structure already
20:54:05 <russellb> i don't know if it was a single incident or not, but markmc were on the same one
20:54:13 <russellb> markmc and I*
20:54:13 <dhellmann> annegent_: do we? what is it?
20:54:26 <ttx> 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 <anteaya> annegent_: yes, I too would like to know
20:54:42 <jeblair> 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 <dhellmann> annegent_ : I thought anteaya said she didn't receive any complaints?
20:54:44 <anteaya> since i didn't and noone else did
20:54:51 <annegent_> 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 <anteaya> whom I consulted while this was going on
20:54:53 <ttx> or with a new version of Anita's that would not feel like empathy  is not an option
20:55:09 <anteaya> annegent_: yes, that is what my proposal references
20:55:10 <annegent_> dhellmann: but anyone could report the violation, does it have to go through election officials?
20:55:23 <anteaya> I had many questions during this situation
20:55:25 <eglynn> ttx: I could draft something of that ilk, keeping the original "ethos" of the proposal
20:55:26 <ttx> annegent_: technically, not
20:55:28 <anteaya> and zero reports
20:55:31 <annegent_> ttx: so you're asking for another proposal?
20:55:32 <dhellmann> annegent_: I don't know. Maybe you're right and we just need to clarify the answer to that question
20:55:50 <jeblair> ttx: i'd be okay with just the first part of anteaya's but i feel like we'd be dropping the ball on trying to clarify a policy and not actually clarifying how to deal with violations
20:55:59 <anteaya> jeblair: +
20:56:07 <anteaya> we need to know how this is resolved
20:56:15 <annegent_> to me, we either are drafting a separate code of conduct for tc / ptl candidates or asking those candidates and the electorate to follow the existing CoC
20:56:22 <ttx> annegent_: I think we can't choose between the two because we want both (and will have both anyway)
20:56:24 <annegent_> there may be a third option
20:56:24 <anteaya> otherwise we end up feeling it isn't even after it is
20:56:43 <sdague> I do think the empathy piece is important. As we grow in community size, we don't know each other like we used to, and if we don't give the benefit of the doubt I'm concerned where that takes us
20:56:48 <ttx> annegent_: since nothing will prevent people from filing CCoC violations and/or publicshame people on -dev
20:56:54 <anteaya> take the shanley thing, which reached a resolution, but people thought it didnt'
20:57:01 <markwash> but empathy has other vehicles than the resolution, too
20:57:02 <anteaya> and still have the perception that it didn't
20:57:04 <ttx> choosing one feels like we promote one behavior over the other
20:57:05 <dhellmann> sdague: +1
20:57:31 <jeblair> sdague: what do you think the reporting mechanism should be?
20:57:36 <anteaya> I'm really surprised at suggestions that conducting an investigation implies I will lack empathy
20:57:51 <anteaya> I just want to find the facts
20:57:56 <anteaya> not dwell in gossip
20:58:16 <dhellmann> ttx: I don't know that I could point to any example of public shaming in open source that had a good outcome.
20:58:27 <annegent_> anteaya: it's not you specifically, it's whether it makes sense to make the election official apart from the foundation
20:58:28 <mikal> anteaya: I agree. There is no harm in the election officials investigating concerns.
20:58:38 <anteaya> mikal: thank you
20:58:45 <anteaya> that is all I am asking for
20:58:50 <anteaya> the abiltiy to investigate
20:58:57 <annegent_> and to me, the election officials serve an important role of knowing the CoC and reporting mechanisms but that they shouldn't be separate from the rest of the membership
20:58:57 <anteaya> if the mistake was genuine
20:59:02 <anteaya> that comes out in the facts
20:59:03 <markmc> anteaya, would you (as the election official) be comfortable summarizing complaints with names redacted?
20:59:08 <markmc> anteaya, publicly
20:59:16 <annegent_> I'd rather the foundation do the investigations and that I know who to report to rather than spreading out the reporting further
20:59:19 <anteaya> markmc: if that is the structure that is decided upon, yes
20:59:29 <markmc> that could be a part of the process
20:59:37 <markmc> not necessarily the whole thing
20:59:39 <anteaya> though my preference would be to report to at least one other body before doing so
20:59:39 <markmc> just an idea
20:59:42 <jbryce> this last time around, i heard concerns after the election was already closed and a comment from those people that they weren’t sure how to report beforehand
20:59:43 <ttx> dhellmann: I agree... which is why i don't really like eglynn's proposal saying "openly draw attention to cases where the actual behavior of candidates is questionable"
21:00:03 <mikal> annegent_: I think what anteaya is saying is that she's effectively the person delegated by the foundation to run the election, and therefore should be the first point of contact for election issues.
21:00:06 <jbryce> so if anything, i think that some guidance on whom to contact is needed. whicever path is chosen
21:00:17 <anteaya> mikal: I'm delegated byt the tc
21:00:20 <ttx> jbryce: +1
21:00:24 <devananda> jbryce: +1
21:00:24 <mikal> annegent_: this might be because for example we might need to stop and re-run the election, which would require the election official's involvement
21:00:31 <anteaya> mikal: the elections follow the tc charter, I report to the tc
21:00:33 <jbryce> whether that’s list, tc delegate, foundation officer…i think right now people just don’t know
21:00:42 <markmc> anteaya, nicely clarified :)
21:00:51 * anteaya nods
21:00:57 <mikal> anteaya: sure, but that's the TC acting on behalf of the foundation, right?
21:00:58 <ttx> ok, time is running out
21:01:04 <ttx> mikal: no
21:01:12 <dhellmann> anteaya: so it sounds like you already know your reporting structure for issues, but people don't know they can report them to you
21:01:29 <anteaya> mikal: yes
21:01:30 <eglynn> any closer to a decision point, folks?
21:01:33 <jeblair> well, the tc is chartered by the foundation bylaws, so there's a relationship there
21:01:35 <mikal> LOL
21:01:37 <anteaya> dhellmann: yes
21:01:42 <anteaya> dhellmann: that is how I felt
21:01:51 <anteaya> I tried to get people to file a report
21:01:52 <ttx> jeblair: yes, partly
21:01:56 <anteaya> they wouldn't
21:02:03 <anteaya> because they didn't kow how it worked
21:02:06 <ttx> ok... next steps?
21:02:16 <annegent_> I'm okay with documenting the reporting... I'm struggling with documenting what behavior to report.
21:02:22 <sdague> anteaya: ok, so with that context, I think it's fine to clarify the reporting
21:02:32 <anteaya> sdague: great thanks
21:02:37 <anteaya> pick whatever body you want
21:02:44 <anteaya> that is whom I will report to
21:02:56 <ttx> we have until the next elections to pick the right thing :)
21:02:58 <dhellmann> annegent_: is there harm in leaving the behavior open-ended, and applying judgement to the reports?
21:02:59 <devananda> I would think folks will continue to hesitate to report a preceived issue when they do not know what that report will lead to
21:03:08 <ttx> and this meeting is over
21:03:14 <mikal> Sigh
21:03:26 <annegent_> dhellmann: it's less risky from a legal standpoint, to me
21:03:29 <devananda> but knowing who to report to is, at least, something :)
21:03:29 <mikal> I feel like sometimes IRC is the wrong format for these contentious issues
21:03:33 <devananda> mikal: ++
21:03:41 <annegent_> mikal: truth
21:03:43 <dhellmann> mikal: +1
21:03:45 <ttx> #endmeeting