20:01:16 #startmeeting tc 20:01:16 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:17 o/ 20:01:19 The meeting name has been set to 'tc' 20:01:20 o/ 20:01:23 * Rockyg lurking, too 20:01:27 jaypipes swimming again 20:01:36 russellb: :) 20:01:46 A pretty busy agenda for today: 20:01:47 russellb: I see it more as a ball and chain 20:01:50 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:56 o/ 20:01:58 #topic Adding Monasca to OpenStack 20:02:02 #link https://review.openstack.org/213183 20:02:13 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 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 It feels like they could use separate repositories or branches so that everything in the repository master branch is properly gated 20:02:42 but I can certainly live with that 20:02:49 ttx: hi, here-ish, we have electricians and all sorts happpening right this second 20:03:02 My other concern was with terse commit messages referencing a private JIRA (inside HP I suspect) 20:03:13 Deklan answered that "from now on, we will be strictly adhering to the OpenStack Commit message standards" 20:03:26 So I think this is, at the very minimum, going in the right direction 20:03:42 dhellmann recently raised videoconferencing being used 20:03:46 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 heh 20:03:51 which kind of prevents logging 20:04:05 dhellmann: can you summarize? 20:04:16 oh, I guess I missed that one 20:04:19 me too 20:04:24 mordred: they're using webex now (vidyo before) 20:04:24 we can switch to IRC, I responded to Doug's questions 20:04:28 oh. 20:04:34 rhochmuth: oh neat! thanks 20:04:36 we gave the trove team a hard time over that before 20:04:37 ttx: I think the Java concerns are a great discussion to have and I tend to agree with sdague's commentary 20:04:44 rhochmuth: yes, I think that would be a requirement for my +1 20:04:52 we've given several teams a hard time about that - so I do think we need to be fair 20:04:53 ok, consider it done!!! 20:05:04 And then it's interesting, apparently the video-based chat is preferred over IRC by the team itself 20:05:14 will switch to IRC immediately 20:05:14 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 just for the record 20:05:30 for the docs team, we have some specialty teams that prefer video and real-time over IRC 20:05:38 mordred: me neither honestly 20:05:45 annegentle: IRC is real time 20:06:13 yeah, i think irc is a requirement, and python is not, actually. :) 20:06:16 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 jeblair: ++ 20:06:24 so, I think we should make the java conversation a separate one 20:06:31 I think we should 20:06:31 sdague: ++ 20:06:33 sdague: it at least sounds like it's moot 20:06:37 jeblair: sure 20:06:46 ++ 20:06:56 clarkb: yes, but I'd like to continue to request a voice/video meeting capability that is acceptable 20:06:57 this is a real transition, right? moving from java to python and discontinuing java? 20:07:06 jeblair: how would we know? :) 20:07:09 jeblair: yes 20:07:11 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 annegentle: we've had a voice one for a long time. video is more difficult. 20:08:16 russellb: ok, cool 20:08:24 rhochmuth: can you speak to jeblair's question above? 20:08:38 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 yes, the transition is real! 20:08:54 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 ttx: thanks for stating that. I have real concerns about "can it be debugged, documented, and quality tested in similar ways" 20:09:08 rhochmuth: oh, yes i see your comment from 08-18 20:09:09 not sure what else to say, everyone in the community wants to do this 20:09:17 in the monasca community that is 20:09:17 jaypipes: that's what we get when we invite competition, no? 20:09:24 dhellmann: no. 20:09:25 but Monasca seems to at least aim at not creating problems 20:09:27 rhochmuth: have a timeline for full java deprecation? 20:09:33 jaypipes: doesn't monasca also integrate with ceilometer? 20:09:36 (mostly just out of curiosity) 20:09:38 jaypipes: well, I thought that was one of the areas we specifically were requesting competition, correct? 20:09:43 (at least as I understand it?) 20:09:53 or at least optionally integrate 20:10:02 i don't have an exact date. We talked about doing this. 20:10:07 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 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 we don't have great follow up for promises not kept 20:10:44 jaypipes: that would require the competing teams to agree on the api, though 20:10:54 jaypipes: so, that seems very overly idealistic. The API isn't devoid of the implementation. And the API drives the implementation 20:10:56 dhellmann: yes, precisely. 20:10:59 ttx: I would be comfortable waiting a bit, I'm not sure there's a hurry 20:11:06 jaypipes: I do not believe we have a mechanism for specifying an API outside of an implementation 20:11:08 sdague: hugely disagree on that. 20:11:14 dhellmann: there is a hurry if Monasca wants design summit space. 20:11:17 jaypipes: and I believe we've always avoided being an API standards body 20:11:20 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 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 which we have literally nowhere 20:11:45 mordred: we should not have 2 OpenStack Telemetry APIs. 20:11:47 there is no way unofficial projects will get space in Tokyo. We are strugfgling with what we have already 20:11:48 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 also, who decides that 20:11:50 jaypipes: I have to say I agree with others that while awesome that doesn't seem very realistic. 20:11:50 ttx: can we wait and grant design summit space? 20:11:51 ttx: I'm not inclined to hurry for that reason. 20:11:53 ttx: is there no "related projects" spaces this time around? 20:11:56 jaypipes: I do not think that monasca is a telemetry api 20:12:03 jaypipes: I believe it is a monitoring API 20:12:04 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 annegentle: it's Japan. There is no space 20:12:14 only people 20:12:25 mordred: https://github.com/stackforge/monasca-api/blob/master/docs/monasca-api-spec.md would say otherwise. 20:12:25 ttx: with white gloves on to push you into train cars though! :) 20:12:26 ttx: :) 20:12:32 ttx: :) 20:12:35 ttx: ha ha ha 20:12:43 annegentle: omg are they going to be at the summit rooms?! 20:12:50 haha 20:12:59 in every workroom, yes 20:12:59 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 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 sdague: ++ 20:13:28 we did speak about joint summit sessions at last meeting though. 20:13:33 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 jaypipes: k. but is the api short-name/id in keystone "telemetry" ? 20:13:54 mordred: not sure :) 20:14:09 if it is - I will be much more inclined to agree with you :) 20:14:12 gordc: great input, thanks 20:14:18 sdague: right, I would expect part of a different implementation to include API changes 20:14:26 dhellmann: yeh, exactly 20:14:32 jaypipes: agree that a single API is ideal, but there is no body capable of declaring one 20:14:46 jaypipes: you'll then need everyone to agree on their own 20:14:54 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 right 20:15:02 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 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 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 yeah, not sure we can require convergent APIs for differ ent projects addressing kind of the same space 20:16:40 edleafe: that may be wishful thinking, different folks will have their reasons for aligning with one over another 20:16:54 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 rhochmuth: what's the story with backend databases these days? there is an open source database available, right? 20:17:09 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 ttx: what's the deadline for space at the summit? 20:17:23 correct. influxdb is supported and we are in the process of adding cassandra 20:17:33 rhochmuth: ok, great, thanks 20:17:37 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 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 sdague: a couple more weeks 20:17:47 if there ever is a definition of a telemetry API that we can point to, then sure, let's enforce it. 20:18:20 i think i'm generally comfortable with the promises made and could +1 now. 20:18:39 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 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 sdague: ++ 20:18:47 I'm ok going now as well 20:18:49 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 sdague: we can certainly wait two weeks 20:18:57 jeblair: waahh :) 20:19:09 sdague: I can poll them on their needs should they be accepted and factor it 20:19:09 ttx: ok, so how about we do that. Table for two weeks 20:19:11 :qa 20:19:15 doh! 20:19:18 heh 20:19:21 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 sdague: works for me 20:19:56 we don't have the required votes in anyway 20:19:59 rhochmuth: you should go ahead and add the team meeting to eavesdrop.openstack.org 20:20:07 rhochmuth: and you have specific feedback of what process changes are expected during that time 20:20:07 ok, will do 20:20:23 #agreed Table Monasca for two weeks so that they can further align with the OpenStack way 20:20:37 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 Also if you have different objections (liek jaypipes has) it's more than time to file them on the review 20:21:10 ttx: yes, I will do so. 20:21:23 got it 20:21:29 #topic Moving the RefStack project from openstack-infra to Big Tent. 20:21:41 #link https://review.openstack.org/213930 20:21:45 So... refstack was recently added to the infra project (with https://review.openstack.org/#/c/205609/) 20:21:54 yay! 20:21:55 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 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 kind of a good thing that the repo wasn't renamed to openstack-infra/refstack yet :) 20:22:26 Uh, I think someone told them they should move? 20:22:26 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 Rockyg: "someone" ? 20:22:45 so ... I have two competing thoughts in my brain on this one 20:22:49 does this group of people want to take on the broader mission? 20:22:49 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 but they weren't ready for that. 20:23:07 (But then if this team is solely focused on the Interoperability Test Report I guess that works) 20:23:09 Yeah. Didn't get the name. Might have been ttx's comment that triggered the whole thing? 20:23:20 heh 20:23:27 late-action trigger 20:23:49 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 i also am not entirely clear on where the change of heart originated 20:23:54 So, I think there is desire for the interop, but they are focused first on just getting the defcore stuff solid 20:24:15 OK anyway... the question is now whether the team is specific to refstack-the-tool or to interoperability-tools in general 20:24:15 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 can always rename, update scope, or whatever if it makes sense later 20:24:28 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 that does not mean it needs to be in the infra project 20:24:38 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 cause i mean, i learned about this yesterday 20:25:01 at any rate, i talked to catherine yesterday 20:25:04 ttx there was desire for better tooling for testing at ops mid-cycle 20:25:25 ttx there are plans to move it beyond defore. Allowing non-defcore schema for interop for example. 20:25:29 I think the thing confusing placement is the data storage requirement 20:25:58 The data is foundation data for defcore, but the rest..... 20:26:14 hogepodge: so you think it majkes more sense as "Refstack" team or as "Interop" team ? 20:26:21 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 and catherine agrees with that. 20:26:46 So, as other projects, Refstack is the project name, interop is the function/area 20:27:05 right, so shouldn't it then be an interop project, with an interop PTL 20:27:09 catherine's concern with 'interop' is that she doesn't want to barge in on defcore's area 20:27:10 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 and refstack is just a piece of that 20:27:24 Rockyg: ok, I guess we can always expand it 20:27:29 if needed 20:27:36 she sees defcore as owning "interop" and refstack as interpreting and executing on that. 20:27:37 jeblair: ok, I guess I'm confused, I thought refstack was tooling to prove defcore 20:27:39 i agree with here there. 20:27:45 sdague: ^ that help? 20:27:47 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 jeblair: sure, I don't understand how that makes it different than QA and Tempest 20:28:21 looks like it's refstack only for the time being, so I +1ed it 20:28:22 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 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 sdague: lack of bod involvement? :) 20:28:39 Still missing quite a few votes 20:29:07 hogepodge: so is it a QA tool then? 20:29:30 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 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 sdague: no, I thnk it isn't 20:29:50 sdague: I think refstack has a different audience - tempest is a tool for developers 20:29:55 i think refstack is part of openstack 20:29:58 sdague: it's built on QA, and we've worked closely with them 20:30:09 refstack is a tool to vet deployments against an interop definition 20:30:15 mordred: sure 20:30:19 which is why i think it being its own openstack project/program is a good thing 20:30:22 jeblair: ++ 20:30:29 I guess I see 3 things: Infra, Interop, QA 20:30:38 and the current conversation is that refstack is a 4th thing 20:30:57 which, I guess if we need it to be so, that's fine 20:30:58 refstack is a specific tool and the refstack team has a narrow mission. I'm fine with that 20:30:58 I think refstack is the technical arm of interop 20:31:05 mordred: ya 20:31:08 so, then it would be the Interop program 20:31:11 right? 20:31:12 yah 20:31:15 refstack is looking at adding support for out of tree tests, and reporting on them 20:31:16 I think that's what they're saying 20:31:21 with a code name of "refstack" 20:31:25 So, interop program, but refstack project 20:31:32 mordred, ++ 20:31:41 interop is more than tech 20:31:47 in a way unlike qa 20:32:02 (sidenote: we don't have programs anymore) 20:32:03 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 there's policy/trademarks/political things involved 20:32:14 (we have project teams and deliverables) 20:32:22 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 I'm fine with it starting as Refstack and expanding if need be to "Interop tools" 20:32:45 hogepodge: if those teams want to work together, it would be good to set that up early 20:32:47 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 s/defocer/defcore/ 20:33:24 I prefer defocer 20:33:32 is that French?:) 20:33:33 ttx: ++ 20:33:34 ok, I guess lets just do the narrow thing and move on then :) 20:33:37 * Rockyg kinda likes defocer 20:33:38 jeblair: it seems wise to limit scope for the team mission, then, if that's what they're actually focused on 20:33:39 hogepodge: tailgge didn't come up in my convo with catherine 20:33:39 sdague: yes 20:33:48 but like i said, i'm late to this :) 20:33:51 dhellmann: yes 20:34:07 jeblair: I've been working more with them. Catherine is very much focused on Refstack server/client as a toolchain. 20:34:09 They signed up to do refstack at this point. Not all interop tools or other interop tools 20:34:14 tailgate is a whole other can of worms... 20:34:19 none of this is set in stone 20:34:19 so the team should be refstack. 20:34:23 for the time being 20:34:28 ttx++ 20:34:34 seems like it 20:34:35 so please pile up approvals :) 20:34:49 one more 20:35:31 ok, let's get back to this later and see 20:35:37 #topic Temporarily add I18n ATCs 20:35:42 #link https://review.openstack.org/213989 20:35:51 We still require the TC to vote on extra-ATCs, and this one was short of a couple votes 20:36:00 I like that the translations team came up with a reasonable way to measure "contribution" there 20:36:04 That will be useful when we run elections for the I18N PTL 20:36:17 ++ 20:36:25 ok, enough votes now, approvinug unless someone screams now 20:36:55 approved 20:37:03 #topic Add constraints details to project testing interface 20:37:08 #link https://review.openstack.org/215399 20:37:14 This is a change to the project testing interface, introducing constrained unit tests 20:37:29 Sounds like a good incremental change to me. Comments ? Objections ? 20:37:44 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 seems fine, I guess I wonder if there is a reason this isn't the default behavior 20:37:52 haha 20:37:52 (has enough votes to pass, so I'll approve unless someone screams now 20:38:09 i was wondering whether this should eventually be required? 20:38:11 dhellmann: that's why I said "good incremental change", was thinking the same 20:38:14 it looks like it's all optional now 20:38:19 yeah 20:38:21 i may be saying similar things 20:38:28 as dhellmann, sdague, and ttx :) 20:38:29 oh, had a question. maybe it shouold be made mandatory ? 20:38:39 jeblair: if it's optional, and a team doesn't do it, the only jobs broken will be theirs, afact 20:38:42 lifeless: ^? (if electricians are leaving you alone for a moment) 20:38:42 afaict 20:38:58 i get the impression we would want this to become the default in time 20:39:14 fungi: that wfm 20:39:15 I suppose technically if we make it the required default now, no projects would be in compliance. 20:39:16 anyway, that doesn't make the change less valid. Can always switch to mandatory in a subsequent patch 20:39:26 so I'll approve now 20:39:38 yup, just would like to know the future 20:39:44 ++ 20:39:52 make it mandatory for Mitaka 20:39:54 I think the future is in "mandatory" 20:40:06 ok approved 20:40:14 #topic Add election repository to tc-repos 20:40:18 #link https://review.openstack.org/213806 20:40:29 That's a TC-owned repo so we need to vote on its addition, but that should be afst 20:40:34 or fast 20:40:37 It will be used to contain election data. Not sure if anyone has questions 20:40:47 A couple more +2s wouldn't hurt there 20:40:57 * dhellmann votes again 20:41:18 fungi: long term maybe, bu tneed to ramp up adoption first. -> back to electricians 20:41:23 ok, we ahve enough, will approve now unless someone screams 20:41:50 approved 20:41:50 lifeless: thanks, that's what it seems like we all ended up assuming anyway 20:41:53 #topic Introduce assert:follows-standard-deprecation tag 20:41:57 #link https://review.openstack.org/207467 20:42:03 Like we decided last week, I removed the "never deprecate anything" assertion from the proposal 20:42:10 and merged Zane's config option deprecation assertion into this 'I follow standard deprecation rules' single tag 20:42:21 ttx: good good 20:42:22 I'm happy answering questions you may have, otherwise please add approvals to the review so we can move on 20:42:41 I'll approve if it ever passes 7 yes 20:42:54 cpallares: around? 20:42:58 yes 20:43:05 #topic Present CoC rework (cpallares) 20:43:13 hello all o/ 20:43:17 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 flaper87 added you on the agenda last week so that you can present the CoC work 20:43:23 welcome cpallares 20:43:38 ttx: thanks! 20:43:41 Our current code of conduct https://www.openstack.org/legal/community-code-of-conduct/ 20:44:00 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 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 cpallares: good point; i think we have previously reported violations to the foundation community folks 20:44:51 jeblair: Oh awesome, that's good to hear. 20:44:53 So my original feedback to an earlier CoC is that I would rather report to a person than a form. 20:44:59 cpallares: good. I was just about to say "a method of ajudication" is also important 20:45:03 annegentle: That would be better. 20:45:16 I would want to know who exactly knows what I am telling them. 20:45:27 annegentle: I think that's a very good point 20:45:30 annegentle: That's the other thing 20:45:35 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 yes, being able to report issues in confidence is important 20:45:41 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 jeblair: worth noting that we don't have a single "community manager" anymore so clarifying wouldn't hurt 20:45:54 The Summit code of conduct has procedures 20:45:55 ttx: yep. 20:45:56 #link https://www.openstack.org/summit/tokyo-2015/code-of-conduct 20:45:58 cpallares: ++ 20:46:13 cpallares: yes 20:46:16 cpallares: I like all of the things you are saying - they addreess my concerns with most of the CoCs out there 20:46:23 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 cpallares: so you're asking about the generic one? 20:46:27 annegentle: The thing is that that one only applies to the summit. 20:46:32 cpallares: got it 20:46:45 cpallares: I completely agree we need one for all contexts. 20:46:46 annegentle: I think there's another one for the openstack blog. 20:47:22 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 cpallares: would there be a single CoC for events & general community conduct ? 20:47:24 I reported a CoC concern to jbryce 20:47:45 yeah, the Foundatiojn secretary is the person ultimately named in the bylaws 20:47:54 ttx: I'd like to examine and expand all of them, but right now I'm focusing on our online community. 20:47:59 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 Things that would apply to IRC, mailing list, meetings, etc. 20:48:15 so at the very least the secretary should be part of whatever first-line committee you would suggest 20:48:18 fungi: ++ 20:48:29 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 enforcement manual, it has frequently asked questions and a change log. 20:48:52 All those things would be a good place to start. 20:48:56 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 (asynchronously approved the refstack project team) 20:49:23 cpallares: and the "ombudsman" group from the board didn't pan out? mordred or markmcclain do you know? 20:49:25 would it be a bylaws change? 20:49:37 annegentle: that's a different group/purpose 20:50:03 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 appendix 6, probably yes 20:50:37 heh, we have a code of conduct and a community code of conduct 20:50:43 oh good 20:50:44 mordred: ok 20:50:50 it's good when we keep things clear 20:50:54 https://www.openstack.org/legal/code-of-conduct/ and https://www.openstack.org/legal/community-code-of-conduct/ 20:51:08 mordred: one is for board members, you should have read it 20:51:33 I think one is specific for people within the foundation? 20:51:43 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 And says things like "don't take bribes" 20:51:59 yeah i think the community coc is what we're primarily concerned with 20:52:07 ttx: I'm looking for guidance. 20:52:11 and ensuring it's applied beyond just events 20:52:17 cpallares: I like the Django CoC - it's clear and communicative 20:52:53 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 cpallares: we can take the homework of reading the Django CoC and get back to you with comments ? 20:53:08 cpallares: since it's a power that lays with the foundatoin and therefore with teh BoD 20:53:14 cpallares: because the events one has guidance that's difficult to enact online? 20:53:14 i do think there are aspects of our current coc not covered by the django coc 20:53:15 ttx: Sounds good. 20:53:17 i would hate to lose those 20:53:18 cpallares: however, I think we'd all love to be actively involved 20:53:25 jeblair: ++ 20:53:26 ttx: So what could be the next steps to make this happen? 20:54:03 how about you come back next week and we'll all have read the CoC and communicate comments 20:54:13 ttx: Sounds good. 20:54:49 #action TC members to read the Django CoC https://www.djangoproject.com/conduct/ and prepare comments for next meeting 20:54:57 thanks cpallares for giving us good reading material and an action 20:55:06 cpallares: yes, many thanks ! 20:55:24 #topic Workgroup reports 20:55:58 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 oh neat 20:56:19 i can kick that manually if needed 20:56:21 I submitted a dumb change to test it 20:56:26 or that 20:56:29 ha no way 20:56:37 it's just llst in the gigantic post queue 20:56:41 lost 20:56:53 annegentle: it was not totally dumb 20:56:54 need moar clouds 20:57:01 jeblair: working on it 20:57:08 woo 20:57:10 zuul gated us 20:57:25 Any other workgroup with an update ? 20:58:28 next-tags WG: Please vote on https://review.openstack.org/#/c/207467/ or ask questions if you still have some 20:58:32 none from comms other than "do we need a blog post this week?" 20:58:57 once we get the new project team guide posted we can add to the highlights blog 20:58:59 Not much to report on, apart from refstack move 20:59:00 other topics? 20:59:07 refstack move is good 20:59:15 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 sdague: wording suggestions welcome :) 20:59:45 #topic Open discussion 20:59:47 annegentle: we have recognized atcs for translation/i18n now. that may be relevant 21:00:15 fungi: perfect, 3 topics makes a post 21:00:36 Last words ? 21:00:45 Thanks everyone 21:00:46 #endmeeting