20:01:08 #startmeeting tc 20:01:09 Meeting started Tue May 2 20:01:08 2017 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:12 The meeting name has been set to 'tc' 20:01:14 * edleafe sips tea 20:01:15 Hi everyone! 20:01:17 o/ 20:01:23 Welcome back. 20:01:24 Thanks to dhellmann for chairing the meeting last week, and welcome to our new members 20:01:30 Our agenda for today is at: 20:01:35 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:42 o/ 20:01:46 Remember that you can all use #info #idea and #link to help build a more readable summary 20:01:56 #topic Elect chair 20:02:04 Looks like we only have one candidate, and he has the necessary votes 20:02:04 ship it! 20:02:08 #link https://review.openstack.org/458774 20:02:12 So I'll approve that person now 20:02:16 ttx: thanks for taking this role on (again) 20:02:22 ttx++ 20:02:25 Thanks for your continued trust, lots of work ahead 20:02:34 ++ thanks ttx 20:02:36 #topic Drop Technical Committee meetings 20:02:42 After the short discussion at the last meeting, flaper87 posted: 20:02:43 ship it (jk) 20:02:47 #link https://review.openstack.org/459848 20:02:50 flaper87: care to introduce it ? 20:02:56 sure 20:03:02 so, as mentioned briefly last week 20:03:18 the goal is to drop the TC meeting entirely and encourage discussion, voting and decisions to happen asynchronously 20:03:41 The existing format adds difficulties for some members of the community 20:03:57 It's not horribly worng but I do believe we can do better 20:04:02 As an example, it feels like most of the discussions from today were not stuck, and could have iterated through reviews alright 20:04:14 So I personally think it's worth a try. 20:04:25 As explained in the review, there's space for synchronous discussions when really needed and undercertain circumstances 20:04:37 but they are not as needed nowadays as they were in the past 20:04:41 I agree with ttx, I like the idea 20:04:43 I think it is worth a try but we really need to make sure we implement office hours and the other "make sure people know how to find us" strategies 20:04:50 WE've adopted tools that allow for more aync work 20:04:54 I think we should consider making f2f meetings at summit/ptg a bit more formalized, ala the current thread 20:04:57 I fear that without the weekly rhythm we might get less done, but I'm fine trying it and revisiting 20:04:58 ttx : has it worked in the SWG? 20:05:00 so, I guess the question I have is just trying to figure out which issue we are trying to address? 20:05:02 I actually hate to see it go, but as ttx broke it out into the goals and how they will still be addressed, I'm willing to give it a shot. 20:05:02 dtroyer++ 20:05:02 Yes, office hours is a big part of this 20:05:04 dims: not at all 20:05:13 is there any reason we can't change the voting rules without dropping the meetings, so we have some feedback mechanism? 20:05:13 dims: but we did not push a weekly summary 20:05:33 sdague: erm, I tried to be explicit about that on the review but I can elaborate more and update the review 20:05:36 There are several, really 20:05:40 because I think just throwing the meeting out without ensuring that we're still productive isn't going to do us any good 20:05:42 because, if the concern is the meeting is hard to follow so people can't participate, removing the meeting doesn't really make that better 20:05:42 There's an issue with the timinig 20:05:52 there's issue with participation for non-native english speakers 20:05:53 sdague++ 20:05:56 if we have adhoc meetings, is it not more difficult for folks to follow? 20:06:06 sdague: there is the issue that it's excluding all people from APAC 20:06:07 sdague: that's not the only concern 20:06:13 and that any other time will just be a pain 20:06:14 dims: ++ one of my concerns 20:06:15 (as mentioned in the review) 20:06:22 ttx: sure, that is a completely fair point 20:06:46 but it's a different point than "the meetings are hard to follow" which has been a chunk of the feedback 20:06:48 I don't object to dropping the meetings eventually. I object to throwing them out without sufficient planning to ensure that this group still functions well. 20:06:55 APAC and EMEA (how many people can stay on a computer at 10pm here?) 20:06:59 ++ dhellmann 20:07:02 dhellmann: yeh, for sure 20:07:22 so let's work on our discussion and voting rules, and prove that we can actually do the work in the way this proposal wants 20:07:24 noting ways in which this proposal differs somewhat from the way the swg went "meetingless" i'm still suspicious we'll find we communicate less once we do 20:07:26 dhellmann: I don't think the suggestion is to drop them without providing anything to replace them 20:07:31 Removing meetings will also make it more difficult for those not on the TC to participate 20:07:33 I would personally rather see us phase in what we think are the right other proposals 20:07:35 Can we start with a transition plan and reduce the meetings to be every other week for now ? 20:07:39 EmilienM : then we should find a slot say 6-7 hours behind what we have now, no? 20:07:43 that should give us some time to "try" this 20:07:55 and we'll know if they are working if the meeting ends after 15 minutes 20:08:07 ttx: how do you see things working? because "someone is going to send an email" isn't really enough, imho 20:08:08 dhellmann: an intermediary proposals would be to introduce the whole weekly reminder / expectation of iteration through reviews, and keep the meeting as optional for any needed discussion when needed 20:08:17 dims: we would probably loose PST folks. I don't think there is a perfect meeting time 20:08:28 i agree with sdague that we should step up the alternatives before winding down the current scheduled meetings 20:08:29 dhellmann ++ 20:08:37 ++ fungi 20:08:42 sdague: TBH, sometimes the meetings have content because ttx takes the time to also go and dig stuff that would fill the hour. (ttx keep me honest) 20:08:53 flaper87: ok, then lets stop doing that 20:08:59 Seems like a simpler thing would be to start with alternating meeting times so all regions at least get a decent time every other week. 20:09:02 that's a pretty concrete thing we could stop 20:09:12 sdague: sure but that doesn't solve the problem with the time 20:09:16 flaper87: it does not 20:09:21 yeah, I think there are smaller steps we could take that would be easier to reverse and less catastrophic if they don't work 20:09:22 but, lets separate the concerns 20:09:27 smcginnis: that just spreads the misery, not the success 20:09:33 so, I want to solve that too 20:09:47 flaper87 : I do too. Let's work toward it in steps. 20:09:47 ttx: Or makes the misery come in alternating waves. 20:09:50 because I think there is a long term concern, the meeting does put geographies in a disadvantage 20:09:57 that's a really thing, we should work towards fixing it 20:10:03 but I think that's step 5 20:10:15 i've also not seen good examples of alternating meeting times working out effectively (they seem to either end up with one meeting slot nobody attends or they bifurcate into two groups of people who don't cross-pollinate discussions and end up duplicating work) 20:10:16 smcginnis: the current time is the only one that makes it /possible/ for all current members to atgtend it. Any alternate time would not only exclude a part of the world from attending, but also some TC members 20:10:17 Is johnthetubaguy here? Because he's a big driver on this topic because he ... doesn't want to be here, now. 20:10:32 and a big thing is to figure out why every meeting runs until the top of the hour, and tends to want to spill over 20:10:47 and how we stop that naturally happening 20:10:51 ttx: Fair point. It definitely would not solve all the concerns here. 20:10:56 agree sdague 20:11:03 cdent : I'm not sure I buy "I don't want to go to meetings" as a reason to make this change. "I cannot" definitely is. 20:11:03 good point sdague. I reckon that's because we don't talk enough, but perhaps that talking doesn't need to be in meetings, but can be in email? 20:11:29 cdent: perhaps it could be, and perhaps we should try that 20:11:38 but we can try that without getting rid of this bit as well 20:11:39 dhellmann: I'm not saying I support that one way or another, just reminding of one of the reasons why it happening. Since I'm in the same timezone as John, I can certainly sympathize 20:12:05 I'd personally be opposed to alternating times. I've tried those in different teams and they didn't work well. I think it's even more confusing 20:12:14 cdent : I sympathize, too. your tz is definitely getting close to "cannot" as a reason 20:12:17 cdent : since we have new tc members, we should start by trying find a better time for everyone currently in TC 20:12:19 I think meetings provide three things, as I commented on the review 20:12:28 weekly reminder, heated discussions, and an opportunity for reaching out / chat 20:12:35 The weekly report could replace the first part 20:12:40 if we do that consistently, that would help with timing i think 20:12:57 but we could in a step 1 keep the weekly meeting (skipping it more often) to cover the tother two 20:13:32 if we're going to take the step, I'd like for one agenda item to be "how well are we doing at eliminating the need for this meeting" 20:13:36 i.e. post a weekly progress email, and only have the weekly meeting if there are stuck things to unblock 20:13:38 as for the "office hours" idea, i'd happily set a reminder for myself covering an americas slot, an emea slot and an apac slot and then make a point of keeping an eye on #openstack-dev (or wherever we decide) for the duration as long as i'm around (and make a point to avoid scheduling myself for conflicting obligations when possible) 20:13:40 dhellmann: ++ 20:13:45 and when that's the only thing on the agenda, I'm not sure that's a reason to skip that week 20:14:01 because maybe it means no one reviewed anything :-) 20:14:06 heh 20:14:37 we've talked about this topic in person, but really I expected more discussion before we went ahead with anything 20:14:38 I mentioned earlier that we could start by having the meeting every other week 20:14:46 that sounds also like a good experiment 20:14:47 fungi: (a phrase people can set as an irc highlight would be useful for ad-hoc openstack-dev conversations) 20:14:57 flaper87 : I do not want to change the meetings at all, to start. We need the feedback loop. 20:15:11 flaper87: Ah, so not alternating times, but just skip every other week? 20:15:11 jeblair: indeed! like we do for i n f r a - r o o t 20:15:12 jeblair that's a good idea 20:15:16 this group can mostly manage to be here, and we need to communicate about this change 20:15:57 dhellmann: right, I think the point is to evolve us away from this 20:16:01 sdague: yes 20:16:15 do you see any reason why we could not have reached the same conclusion using the review as a medium ? Or some people just do not like to post -1s ahead of the meeting ? 20:16:20 and maybe part of it is really to challenge the agenda more often when ttx sends it out 20:16:31 i.e. was the meeting necessary to make progress on this particular discussion ? 20:16:52 ttx: fwiw, I don't think it was. Some folks did read and posted comments on the review. 20:16:53 ttx: one of the things we're going to have to change is our own habits on reviewing those proposals 20:17:10 i tend to defer my governance votes until the meeting because points are often made during the meeting which influence my eventual choice 20:17:15 dhellmann: right, and that can be done before we drop the meeting, I agree 20:17:15 but, for example, I did post these concerns and no one responded 20:17:38 the meeting is just like a quick cycle of reviews 20:17:43 so if this was my chance to be heard, I don't want to lose that 20:17:44 fungi: I've changed my votes on gerrit after reading other folk's comments and views 20:17:53 honestly, gerrit is shitty conversational medium 20:17:54 it just makes it a lot harder for anyone following the discussion 20:17:55 happy to adjust reviewing habits to accommodate a more asynch pattern there 20:17:58 cdent: ++ 20:17:59 cdent : ++ 20:18:11 gerrit is really good once you are close to concensus to work out the kinks 20:18:14 we'll all definitely switch the way we work when we drop meetings and/or ttx stops sending detailed agenda 20:18:15 cdent: it is but then there's also email 20:18:24 it's definitely not a concensus builder 20:18:26 which would increase visibility also in the TC activities 20:18:27 yes, I've been saying all along we need ot use email a lot more 20:18:39 yeah, I think we should move this discussion to email, not gerrit 20:18:43 +1 20:18:48 dims: I would still post the status of progress on proposals and priority reviews, which would end up looking a lot like the meeting agenda 20:18:48 ok, so, follow on, why wasn't this a TC mailing list thread :) 20:18:58 but that's an example of the sort of thing that it may have taken us ages to work out if we were trying to do it on a gerrit review 20:19:01 taking things off the meeting agenda if they're already represented by a governance change could work as a step 20:19:18 sdague: I don't know, I wasn't around last week :) 20:19:26 sdague: there was one, before the voting, then last week it was proposed but there was not enough time to discuss it. Also, anyone can start the thread if discussion over email is required ;) 20:19:45 before the TC election* 20:19:56 i think we're better at achieving consensus synchronously; with the async mechanisms (email/gerrit) we're often better at exposing many diverse viewpoints, but we're not always great at converging to consensus there. 20:19:58 anyway, so, action... discuss on TC mailing list? 20:20:09 jeblair : that's a good way to put it 20:20:09 sdague: no no, -dev mailing list, not TC 20:20:13 neatly frames some of my concerns 20:20:14 and next week in person, likely 20:20:14 jeblair: that's definitely true 20:20:16 * flaper87 thinks 20:20:23 flaper87: or that 20:20:24 jeblair: that's true, but I think it is unfair to people who can't attend the meeting. We need to work harder in email. 20:20:47 flaper87: it's somewhere between TC minutia (-tc list) and community change (-dev list) 20:20:47 I guess one thing that also helps is the TC can all meet face to face at least every three months for larger discussion needs. 20:20:56 cdent: yep. and i say that not to say it's not possible. it's worth trying to improve. :) 20:20:57 moving to email also helps slow the pace of the conversation for non-english speakers 20:21:05 lbragstad : ++ 20:21:07 perhaps if we had some agreement on how to tell when an e-mail thread has reached consensus or needs to wait for more input ;) 20:21:22 fungi : AI :) 20:21:29 smcginnis : we've mostly not taken advantage of that in the past, in any formal sense 20:21:33 lbragstad: one of the reasons why I also think we should get rid of the meeting entirely 20:21:35 maybe we set time limits for feedback on proposals? 20:21:48 fungi: that just needs a shephard on the conversation 20:21:59 lbragstad : although I've had non-native readers also complain to me about having to read a lot of prose (like our vision statement) 20:22:17 we've had threads that worked well before when someone responds every 3 - 5 days with "this seems to be where we are" 20:22:30 okay, so we need designated shepherds for each thread, or maybe the chair is the poor sucker stuck shepherding them all? 20:22:30 and you reroot the thread 20:22:30 sdague++ yeah that's the formal technique for such things 20:23:00 ok so action is.. a bit early for a proposal, next step is to push a ML thread about it; and discuss it in person next week 20:23:00 dhellmann that's also a good point - is there a lesser of two evils there? 20:23:10 lbragstad : write concisely 20:23:18 ML thread on -tc list ttx ? 20:23:29 default to -dev 20:23:30 * flaper87 prefers -dev 20:23:31 ? 20:23:39 y just checking to make sure 20:23:44 dims: see my above answer, could be any, in doubt I would pick -dev 20:24:02 is te concern that not enough people subscribe to the -tc ml? or the moderator load? 20:24:13 #info a bit early for a proposal. Next step: push a ML tread, and discuss it in person next week 20:24:14 -dev is totally fine, as long as we get a commit from all the TC members to actually be reading it 20:24:19 Who is up to push the thread ? 20:24:20 I know that's been an issue in the past 20:24:25 ttx: I'll do it 20:24:29 fungi : both? 20:24:34 fungi: fwiw, -dev is like using this channel 20:24:35 sdague : and reply at least once per thread :) 20:24:38 #action flaper87 to start another -dev thread about this 20:24:43 anyone can join, anyone can comment 20:24:44 etc 20:24:48 no need for mod 20:24:58 OK, let's move on 20:25:05 ++ move on 20:25:11 #topic Do not make decisions using synchronous communication 20:25:16 #link https://review.openstack.org/460946 20:25:24 this seems related 20:25:25 johnthetubaguy is not around to talk about it 20:25:39 He just W-1 it and will work on a "principle" version of it 20:25:41 this feels like step 1 20:25:59 dhellmann: what do you mean ? 20:26:08 to the process of dropping meetings 20:26:12 ah, ok 20:26:22 I thought step1 would be to be present to support it 20:26:34 well, yeah, I meant of the actual implementation 20:26:38 so... how many times in the last cycle did we make decisions synchronously? 20:26:49 like how many #vote instances did we really have? 20:27:02 I would say a couple of times 20:27:18 we use gerrit a lot in meeting, but I only remember one #vote case in the last year 20:27:19 I'm all for this one, but it would be good to at least quantify what we are eliminating 20:27:22 but also we wait on meetings to rubber stamp reviews. 20:27:23 and now I can't even remember what that was 20:27:38 it's the "waiting for the meeting to rubber stamp" which I think is the real issue 20:27:38 guess this is not just for tc, but for everyone in the community. 20:27:42 That, sometimes, feels like we're not using the tool properly. I understand the motivation 20:27:51 dhellmann: but, every gerrit review that gets decided on has been out there for > 1 week right? 20:28:01 yeah, the idea was never that we'd wait for meetings to vote 20:28:15 sdague : often without sufficient votes to proceed, but yeah 20:28:20 * ttx looks up 2017 meetings real quick 20:28:43 I like the way the api-wg does the reviews and voting 20:28:44 so is this really that there should be a waiting period after sufficient votes are gathered? 20:28:50 "Driver teams: establish new "driver team" concept, or not" 20:29:06 "Glance: Changing response status code. What's the best path forward?" 20:29:07 rocky_g_: me to 20:29:08 seems like, similar to the last topic, letting more involved proposals get approved when they reach quorum+consensus could address a good chunk of the need for asynchronicity? 20:29:12 o 20:29:13 yeah 20:29:26 so, could we add that as a detail 20:29:32 sdague : well, I read it as "do not make decisions on irc or in person" and I'm not sure I agree with all of that sentiment, but I do understand it 20:29:38 so twice in the last 4 months 20:30:05 try to avoid #vote in meeting, and all gerrit reviews should wait 3 days between reaching sufficient votes and being approved? 20:30:09 rocky_g_: cdent: can you elaborate? 20:30:30 ttx: the first instance at least was not exclusive with gerrit voting -- just used to help gauge consensus iirc. i don't recall the second. 20:30:42 review internal, freeze for public review (with email announcements), publish a week later 20:31:09 cdent much better than mine woulda been 20:31:09 cdent: thanks, that sounds sensible to me at least 20:31:10 jeblair: http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-02-14-20.01.log.html#l-93 20:31:13 ttx: is this "no voting" proposal for the TC decisions or one that is to apply to every openstack group? 20:31:14 fungi: to me the good part is the visibility and regular announcements 20:31:35 ++ 20:31:35 notmyname: TC 20:31:54 notmyname: not sure... If it's set as a principle that would affect everyone I guess 20:32:01 flaper87: ah, ok. that wasn't clear from the gerrit proposal 20:32:11 oh. flaper87 and ttx don't agree on that :-) 20:32:25 I also want to be careful with "don't make decisions in synchronous fashion" because the real concern is the exclusion not the decision process right? Especially when we know decisions impact folks not in the room. 20:32:26 notmyname: this is not your first rodeo? 20:32:28 notmyname: yeah, I believe it came out from my proposal to drop the meeting 20:32:55 flaper87 : then it needs to be documented in our voting rules, not as a principle 20:33:00 obviously if it applies to all of the technical community, then it also applies to the tc (and we should be the first to take it on and prove that it's working for us before we expect anyone else to do the same) 20:33:16 dhellmann: sure 20:33:19 I think the intent is principle, because it comes out of the SWG's thinking about increasing diverse participation for everyone, throughout the community, yeah? 20:33:20 flaper87: I think it came out as a consequence (like dhellmann said, feels like first step) but then it feels like johnthetubaguy wants it to be a general principle to guarantee inclusion 20:33:25 fungi: ++ 20:33:53 what about we just ask johnthetubaguy to send an email about this so we can discuss the idea there? 20:33:58 Also, it'd difficult to reconcile with "the PTL ultimately decides if need be" 20:33:59 ttx: ^ 20:34:14 ++ flaper87 20:34:16 a single-person decision is obviously synchronous 20:34:31 (and exclusive!) 20:34:34 it doesn't make sense for us to keep guessing on what the direction of the proposal actually is 20:34:52 flaper87, ha, yes 20:35:03 yeah, let's not waste to much effort guessing here 20:35:10 though it _is_ an effective way to fill up an hour ;) 20:35:20 But as much as I like the intent, it's difficult to make it a hard rule I think 20:35:25 let's paint it blue 20:35:40 (just as an example, some of these questions could be asked on the review and/or a proposal to start a new mailing list thread could be made there: This is not a complain but a highlight of how we can change the way we interact to allow for meetings to be dropped) 20:35:44 dims: :) 20:35:58 #info waiting for johnthetubaguy to precise if it's meant as a general rule or just for the TC 20:36:04 Let's move on to the next topic 20:36:27 #topic Change the target for this goal to uWSGI not Apache mod_wsgi 20:36:32 #link https://review.openstack.org/460951 20:36:39 sdague: care to introduce this one ? 20:37:02 sure, basically when that goal was proposed I suggested we not do it on mod_wsgi, because of technical shortcomings 20:37:14 it moved forward because no one else signed up to get us over to uwsgi first 20:37:32 I moved all the infrastructure over to uwsgi last month, which is now the default gate mode 20:37:39 we should really be doing that instead 20:37:50 yay, thanks sdague 20:37:56 So the main issue here is that we would change the definition of a goal in the middle of the implementation of it, setting a bad precedent 20:38:08 But then it feels like it's more of a clarification of how the goal shall be reached, than a "change", so this is probably OK. 20:38:18 I don't think there has been too much progress there, so now would be the time to switch. 20:38:19 I raised that objection, but I actually think in this case it is not a big deal at all 20:38:39 yeah, I don't have a problem with changing the goal, I just want the text to reflect the change (not just the git history) 20:38:47 ++ 20:38:55 Does it mean avery goal definition should include clear(er) instructions on how to reach it, to avoid such a situation in the future ? 20:38:56 dhellmann: sure, I can update it accordingly post meeting 20:39:05 every* 20:39:17 ttx: well, we should consider some of the downsides of approach 20:39:18 ttx: we knew this one might change when we wrote it (hence the hedging about "that's what devstack uses now") 20:39:23 I do remember bringing those up 20:39:23 smcginnis: we have a bunch of projects working on it, I think some progress has been made, no? 20:39:30 yeh, that's why that hedge is there 20:39:45 it's actually a ton easier to do it with this new way 20:40:07 EmilienM: Some, but I didn't get the impression it was being done with much urgency and there hasn't been many done making the switch. 20:40:30 smcginnis: cdent basically has it done for nova 20:40:32 so there! 20:40:38 ok, so general agreement on this, just put the historical bits in there? 20:40:44 mriedem: Oh good, one I can copy for cinder. 20:40:49 sdague: good for me 20:40:54 mriedem: sure, but he's done it on the new way :) 20:40:57 smcginnis: another example is placement 20:41:00 #info general agreement on this, just put the historical bits in 20:41:03 because he helped me figure out how to do it 20:41:26 sdague : would it make sense to somehow signal that the text had an update? when the goal is viewed in the web site 20:41:30 so i'm confused, we're updating a goal with a technical change that was already done in Infra? why do we need to discuss then? 20:41:52 sdague: when you mentioned "downsides", were you replying to my "Does it mean avery goal definition" question ? 20:42:06 EmilienM : because the goal is the instructions we've given to teams about what they're supposed to do, and we want it to reflect current reality 20:42:11 EmilienM: because we're still telling people to do it the other way 20:42:11 Does it mean avery goal definition should include clear(er) instructions on how to reach it, to avoid such a situation in the future ? 20:42:22 dhellmann: but sdague already changed infra & devstack things 20:42:31 EmilienM : someone looking at the goal does not know that 20:42:43 or should we just expect goals posts can move ? 20:42:48 if that change to devstack had happened in queens, we wouldn't need to update the document 20:42:54 but this is still an active set of instructions 20:43:01 (as long as they move in the "facilitation" direction) 20:43:05 ttx: I don't know, I think there was a vaguery here 20:43:18 yeah, I think it's OK to move them if it makes things simpler 20:43:21 sdague: ok 20:43:21 also, I don't think the goal changed, but the implementation approach did 20:43:27 dtroyer : true 20:43:27 dtroyer: right 20:43:27 sdague : "Completion Criteria - Updated on May 2, 2017" or some such text 20:43:34 dims: sure 20:43:46 alright, I think we have a way forward, let's switch to next topic ? 20:43:53 +1 20:43:54 ++ 20:43:56 #topic TC to have approve authority on maintenance-mode projects 20:43:57 and the goal kind of allowed for that because it had the hedge of "what devstack uses" 20:43:59 the infra team has an established history of updating its approved specs to reflect changes in implementation decisions based on new information. this seems like a pretty similar situation 20:44:00 #link https://review.openstack.org/460963 20:44:04 sdague: yours again 20:44:10 ++ fungi 20:44:13 yes, this is follow on from a couple of weeks ago 20:44:16 (sorry, i'm a terribly slow reader and typist) 20:44:36 basically if we end up with a project in maintenance mode, I suggested the TC be added to the core team as backstop 20:45:08 because there are already challenges when we have must approve patches with active core teams 20:45:22 sdague: I suspect our disagreement in the review comes from a glass half-full /half-empty difference in what maintenance-mode really is 20:45:32 if a change is so urgent that the tc needs to step in and approve it because there's nobody on the actual project team available to do so, that seems to me like a project we should go ahead and reture 20:45:35 if the TC has decided to move a thing to maintenance mode, instead of moving it out entirely, the TC should take responsibility for it 20:45:50 fungi: sure 20:45:53 s/reture/retire/ 20:45:56 but that should be the consideration 20:45:58 sdague: I guess, if the *TC* moves it 20:46:07 do we want it in maintenance mode, where TC acts as backstop 20:46:19 or does the TC not want the responsiblity on that project, then move it out 20:46:34 at least, that model made sense in my head 20:46:37 sdague: but the current definition of maintenance-mode says that the team must have responsive liaisons and process critical patches 20:46:38 so it's up for debate 20:46:59 so it feels like we are adding a clause to cover something that does not match the definition 20:47:10 if the tc needs change approval on a project's deliverables, that could i guess be used to approve the change required to mark it retired (delete all files, replace readme with information on its archival state) 20:47:12 ttx: sure... I guess given that some active projects aren't always responsive there, I'm not sure I fully trust that maintenance mode projects will 20:47:27 in effect, if critical patches don't get merged, the project is failing maintenance-mode requirements 20:47:44 does it mean TC should also take care of releasing the project sometimes? (yeah because what's the point of merging patches if we don't release the project) 20:47:51 that's totally possible 20:47:53 The alternative is if we end up in a non-responsive situation, we ask infra to add us and take care of it. 20:48:00 sdague: it feels like your concern spans more than just maintenance mode 20:48:07 So this seems to want to be proactive about that possibility. 20:48:08 smcginnis: and move the project from maintenance-mode to abandoned 20:48:15 smcginnis: agreed 20:48:24 I fear that it would dilute the meaning of maintenance-mode, in a negative way 20:48:32 ttx: Which I think is what you're saying - if it comes down to it, we can do that as it is now. 20:48:36 dtroyer: it's possible, again, it's up for discussion 20:48:39 smcginnis: yeah 20:48:50 smcginnis: we can, but I kind of feel we should really be more explicit about this 20:48:57 and as smcginnis points out, the infra team's gerrit admins already have the ability to grant that access or take directed action from the tc as needed 20:49:17 If we say "we want critical patches to be processed but we'll cover them if you don't" that sends a rather mixed message 20:49:34 maybe what we need to be explicit about is jsut "unresponsive teams"? 20:49:54 ttx: it also shows that the TC is willing to put some effort into rekindling the project by handling some class of issues, while the project could rebuild core expertise 20:50:06 dtroyer: I think we already have a process for unresponsive teams where we can step up. I would prefer not to bake it in the maintenance-mode definition 20:50:24 I'm suggesting that thsi isn't a maintenace-mode-only thing 20:50:31 an alternative would be for the tc to reserve the right to appoint new core reviewers (or just ptl? though we already have that and could exercise it today) 20:50:32 agreed on not limiting it to that tag 20:50:33 because a maintenance-mode project is not going to rekindle if all their bandwidth is on non project things 20:51:06 sdague: maybe we need a under-tc-life-support status, in parallel to the maintenance-mode status, in case teams are unreponsive 20:51:11 fungi: exactly, as has already been said, I think we have what we need to day to cover this 20:51:51 the impression I get is that the maintenance-mode tag is woefully under-defined 20:51:55 the rules we have now don't state that we can't appoint ourselves as new owners of a project, it's probably just understood that that could be seen as bad form 20:52:10 basically I see maintenance-mode in a positive way -- going through a hard period so refocusing on the basic essentials 20:52:29 I feel like saying that we half-expect to have to step up shines a negtive light on it 20:52:42 ttx: sure, but the current cores on that project need to spend their time on pbr synchronization instead of mentoring new members 20:52:51 I don't think that brings the project back 20:53:23 sdague: so you are saying is that TC members are encouraged to step in to help maintenance-mode projects ? 20:53:26 I personally see this as "we want you to recover, so we the TC will help" 20:53:26 err 20:53:31 yes 20:53:44 while i appreciate the sentiment of wanting to pitch in and help out in that situation, i question whether every (or any) tc member elected has the necessary skills to do so (i certainly don't feel that i do anyway) 20:53:46 but we can already do that without signing up the whole TC members as core members 20:53:47 the truth is that whether a project is maintenance mode or not, if it need urgent attention and the project doesn't attend, we step in, right? So why do we need a resolution? 20:53:49 and if the TC membership doesn't want to take that one 20:53:59 then we shouldn't put it into this state 20:54:01 fungi: good question. Skills and time. 20:54:28 sdague: basically, if you as a person want to commit time to help a struggling project, that's awesome 20:54:47 we seem to conflating "helping a project" with "dealing with critical things that come up" 20:54:49 I don't think we need to give every TC members core rights to make that happen 20:54:54 and it's that sort of involvement which causes you to be elected to the tc in the first place 20:55:07 who is this text signalling to? the people left in the project? or the operators/users? 20:55:09 cdent : some of what we're trying to do is write down those undocumented assumptions 20:55:47 yeh, well, discussion point :) 20:55:59 dhellmann : are we making sure folks who want to apply the tag, we tell them we will back you up? 20:56:01 dhellmann: sure, I guess I had assumed incorrectly that the global power to step in in emergencies was already documented 20:56:25 cdent : that's a good question, and I'm not sure I know the answer. 20:56:26 do we have a use-case (or in other words, a project that might have the tag soon), so we can go in concrete examples? 20:56:35 cdent: definitely not documented, which also means that most of the time it's only done because of trust not because of need 20:56:39 cdent: i believe it is (we already document what happens if a ptl disappears or nobody is nominated) 20:56:52 oh well, let's continue on the review 20:56:53 ha, that's three different answers :) 20:56:55 EmilienM: the tag was proposed so it could be applied to trove 20:56:58 and move to open discussion 20:57:02 like if I explain to fungi something really needs to happen, with a good explanation, he'll typically do it 20:57:07 dtroyer: right so, let's talk about trove case? 20:57:09 cdent : welcome again :) 20:57:14 dims++ 20:57:20 because he knows I'm not off on crazy land, and I only ask when it's really needed 20:57:22 #topic Open discussion 20:57:32 if there's nobody around still to tend to urgent matters on a team, then there is also (effectively at least) no ptl 20:57:34 Boston next week, feels like we could organize a TC dinner for those still standing on Thursday evening 20:57:44 and we can appoint one (which could be a tc member i suppose) 20:58:02 As cdent suggested we gather to do some work too, I booked a slot in a late Thursday Forum session... so far only johnthetubaguy won't be able to make it 20:58:03 fungi: right, like the "no cores on sqlachemy-migrate" thing 20:58:10 ttx : +1 from me 20:58:16 ttx: +1 would love to spend time with everyone. 20:58:20 yeh +1 20:58:26 very +1 on that. some face time to spitball 20:58:27 alright, let's do it 20:58:39 blocked my calendar 20:58:45 as long as it's not too expensive, +1 20:58:45 Anything else, anyone ? 20:58:48 i'm fine with it so long as cdent promises not to spit on me at least ;) 20:58:50 * smcginnis notes to not sit across from cdent's spitballs 20:59:05 you people are no fun at all! 20:59:13 We likely won't have a sponsor, so it will be split tab 20:59:16 EmilienM : the new folks have to pay, do don't worry about it ;-) 20:59:23 Hah! 20:59:26 reminder: some of our folks have to pay for their own expenses 20:59:29 ++ dhellmann 20:59:36 I wanted to mention that the compatibility guidelline that is blocked on the interop guideline in the api-wg will unblock on thursday when interop merges 20:59:38 yeah, low key is fine 20:59:50 yeah, we usually have good samaritans to pick up the bill for them in those cases 21:00:00 cdent: \o/ 21:00:10 ok, time is up 21:00:15 thanks ttx! 21:00:16 Thanks 21:00:17 see you all next week 21:00:21 Thanks everyone and see you next week 21:00:26 #endmeeting