20:01:31 <ttx> #startmeeting tc
20:01:31 <openstack> Meeting started Tue Jul  5 20:01:31 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:33 <annegentle> hey jroll
20:01:34 <openstack> The meeting name has been set to 'tc'
20:01:35 <edleafe-> damn you annegentle!
20:01:38 <ttx> jroll: o/
20:01:43 <flaper87> o/
20:01:51 <mtreinish> o/
20:01:52 <amrith> \./
20:01:53 <ttx> Hi everyone... Short agenda for today, should be plenty of time for open discussion at the end
20:01:54 <devananda> o/
20:02:00 <dims> o/
20:02:02 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:09 <ttx> #topic Add project Bilean to OpenStack big-tent
20:02:14 <ttx> #link https://review.openstack.org/334350
20:02:26 <ttx> So... Bilean implements trigger-type billing, which is reactive to events rather than usage
20:02:36 <ttx> This is pretty close to the CloudKitty/Ceilometer/Gnocchi combination in scope, but different
20:02:45 <ttx> That is in itself fine, it may well be different enough to justify a separate project
20:02:56 <ttx> But the path of developing the missing features in existing projects should be explored first
20:03:07 <ttx> Since otherwise we may end up with separate projects both dying of not reaching critical mass (instead of one successful project)
20:03:20 <ttx> sheeprine (CloudKitty PTL) opened a thread to discuss that on the ML
20:03:20 <flaper87> yeah
20:03:26 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/098640.html
20:03:27 <annegentle> yeah
20:03:28 <flaper87> I've put my thoughts on the review
20:03:38 <ttx> no answer yet
20:03:38 <flaper87> and I still think it makes sense to wait before adding Bilean
20:03:47 <ttx> (and I really think that should have happened before this was ever presented to us)
20:03:57 <mordred> o/
20:04:06 <ttx> Also, quick glance at Bilean shows that most changes are massive and self-approved
20:04:10 <dhellmann> it looks like this repo was imported from a bunch of existing code?
20:04:14 <dims> they had one meeting (http://eavesdrop.openstack.org/meetings/bilean/2016/) - 2 emails to openstack-dev. that's it
20:04:18 <ttx> So even ignoring the scope issue I'm not convinced we would approve it as it stands
20:04:23 <flaper87> dhellmann: yup, that's my understanding
20:04:27 <russellb_> Seems premature
20:04:38 <russellb_> (Here via mobile until take off)
20:04:52 <flaper87> russellb_: safe travels
20:05:04 <johnthetubaguy> yeah, seems premature right now to add it, regardless
20:05:15 <ttx> OK, I'll draft careful rejection pointing at the started thread, the Project Team Guide and the need for more core reviewers
20:05:19 <dims> one person committing code - http://git.openstack.org/cgit/openstack/bilean/log/ (mostly)
20:05:33 <ttx> dims:  same person +2/W+1 ing too
20:05:43 <flaper87> is this perhaps one of those cases where the contributor thinks being in the big tent is a requirement ?
20:05:55 <russellb_> Thanks ttx
20:05:55 <flaper87> I honestly didn't dive much into the list of contributors
20:05:58 <dims> flaper87 : yea, possibly
20:06:15 <ttx> flaper87: I don't think so. Looks more like a case of an internal development that they thought they would propose to us
20:06:38 <flaper87> sure but given the state of the project, it feels like the former
20:06:38 <dims> ttx : ah
20:06:39 <ttx> I'm not convinced they are interested in converging with CK. They have something and use it the way it stands
20:06:50 <johnthetubaguy> in many ways, the process worked, they proposed it, and we have told them who they should talk to first
20:06:58 <dhellmann> good point, johnthetubaguy
20:07:00 <ttx> But we'll see where the discussion goes. Could be good news and additional contributors to CK
20:07:04 <flaper87> anway, without THE contributor around (I don't know his/her IRC nick) it'll be a bit hard to clarify these things
20:07:15 <dhellmann> there's some evidence that the company here has worked with other teams already
20:07:24 <dhellmann> http://stackalytics.com/?user_id=&project_type=all&release=all&metric=marks&company=Kylin%20Cloud&module=bilean
20:07:33 <dhellmann> oops, try http://stackalytics.com/?project_type=all&release=all&metric=marks&company=Kylin%20Cloud
20:08:01 <dims> flaper87 : 3 people nicks are listed in meeting - http://eavesdrop.openstack.org/meetings/bilean/2016/bilean.2016-06-23-14.00.html
20:08:09 <russellb_> I just want to encourage collaboration wherever we can. I haven't taken a close look yet. The lack of discussion or analysis was enough for me to start with.
20:08:14 <amrith> flaper87, his irc name is lvdongbing, I think.
20:08:17 <dhellmann> flaper87 : looks like a chinese company, so this may be a bad time for synchronous discussion
20:08:20 <ttx> OK, I think we can move on, I'll write up something on the review. If you have other points you can file them there
20:08:24 <annegentle> okay.
20:08:27 <dhellmann> russellb_ : ++
20:08:33 <dims> ++ ttx
20:08:38 <flaper87> let's move on and I'd love to see more collaboration too
20:08:39 <flaper87> amrith: thanks
20:08:51 <russellb_> Cheers.
20:08:56 <ttx> #topic Exclude inactive core reviewers from core metrics
20:09:01 <ttx> #link https://review.openstack.org/332751
20:09:14 <ttx> This proposes that we ignore *inactive* core reviewers from the 'core reviewers %' and 'core reviews %' metrics used in diversity tags
20:09:24 <russellb_> +1 to the idea of this.
20:09:29 <ttx> My initial reaction to this one was that the "core reviews %" metric already takes activity into account, so I didn't think we'd capture additional issues using this adjustment
20:09:40 <ttx> But then I agree that inactive core reviewers should just be considered as leftover entries rather than real core reviewers
20:09:47 <dhellmann> while this doesn't actually encourage folks to clean up their core teams, it closes a whole where we were rewarding them for not doing so
20:09:55 <dhellmann> *hole
20:09:57 <flaper87> yeah
20:09:59 <dims> dhellmann : right
20:10:06 <ttx> I'm not sure the '30' threshold is the best one to capture that, but we can nitpick that in the tools by looking at the effect of the change
20:10:21 <dhellmann> yes, I think we should definitely have that separate discussion
20:10:24 <ttx> So I agree that we can add the word 'active' to the tag definition, and then adjust the tools.
20:10:33 <johnthetubaguy> yeah, I like how its nice and explicit, and simple
20:10:34 <flaper87> Also, note the goal of this patch is not to discuss what active/inactive is. It also doesn't define what the right threshold should be. I'm working on a follow-up patch for that
20:10:46 <flaper87> we should stick to the current definition and threshold
20:10:49 <annegentle> flaper87: and I added (just now) a request to put the definition of "active" in the text itsefl
20:10:52 <annegentle> itself
20:10:58 <annegentle> flaper87: ah ok.
20:11:03 <mtreinish> I understand the motivation here, but it seems kinda arbitrary to me without the second part flaper87 just mentioned
20:11:19 <mtreinish> I think we should have the definition first before applying it to things
20:11:26 <annegentle> flaper87: so you don't mind updating the patch after discussing here? So the text and code are synched?
20:11:31 <dims> ++ mtreinish
20:11:32 <flaper87> mtreinish: fwiw, we already do this for the diverse-affiliation tag. We're adopting it in the single-vendor one
20:11:34 <dhellmann> annegentle : yeah, we use it elsewhere in the repo both in text and code, but I agree we should move the definition to text somewhere and have the tool refer to that (as ttx said)
20:11:37 <russellb_> Doesn't one of the tools already check this?
20:11:38 <ttx> flaper87: I'm good with how it stands right now
20:11:43 <russellb_> And we just didn't document it?
20:11:47 <flaper87> annegentle: there was one and I just removed it
20:11:49 <dhellmann> mtreinish : we do have a definition already, it's just documented as code
20:12:00 <ttx> russellb_: no, we only used the threshold for "reviewers"
20:12:02 <fungi> so this is at least 6 commits merged and at least 30 reviews posted in a 6-month period?
20:12:07 <russellb_> Ah ok
20:12:14 <mtreinish> dhellmann: is it, flaper87 just said we're not defining 'active' in the code patch. That it'll be a follow up change
20:12:27 <amrith> to ttx's point here though, I'm not certain what this change would actually accomplish. If a core reviewer is not active (i.e. not a lot of reviews) then the other metric (core reviews by company) would trip. So, what really is the change? So I tried to run flavio's code and noticed nothing really changed in terms of tags. So, is it worth it? Should we figure out what metrics we want to measure first and then decide
20:12:27 <amrith> the metrics?
20:12:30 <flaper87> fungi: it currently just uses the reviews number
20:12:41 <mtreinish> the 30 in there feels kinda random to me, and just a starting point
20:12:44 <dhellmann> mtreinish : we're going to propose moving that definition to prose and possibly changing the value
20:12:55 <flaper87> amrith: it does change if you print the values of the metric
20:12:55 <dhellmann> bah, this is exactly what we were trying to avoid
20:12:59 <mtreinish> dhellmann: and I'm saying that should come first
20:13:06 <flaper87> several projects get close to the threshold
20:13:14 <dhellmann> we have 2 things to do: fix this tag and fix the active definition. they're orthogonal. let's focus on this patch.
20:13:17 <ttx> mtreinish: why ? I'm fine giving us some flexibility there
20:13:31 <ttx> for example, 30 might be too large for smallish projects
20:13:43 <ttx> but 2 too small for largish projects
20:13:45 <notmorgan> mtreinish: i am -1 unless we have a clear definition at least proposed on what is active
20:13:50 <dhellmann> mordred proposed looking at standard deviations, too
20:13:55 <notmorgan> i'm also ok with a "scaling" 'active' standard
20:14:03 <dhellmann> notmorgan : the existing script is the definition of active.
20:14:04 <notmorgan> but we need some level of metric (or range?)
20:14:16 <notmorgan> dhellmann: that is not sufficient imo, it needs to be in the text.
20:14:24 <notmorgan> not digging into python code
20:14:32 <ttx> notmorgan: why ?
20:14:49 <notmorgan> it should be clearly published in the same place we define activity is required
20:14:54 <flaper87> whether it is in text or not, I don't think we should block this patch on that.
20:15:00 <notmorgan> not "oh go find it here in the python ->>>>"
20:15:11 <jroll> presumably, not everyone reading tag definitions can read python
20:15:13 <notmorgan> or wherver, or at least *linked* to the place in the code
20:15:18 <notmorgan> jroll: ++
20:15:18 <ttx> notmorgan: we could let it be slightly subjective
20:15:20 <dhellmann> we are going to do both
20:15:25 <flaper87> I've some text written (Actual text) to define this but I was not happy with the wording so I decided not to publish it yet
20:15:26 <dhellmann> we are trying to close a loophole first
20:15:32 <notmorgan> ttx: i'm fine with it being subjective, but define "active"
20:15:39 <notmorgan> not say "active is needed" without definition
20:15:43 <ttx> notmorgan: "not dead" ?
20:15:47 <mtreinish> notmorgan: ++
20:16:03 <dims> ttx : dhellmann : which repo? (python code)
20:16:14 <flaper87> dims: governance: teamstats.py
20:16:18 <dhellmann> dims : the script in the governance repo that is used to apply this tag to projects
20:16:44 <ttx> notmorgan, mtreinish: (I don't really disagree with you, playing devil's advocate to get to the bottom of your objection)
20:16:58 <notmorgan> a minimal definition of "what is active"
20:17:00 <ttx> I also think we can do it in two steps
20:17:03 <notmorgan> even if ti claims it is subjective
20:17:05 <notmorgan> that is fine
20:17:14 <flaper87> notmorgan: FWIW, I don't think it's not defined. The way I see it is that we need to make the definition more explicit (the follow-up patch). But that won't change the fact that we should be excluding inactive core reviewers. We've a definition that we're using already and this proposes sticking to that definition until the next discussion happens
20:17:15 <notmorgan> just be clear what the current definition is before we add it
20:17:21 <notmorgan> also, a followup patch is fine.
20:17:26 <notmorgan> just have it proposed.
20:17:33 <ttx> notmorgan: we use the wording "active reviewer" in the other tag definition, without defining it. That just proposes to make the "core reviewers" side of the equation catch up
20:17:38 <notmorgan> i'm -1 code review, but wont -1 Rollcall
20:17:38 <notmorgan> i also wont +1 either way.
20:17:40 <ttx> then we can refine
20:17:54 <notmorgan> just my view.
20:17:55 <annegentle> flaper87: what's interesting then is the definition of core reviewer, right? each project will have a different set of criteria / activity and some may have written those down. then what?
20:17:58 <mtreinish> notmorgan: I did the same
20:18:07 <ttx> could be done the other way around though, I agree
20:18:17 <notmorgan> so, feel free to override me, i'll support. my -1 is a voice of i dislike this change w/o some level of definition
20:18:21 <dhellmann> annegentle : we don't usually get into that in terms of stats. We look at members of the team with +2 rights.
20:18:33 <notmorgan> since we're leaning on it. but i'm also not wanting to block this.
20:18:35 <annegentle> flaper87: do we encode what projects have already written down as "here's how you get to core?"
20:18:37 <notmorgan> if that makes sense.
20:18:38 <johnthetubaguy> annegentle: its always someone who can +2 though, which I think is OK
20:18:54 <annegentle> johnthetubaguy: yeah, that definition is true any given query
20:19:02 <notmorgan> it's "good", just should have a minimal level of refinement so if we lean on this at all before we change the definition we have something to point at
20:19:02 <ttx> annegentle: that's subjective rather than quantitative
20:19:04 <notmorgan> thats all.
20:19:04 <flaper87> annegentle: this metric and definition is for use in the governance repo. I don't think we should get into the business of defining what active/core means for project teams
20:19:23 <annegentle> flaper87: but some teams already do... I think. I may be wrong.
20:19:37 <annegentle> flaper87: I looked into this for docs. Lana then wrote down a definition.
20:19:46 <johnthetubaguy> annegentle: all I mean is, projects define who they trust to have +2, and thats fine, largely
20:19:51 <ttx> flaper87: looks like you won't get enough votes to do it in two steps
20:19:55 <notmorgan> even just linking to a previous definition of active (fwiw, it should be central)
20:19:57 <notmorgan> is fine
20:20:07 <notmorgan> not "every doc re-defines" active
20:20:10 <mtreinish> flaper87: yeah I agree, we just should make that point clear. This is for governane purposes and project teams still define who has +2 etc...
20:20:39 <flaper87> I could publish my draft for the second patch now, I've it written down but I don't see why having the second patch up will change some of the votes
20:20:45 <ttx> Hrm. this is not about defining core reviewers anyway
20:20:46 <dims> i am ok with 2 step tango
20:21:04 <fungi> it might make more sense to avoid using the term "active" in the prose in that case, and just indicate what is actually being measured objectively rather than using a subjective term for it
20:21:15 <notmorgan> fungi: that would work for me too.
20:21:41 <dhellmann> fungi : that's like using a constant instead of a variable. if we end up changing the definition of active, we have to go change it here, too.
20:21:50 <dims> fungi : I like it
20:21:52 <annegentle> ttx: hm, true... it's about a metric
20:21:57 <fungi> dhellmann: yep, i'm saying don't have a definition for "active"
20:22:00 <notmorgan> i just worry that we're going to lean on this verbiage and then need to justify it AND then change it after the fact
20:22:09 <notmorgan> which could make people who are affected unhappyu
20:22:23 <johnthetubaguy> I would rather the rule was subjective, and we note we estimate that with this objective measure, as I think thats closer to the reality here
20:22:35 <notmorgan> and it can be defined as subjective
20:22:42 <notmorgan> just be clear what we're looking at
20:22:47 <mtreinish> johnthetubaguy: yeah, I'm leaning that way too
20:22:47 <fungi> just say the tag applies to reviewers with +2 on at least one repo and who have left n comments in 6 months instead of making up a word that it's a definition for
20:22:48 <notmorgan> "active" is VERY uncertain.
20:23:01 <johnthetubaguy> notmorgan: true
20:23:03 <notmorgan> because it could be lots and lots of things.
20:23:38 <notmorgan> i reviewed 3 things in two days, i am currently active.
20:23:38 <russellb> surely we can agree that someone who hasn't done anything in 3 years isn't worth counting?
20:23:46 <notmorgan> is that "Active"?
20:23:47 <dhellmann> this is one of the most objective we have because there's a script written specifically to generate the output for applying it. We're leaning on that existing, well trod, definition of "active"
20:23:47 <russellb> and if so, we can draw some sane line?
20:24:13 <russellb> it doesn't have to be perfect
20:24:15 <johnthetubaguy> so exclude inactive reviewers, then estimate that somehow?
20:24:18 <notmorgan> like i said, my concern is a bait and switch feel from folks affected
20:24:19 <notmorgan> thats all.
20:24:26 <fungi> again, which existing, well trod, definition of "active?"
20:24:35 <dims> flaper87 : do you have a list of projects that will switch tags based on this?
20:24:35 <flaper87> notmorgan: so, you want it all in a single patch. Is that correct?
20:24:40 <dhellmann> fungi : the script that flaper87 referenced above that's used to update the yaml file with this tag
20:24:43 <notmorgan> flaper87: or proposed as a followup
20:24:44 <ttx> OK -- SO... We already have a de-facto definition of active, used in the reviews % metric and reviewers % metric
20:24:58 <notmorgan> ttx: if we have that, we should lean on it for now or link to it.
20:25:00 <ttx> This just proposes to apply the same definition to core reviews
20:25:01 <russellb> which i made up when first writing that script
20:25:09 <russellb> and folks said "shrug, seems like a reasonable starting point"
20:25:16 <dims> russellb :)
20:25:18 <notmorgan> and it can be adjusted
20:25:18 <flaper87> notmorgan: I could propose the follow-up *now* but I'm curious to know how/why would that change your mind? It'd still be a 2-steps change
20:25:23 <fungi> and it was previously called "active" in another tag (but not this one). so i guess that counts as it being a sort of definition of the term
20:25:35 <ttx> notmorgan: That's what the proposed patch does. THEN we need to extract it from code to governance, I guess
20:25:42 <ttx> But this patch doesn't make anything worse
20:25:49 <notmorgan> flaper87: it means it is in work. i have seen a LOT of things fall off the radar (and I'm guilty of this too), it just keeps the convo active [or ML topic?]
20:26:09 <annegentle> flaper87: I'd can get behind a second patch that follows on
20:26:13 <russellb> i'd also like to paint it green
20:26:14 <mtreinish> ttx: except it silentyl changes what we're enforcing, without any outward indication. You have to look at the script to figure it out
20:26:14 <notmorgan> it's a continuity, so if someone complains we can say "lok here in XXXX review and comment"
20:26:17 <flaper87> ok, proposing it now
20:26:27 <notmorgan> we have a clear place to point folks vs "oh ... in the future"
20:26:28 <dims> ttx : if we end up changing definition of active, then some projects will flip flop
20:26:58 <notmorgan> flaper87: i prefer it a single patch, but also understand the defnition may need work
20:27:01 <annegentle> dims: amrith (who's better than me!) tested it though and no projects get different tags because of it (Right?)
20:27:14 <amrith> I'm trying it again annegentle
20:27:20 <amrith> I've used this tool in the past
20:27:26 <amrith> and am somewhat familiar with it
20:27:49 <amrith> but the threshold that flaper87 proposed doesn't cause it to generate any warnings like "XYZ shouldn't have this tag" or "XYZ should have this tag"
20:27:51 <notmorgan> sorry, just trying to make sure we're not causing flip-flopping of project status etc.
20:27:52 <amrith> which is what I expected.
20:28:00 <ttx> Oh well, I guess we could continue that one on the review. It's sad that those opposing it did not read it before
20:28:04 <amrith> notmorgan, that was my concern as well.
20:28:06 <notmorgan> without at least a place for those affected to comment after this lands.
20:28:13 <russellb> it's just a cleanup to be more explicit about something ...
20:28:15 <ttx> because this is not very constructive
20:28:23 <russellb> ttx: ++
20:28:24 <annegentle> I read it, but didn't test it.
20:28:49 <dims> ttx : i am not opposed, just looking for some additional info
20:28:54 <ttx> The meeting is not the best placve to discover opposition
20:28:59 <ttx> place*
20:29:12 <flaper87> annegentle: fwiw, I tested it too and no projects would be tagged as a sinle vendor just yet. Some of them get close, though.
20:29:32 <ttx> flaper87: do you think we should continue to discuss it here, or on the review ?
20:29:33 <amrith> thx flaper87 I concur with that assessment.
20:29:39 <dims> flaper87 : fair enough.
20:29:40 <dhellmann> the projects with this tag are going to change over time, whether we change its definition or not
20:29:44 <annegentle> flaper87: ok, thanks
20:29:46 <flaper87> notmorgan: mtreinish https://review.openstack.org/#/c/337853/
20:29:52 <flaper87> That's the follow-up
20:30:01 <flaper87> I've marked as WIP but that's the draft I have
20:30:24 <flaper87> I'm not super happy with it, I'll be super honest and say I had a bit of a hard time writing that down and finding the "right" wording.
20:30:28 <ttx> Oh, this one is a bikeshed magnet
20:30:29 <notmorgan> flaper87: thats fine
20:30:36 <flaper87> but I hope the review would be a good place for people to go crazy over the text
20:30:40 <flaper87> (go crazy in a good sense)
20:30:45 <mtreinish> flaper87: yeah, that's what I'm looking for
20:30:47 <notmorgan> flaper87: removed my -1 on the original one with a link so we can continue the convo
20:30:51 <dims> flaper87 : "minimum number of gerrit reviews"
20:31:12 <ttx> "This metric is not used (but will be used) to evaluate reviewers"
20:31:33 <fungi> this is what i meant about avoiding the word "active"
20:31:37 <flaper87> I'm done now. I hope we can get the first one in while we discuss the second one
20:31:45 <flaper87> we can move on
20:31:59 <flaper87> I don't expect us to fine the perfect definition for what we really mean in this meeting
20:32:07 <ttx> me neither
20:32:15 <dhellmann> fungi : we're trying to define "active" in one place so we can use the same definition in more than one place without having to update it everywhere when that definition changes. Why do you consider that a bad practice?
20:32:26 <fungi> dhellmann: the word itself is charged
20:32:30 <flaper87> s/fine/find/
20:32:45 <ttx> ok, moving on
20:32:47 <dhellmann> fungi : ok, we can pick a new word.
20:32:47 <fungi> but we can take that discussion off-meetiong
20:32:51 <dhellmann> ttx: yes, please
20:32:53 <ttx> #topic remove release:managed tag
20:32:59 * dhellmann stops beating his head on his desk
20:33:00 <ttx> #link https://review.openstack.org/335440
20:33:04 <ttx> dhellmann: care to introduce this one ?
20:33:14 <ttx> (or I can if you prefer)
20:33:33 <dhellmann> this tag is no longer used by the release team. I think it's no longer useful to the TC either. Folks have been trying to add it to their project, and I don't want us to spend time on it since no one is using it.
20:34:12 <ttx> Still missing a couple of votes
20:34:53 <russellb> vote added
20:34:59 <notmorgan> vote added
20:35:00 <russellb> still 1 down
20:35:09 <notmorgan> i already looked at it, and hadn't scored it
20:35:09 <ttx> alright, a winner we have
20:35:10 <notmorgan> lgtm
20:35:23 <amrith> good to go, this is (yoda)
20:35:27 <ttx> die, useless tag, die
20:35:30 <annegentle> it's deliverables not projects... but I didn't vote...
20:35:31 <notmorgan> lol
20:35:46 <ttx> annegentle: heh
20:35:51 <annegentle> I like the spirit! :)
20:36:32 <ttx> #topic Open discussion
20:36:43 <ttx> Some early feedback from the leadership training that some of us attended last week
20:36:48 <ttx> I think we were all surprised how useful it was
20:36:50 * dims perks up
20:36:52 * notmorgan is super sad to have missed it
20:37:04 <ttx> Personally I think the main value was in having us locked in a room for 2/3 days without distraction with some training/inspiration/tooling to learn from and open our minds
20:37:07 <notmorgan> i... also am just now feeling closer to 100%. stupid flu.
20:37:09 * devananda perks up, too
20:37:16 <ttx> This was extremely well selected and prepared by gothicmindfood
20:37:21 <dhellmann> ++
20:37:26 * amrith very honored to have been there. wrote a blog post about it http://www.tesora.com/openstack-tc-will-not-opening-deli/
20:37:30 <jroll> ++
20:37:32 <devananda> ++
20:37:36 <notmorgan> i am also very glad to not have shared the flu with the TC
20:37:40 <notmorgan> and other folks.
20:37:45 <flaper87> o/
20:37:45 <dhellmann> notmorgan : thank you for that
20:37:53 <flaper87> 2 things
20:37:59 <flaper87> The first is a more general question to other TC members. How do people in the TC feel about the tc-chair delegating some of his duties when he/she is away? This doesn't happen frequently but there are occations when those delegations would help moving things forward in the absence of the tc-chair. We've never talked about this and a quick show hands would be great.
20:38:01 <annegentle> notmorgan: yeah, thanks, no time for that!
20:38:26 <notmorgan> i think it's fine. it's the same as a PTL delegating imo
20:38:27 <dhellmann> flaper87 : we've delegated chairing meetings before. What else did you have in mind?
20:38:32 <ttx> that would include delegation of the tc-chair +2 rights over the repo
20:38:37 <flaper87> dhellmann: formal votes
20:38:38 <mtreinish> flaper87: ttx takes time off?
20:38:38 <notmorgan> the responsibility is the chair's but delegation is within those rights
20:38:43 <ttx> mtreinish: no
20:38:44 <flaper87> mtreinish: secretly
20:38:52 <dhellmann> mtreinish : not enough
20:38:59 <flaper87> dhellmann: ++
20:39:17 <annegentle> that's a good idea for sanity and stewardship in combination
20:39:36 <flaper87> just wanted to make sure there weren't strong oppositions to encouraging ttx to take some proper time off
20:39:40 <flaper87> :P
20:39:44 <johnthetubaguy> yeah, seems sound to me, to allow that
20:39:45 <notmorgan> i have zero issue. and ttx should totally take time off.
20:39:47 <mtreinish> flaper87: heh
20:39:47 <ttx> I'll be explicit anyway, like posting a warning on the tc list
20:39:47 <dhellmann> I think it would be fine. We have a good level of trust with each other and it'd be wise to have multiple folks with the experience.
20:40:07 * flaper87 calls ttx's ISP and asks them to shut his internet connection DOWN
20:40:09 <ttx> whenever I adjust the gerrit group
20:40:19 <flaper87> ok, I've one more thing
20:40:21 <flaper87> The second thing is a, hopefully, improvement to the way we communicate TC matters to the rest of the community. I'd like to start sending TC meeting logs to the mailing list (again?). This would not replace the communications posted on the foundation blog but it'd give more immediate feedback of what's going on in the TC.
20:40:22 <ttx> flaper87: you don't need to call, that happens regularly
20:40:22 <flaper87> The format of the email would include the agenda and quick (short) notes from the discussion. I'd love for us to start using meetbot's notes/infos more agressively as that would help writing this summary. Ideally, this would go out in the 24h that follow every TC meeting.
20:40:27 <flaper87> ttx: LOOOOOOL
20:40:59 <ttx> ew, yeah, we'd need to behave again
20:41:10 <ttx> and #info and #do things
20:41:16 <annegentle> flaper87: like more info tags?
20:41:18 <annegentle> ttx: yeah
20:41:21 <dhellmann> flaper87 : in the car on the way to the airport last week we identified meeting announcements and summaries as things that could be dropped from the ML to cut down traffic
20:41:42 <dims> i was thinking the same thing dhellmann
20:41:45 <johnthetubaguy> dhellmann: I have similar feelings, honestly
20:41:48 <annegentle> flaper87: do we have input that people want meeting notes?
20:41:51 <ttx> feels like a step backward
20:41:55 <dhellmann> anyone can use those commands, right?
20:41:57 <johnthetubaguy> that being said, I do like the idea of the notes being better
20:41:58 <mtreinish> dhellmann: yeah I know I normally skip the meeting log ml posts
20:42:00 <ttx> dhellmann: yes
20:42:15 <dhellmann> so we could have a volunteer to add them, so ttx doesn't have to
20:42:16 <flaper87> dhellmann: most of those have been dropped, I forgot already when I sent one the last time as PTL. However, the TC being such a cross-project/cross-community thing, it feels like those summaries would be useful
20:42:18 <jroll> I'd almost rather a newsletter "what's the TC been up to?"
20:42:25 <dhellmann> and then we would still have the results, but skip the email
20:42:26 <johnthetubaguy> flaper87: so would just better notes be a reasonable middle ground?
20:42:28 <jroll> similar to the "what's up doc" thing
20:42:36 <ttx> yeah, agree that we should #info more things -- not sure yet another post to the ML helps
20:42:40 <flaper87> dhellmann: anyone can run those commands, yes
20:42:45 <flaper87> more notes would definitely help
20:42:47 <dhellmann> jroll : yeah, annegentle and flaper87 have been doing those as blog posts
20:42:48 <notmorgan> jroll: and the infra thing.
20:42:50 <mtreinish> jroll: isn't that the foundation blog post?
20:42:52 <jroll> then it could include things like summaries of threads on the tc mailing list or side conversations
20:43:01 <jroll> mtreinish: not sure, how often is that published?
20:43:08 <dhellmann> "as needed"
20:43:14 <johnthetubaguy> jroll: I do like that general idea, maybe once per milestone ish
20:43:33 <johnthetubaguy> dhellmann: as needed is a little dangerous, in terms of it not happening
20:43:34 <flaper87> jroll: every time we feel there's enough info to publish
20:43:44 <jroll> ah
20:43:46 <flaper87> which is one of the reasons I'd like to make this summaries a routine
20:43:52 <flaper87> let me rephrase the intent
20:43:54 <johnthetubaguy> dhellmann: basing that purely on python-novaclient releases while I was PTL
20:43:57 <jroll> johnthetubaguy: I was thinking 1-4 times per month
20:43:57 <dhellmann> johnthetubaguy : they've been mostly doing OK at doing it every few meetings, esp. when there are big topics
20:44:10 <annegentle> flaper87: yeah state the outcome you're looking for if you can
20:44:15 <flaper87> One thing I'd like to improve is the request for input from the community on ongoing discussions
20:44:28 <ttx> flaper87: you should write a vision for it
20:44:31 <dhellmann> flaper87 : I agree that turning it into a routine would be good. I don't think we want to post a log from every meeting just because
20:44:31 <flaper87> And to provide quick updates of what has been discussed
20:44:37 <flaper87> ttx: jeeeeeeeeeeeeeeeeeeeeeeeeeeez
20:44:41 <dhellmann> the logs aren't that useful without the context you and annegentle have been adding to the blog post
20:45:02 <annegentle> yeah and the context is the hardest part to write :)
20:45:04 <flaper87> I can work on a sample format for that email
20:45:09 <flaper87> just posting logs is not what I want
20:45:12 <dhellmann> annegentle : right. maybe we should go back to rotating that duty
20:45:14 <annegentle> flaper87: I agree with wanting more input on discussions.
20:45:22 <flaper87> I'd send the agenda with notes on the topics that were discussed
20:45:28 <flaper87> with links to the logs at the bottom
20:45:41 <ttx> fact is, most weeks we just process boring stuff, so there isn't so much to learn from that
20:45:43 <jroll> vision: the community is up to speed with the happenings in the TC, and regularly giving feedback on those happenings :)
20:46:13 <johnthetubaguy> so... on that note, how do we get more of our work done async?
20:46:18 <flaper87> ttx: that's cool! Making it a routine would avoid thinking whether it's needed or not
20:46:21 <jroll> flaper87: I wonder if a better one is publish topics the TC wants input on before they're discussed in the meeting
20:46:30 <jroll> with a brief summary
20:46:41 <flaper87> jroll: sometimes we don't know that in advance :/
20:46:48 <amrith> jroll, I thought that was generally the case (generally ...)
20:46:50 <jroll> yeah
20:46:51 <johnthetubaguy> so the agenda post could go to the dev list?
20:46:52 <flaper87> I mean, some discussions evolve in unexpected ways
20:46:52 <ttx> johnthetubaguy: by commenting more on the review and less in the meeting ?
20:47:04 <johnthetubaguy> ttx: yeah, basically
20:47:04 <flaper87> input is *always* welcome
20:47:06 <dims> flaper87 : the email that ttx already sends on mondays...we can add more stuff there?
20:47:17 <johnthetubaguy> so I think if we are more async, ML and on reviews
20:47:24 <johnthetubaguy> it gives everyone more chance to contribute
20:47:26 <flaper87> dims: pretty much! Add the notes from the meeting and send that to the ML
20:47:31 <flaper87> that's the format I had in mind
20:47:47 <ttx> dims: except that is an openstack-tc email
20:47:57 <ttx> we could move it to -dev though, I guess
20:47:59 <dims> right
20:48:02 <flaper87> ttx: yeah, I'd send that to the -dev ML, of course
20:48:20 <ttx> but frankly, I would expect most people to not read past the first lines
20:48:41 <johnthetubaguy> so... should we kill the TC list? or is that still useful for something I haven't seen yet?
20:48:41 <notmorgan> ttx: i promise i'll at least read the subject! :P
20:48:47 <ttx> We can't rely on that as a way to communicate
20:48:57 <ttx> We are teaching everyone to filter aggressively openstack-dev
20:49:12 <ttx> so an email that is boring most of the tim shall be quickly ignored
20:49:16 <ttx> time*
20:49:30 <flaper87> except for the things that are important. I'd personally consider updates from the TC important but that's expected, I guess
20:49:34 <flaper87> (or not :P)
20:50:24 <ttx> johnthetubaguy: it's useful for administrativia discussions that we'd rather not spam the list with.
20:50:27 <amrith> ttx, with sending restrictions in place (must be a member to send), more lists is likely better than fewers lists.
20:50:33 <flaper87> ttx: do you have feedback from thingee w.r.t the ML weekly summaries ?
20:50:34 <johnthetubaguy> if we don't do it every week, I think the email becomes important
20:50:36 <ttx> Useful, but we could do without, certainly
20:50:40 <amrith> rather than the current method of [topic] in the subject.
20:50:43 <annegentle> flaper87: might be nice to brainstorm more communication and "write it down" ideas
20:51:03 <annegentle> flaper87: we could meet tomorrow early and send a post with ideas?
20:51:04 <ttx> flaper87: to make that efficient thingee hasd to cross-post it to planet / openstack blog and 3 MLs
20:51:08 <johnthetubaguy> ttx: I just wonder if we should do [tc-admin] or something, like we tell the projects to do?
20:51:20 <flaper87> annegentle: sounds great. I wrote some ideas down on my flight back last week
20:51:22 <annegentle> ttx: yeah, that was my thinking as well, you have to drown people with comms
20:51:31 <ttx> johnthetubaguy: that will likely result in people learning to ignore [tc]
20:51:43 <dims> ttx : dhellmann : during the training, was there some carrots or sticks we could be using better? (assuming we did not find any new carrots or sticks to influence)
20:51:44 <johnthetubaguy> ttx: yeah, thats while I think we need a separate tag for it
20:52:02 <annegentle> flaper87: ok, cool, I'll find you on IRC around 1430?
20:52:20 <dhellmann> dims : most of the "next steps" we identified were related to writing down assumptions and expectations that many folks understand but may not be clearly documented
20:52:38 <mtreinish> ttx: heh, you don't ignore it already? It gets put on random threads all the time
20:52:39 <flaper87> mmh, 15UTC would be better. I've a call at 1430 UTC
20:52:43 <ttx> dims: we're still digesting what we learned. We discussed communications on the last day but without a clear solution
20:52:48 <dhellmann> dims : and then building on those as a foundation
20:52:49 <annegentle> dims: it's about writing down expectations (at the six year mark we do need to write more down)
20:52:53 <annegentle> flaper87: works for me, great
20:52:57 <dims> dhellmann : ttx : annegentle : ack
20:53:30 <ttx> annegentle: flaper87: feel free to include me in that
20:53:31 <johnthetubaguy> dhellmann: ++ that stuff is the big (slightly hidden) barrier to entry, did a lot of that kind of documentation with the Nova team last few cycles
20:53:36 <flaper87> ttx: sure thing
20:53:43 <annegentle> dims: you want to read more about influence, I wrote this up afterwards (though it's not completely about the training, it's about having influence when you don't directly manage resources) http://justwriteclick.com/2016/06/30/influencing-community-documentation-contributions/
20:53:54 <annegentle> ttx: it's a party
20:53:59 <dhellmann> dims : one of the big take-aways for me was that the zingerman community of businesses is also based on a group of people who do things a certain way, and not that they do a certain thing. Similar to our big tent change.
20:54:01 <flaper87> ok, I'm done
20:54:05 <annegentle> is thingee around at that time?
20:54:11 <ttx> I fear we need to fix / facilitate communications first before we had more things to the pile
20:54:17 <dims> another interesting thought was about recording history of projects, decisions taken etc. (example http://docs.openstack.org/project-team-guide/oslo.html)
20:54:22 <ttx> annegentle: no, he is in Asia this week
20:54:27 <annegentle> ttx: ok thanks
20:54:31 <dims> annegentle : thanks! added to my reading list
20:54:36 <ttx> s/had/add
20:54:43 <johnthetubaguy> dims: that sounds a little like the architecture group
20:54:43 <flaper87> ttx: yeah, that's what I've been putting most of my thoughts on lately
20:54:50 <flaper87> ttx: how to facilitate/improve communication
20:55:17 <dims> dhellmann : ack
20:55:20 <ttx> flaper87: frankly, adding meeting summaries to an overcrowded list doesn't sound like a great solution to that :)
20:55:40 <dims> johnthetubaguy : yeah possibly
20:55:45 <johnthetubaguy> but having meeting summaries available for those that go looking, is useful
20:55:50 <anteaya> ttx: yeah I was just thinking we already have a lot to read
20:55:54 <dims> right johnthetubaguy
20:55:54 <ttx> johnthetubaguy: yes
20:56:01 <dhellmann> yeah, we want folks to learn where to find the information they're seeking and make it easy to consume. meetings are already logged somewhere other than the ML.
20:56:03 <ttx> johnthetubaguy: but they already are
20:56:26 <ttx> We shoudl do better at #info to make readable summaries. We should link them on governance.o.o
20:56:35 <annegentle> #link http://www.openstack.org/blog/category/technical-committee-updates/
20:56:35 <anteaya> doubling up communication I think is less efficient that saying this is where you find it
20:56:37 <flaper87> ttx: it might not be, sure.
20:56:38 <annegentle> that's the grouping
20:56:40 <ttx> We should publicize governance.o.o more
20:56:44 <johnthetubaguy> yeah, thats what I am meaning, better summaries, by using the cmds better
20:56:54 <dhellmann> johnthetubaguy : ++
20:57:00 <ttx> those are all steps that would improve the situation
20:57:11 <dhellmann> #agreed we should use meetbot more
20:57:18 <annegentle> yeah
20:57:26 <flaper87> dhellmann: :)
20:57:45 <ttx> dhellmann: #agreed is a chair command :)
20:57:46 <johnthetubaguy> so iterating feels good for these things, hopefully folks start finding us and asking questions, and we can start to build on what we have
20:57:50 <dhellmann> ttx: :-(
20:58:03 <ttx> You can do #info #idea #help and #action and #link
20:58:09 * flaper87 is happy we agreed on using meetbot more aggressively
20:58:10 <flaper87> :P
20:58:20 <ttx> #agreed we should use meetbot more
20:58:20 <dims> ++ flaper87
20:58:26 <flaper87> #action everyone to use meetbot more aggressively
20:58:43 <ttx> Anything else, anyone ?
20:58:51 <flaper87> nothing here
20:58:54 <flaper87> thanks everyone
20:58:59 <mtreinish> I likely won't be able to make it to the next 2 meetings
20:59:10 <mtreinish> I put it on the wiki already
20:59:24 <dims> mtreinish : safe travels/vacation!
20:59:36 <ttx> Any opposition to adding CPLs to projects.yaml ?
20:59:38 <mtreinish> heh, well linuxcon japan and the nova midcycle :)
20:59:43 <ttx> https://review.openstack.org/336395
20:59:44 <mtreinish> so mostly vacation
20:59:50 <dims> :)
21:00:01 <johnthetubaguy> ttx: feels like CPLs are a bit like cores, dealt with by the project
21:00:06 <ttx> On one hand it's good to have information centralized, on the other it feels like more churn for projects.yaml
21:00:09 <johnthetubaguy> ttx: but the wiki feels a bad way to maintain them
21:00:18 <ttx> johnthetubaguy: yeah, I'm there too
21:00:36 <dims> +1 ttx we can treat that as a trivial update
21:00:44 <dhellmann> ttx: they are series specific, so I suggested to include them in the new series stuff we're going to set up for goals
21:00:47 <johnthetubaguy> ttx: maybe a standard text file in every repo for contact info?
21:00:53 <ttx> dhellmann: ooooh
21:00:55 <ttx> nice
21:01:06 <ttx> dhellmann: could be in release repo ?
21:01:06 <dims> even better
21:01:07 <dhellmann> ttx: we could talk about moving ptls there, too
21:01:10 <anteaya> what is the benefit to having them in projects.yaml?
21:01:11 <notmorgan> (FYI timecheck, i think we're at the end)
21:01:12 <mtreinish> johnthetubaguy: that's an interesting idea
21:01:15 <dhellmann> ttx: no, governance
21:01:27 <ttx> ok, let's move that in-review
21:01:28 <dhellmann> anteaya : we're starting to build tools that want to parse the wiki page, and yaml is easier
21:01:32 <ttx> thanks everyone
21:01:36 <ttx> #endmeeting