20:01:16 <ttx> #startmeeting tc
20:01:16 <openstack> Meeting started Tue Aug 25 20:01:16 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:17 <rhochmuth> o/
20:01:19 <openstack> The meeting name has been set to 'tc'
20:01:20 <cpallares> o/
20:01:23 * Rockyg lurking, too
20:01:27 <russellb> jaypipes swimming again
20:01:36 <jaypipes> russellb: :)
20:01:46 <ttx> A pretty busy agenda for today:
20:01:47 <edleafe> russellb: I see it more as a ball and chain
20:01:50 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:56 <mordred> o/
20:01:58 <ttx> #topic Adding Monasca to OpenStack
20:02:02 <ttx> #link https://review.openstack.org/213183
20:02:13 <ttx> I was initially put off by the fact the commit message doesn't mention Java at all, but apparently they are in the middle of a full transition to Python (which I didn't know about)
20:02:23 <ttx> I'm still a bit uncomfortable with the fact that both codebases (the legacy Java one and the Python one) coexist under the same repository
20:02:33 <ttx> It feels like they could use separate repositories or branches so that everything in the repository master branch is properly gated
20:02:42 <ttx> but I can certainly live with that
20:02:49 <lifeless> ttx: hi, here-ish, we have electricians and all sorts happpening right this second
20:03:02 <ttx> My other concern was with terse commit messages referencing a private JIRA (inside HP I suspect)
20:03:13 <ttx> Deklan answered that "from now on, we will be strictly adhering to the OpenStack Commit message standards"
20:03:26 <ttx> So I think this is, at the very minimum, going in the right direction
20:03:42 <ttx> dhellmann recently raised videoconferencing being used
20:03:46 <dhellmann> ttx: I had a concern about where the weekly meetings are being held, which I noticed today when re-reading the proposal and looking at their launchpad page
20:03:47 <dhellmann> heh
20:03:51 <ttx> which kind of prevents logging
20:04:05 <mordred> dhellmann: can you summarize?
20:04:16 <sdague> oh, I guess I missed that one
20:04:19 <mordred> me too
20:04:24 <dhellmann> mordred: they're using webex now (vidyo before)
20:04:24 <rhochmuth> we can switch to IRC, I responded to Doug's questions
20:04:28 <mordred> oh.
20:04:34 <mordred> rhochmuth: oh neat! thanks
20:04:36 <dhellmann> we gave the trove team a hard time over that before
20:04:37 <annegentle> ttx: I think the Java concerns are a great discussion to have and I tend to agree with sdague's commentary
20:04:44 <dhellmann> rhochmuth: yes, I think that would be a requirement for my +1
20:04:52 <mordred> we've given several teams a hard time about that - so I do think we need to be fair
20:04:53 <rhochmuth> ok, consider it done!!!
20:05:04 <annegentle> And then it's interesting, apparently the video-based chat is preferred over IRC by the team itself
20:05:14 <rhochmuth> will switch to IRC immediately
20:05:14 <ttx> annegentle: I don't. But then Monasca isn't really a problem if they move to Python anyway
20:05:24 * mordred does not have a problem with the java
20:05:29 <mordred> just for the record
20:05:30 <annegentle> for the docs team, we have some specialty teams that prefer video and real-time over IRC
20:05:38 <annegentle> mordred: me neither honestly
20:05:45 <clarkb> annegentle: IRC is real time
20:06:13 <jeblair> yeah, i think irc is a requirement, and python is not, actually.  :)
20:06:16 <ttx> I'm against fragmentation, for the reason I indicated on the review. That includes gratuitously adding a language or a conference media
20:06:19 <mordred> jeblair: ++
20:06:24 <sdague> so, I think we should make the java conversation a separate one
20:06:31 <ttx> I think we should
20:06:31 <markmcclain> sdague: ++
20:06:33 <jeblair> sdague: it at least sounds like it's moot
20:06:37 <sdague> jeblair: sure
20:06:46 <mordred> ++
20:06:56 <annegentle> clarkb: yes, but I'd like to continue to request a voice/video meeting capability that is acceptable
20:06:57 <jeblair> this is a real transition, right?  moving from java to python and discontinuing java?
20:07:06 <annegentle> jeblair: how would we know? :)
20:07:09 <ttx> jeblair: yes
20:07:11 <jeblair> i ask because the whole "two languages one repo" thing makes it seem like a grey area?
20:07:27 * maishsk is lurking in the background
20:07:32 <russellb> annegentle: we've had a voice one for a long time.  video is more difficult.
20:08:16 <annegentle> russellb: ok, cool
20:08:24 <mordred> rhochmuth: can you speak to jeblair's question above?
20:08:38 <ttx> Just as a sidenote, I'm extremely concerned about common culture and the fact that openstack doesn't mean anything anymore. I think that's the biggest risk our community faces over the coming two years. So I'll oppose convenience choices that fragment our community even further.
20:08:44 <rhochmuth> yes, the transition is real!
20:08:54 <anteaya> ttx: ++
20:09:00 * jaypipes primarily concerned about the huge overlap between Monasca's REST API and the OpenStack Telemetry API (as currently implemented by Ceilometer)
20:09:04 <annegentle> ttx: thanks for stating that. I have real concerns about "can it be debugged, documented, and quality tested in similar ways"
20:09:08 <jeblair> rhochmuth: oh, yes i see your comment from 08-18
20:09:09 <rhochmuth> not sure what else to say, everyone in the community wants to do this
20:09:17 <rhochmuth> in the monasca community that is
20:09:17 <dhellmann> jaypipes: that's what we get when we invite competition, no?
20:09:24 <jaypipes> dhellmann: no.
20:09:25 <ttx> but Monasca seems to at least aim at not creating problems
20:09:27 <jeblair> rhochmuth: have a timeline for full java deprecation?
20:09:33 <mordred> jaypipes: doesn't monasca also integrate with ceilometer?
20:09:36 <jeblair> (mostly just out of curiosity)
20:09:38 <sdague> jaypipes: well, I thought that was one of the areas we specifically were requesting competition, correct?
20:09:43 <mordred> (at least as I understand it?)
20:09:53 <mordred> or at least optionally integrate
20:10:02 <rhochmuth> i don't have an exact date. We talked about doing this.
20:10:07 <ttx> My main concern is that we have to take a number of promises at face value (no more JIRA references, no more videoconferencing, no more Java). So the question ebcomes, is it ready to be approved now, or should we wait for more progress
20:10:09 <jaypipes> dhellmann: I have always consistently said we should not have a competition for APIs. We should have competition for differing implementations of a single OpenStack API for XXXX
20:10:40 <anteaya> we don't have great follow up for promises not kept
20:10:44 <dhellmann> jaypipes: that would require the competing teams to agree on the api, though
20:10:54 <sdague> jaypipes: so, that seems very overly idealistic. The API isn't devoid of the implementation. And the API drives the implementation
20:10:56 <jaypipes> dhellmann: yes, precisely.
20:10:59 <dhellmann> ttx: I would be comfortable waiting a bit, I'm not sure there's a hurry
20:11:06 <mordred> jaypipes: I do not believe we have a mechanism for specifying an API outside of an implementation
20:11:08 <jaypipes> sdague: hugely disagree on that.
20:11:14 <ttx> dhellmann: there is a hurry if Monasca wants design summit space.
20:11:17 <mordred> jaypipes: and I believe we've always avoided being an API standards body
20:11:20 <annegentle> sdague: I think you're getting at the "docs, tests, builds, debugging" layer with the "A working OpenStack is not just the python glue layer, it's the whole thing."
20:11:37 <mordred> jaypipes: and the only way that two different projects can implement the same API is if we had an API definition that lived apart from the implementation
20:11:40 <mordred> which we have literally nowhere
20:11:45 <jaypipes> mordred: we should not have 2 OpenStack Telemetry APIs.
20:11:47 <ttx> there is no way unofficial projects will get space in Tokyo. We are strugfgling with what we have already
20:11:48 <SpamapS> If you don't push toward agreeing API's, you end up with the Neutron effect: "This is the BEST way" without a path from the other way and users forked.
20:11:49 <sdague> also, who decides that
20:11:50 <jgriffith> jaypipes: I have to say I agree with others that while awesome that doesn't seem very realistic.
20:11:50 <markmcclain> ttx: can we wait and grant design summit space?
20:11:51 <dhellmann> ttx: I'm not inclined to hurry for that reason.
20:11:53 <annegentle> ttx: is there no "related projects" spaces this time around?
20:11:56 <mordred> jaypipes: I do not think that monasca is a telemetry api
20:12:03 <mordred> jaypipes: I believe it is a monitoring API
20:12:04 <ddieterly> i think we can take the JIRA references problem off the table. i was responsible for that mistake and was severely castigated for it by Roland.
20:12:07 <ttx> annegentle: it's Japan. There is no space
20:12:14 <ttx> only people
20:12:25 <jaypipes> mordred: https://github.com/stackforge/monasca-api/blob/master/docs/monasca-api-spec.md would say otherwise.
20:12:25 <annegentle> ttx: with white gloves on to push you into train cars though! :)
20:12:26 <mordred> ttx: :)
20:12:32 <maishsk> ttx: :)
20:12:35 <anteaya> ttx: ha ha ha
20:12:43 <jeblair> annegentle: omg are they going to be at the summit rooms?!
20:12:50 <markmcclain> haha
20:12:59 <ttx> in every workroom, yes
20:12:59 <sdague> because I think one of the issues we had in the whole telemetry space is we tried to make a bunch of different teams work together that weren't really aligned, and that didn't work out so well
20:13:02 <gordc> mordred: as ceilometer dev, we're actually not sure about what level of integration exists... we're sort of in the dark on how ceilo/monasca integrates... there has been mentions about it for a while but we've never been asked.
20:13:10 <dhellmann> sdague: ++
20:13:28 <gordc> we did speak about joint summit sessions at last meeting though.
20:13:33 <sdague> so I feel like saying "no, you all have to agree on API" puts us right back into a non working place
20:13:33 <mordred> jaypipes: k. but is the api short-name/id in keystone "telemetry" ?
20:13:54 <jaypipes> mordred: not sure :)
20:14:09 <mordred> if it is - I will be much more inclined to agree with you :)
20:14:12 <annegentle> gordc: great input, thanks
20:14:18 <dhellmann> sdague: right, I would expect part of a different implementation to include API changes
20:14:26 <sdague> dhellmann: yeh, exactly
20:14:32 <edleafe> jaypipes: agree that a single API is ideal, but there is no body capable of declaring one
20:14:46 <edleafe> jaypipes: you'll then need everyone to agree on their own
20:14:54 <sdague> especially because this an area where it's not a solved space, and there is still a bunch of exploration going on
20:15:01 <dhellmann> right
20:15:02 <jaypipes> edleafe: if we don't push competing implementations to agree on an API, we will end up with mass confusion and not serve our users, IMHO.
20:15:41 <edleafe> jaypipes: if a product differs from existing APIs without providing at least as much new benefit, it will die on its own
20:15:45 <sdague> see the various internal rewrites of key things in ceilometer to explore more efficient ways of handling this, which is all good, but I can't even imagine the drag placed on that if they also needed to coordinate with other metrics teams on shared API
20:16:12 <ttx> yeah, not sure we can require convergent APIs for differ ent projects addressing kind of the same space
20:16:40 <jgriffith> edleafe: that may be wishful thinking, different folks will have their reasons for aligning with one over another
20:16:54 <sdague> jaypipes: we did that before in this space, and we ended up with deadlock and a software stack that didn't serve our users well. I think all the software stacks in this space, ceilometer included, got much better once the TC let them all try their own things.
20:16:58 <dhellmann> rhochmuth: what's the story with backend databases these days? there is an open source database available, right?
20:17:09 <ttx> so the options are approve it now or delay it to give them a chance to further align to openstack way first
20:17:23 <sdague> ttx: what's the deadline for space at the summit?
20:17:23 <rhochmuth> correct. influxdb is supported and we are in the process of adding cassandra
20:17:33 <dhellmann> rhochmuth: ok, great, thanks
20:17:37 <jaypipes> on another unrelated note, I do have some concern that Monasca is a monolithic things trying to do too much (monitoring, metric storage, alarming, events), which is the same problem domain that Ceilometer finds itself in, no?
20:17:39 * dhellmann can never remember the name of influxdb
20:17:39 <annegentle> I'd still like to understand if we believe a Java or Go or Erlang project can be documented and tested with self-service adequately?
20:17:44 <ttx> sdague: a couple more weeks
20:17:47 <edleafe> if there ever is a definition of a telemetry API that we can point to, then sure, let's enforce it.
20:18:20 <jeblair> i think i'm generally comfortable with the promises made and could +1 now.
20:18:39 <sdague> ttx: personally, I'd like to revisit as late as we can. I'm happy to delay a couple of weeks and have the team prove they are implementing the new changes.
20:18:40 <jeblair> annegentle: i think we want to kick that can down the road since we don't have to deal with it for this one.  :)
20:18:46 <dhellmann> sdague: ++
20:18:47 <sdague> I'm ok going now as well
20:18:49 <annegentle> For example, I believe the REST API docs can be standardized without concern for language. However RST/Sphinx docs are pretty Python-specific, do we then also enable Java-based doc tools?
20:18:56 <ttx> sdague: we can certainly wait two weeks
20:18:57 <annegentle> jeblair: waahh :)
20:19:09 <ttx> sdague: I can poll them on their needs should they be accepted and factor it
20:19:09 <sdague> ttx: ok, so how about we do that. Table for two weeks
20:19:11 <edleafe> :qa
20:19:15 <edleafe> doh!
20:19:18 <annegentle> heh
20:19:21 <gordc> jaypipes: specifically re: ceilometer, yes, a lot (too much) is covered. we started branching out projects this cycle (see: alarming split) also to make collaboration easier.
20:19:27 <ttx> sdague: works for me
20:19:56 <ttx> we don't have the required votes in anyway
20:19:59 <dhellmann> rhochmuth: you should go ahead and add the team meeting to eavesdrop.openstack.org
20:20:07 <sdague> rhochmuth: and you have specific feedback of what process changes are expected during that time
20:20:07 <rhochmuth> ok, will do
20:20:23 <ttx> #agreed Table Monasca for two weeks so that they can further align with the OpenStack way
20:20:37 <jaypipes> gordc: yeah, precisely my point that ceilometer reached some self-awareness that it was tackling too much. has monasca reached a similar awareness is my question :)
20:20:55 <ttx> Also if you have different objections (liek jaypipes has) it's more than time to file them on the review
20:21:10 <jaypipes> ttx: yes, I will do so.
20:21:23 <annegentle> got it
20:21:29 <ttx> #topic Moving the RefStack project from openstack-infra to Big Tent.
20:21:41 <ttx> #link https://review.openstack.org/213930
20:21:45 <ttx> So... refstack was recently added to the infra project (with https://review.openstack.org/#/c/205609/)
20:21:54 <jeblair> yay!
20:21:55 <ttx> On that review I questioned why that would not be an Interoperability project team instead, but people were apparently happy with it being under Infra
20:22:08 <ttx> Now they changed their minds and prefer a project team instead, the rationale for the change of mind is not perfectly clear to me
20:22:14 <ttx> kind of a good thing that the repo wasn't renamed to openstack-infra/refstack yet :)
20:22:26 <Rockyg> Uh, I think someone told them they should move?
20:22:26 <ttx> I'm generally fine with it -- My only concern with a "RefStack" project team is that it's very narrow (I would prefer an "Interoperability" team with the wider scope of providing tooling for interoperability efforts)
20:22:37 <ttx> Rockyg: "someone" ?
20:22:45 <mordred> so ... I have two competing thoughts in my brain on this one
20:22:49 <dhellmann> does this group of people want to take on the broader mission?
20:22:49 <jeblair> yep, and in fact, i think i also suggested that while i'd be happy either way, i also thought that ideally, it should be its own official openstack project.  :)
20:22:59 <jeblair> but they weren't ready for that.
20:23:07 <ttx> (But then if this team is solely focused on the Interoperability Test Report I guess that works)
20:23:09 <Rockyg> Yeah.  Didn't get the name.  Might have been ttx's comment that triggered the whole thing?
20:23:20 <ttx> heh
20:23:27 <ttx> late-action trigger
20:23:49 <mordred> which is that I'm ultimately fine either way - but I think there is both the tool and a long-lived service to collect the data
20:23:49 <jeblair> i also am not entirely clear on where the change of heart originated
20:23:54 <Rockyg> So, I think there is desire for the interop, but they are focused first on just getting the defcore stuff solid
20:24:15 <ttx> OK anyway... the question is now whether the team is specific to refstack-the-tool or to interoperability-tools in general
20:24:15 <mordred> and if infra is going to run the long-lived tool, I'd love for the engineering of that data collection tool to at least be somewhat done in collaboration with infra
20:24:17 <russellb> can always rename, update scope, or whatever if it makes sense later
20:24:28 <Rockyg> I suggested that they can do POC on defcore and sit with that until they are ready to expand to more interop
20:24:32 <mordred> that does not mean it needs to be in the infra project
20:24:38 <jeblair> and also, for the record, if the foundation staff comes to consensus on something like this, maybe we could start talking to related ptls earlier rather than later?
20:24:49 <jeblair> cause i mean, i learned about this yesterday
20:25:01 <jeblair> at any rate, i talked to catherine yesterday
20:25:04 <hogepodge> ttx there was desire for better tooling for testing at ops mid-cycle
20:25:25 <hogepodge> ttx there are plans to move it beyond defore. Allowing non-defcore schema for interop for example.
20:25:29 <Rockyg> I think the thing confusing placement is the  data storage requirement
20:25:58 <Rockyg> The data is foundation data for defcore, but the rest.....
20:26:14 <ttx> hogepodge: so you think it majkes more sense as "Refstack" team or as "Interop" team ?
20:26:21 <jeblair> the operation of refstack.o.o falls squarely within infra's mission statement, and we will be happy to continue to manage the operation of the service and the deployment tools.  even the data management policies.
20:26:32 <jeblair> and catherine agrees with that.
20:26:46 <Rockyg> So, as other projects, Refstack is the project name, interop is the function/area
20:27:05 <sdague> right, so shouldn't it then be an interop project, with an interop PTL
20:27:09 <jeblair> catherine's concern with 'interop' is that she doesn't want to barge in on defcore's area
20:27:10 <hogepodge> ttx: right now it's just the refstack tool. I could see it expanding, especially if there's buy in from other contributors
20:27:12 <sdague> and refstack is just a piece of that
20:27:24 <ttx> Rockyg: ok, I guess we can always expand it
20:27:29 <ttx> if needed
20:27:36 <jeblair> she sees defcore as owning "interop" and refstack as interpreting and executing on that.
20:27:37 <sdague> jeblair: ok, I guess I'm confused, I thought refstack was tooling to prove defcore
20:27:39 <jeblair> i agree with here there.
20:27:45 <jeblair> sdague: ^ that help?
20:27:47 <hogepodge> defcore is a board committee with a narrow focus: the guideline for what an interop openstack deployment is, as defined by tests and code
20:28:05 <sdague> jeblair: sure, I don't understand how that makes it different than QA and Tempest
20:28:21 <ttx> looks like it's refstack only for the time being, so I +1ed it
20:28:22 <sdague> for a while we only had one tool, now we have more than one, but the mission was still the abstract one
20:28:31 <hogepodge> sdague: it's been adopted as the tool to collect defcore results, but we would be doing ourself a disservice if it was only for that.
20:28:33 <jeblair> sdague: lack of bod involvement? :)
20:28:39 <ttx> Still missing quite a few votes
20:29:07 <sdague> hogepodge: so is it a QA tool then?
20:29:30 <Rockyg> I'd like to get Catherine's take on this whole thing.  Can we table until next week and get Catherine here?
20:29:34 <hogepodge> part of this came up to as a delayed reponse to -1 infra votes on making it an infra project, so we're exploring the possibilities here
20:29:40 <mordred> sdague: no, I thnk it isn't
20:29:50 <mordred> sdague: I think refstack has a different audience - tempest is a tool for developers
20:29:55 <jeblair> i think refstack is part of openstack
20:29:58 <hogepodge> sdague: it's built on QA, and we've worked closely with them
20:30:09 <mordred> refstack is a tool to vet deployments against an interop definition
20:30:15 <sdague> mordred: sure
20:30:19 <jeblair> which is why i think it being its own openstack project/program is a good thing
20:30:22 <mordred> jeblair: ++
20:30:29 <sdague> I guess I see 3 things: Infra, Interop, QA
20:30:38 <sdague> and the current conversation is that refstack is a 4th thing
20:30:57 <sdague> which, I guess if we need it to be so, that's fine
20:30:58 <ttx> refstack is a specific tool and the refstack team has a narrow mission. I'm fine with that
20:30:58 <mordred> I think refstack is the technical arm of interop
20:31:05 <jeblair> mordred: ya
20:31:08 <sdague> so, then it would be the Interop program
20:31:11 <sdague> right?
20:31:12 <mordred> yah
20:31:15 <hogepodge> refstack is looking at adding support for out of tree tests, and reporting on them
20:31:16 <mordred> I think that's what they're saying
20:31:21 <mordred> with a code name of "refstack"
20:31:25 <Rockyg> So, interop program, but refstack project
20:31:32 <Rockyg> mordred, ++
20:31:41 <jeblair> interop is more than tech
20:31:47 <jeblair> in a way unlike qa
20:32:02 <ttx> (sidenote: we don't have programs anymore)
20:32:03 <dhellmann> sdague: I agree, but I'm also ok with not pushing the point on team scope right now if this set of people isn't looking beyond refstack itself at other interop tools
20:32:03 <jeblair> there's policy/trademarks/political things involved
20:32:14 <ttx> (we have project teams and deliverables)
20:32:22 <hogepodge> it would be nice to pull in efforts from the tailgage team to be part of interop effort, since they have similar interests
20:32:41 <ttx> I'm fine with it starting as Refstack and expanding if need be to "Interop tools"
20:32:45 <dhellmann> hogepodge: if those teams want to work together, it would be good to set that up early
20:32:47 <jeblair> dhellmann: i can definitely speak for catherine that she wants to focus purely on driving refstack to implement the technical goals of interoperability set by defocer
20:33:15 <mordred> s/defocer/defcore/
20:33:24 <ttx> I prefer defocer
20:33:32 <annegentle> is that French?:)
20:33:33 <mordred> ttx: ++
20:33:34 <sdague> ok, I guess lets just do the narrow thing and move on then :)
20:33:37 * Rockyg kinda likes defocer
20:33:38 <dhellmann> jeblair: it seems wise to limit scope for the team mission, then, if that's what they're actually focused on
20:33:39 <jeblair> hogepodge: tailgge didn't come up in my convo with catherine
20:33:39 <ttx> sdague: yes
20:33:48 <jeblair> but like i said, i'm late to this :)
20:33:51 <ttx> dhellmann: yes
20:34:07 <hogepodge> jeblair: I've been working more with them. Catherine is very much focused on Refstack server/client as a toolchain.
20:34:09 <ttx> They signed up to do refstack at this point. Not all interop tools or other interop tools
20:34:14 <sdague> tailgate is a whole other can of worms...
20:34:19 <dhellmann> none of this is set in stone
20:34:19 <ttx> so the team should be refstack.
20:34:23 <ttx> for the time being
20:34:28 <sdague> ttx++
20:34:34 <annegentle> seems like it
20:34:35 <ttx> so please pile up approvals :)
20:34:49 <ttx> one more
20:35:31 <ttx> ok, let's get back to this later and see
20:35:37 <ttx> #topic Temporarily add I18n ATCs
20:35:42 <ttx> #link https://review.openstack.org/213989
20:35:51 <ttx> We still require the TC to vote on extra-ATCs, and this one was short of a couple votes
20:36:00 <ttx> I like that the translations team came up with a reasonable way to measure "contribution" there
20:36:04 <ttx> That will be useful when we run elections for the I18N PTL
20:36:17 <jeblair> ++
20:36:25 <ttx> ok, enough votes now, approvinug unless someone screams now
20:36:55 <ttx> approved
20:37:03 <ttx> #topic Add constraints details to project testing interface
20:37:08 <ttx> #link https://review.openstack.org/215399
20:37:14 <ttx> This is a change to the project testing interface, introducing constrained unit tests
20:37:29 <ttx> Sounds like a good incremental change to me. Comments ? Objections ?
20:37:44 <dhellmann> it's not entirely clear to me why we wouldn't want this to be the default, but i guess that's ok
20:37:48 <sdague> seems fine, I guess I wonder if there is a reason this isn't the default behavior
20:37:52 <dhellmann> haha
20:37:52 <ttx> (has enough votes to pass, so I'll approve unless someone screams now
20:38:09 <jeblair> i was wondering whether this should eventually be required?
20:38:11 <ttx> dhellmann: that's why I said "good incremental change", was thinking the same
20:38:14 <jeblair> it looks like it's all optional now
20:38:19 <dhellmann> yeah
20:38:21 <jeblair> i may be saying similar things
20:38:28 <jeblair> as dhellmann, sdague,  and ttx :)
20:38:29 <ttx> oh, had a question. maybe it shouold be made mandatory ?
20:38:39 <dhellmann> jeblair: if it's optional, and a team doesn't do it, the only jobs broken will be theirs, afact
20:38:42 <fungi> lifeless: ^? (if electricians are leaving you alone for a moment)
20:38:42 <dhellmann> afaict
20:38:58 <fungi> i get the impression we would want this to become the default in time
20:39:14 <jeblair> fungi: that wfm
20:39:15 <dhellmann> I suppose technically if we make it the required default now, no projects would be in compliance.
20:39:16 <ttx> anyway, that doesn't make the change less valid. Can always switch to mandatory in a subsequent patch
20:39:26 <ttx> so I'll approve now
20:39:38 <jeblair> yup, just would like to know the future
20:39:44 <dhellmann> ++
20:39:52 <Rockyg> make it mandatory for Mitaka
20:39:54 <ttx> I think the future is in "mandatory"
20:40:06 <ttx> ok approved
20:40:14 <ttx> #topic Add election repository to tc-repos
20:40:18 <ttx> #link https://review.openstack.org/213806
20:40:29 <ttx> That's a TC-owned repo so we need to vote on its addition, but that should be afst
20:40:34 <ttx> or fast
20:40:37 <ttx> It will be used to contain election data. Not sure if anyone has questions
20:40:47 <ttx> A couple more +2s wouldn't hurt there
20:40:57 * dhellmann votes again
20:41:18 <lifeless> fungi: long term maybe, bu tneed to ramp up adoption first. -> back to electricians
20:41:23 <ttx> ok, we ahve enough, will approve now unless someone screams
20:41:50 <ttx> approved
20:41:50 <fungi> lifeless: thanks, that's what it seems like we all ended up assuming anyway
20:41:53 <ttx> #topic Introduce assert:follows-standard-deprecation tag
20:41:57 <ttx> #link https://review.openstack.org/207467
20:42:03 <ttx> Like we decided last week, I removed the "never deprecate anything" assertion from the proposal
20:42:10 <ttx> and merged Zane's config option deprecation assertion into this 'I follow standard deprecation rules' single tag
20:42:21 <annegentle> ttx: good good
20:42:22 <ttx> I'm happy answering questions you may have, otherwise please add approvals to the review so we can move on
20:42:41 <ttx> I'll approve if it ever passes 7 yes
20:42:54 <ttx> cpallares: around?
20:42:58 <cpallares> yes
20:43:05 <ttx> #topic Present CoC rework (cpallares)
20:43:13 <cpallares> hello all o/
20:43:17 <cpallares> I'm here to ask for direction and help in expanding OpenStack's community code of conduct. We are hoping to expand it as part of the diversity work group, as we are trying to make the OpenStack community more welcoming towards people of all races, genders, cultures, religions, ages, etc.
20:43:19 <ttx> flaper87 added you on the agenda last week so that you can present the CoC work
20:43:23 <annegentle> welcome cpallares
20:43:38 <cpallares> ttx: thanks!
20:43:41 <cpallares> Our current code of conduct https://www.openstack.org/legal/community-code-of-conduct/
20:44:00 <cpallares> So our current code of conduct is missing a couple of things. Ideally a code of conduct should have a place to easily report violations, because that's the only way to enforce it, otherwise it's like it doesn't exist. It should have either an email or a form to report violations.
20:44:30 <cpallares> We need to create some sort of committee who is dedicated to handling incidents, because our current code of conduct states that violators will be accountable to the board of directors. I'm not sure if there's ever been reported violations to the code of conduct, but I doubt the board of directors spend a lot of time discussing or reprimanding small violations within the OpenStack community.
20:44:36 <jeblair> cpallares: good point; i think we have previously reported violations to the foundation community folks
20:44:51 <cpallares> jeblair: Oh awesome, that's good to hear.
20:44:53 <annegentle> So my original feedback to an earlier CoC is that I would rather report to a person than a form.
20:44:59 <mordred> cpallares: good. I was just about to say "a method of ajudication" is also important
20:45:03 <cpallares> annegentle: That would be better.
20:45:16 <annegentle> I would want to know who exactly knows what I am telling them.
20:45:27 <sdague> annegentle: I think that's a very good point
20:45:30 <cpallares> annegentle: That's the other thing
20:45:35 <cpallares> It should have a defined and documented complaint handling process, so each violation case is handled the same way and there is transparency on how reporting a violation works. Of course, all reports would be kept confidential.
20:45:36 <fungi> yes, being able to report issues in confidence is important
20:45:41 <cpallares> The code of conduct should also include how reprimands will work and who will decide them (this is where the code of conduct committee would come in). And reprimands be things like warnings, a request for a public or private apology, a public statement about an incident, etc.
20:45:43 <ttx> jeblair: worth noting that we don't have a single "community manager" anymore so clarifying wouldn't hurt
20:45:54 <annegentle> The Summit code of conduct has procedures
20:45:55 <jeblair> ttx: yep.
20:45:56 <annegentle> #link https://www.openstack.org/summit/tokyo-2015/code-of-conduct
20:45:58 <mordred> cpallares: ++
20:46:13 <edleafe> cpallares: yes
20:46:16 <mordred> cpallares: I like all of the things you are saying - they addreess my concerns with most of the CoCs out there
20:46:23 <ttx> cpallares: it's not completely crazy to have a small committee with folks from foundation staff, nominees from the TC and from the board to act as a first line
20:46:27 <annegentle> cpallares: so you're asking about the generic one?
20:46:27 <cpallares> annegentle: The thing is that that one only applies to the summit.
20:46:32 <annegentle> cpallares: got it
20:46:45 <annegentle> cpallares: I completely agree we need one for all contexts.
20:46:46 <cpallares> annegentle: I think there's another one for the openstack blog.
20:47:22 <cpallares> I think it should have it's own dedicated space or page within OpenStack. Someplace where it can be updated, easily found, and available for people to easily link for reference.
20:47:23 <ttx> cpallares: would there be a single CoC for events & general community conduct ?
20:47:24 <anteaya> I reported a CoC concern to jbryce
20:47:45 <ttx> yeah, the Foundatiojn secretary is the person ultimately named in the bylaws
20:47:54 <cpallares> ttx: I'd like to examine and expand all of them, but right now I'm focusing on our online community.
20:47:59 <fungi> being able to combine/replace those would be great, though it may not be feasible if the users of different services/sites/events are accountable to different groups
20:48:04 <cpallares> Things that would apply to IRC, mailing list, meetings, etc.
20:48:15 <ttx> so at the very least the secretary should be part of whatever first-line committee you would suggest
20:48:18 <cpallares> fungi: ++
20:48:29 <cpallares> I've been looking at different Code of Conducts from different communities and I've found Django's code of conduct ( https://www.djangoproject.com/conduct/ ) to be the most documented and well thought-out and it's licensed under a Creative Commons Attribution license so we could fork it and modify it. It includes a clear reporting guide, a clear and documented process for dealing with violators, an
20:48:32 <cpallares> enforcement manual, it has frequently asked questions and a change log.
20:48:52 <cpallares> All those things would be a good place to start.
20:48:56 <cpallares> We are having trouble finding a way to make this happen, since we are not sure where the code of conduct operates within OpenStack and we're not sure who would review the violations or how to create this committee.
20:49:11 * mordred adds to reading list
20:49:22 <ttx> (asynchronously approved the refstack project team)
20:49:23 <annegentle> cpallares: and the "ombudsman" group from the board didn't pan out? mordred or markmcclain do you know?
20:49:25 <jeblair> would it be a bylaws change?
20:49:37 <mordred> annegentle: that's a different group/purpose
20:50:03 <mordred> annegentle: although I'm not sure it did pan out - but that was a group to ensure that the board was operating in a manner consistent with how the board had declared it would operate
20:50:06 <ttx> appendix 6, probably yes
20:50:37 <ttx> heh, we have a code of conduct and a community code of conduct
20:50:43 <mordred> oh good
20:50:44 <annegentle> mordred: ok
20:50:50 <mordred> it's good when we keep things clear
20:50:54 <ttx> https://www.openstack.org/legal/code-of-conduct/ and https://www.openstack.org/legal/community-code-of-conduct/
20:51:08 <ttx> mordred: one is for board members, you should have read it
20:51:33 <cpallares> I think one is specific for people within the foundation?
20:51:43 <ttx> cpallares: clarity and convergence are definitely needed in that dark area, and you seem to have the issue under control. Anything you need from this group ?
20:51:45 <cpallares> And says things like "don't take bribes"
20:51:59 <jeblair> yeah i think the community coc is what we're primarily concerned with
20:52:07 <cpallares> ttx: I'm looking for guidance.
20:52:11 <annegentle> and ensuring it's applied beyond just events
20:52:17 <mordred> cpallares: I like the Django CoC - it's clear and communicative
20:52:53 <mordred> cpallares: I think we/you need to make a recommendation to the board to form the ajudication body you are talking about
20:53:06 <ttx> cpallares: we can take the homework of reading the Django CoC and get back to you with comments ?
20:53:08 <mordred> cpallares: since it's a power that lays with the foundatoin and therefore with teh BoD
20:53:14 <annegentle> cpallares: because the events one has guidance that's difficult to enact online?
20:53:14 <jeblair> i do think there are aspects of our current coc not covered by the django coc
20:53:15 <cpallares> ttx: Sounds good.
20:53:17 <jeblair> i would hate to lose those
20:53:18 <mordred> cpallares: however, I think we'd all love to be actively involved
20:53:25 <mordred> jeblair: ++
20:53:26 <cpallares> ttx: So what could be the next steps to make this happen?
20:54:03 <ttx> how about you come back next week and we'll all have read the CoC and communicate comments
20:54:13 <cpallares> ttx: Sounds good.
20:54:49 <ttx> #action TC members to read the Django CoC https://www.djangoproject.com/conduct/ and prepare comments for next meeting
20:54:57 <annegentle> thanks cpallares for giving us good reading material and an action
20:55:06 <ttx> cpallares: yes, many thanks !
20:55:24 <ttx> #topic Workgroup reports
20:55:58 <ttx> Small update from the project team guide, lost in the zuul post queue is the first run of the projectteam guide publication job
20:56:11 <jeblair> oh neat
20:56:19 <jeblair> i can kick that manually if needed
20:56:21 <ttx> I submitted a dumb change to test it
20:56:26 <jeblair> or that
20:56:29 <annegentle> ha no way
20:56:37 <ttx> it's just llst in the gigantic post queue
20:56:41 <ttx> lost
20:56:53 <ttx> annegentle: it was not totally dumb
20:56:54 <jeblair> need moar clouds
20:57:01 <ttx> jeblair: working on it
20:57:08 <jeblair> woo
20:57:10 <annegentle> zuul gated us
20:57:25 <ttx> Any other workgroup with an update ?
20:58:28 <ttx> next-tags WG: Please vote on https://review.openstack.org/#/c/207467/ or ask questions if you still have some
20:58:32 <annegentle> none from comms other than "do we need a blog post this week?"
20:58:57 <annegentle> once we get the new project team guide posted we can add to the highlights blog
20:58:59 <ttx> Not much to report on, apart from refstack move
20:59:00 <annegentle> other topics?
20:59:07 <annegentle> refstack move is good
20:59:15 <sdague> ttx: I left some concerns on that about what counts as "feature". I was not here for last weeks meeting due to LinuxCOn
20:59:41 <ttx> sdague: wording suggestions welcome :)
20:59:45 <ttx> #topic Open discussion
20:59:47 <fungi> annegentle: we have recognized atcs for translation/i18n now. that may be relevant
21:00:15 <annegentle> fungi: perfect, 3 topics makes a post
21:00:36 <ttx> Last words ?
21:00:45 <ttx> Thanks everyone
21:00:46 <ttx> #endmeeting