20:01:36 #startmeeting tc 20:01:37 Meeting started Tue Mar 28 20:01:36 2017 UTC and is due to finish in 60 minutes. The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:40 The meeting name has been set to 'tc' 20:01:41 thingee: they all decide to go to bed early 20:01:51 decided* 20:01:53 Agenda at: 20:01:54 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:08 let's start with the first topic: 20:02:10 #topic Update diversity tags 20:02:14 #link https://review.openstack.org/448667 20:02:34 sounds like we had a negative feedback a few hours ago from Michael 20:02:46 I am here to answer questions 20:02:55 Give comments if asked for... 20:02:59 johnsom: do you disagree with the script we use to produce these results? 20:03:06 * edleafe hopes no one sees him wandering in late 20:03:11 johnsom: the ;etric at fault is core reviezs 20:03:18 oops us keyboard 20:03:28 the metric at fault is core reviews 20:03:34 I think it is a bit on the harsh side and penalizes a project for having the PTL at an active company. 20:03:42 johnsom: did you see the definition here: https://governance.openstack.org/tc/reference/tags/team_diverse-affiliation.html 20:03:54 Right, percent of core reviews from one company. 20:04:06 its two companies being more than 80% of something I thought? 20:04:12 I dug into the script when I heard about this. 20:04:23 it's not single-vendor, but it's not diverse either 20:04:52 johnthetubaguy: single company core review > 50% 20:04:54 right, diverse is a high-sh bar, and for a good reason 20:04:57 It was only the core metric we were over. 20:05:02 ttx: ah, OK 20:05:14 johnsom: yes true, and not by far 20:05:38 Right. We of course have been impacted my the musical chairs with developers. 20:05:50 * rockyg spies a slinking edleafe 20:05:55 johnsom: which also means it's probably not hard to get back over that line as long as it's a team focus 20:05:56 if the script isn't measuring what we intended, then i agree we should hold off updating tag application and fix that. if it's just that we're focusing on the wrong metrics entirely that's a separate discussion we should handle through a different proposal which shouldn't block the current one 20:05:57 the issue is, I don't think we can make the rule subjective 20:06:00 https://www.irccloud.com/pastebin/jR9uwWyL/ 20:06:05 * bswartz invokes Goodhart's Law 20:06:06 https://en.wikipedia.org/wiki/Goodhart%27s_law 20:06:12 johnsom: tbh, I don't think it's a terrible news to loose this tag. you're close to have it again anyway 20:06:20 fungi: ++ 20:06:31 For those curious in the actual numbers. (which might be nice on the commit message). 20:06:37 johnsom: the most important is the health of your project and I haven't seen negative signs so far 20:06:49 These don't get automatically re-added right? 20:06:54 fungi: yes, we can wait for sure. 20:06:58 johnsom: no 20:07:06 johnsom: we have a bot called ttx :D 20:07:21 he's a good little bot 20:07:22 johnsom: they get readded whenever someone runs the script again 20:07:22 can confirm he's a robot 20:07:26 but they do get re-added without necessarily needing to request that it happen 20:07:31 I try to do that every 2months-ish 20:07:39 ttx: it would be nice if the numbers for the projects were in the commit message 20:07:40 i was just going to ask that ttx :) 20:07:44 This just seems like another thing that makes it hard for small teams to participate and grow momentum. 20:07:47 just to make it concrete 20:07:58 ttx: we could have a periodic job in governance (so we stop doing it manually?) 20:07:58 sdague: ++ 20:08:04 sdague: aren't they ? you mean all the numbers ? 20:08:07 the 56 and 92 are there I guess 20:08:10 ttx: yeh 20:08:11 johnsom: well - in the past we've also talked about hopefully being able to use some of these to cajole folks in to contributing resources ... 20:08:14 ah, all 20:08:24 sdague: ok, will copy more next time 20:08:25 ttx: all of them, just as baseline 20:08:43 mordred Understand, it's a fine line I think we dance 20:08:54 johnsom: other companies may not realize that it would be good to get more humans on a thing - I _know_ everyone is always interested in the topic of lbaas 20:08:55 so do we agree to postpone it a little more until we discuss more about the script? 20:09:01 johnsom: totally agree 20:09:09 EmilienM: I'm good with postponing a bit 20:09:18 sure no urgency 20:09:22 one problem with a hard threshold is that teams right on the threshold for one of the metrics will tend to bounce in and out 20:09:24 can we set a time table though? 20:09:31 This is an indicator, and it is doing its job in raising awareness in places not otherwise aware of the situation. 20:09:32 some hysteresis might help here 20:09:36 zaneb: sort of a hysteresis? 20:09:37 zaneb: yeh, that's going to be true anywhere 20:10:05 zaneb: one reason for not running it weekly 20:10:06 #action postpone https://review.openstack.org/#/c/448667 and start discussion on how the script computes the diversity metrics 20:10:10 * mordred can provide hysteresis just by running around screaming, if it would help 20:10:31 Small teams, the cores are likely concentrated at a few organizations (we have three). 20:10:32 EmilienM: can we give it a date where we're going to move forward regardless 20:10:34 yeah, so once a team has the tag, maybe give them a bit more leeway before losing it again 20:10:38 mordred: i think you meant hysteria? 20:10:41 I will noodle and maybe propose something 20:10:51 johnsom: ++ 20:10:58 johnsom: well it's sure it's harder for small teams to be diverse 20:11:08 sdague: in 2 weeks max? 20:11:11 doesn't mean the tag definition is inaccurate 20:11:12 EmilienM: ++ 20:11:14 ttx: ++ 20:11:16 #undo 20:11:17 Removing item from minutes: #action postpone https://review.openstack.org/#/c/448667 and start discussion on how the script computes the diversity metrics 20:11:20 ttx: ++ 20:11:31 #action postpone https://review.openstack.org/#/c/448667 and start discussion on how the script computes the diversity metrics - take decision on the patch in the next 2 weeks 20:11:50 #undo 20:11:51 Removing item from minutes: #action postpone https://review.openstack.org/#/c/448667 and start discussion on how the script computes the diversity metrics - take decision on the patch in the next 2 weeks 20:11:55 #action postpone https://review.openstack.org/#/c/448667 20:12:07 right, part of the reason for this tag to exist it for consumers to understand how robust the contributor field is behind a project, so that if one or more orgs close shop, what is the impact on the project 20:12:08 #action start discussion about how we compute diversity metrics 20:12:15 I think "diverse-affiliation" is a high bar and hard to reach. Was honestly surprised to see Octavia had it in the first place 20:12:16 #action take decision for https://review.openstack.org/#/c/448667 in the next 2 weeks 20:12:22 sdague: +1 for keeping that in mind here 20:12:28 because, we've totally had organizations actually close up shop 20:12:34 ++ EmilienM 20:12:38 that's not a theoretical 20:12:44 sdague: yes, agreed 20:12:47 although small teams are had to keep the diverse tag, they are also more likely to be affected by one company walking away 20:12:53 We were the #1 neutron sub-project based on the April 2016 survey.... 20:12:53 johnthetubaguy: ++ 20:13:05 johnsom: which is fine, that's a different axis 20:13:31 Agreed 20:13:35 johnsom: again, you shouldn't take this one as a bad news tbh 20:13:38 we could have some grace period 20:13:52 johnsom: I haven't seen any sigh of octavia being in bad shape 20:13:55 sign* 20:14:00 or sigh 20:14:04 It is perceived as a path to getting booted from an official project..... 20:14:11 johnsom: why? 20:14:18 ah - well, we should work on changing that perception 20:14:20 johnsom: not at all 20:14:23 yeh, definitely not that 20:14:26 johnsom: fwiw most teams aren't diverse 20:14:27 that is definitely not the _intent_ 20:14:53 mordred: ++ 20:14:58 I think it is confused with single vendor and it is part of the discussion to become a project 20:15:05 and, for the love of all that is good and holy, I think the _last_ thing any of us want to do is boot LBaaS out 20:15:12 we need to send a message that this tag doesn't make you a first class citizen 20:15:15 Hahaha 20:15:16 it's just a number 20:15:36 should we move on? 20:15:44 yes 20:15:47 if anything it should be a message to member companies that maybe they need to allocate a human to work on a thing if they care about it 20:15:47 #topic Various repository moves 20:15:48 please 20:15:54 * Move DIB from TripleO to Infra 20:15:54 o/ 20:15:57 #link https://review.openstack.org/445617 20:16:11 I didn't vote because I'm the author 20:16:15 but with my TC hat, +1 :) 20:16:27 (and TripleO PTL hat) 20:16:34 I am guessing this is just a topic mistype but the intent is for us to not remove the repository fwiw 20:16:36 was there some discussion on this in the infra meeting earlier? 20:16:37 yeah, we just re-discussed it in the infra meeting moments ago, so i'm good 20:16:38 these should be pretty rote right? just let ttx slam them all in 20:16:39 so far we have zero negative feedback until now 20:16:44 er 20:16:45 not move 20:16:58 :) 20:17:10 good if both ptls are ok 20:17:10 ttx: ship it please 20:17:15 shipping 20:17:21 * Remove Gnocchi from Telemetry 20:17:23 #link https://review.openstack.org/447438 20:17:35 gordc: any last word? :) 20:17:41 (jd is offline) 20:17:55 gordc : are you moving out of openstack ci infra as well? 20:18:02 dims: AFIK yes 20:18:13 but I might have missed something 20:18:24 according to the email, that was eventually happening 20:18:34 i read it as "might eventuaklly be in the cards" 20:18:35 thanks EmilienM thingee - just curious 20:18:57 it didn't sound like there were any immediate plans to relocate the repo 20:19:07 http://lists.openstack.org/pipermail/openstack-dev/2017-March/114300.html 20:19:30 "As a second step, the project will likely move out of the OpenStack infrastructure in the future." 20:19:43 yeah, so no set timeline for that 20:19:50 ttx: ship it please, no blocker afik 20:19:59 ++ 20:20:00 just for clarity, we are not requiring them to stop using infra I assume? 20:20:08 I guess the only auestion is, are we happy to see it go, or should we fork it in openstack. 20:20:10 nope 20:20:22 no they would essentially be "stackforge' at that point 20:20:24 I think I'm in the first camp 20:20:29 johnthetubaguy: that was for you - we are certainly not requiring hem to stop 20:20:35 y happy to let go 20:20:40 ttx: I am too - I do not see any need to 20:20:41 for what it's worth, we did discuss a few weeks ago in boston that we need to take action to get rid of the perception that openstack is one monolithic thing you have to run all of 20:20:50 why forking it? 20:20:52 mordred: clarkb: yeah, that was my hope, just wanted to make that clear 20:21:05 fungi: yeah, that's something I'd like to figure out how to fix 20:21:12 so the concern raised in that review will one day, i hope, no longer be 20:21:20 EmilienM: well, if there were some people in openstack wanting to continue it... we'd be in a bind 20:21:34 and would probably have to fork it 20:22:03 fungi: mtreinish: +1 talking more about constellations as sets of things that run together for particular use cases should help some, but thats a different discussion 20:22:04 ttx: AFICT, "people in openstack" who worked / work on Gnocchi are part of Gnocchi team and are happy with this move 20:22:07 (that's due to the "leave infra" part) 20:22:18 yah, just because a team wants to go away doesn't necessarily mean OpenStack as a whole feels the same way - imagine if the nova cores decided they wanted to take nova elsewhere 20:22:22 ttx: I never had the impression (unless I missed something) that someone wasn't happy and would eventually fork it 20:22:26 EmilienM: indeed, which is why I said, no problem in this case 20:22:52 I'm pretty sure we would _not_ just delete nova from infra and wash our hands of it - but in this case, I think there is no need for such a behavior 20:23:09 johnthetubaguy: this is somewhat independent of that I think. It's more a general perception that if it's a git repo in openstack/ you can't use it outside of openstack 20:23:12 but when am official deliverable leaves openstack infrastructure, I think it's good to check :) 20:23:14 their reasons for making the change all make sense 20:23:26 ttx: ++ 20:23:30 ship it! 20:23:48 I'm not sure constellations will help with that (but they might, I really don't know) 20:23:51 mtreinish: yah - we should also work on that perception 20:23:51 shipping 20:24:03 mtreinish: I mean, I do not think that I can't run statsd just because I don't work on etsy :) 20:24:05 EmilienM: sorry, you still need me? 20:24:09 shipped 20:24:10 gordc: too late :) 20:24:14 gordc: nope! you're all set 20:24:17 * Move castellan under Oslo governance 20:24:18 johnthetubaguy: more the thing we discussed where we should make it possible to run services independent of one another 20:24:19 #link https://review.openstack.org/449137 20:24:21 mtreinish: true, that is maybe wider 20:24:33 dims: i think eventually yes. this is mainly for formality right now. 20:24:40 ack gordc 20:24:42 fungi: so thats possible today, and people do it, I guess its just not talked about a whole bunch 20:24:59 johnthetubaguy: right 20:25:16 dims: looks like that one could use last-minute additions 20:25:30 fungi: I was really suggesting we make those constellations (of maybe one), but that might be overkil 20:25:45 gcb: any thoughts you want to share? 20:25:59 dims: to please gcb 20:26:06 it's worth mentioning this spec in progress: https://blueprints.launchpad.net/oslo.utils/+spec/adopt-castellan 20:26:38 ack ttx : will rev the patch and get ok from gcb 20:27:02 ok, and with the TC approval I'll merge the result 20:27:17 whenever it has gcb +! 20:27:20 +1 20:27:26 ttx: he already +1 fwiw 20:27:29 @action Dims to follow up with Oslo PTL on Castellan review 20:27:34 #action Dims to follow up with Oslo PTL on Castellan review 20:27:43 yeah, but I think it's better to fix the patch and approve it 20:28:01 agree ttx 20:28:19 moving on 20:28:22 #topic Move shade into its own top-level team 20:28:23 #link https://review.openstack.org/446426 20:28:36 mordred: o/ 20:28:41 also just talked through this one in the infra meeting 20:28:42 this one has had an update to the commit message since last you voted on it 20:28:48 based on feedback in the infra meeting 20:28:52 mordred: so we're moving a bug to another place? :P 20:29:05 we're playing musical bugs 20:29:08 mordred: where you are the PTL of this bug? 20:29:15 sounds like a safe plan ;-) 20:29:17 mmm. bug orchestras 20:29:26 EmilienM: aren't I the PTL of all bugs? :) 20:29:28 Hi, I'm PTL of a bug 20:30:02 mordred: you're probably about to be at any rate 20:30:11 fungi: indeed 20:30:24 fungi: is the namespace still ok? 20:30:33 I guess we don't want to mess with git migration? 20:30:36 * stevemar sneaks in 20:30:52 yah - I'm concerned that would wind up breaking humans for no great reason 20:30:53 EmilienM: repo renames are painful, but also doable separately later if we really decide it's causing a problem 20:30:57 yah 20:30:57 EmilienM : we can leave it to the infra team if/when they want to do the git migration 20:31:07 fair enough, just a random question 20:31:21 we have the quorum, ship it 20:31:21 EmilienM : needed to be asked :) 20:31:33 /me ships 20:31:33 and as i mentioned in one of the review comments, it's not the first repo in the openstack-infra namespace which isn't an infra team deliverable 20:31:54 fungi: good to know 20:31:56 #topic Add tag assert:never-breaks-compat 20:31:58 #link https://review.openstack.org/446561 20:32:00 mordred: you again?? :) 20:32:14 yah - this one I think people had more concerns with 20:32:30 I think you all know I have extreme views on compatibility 20:32:47 this is an attempt to create an opt-in assertion for anyone who starts sharing them with me :) 20:32:47 I found the name weird tbh 20:32:59 EmilienM: I'm also _very_ bad at naming things 20:33:18 stevemar had a great proposal I think 20:33:37 mordred: how does this relate to https://review.openstack.org/#/c/418010/ ? 20:33:47 basically - as I was looking at the standard-deprecation tag and applying it to shade, I was dismayed that it laid out concepts around removal that shade did not, in fact, share 20:33:58 I liked assert:fully-compatible 20:34:13 mtreinish: it's very very similar 20:34:25 do we have a team to start adopting this one? was it swift? 20:34:29 mordred: heh, that's what I was thinking as I started reading it 20:34:34 johnthetubaguy: probably shade :P 20:34:41 jroll: heh 20:35:09 timely given that novaclient has just stopped supporting some nova-net features which may still be in heavy use in the wild 20:35:13 johnthetubaguy: swift as so far not broken anything, although notmyname wasn't sure they wanted to assert it 20:35:23 mordred: ok, so before creating a wish list tag, is any team going to assert that? 20:35:23 fungi: those, in fact, broke shade for a second 20:35:35 sdague: I mean, shade is - but I konw that's only one team 20:35:38 I agreed with clayg's comments on the review (which in large part were due to the name) 20:35:46 mordred: do they know? the testing on this is really hard, I know you touch on that, did you want to include that 20:36:24 I think we shouldn't create the tag until we want to encourage more projects to adopt it 20:36:38 johnthetubaguy: well - there's intent and then there is perfection in reality 20:36:42 as of this point today, the swift team is not looking to assert this tag 20:37:05 i feel like it's sufficient to declare that a project will try not to break backward compatibility and will consider any such breakage (even if not actively tested) an important bug worth fixing 20:37:06 for now this is about intent - the team asserts its intent is to not release breaking changes to its api 20:37:12 base question is, is that a behavior we ideally want all projects to have 20:37:15 fungi: ++ 20:37:39 ttx: I'm not sure we need that, it is another indicator of intent/status 20:37:44 I also think like it's a different story between a library and service, and the challenges of the 2 mean it's a little weird to lump them in 20:38:02 sdague: thats a very good point 20:38:11 so - the reason I think they're the same, and that's it's valuable 20:38:20 I would also wonder if having a "super" we-don't-break-compatibility tag will water down the value of a project that has standard-deprecation. For instance, I could see an external force (like someone in management) wanting to push for the more impactful tag. 20:38:32 is that it's also entirely possible that teams value things like "cleaning things up" or "reducing maint burden" 20:38:48 which are other points of view that are held, from time to time, by various people 20:39:38 never breaks requires basically infinite man power, at least feels that way as a service 20:40:02 notmyname : were there any things in that review that did not sit well with the swift team? 20:40:07 johnthetubaguy: but if the service team doesn't do it- the end user has to 20:40:37 mordred: I keep thinking about cloud pipe VPN as the example 20:40:49 the burden exists somewhere, because we aren't a single implementation of any of our services, but are instead a collection of differently versioned points in time of each service out in the world 20:40:59 definitely runs counter to the interest in the joint board/tc/uc meeting for dropping rarely-used options, features and backends to simplify service complexity 20:40:59 mordred: I definitely agree with you on the slider 20:41:07 I'm ok with the idea. I like that there is something that encourages and asserts this value of a project. 20:41:14 johnthetubaguy: yah - I mean, I don't thikn teams should start off with this 20:41:20 where there are things where either the service handles it or externalizes to all the users 20:41:22 dims: in general, the absolute-ness of it. true, we do our best not to break clients. but sometimes it's a very fuzzy line to determine what "break" means 20:41:28 but *never* is a really strong word 20:41:35 sdague: +1 on the slider, I am just not right up against the far end 20:41:35 to quote the gerrit review from clayg: 'there should be a thing here for security too - like "when faced with a mistake and given the choice that either the behavior of the api changes to include a new restriction or it's impossible to use safely prefer to fix it"' 20:41:37 fungi: good point 20:41:50 ack notmyname 20:41:55 notmyname: ++ 20:42:04 notmyname: agreed 20:42:05 notmyname: yah - I mean, I thought I had that in there already 20:42:16 I think that's just one example where we do "break" compat, but it depends on what breaking means 20:42:16 but I'll definitely take another stab at making that much clearer - beause I totally agree with that 20:42:19 yup 20:42:33 may be this language goes somewhere else as projects should aspire to be doing this 20:42:40 another is when implementation is different than RFC. who's wrong? the client? the service? it's different at different times 20:42:44 my main issue is that it doesn't seem like it can actually be meaningful. does applying it now mean the project has never broken backward compatibility in the past? or just promises not to do so from now on? and only until they choose to remove the tag? can it be re-added again after that? "247 days since last api backward-compatibility breakage" 20:42:52 and we've made different calls at different times (and sometimes reverted) 20:43:07 fungi: right, past returns not indicative of future performance? 20:43:08 fungi: zomg. we need that badge 20:43:31 mordred: so that API almost never worked on any cloud, probably has worked for years, no one dare test it, we can keep that behaviour today, but removing it might actually cause less user confusion... but I am agree its all about the users. 20:43:32 fungi : if we don't make any changes in the repo :) 20:44:06 johnthetubaguy: yah. fair point 20:44:21 mordred: badge/sticker idea for shade 20:44:26 mordred: honestly, on the mission of helping more developers understand the cost of externalizing their API changes without compatibility, it feels like a description of the costs of that is maybe better than a tag 20:44:32 mordred: I mean I am totally on your side in terms of getting the slider in the right place though 20:44:40 ++ johnthetubaguy 20:44:43 ++ 20:44:44 sdague: thats a top idea 20:44:48 to both of you 20:44:49 I feel like a lot of the heatedness during the API WG sessions at the PTG were because people really hadn't thought through 20:45:08 sdague: where should that go, do you think? 20:45:10 like "oh, then you have to make this change to ruby sdk, this go thing, this nodejs thing, etc" 20:45:33 mordred: that's a good question... api-wg repo maybe? 20:45:43 sdague: yah - that's probablya good place 20:45:57 * johnthetubaguy remembers the Nova v3.0 API debates... its really not obvious as it seems after you have the "ah ha moment" 20:46:01 also, time check. 15 minutes remaining with another topic before open discussion 20:46:19 fungi: indeed 20:46:23 mordred: can we move on? 20:46:30 mordred: and re-iterate next week probably 20:46:45 EmilienM: yup 20:46:47 #topic Resolution on OpenStack's mission for cloud applications 20:46:50 #link https://review.openstack.org/447031 20:46:58 mordred: sdague: that new API guidelines thing probably has 80/90% of that context thinking about it 20:47:11 johnthetubaguy: maybe, I think there is more context here 20:47:13 kudos to zaneb 20:47:25 zaneb++ 20:47:29 zaneb: any comment on this one? 20:47:32 dims: thanks for prompting me to do this :) 20:47:33 sdague: +1 for there being some missing, totally needs checking 20:48:08 EmilienM: not much to add really. if anyone has questions I can try to answer 'em 20:48:47 I think we miss one vote to ship it 20:48:58 when we get this in, we should promote this mission statement heavily 20:49:00 zaneb: I guess my only question is how does paragraph 4 turn into concrete things 20:49:01 I'm also interested in how we can get the whole community on board with this, not only the TC 20:49:24 zaneb: there are other people? 20:50:05 sdague: it's a balancing act between getting too concrete and failing to say anything at all 20:50:13 (I want to keep 7 min for open discussion fyi) 20:50:52 zaneb: srrsly though - even just tweeting out the link to the published doc when it lands would be a good first step in folks seeing it / reading it / ingesting it 20:50:55 so I have been thinking about including this kind of discussion as part of the VM & BM working group thing, for the next PTG 20:50:56 sdague: feedback on the first draft was that it was too vague 20:51:08 johnthetubaguy: ++ 20:51:20 zaneb : the board and tc talked about adjacent communities which we turned around and running with it in the "go/containers" thread and actively finding people and proposals to expand on that. we need to do something similar 20:51:31 zaneb: yeh, I guess it feels like a bunch of keystone related effort, and it would be nice to have keystone community members bought in before the TC declares this a thing 20:51:54 I don't see any keystone folks in the the +1 list, right? 20:52:02 lbragstad: ^^^ 20:52:21 johnthetubaguy: that would be great. it might be worth discussing if there are any sessions we could organise at the Forum to get started too 20:52:25 sdague: thats a very good point, more keystone +1 around that would be good 20:52:45 mtreinish o/ 20:52:56 sdague: I agree, although it's not _just_ keystone that needs to be on board 20:53:07 zaneb: sure 20:53:09 lbragstad: we're running out of time but it would be great if your team could have a look at https://review.openstack.org/#/c/447031 20:53:12 I just wouldn't want to land it without any keystone feedback 20:53:21 zaneb: possibly, I was getting the vibes we wouldn't have enough of those project developers present to have a good discussion 20:53:23 sdague: +1 20:53:30 EmilienM: can I propose we table until next week and make sure keystone folks throw in 20:53:35 sdague: yes please 20:53:47 mordred: https://twitter.com/zerobanana/status/842763247543640064 20:53:50 EmilienM sdague awesome - i'll review today 20:53:58 zaneb : let's throw this into general mailing list too and ask folks to vote 20:54:10 #action Get Keystone team to review https://review.openstack.org/#/c/447031 20:54:15 dims: ack, will send a mail today 20:54:22 zaneb: awesome 20:54:26 #topic Open discussion 20:54:28 thanks zaneb 20:54:39 * Forum topics: http://forumtopics.openstack.org/ 20:54:57 * dims has to run. will catch up on the meeting log 20:54:58 I sent an email to tc ML about the sessions I created on behalf of the authord in the etherpad we have 20:55:00 Posted details about the TC+Board+UC meeting (and dinner) in Boston around summit 20:55:05 #link https://etherpad.openstack.org/p/BOS-TC-brainstorming 20:55:26 if anyone who wrote a topic on https://etherpad.openstack.org/p/BOS-TC-brainstorming wants to change the content on http://forumtopics.openstack.org/ - please let me know 20:55:42 I was thinking about a "should Stackalytics die" session. Does that sound like a good idea ? 20:55:56 floor is open to questions and feedback or any other topic! 20:56:06 ttx: yes. also, it's a good forum topic ;-) 20:56:07 ttx: does anyone think we shouldn't kill it? 20:56:17 EmilienM: I did mean to reply to you, honest, just not had chance 20:56:18 ttx: maybe not die, but evolve 20:56:25 mtreinish: you'll have to attend the session to find out! 20:56:26 johnthetubaguy: you don't have to worry 20:57:11 EmilienM: all metrics used to compare performance will result in gaming amd incentivize bad behavior 20:57:24 stackalytics is super nice for some quick information discovery, e.g. finding out if cores are pulling their weight and such. I do wonder if the downstream abuse outweighs those benefits 20:57:27 so that evolution would need to be very close to death 20:57:28 mtreinish: it fills the gap of having some sort of central statistics so that every member company doesn't feel obliged to publish their own conflicting community involvement metrics, at least 20:57:29 I used it all the time as PTL 20:57:55 jroll: same thing. Very useful to find out who in the team makes good progress on reviews, etc 20:57:57 I still use russellb's stats 20:58:01 even if it doesn't update 20:58:05 thingee ++ same here 20:58:11