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