20:01:08 <ttx> #startmeeting tc
20:01:09 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:12 <openstack> The meeting name has been set to 'tc'
20:01:14 * edleafe sips tea
20:01:15 <ttx> Hi everyone!
20:01:17 <mriedem> o/
20:01:23 <smcginnis> Welcome back.
20:01:24 <ttx> Thanks to dhellmann for chairing the meeting last week, and welcome to our new members
20:01:30 <ttx> Our agenda for today is at:
20:01:35 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:42 <flaper87> o/
20:01:46 <ttx> Remember that you can all use #info #idea and #link to help build a more readable summary
20:01:56 <ttx> #topic Elect chair
20:02:04 <ttx> Looks like we only have one candidate, and he has the necessary votes
20:02:04 <flaper87> ship it!
20:02:08 <ttx> #link https://review.openstack.org/458774
20:02:12 <ttx> So I'll approve that person now
20:02:16 <flaper87> ttx: thanks for taking this role on (again)
20:02:22 <cdent> ttx++
20:02:25 <ttx> Thanks for your continued trust, lots of work ahead
20:02:34 <dims> ++ thanks ttx
20:02:36 <ttx> #topic Drop Technical Committee meetings
20:02:42 <ttx> After the short discussion at the last meeting, flaper87 posted:
20:02:43 <flaper87> ship it (jk)
20:02:47 <ttx> #link https://review.openstack.org/459848
20:02:50 <ttx> flaper87: care to introduce it ?
20:02:56 <flaper87> sure
20:03:02 <flaper87> so, as mentioned briefly last week
20:03:18 <flaper87> the goal is to drop the TC meeting entirely and encourage discussion, voting and decisions to happen asynchronously
20:03:41 <flaper87> The existing format adds difficulties for some members of the community
20:03:57 <flaper87> It's not horribly worng but I do believe we can do better
20:04:02 <ttx> 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 <ttx> So I personally think it's worth a try.
20:04:25 <flaper87> As explained in the review, there's space for synchronous discussions when really needed and undercertain circumstances
20:04:37 <flaper87> but they are not as needed nowadays as they were in the past
20:04:41 <EmilienM> I agree with ttx, I like the idea
20:04:43 <cdent> 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 <flaper87> WE've adopted tools that allow for more aync work
20:04:54 <dtroyer> I think we should consider making f2f meetings at summit/ptg a bit more formalized, ala the current thread
20:04:57 <ttx> I fear that without the weekly rhythm we might get less done, but I'm fine trying it and revisiting
20:04:58 <dims> ttx : has it worked in the SWG?
20:05:00 <sdague> so, I guess the question I have is just trying to figure out which issue we are trying to address?
20:05:02 <smcginnis> 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 <cdent> dtroyer++
20:05:02 <flaper87> Yes, office hours is a big part of this
20:05:04 <ttx> dims: not at all
20:05:13 <dhellmann> is there any reason we can't change the voting rules without dropping the meetings, so we have some feedback mechanism?
20:05:13 <ttx> dims: but we did not push a weekly summary
20:05:33 <flaper87> sdague: erm, I tried to be explicit about that on the review but I can elaborate more and update the review
20:05:36 <flaper87> There are several, really
20:05:40 <dhellmann> 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 <sdague> 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 <flaper87> There's an issue with the timinig
20:05:52 <flaper87> there's issue with participation for non-native english speakers
20:05:53 <david-lyle> sdague++
20:05:56 <dims> if we have adhoc meetings, is it not more difficult for folks to follow?
20:06:06 <ttx> sdague: there is the issue that it's excluding all people from APAC
20:06:07 <flaper87> sdague: that's not the only concern
20:06:13 <ttx> and that any other time will just be a pain
20:06:14 <smcginnis> dims: ++ one of my concerns
20:06:15 <flaper87> (as mentioned in the review)
20:06:22 <sdague> ttx: sure, that is a completely fair point
20:06:46 <sdague> but it's a different point than "the meetings are hard to follow" which has been a chunk of the feedback
20:06:48 <dhellmann> 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 <EmilienM> APAC and EMEA (how many people can stay on a computer at 10pm here?)
20:06:59 <dims> ++ dhellmann
20:07:02 <sdague> dhellmann: yeh, for sure
20:07:22 <dhellmann> 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 <fungi> 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 <ttx> dhellmann: I don't think the suggestion is to drop them without providing anything to replace them
20:07:31 <edleafe> Removing meetings will also make it more difficult for those not on the TC to participate
20:07:33 <sdague> I would personally rather see us phase in what we think are the right other proposals
20:07:35 <flaper87> Can we start with a transition plan and reduce the meetings to be every other week for now ?
20:07:39 <dims> EmilienM : then we should find a slot say 6-7 hours behind what we have now, no?
20:07:43 <flaper87> that should give us some time to "try" this
20:07:55 <sdague> and we'll know if they are working if the meeting ends after 15 minutes
20:08:07 <dhellmann> ttx: how do you see things working? because "someone is going to send an email" isn't really enough, imho
20:08:08 <ttx> 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 <EmilienM> dims: we would probably loose PST folks. I don't think there is a perfect meeting time
20:08:28 <fungi> i agree with sdague that we should step up the alternatives before winding down the current scheduled meetings
20:08:29 <Rockyg> dhellmann ++
20:08:37 <dims> ++ fungi
20:08:42 <flaper87> 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 <sdague> flaper87: ok, then lets stop doing that
20:08:59 <smcginnis> 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 <sdague> that's a pretty concrete thing we could stop
20:09:12 <flaper87> sdague: sure but that doesn't solve the problem with the time
20:09:16 <sdague> flaper87: it does not
20:09:21 <dhellmann> 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 <sdague> but, lets separate the concerns
20:09:27 <ttx> smcginnis: that just spreads the misery, not the success
20:09:33 <flaper87> so, I want to solve that too
20:09:47 <dhellmann> flaper87 : I do too. Let's work toward it in steps.
20:09:47 <smcginnis> ttx: Or makes the misery come in alternating waves.
20:09:50 <sdague> because I think there is a long term concern, the meeting does put geographies in a disadvantage
20:09:57 <sdague> that's a really thing, we should work towards fixing it
20:10:03 <sdague> but I think that's step 5
20:10:15 <fungi> 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 <ttx> 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 <cdent> Is johnthetubaguy here? Because he's a big driver on this topic because he ... doesn't want to be here, now.
20:10:32 <sdague> 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 <sdague> and how we stop that naturally happening
20:10:51 <smcginnis> ttx: Fair point. It definitely would not solve all the concerns here.
20:10:56 <dims> agree sdague
20:11:03 <dhellmann> 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 <cdent> 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 <sdague> cdent: perhaps it could be, and perhaps we should try that
20:11:38 <sdague> but we can try that without getting rid of this bit as well
20:11:39 <cdent> 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 <flaper87> 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 <dhellmann> cdent : I sympathize, too. your tz is definitely getting close to "cannot" as a reason
20:12:17 <dims> cdent : since we have new tc members, we should start by trying find a better time for everyone currently in TC
20:12:19 <ttx> I think meetings provide three things, as I commented on the review
20:12:28 <ttx> weekly reminder, heated discussions, and an opportunity for reaching out / chat
20:12:35 <ttx> The weekly report could replace the first part
20:12:40 <dims> if we do that consistently, that would help with timing i think
20:12:57 <ttx> but we could in a step 1 keep the weekly meeting (skipping it more often) to cover the tother two
20:13:32 <dhellmann> 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 <ttx> i.e. post a weekly progress email, and only have the weekly meeting if there are stuck things to unblock
20:13:38 <fungi> 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 <sdague> dhellmann: ++
20:13:45 <dhellmann> 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 <dhellmann> because maybe it means no one reviewed anything :-)
20:14:06 <sdague> heh
20:14:37 <dhellmann> we've talked about this topic in person, but really I expected more discussion before we went ahead with anything
20:14:38 <flaper87> I mentioned earlier that we could start by having the meeting every other week
20:14:46 <flaper87> that sounds also like a good experiment
20:14:47 <jeblair> fungi: (a phrase people can set as an irc highlight would be useful for ad-hoc openstack-dev conversations)
20:14:57 <dhellmann> flaper87 : I do not want to change the meetings at all, to start. We need the feedback loop.
20:15:11 <smcginnis> flaper87: Ah, so not alternating times, but just skip every other week?
20:15:11 <fungi> jeblair: indeed! like we do for i n f r a - r o o t
20:15:12 <lbragstad> jeblair that's a good idea
20:15:16 <dhellmann> this group can mostly manage to be here, and we need to communicate about this change
20:15:57 <sdague> dhellmann: right, I think the point is to evolve us away from this
20:16:01 <flaper87> sdague: yes
20:16:15 <ttx> 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 <sdague> and maybe part of it is really to challenge the agenda more often when ttx sends it out
20:16:31 <ttx> i.e. was the meeting necessary to make progress on this particular discussion ?
20:16:52 <flaper87> ttx: fwiw, I don't think it was. Some folks did read and posted comments on the review.
20:16:53 <dhellmann> ttx: one of the things we're going to have to change is our own habits on reviewing those proposals
20:17:10 <fungi> 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 <ttx> dhellmann: right, and that can be done before we drop the meeting, I agree
20:17:15 <dhellmann> but, for example, I did post these concerns and no one responded
20:17:38 <ttx> the meeting is just like a quick cycle of reviews
20:17:43 <dhellmann> so if this was my chance to be heard, I don't want to lose that
20:17:44 <flaper87> fungi: I've changed my votes on gerrit after reading other folk's comments and views
20:17:53 <cdent> honestly, gerrit is shitty conversational medium
20:17:54 <ttx> it just makes it a lot harder for anyone following the discussion
20:17:55 <fungi> happy to adjust reviewing habits to accommodate a more asynch pattern there
20:17:58 <sdague> cdent: ++
20:17:59 <dhellmann> cdent : ++
20:18:11 <sdague> gerrit is really good once you are close to concensus to work out the kinks
20:18:14 <dims> we'll all definitely switch the way we work when we drop meetings and/or ttx stops sending detailed agenda
20:18:15 <flaper87> cdent: it is but then there's also email
20:18:24 <sdague> it's definitely not a concensus builder
20:18:26 <flaper87> which would increase visibility also in the TC activities
20:18:27 <cdent> yes, I've been saying all along we need ot use email a lot more
20:18:39 <dhellmann> yeah, I think we should move this discussion to email, not gerrit
20:18:43 <cdent> +1
20:18:48 <ttx> 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 <sdague> ok, so, follow on, why wasn't this a TC mailing list thread :)
20:18:58 <dhellmann> 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 <fungi> taking things off the meeting agenda if they're already represented by a governance change could work as a step
20:19:18 <ttx> sdague: I don't know, I wasn't around last week :)
20:19:26 <flaper87> 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 <flaper87> before the TC election*
20:19:56 <jeblair> 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 <sdague> anyway, so, action... discuss on TC mailing list?
20:20:09 <dhellmann> jeblair : that's a good way to put it
20:20:09 <flaper87> sdague: no no, -dev mailing list, not TC
20:20:13 <dhellmann> neatly frames some of my concerns
20:20:14 <ttx> and next week in person, likely
20:20:14 <sdague> jeblair: that's definitely true
20:20:16 * flaper87 thinks
20:20:23 <sdague> flaper87: or that
20:20:24 <cdent> 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 <ttx> flaper87: it's somewhere between TC minutia (-tc list) and community change (-dev list)
20:20:47 <smcginnis> 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 <jeblair> cdent: yep.  and i say that not to say it's not possible.  it's worth trying to improve.  :)
20:20:57 <lbragstad> moving to email also helps slow the pace of the conversation for non-english speakers
20:21:05 <dims> lbragstad : ++
20:21:07 <fungi> 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 <dims> fungi : AI :)
20:21:29 <dhellmann> smcginnis : we've mostly not taken advantage of that in the past, in any formal sense
20:21:33 <flaper87> lbragstad: one of the reasons why I also think we should get rid of the meeting entirely
20:21:35 <fungi> maybe we set time limits for feedback on proposals?
20:21:48 <sdague> fungi: that just needs a shephard on the conversation
20:21:59 <dhellmann> 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 <sdague> 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 <fungi> okay, so we need designated shepherds for each thread, or maybe the chair is the poor sucker stuck shepherding them all?
20:22:30 <sdague> and you reroot the thread
20:22:30 <cdent> sdague++ yeah that's the formal technique for such things
20:23:00 <ttx> 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 <lbragstad> dhellmann that's also a good point - is there a lesser of two evils there?
20:23:10 <dhellmann> lbragstad : write concisely
20:23:18 <dims> ML thread on -tc list ttx ?
20:23:29 <cdent> default to -dev
20:23:30 * flaper87 prefers -dev
20:23:31 <cdent> ?
20:23:39 <dims> y just checking to make sure
20:23:44 <ttx> dims: see my above answer, could be any, in doubt I would pick -dev
20:24:02 <fungi> is te concern that not enough people subscribe to the -tc ml? or the moderator load?
20:24:13 <ttx> #info a bit early for a proposal. Next step: push a ML tread, and discuss it in person next week
20:24:14 <sdague> -dev is totally fine, as long as we get a commit from all the TC members to actually be reading it
20:24:19 <ttx> Who is up to push the thread ?
20:24:20 <sdague> I know that's been an issue in the past
20:24:25 <flaper87> ttx: I'll do it
20:24:29 <dhellmann> fungi : both?
20:24:34 <flaper87> fungi: fwiw, -dev is like using this channel
20:24:35 <dims> sdague : and reply at least once per thread :)
20:24:38 <ttx> #action flaper87 to start another -dev thread about this
20:24:43 <flaper87> anyone can join, anyone can comment
20:24:44 <flaper87> etc
20:24:48 <flaper87> no need for mod
20:24:58 <ttx> OK, let's move on
20:25:05 <sdague> ++ move on
20:25:11 <ttx> #topic Do not make decisions using synchronous communication
20:25:16 <ttx> #link https://review.openstack.org/460946
20:25:24 <fungi> this seems related
20:25:25 <ttx> johnthetubaguy is not around to talk about it
20:25:39 <ttx> He just W-1 it and will work on a "principle" version of it
20:25:41 <dhellmann> this feels like step 1
20:25:59 <ttx> dhellmann: what do you mean ?
20:26:08 <dhellmann> to the process of dropping meetings
20:26:12 <ttx> ah, ok
20:26:22 <ttx> I thought step1 would be to be present to support it
20:26:34 <dhellmann> well, yeah, I meant of the actual implementation
20:26:38 <sdague> so... how many times in the last cycle did we make decisions synchronously?
20:26:49 <sdague> like how many #vote instances did we really have?
20:27:02 <ttx> I would say a couple of times
20:27:18 <dhellmann> we use gerrit a lot in meeting, but I only remember one #vote case in the last year
20:27:19 <sdague> I'm all for this one, but it would be good to at least quantify what we are eliminating
20:27:22 <flaper87> but also we wait on meetings to rubber stamp reviews.
20:27:23 <dhellmann> and now I can't even remember what that was
20:27:38 <cdent> it's the "waiting for the meeting to rubber stamp" which I think is the real issue
20:27:38 <dims> guess this is not just for tc, but for everyone in the community.
20:27:42 <flaper87> That, sometimes, feels like we're not using the tool properly. I understand the motivation
20:27:51 <sdague> dhellmann: but, every gerrit review that gets decided on has been out there for > 1 week right?
20:28:01 <dhellmann> yeah, the idea was never that we'd wait for meetings to vote
20:28:15 <dhellmann> sdague : often without sufficient votes to proceed, but yeah
20:28:20 * ttx looks up 2017 meetings real quick
20:28:43 <rocky_g_> I like the way the api-wg does the reviews and voting
20:28:44 <sdague> so is this really that there should be a waiting period after sufficient votes are gathered?
20:28:50 <ttx> "Driver teams: establish new "driver team" concept, or not"
20:29:06 <ttx> "Glance: Changing response status code. What's the best path forward?"
20:29:07 <cdent> rocky_g_:  me to
20:29:08 <fungi> 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 <cdent> o
20:29:13 <dhellmann> yeah
20:29:26 <sdague> so, could we add that as a detail
20:29:32 <dhellmann> 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 <ttx> so twice in the last 4 months
20:30:05 <sdague> try to avoid #vote in meeting, and all gerrit reviews should wait 3 days between reaching sufficient votes and being approved?
20:30:09 <fungi> rocky_g_: cdent: can you elaborate?
20:30:30 <jeblair> 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 <cdent> review internal, freeze for public review (with email announcements), publish a week later
20:31:09 <rocky_g_> cdent much better than mine woulda been
20:31:09 <fungi> cdent: thanks, that sounds sensible to me at least
20:31:10 <ttx> jeblair: http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-02-14-20.01.log.html#l-93
20:31:13 <notmyname> ttx: is this "no voting" proposal for the TC decisions or one that is to apply to every openstack group?
20:31:14 <cdent> fungi: to me the good part is the visibility and regular announcements
20:31:35 <rocky_g_> ++
20:31:35 <flaper87> notmyname: TC
20:31:54 <ttx> notmyname: not sure... If it's set as a principle that would affect everyone I guess
20:32:01 <notmyname> flaper87: ah, ok. that wasn't clear from the gerrit proposal
20:32:11 <notmyname> oh. flaper87 and ttx don't agree on that :-)
20:32:25 <sdague> 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 <cdent> notmyname: this is not your first rodeo?
20:32:28 <flaper87> notmyname: yeah, I believe it came out from my proposal to drop the meeting
20:32:55 <dhellmann> flaper87 : then it needs to be documented in our voting rules, not as a principle
20:33:00 <fungi> 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 <flaper87> dhellmann: sure
20:33:19 <cdent> 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 <ttx> 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 <rocky_g_> fungi: ++
20:33:53 <flaper87> what about we just ask johnthetubaguy to send an email about this so we can discuss the idea there?
20:33:58 <ttx> Also, it'd difficult to reconcile with "the PTL ultimately decides if need be"
20:33:59 <flaper87> ttx: ^
20:34:14 <dims> ++ flaper87
20:34:16 <ttx> a single-person decision is obviously synchronous
20:34:31 <fungi> (and exclusive!)
20:34:34 <flaper87> it doesn't make sense for us to keep guessing on what the direction of the proposal actually is
20:34:52 <cdent> flaper87, ha, yes
20:35:03 <ttx> yeah, let's not waste to much effort guessing here
20:35:10 <fungi> though it _is_ an effective way to fill up an hour ;)
20:35:20 <ttx> But as much as I like the intent, it's difficult to make it a hard rule I think
20:35:25 <dims> let's paint it blue
20:35:40 <flaper87> (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 <smcginnis> dims: :)
20:35:58 <ttx> #info waiting for johnthetubaguy to precise if it's meant as a general rule or just for the TC
20:36:04 <ttx> Let's move on to the next topic
20:36:27 <ttx> #topic Change the target for this goal to uWSGI not Apache mod_wsgi
20:36:32 <ttx> #link https://review.openstack.org/460951
20:36:39 <ttx> sdague: care to introduce this one ?
20:37:02 <sdague> sure, basically when that goal was proposed I suggested we not do it on mod_wsgi, because of technical shortcomings
20:37:14 <sdague> it moved forward because no one else signed up to get us over to uwsgi first
20:37:32 <sdague> I moved all the infrastructure over to uwsgi last month, which is now the default gate mode
20:37:39 <sdague> we should really be doing that instead
20:37:50 <dims> yay, thanks sdague
20:37:56 <ttx> 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 <ttx> 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 <smcginnis> I don't think there has been too much progress there, so now would be the time to switch.
20:38:19 <cdent> I raised that objection, but I actually think in this case it is not a big deal at all
20:38:39 <dhellmann> 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 <dtroyer> ++
20:38:55 <ttx> 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 <sdague> dhellmann: sure, I can update it accordingly post meeting
20:39:05 <ttx> every*
20:39:17 <sdague> ttx: well, we should consider some of the downsides of approach
20:39:18 <dhellmann> ttx: we knew this one might change when we wrote it (hence the hedging about "that's what devstack uses now")
20:39:23 <sdague> I do remember bringing those up
20:39:23 <EmilienM> smcginnis: we have a bunch of projects working on it, I think some progress has been made, no?
20:39:30 <sdague> yeh, that's why that hedge is there
20:39:45 <sdague> it's actually a ton easier to do it with this new way
20:40:07 <smcginnis> 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 <mriedem> smcginnis: cdent basically has it done for nova
20:40:32 <mriedem> so there!
20:40:38 <sdague> ok, so general agreement on this, just put the historical bits in there?
20:40:44 <smcginnis> mriedem: Oh good, one I can copy for cinder.
20:40:49 <ttx> sdague: good for me
20:40:54 <sdague> mriedem: sure, but he's done it on the new way :)
20:40:57 <cdent> smcginnis: another example is placement
20:41:00 <ttx> #info general agreement on this, just put the historical bits in
20:41:03 <sdague> because he helped me figure out how to do it
20:41:26 <dims> 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 <EmilienM> 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 <ttx> sdague: when you mentioned "downsides", were you replying to my "Does it mean avery goal definition" question ?
20:42:06 <dhellmann> 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 <sdague> EmilienM: because we're still telling people to do it the other way
20:42:11 <ttx> <ttx> 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 <EmilienM> dhellmann: but sdague already changed infra & devstack things
20:42:31 <dhellmann> EmilienM : someone looking at the goal does not know that
20:42:43 <ttx> or should we just expect goals posts can move ?
20:42:48 <dhellmann> if that change to devstack had happened in queens, we wouldn't need to update the document
20:42:54 <dhellmann> but this is still an active set of instructions
20:43:01 <ttx> (as long as they move in the "facilitation" direction)
20:43:05 <sdague> ttx: I don't know, I think there was a vaguery here
20:43:18 <dhellmann> yeah, I think it's OK to move them if it makes things simpler
20:43:21 <ttx> sdague: ok
20:43:21 <dtroyer> also, I don't think the goal changed, but the implementation approach did
20:43:27 <dhellmann> dtroyer : true
20:43:27 <sdague> dtroyer: right
20:43:27 <dims> sdague : "Completion Criteria - Updated on May 2, 2017" or some such text
20:43:34 <sdague> dims: sure
20:43:46 <ttx> alright, I think we have a way forward, let's switch to next topic ?
20:43:53 <smcginnis> +1
20:43:54 <dtroyer> ++
20:43:56 <ttx> #topic TC to have approve authority on maintenance-mode projects
20:43:57 <sdague> and the goal kind of allowed for that because it had the hedge of "what devstack uses"
20:43:59 <fungi> 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 <ttx> #link https://review.openstack.org/460963
20:44:04 <ttx> sdague: yours again
20:44:10 <dims> ++ fungi
20:44:13 <sdague> yes, this is follow on from a couple of weeks ago
20:44:16 <fungi> (sorry, i'm a terribly slow reader and typist)
20:44:36 <sdague> 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 <sdague> because there are already challenges when we have must approve patches with active core teams
20:45:22 <ttx> 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 <fungi> 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 <sdague> 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 <sdague> fungi: sure
20:45:53 <fungi> s/reture/retire/
20:45:56 <sdague> but that should be the consideration
20:45:58 <ttx> sdague: I guess, if the *TC* moves it
20:46:07 <sdague> do we want it in maintenance mode, where TC acts as backstop
20:46:19 <sdague> or does the TC not want the responsiblity on that project, then move it out
20:46:34 <sdague> at least, that model made sense in my head
20:46:37 <ttx> sdague: but the current definition of maintenance-mode says that the team must have responsive liaisons and process critical patches
20:46:38 <sdague> so it's up for debate
20:46:59 <ttx> so it feels like we are adding a clause to cover something that does not match the definition
20:47:10 <fungi> 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 <sdague> 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 <ttx> in effect, if critical patches don't get merged, the project is failing maintenance-mode requirements
20:47:44 <EmilienM> 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 <sdague> that's totally possible
20:47:53 <smcginnis> 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 <dtroyer> sdague: it feels like your concern spans more than just maintenance mode
20:48:07 <smcginnis> So this seems to want to be proactive about that possibility.
20:48:08 <ttx> smcginnis: and move the project from maintenance-mode to abandoned
20:48:15 <fungi> smcginnis: agreed
20:48:24 <ttx> I fear that it would dilute the meaning of maintenance-mode, in a negative way
20:48:32 <smcginnis> 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 <sdague> dtroyer: it's possible, again, it's up for discussion
20:48:39 <ttx> smcginnis: yeah
20:48:50 <sdague> smcginnis: we can, but I kind of feel we should really be more explicit about this
20:48:57 <fungi> 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 <ttx> 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 <dtroyer> maybe what we need to be explicit about is jsut "unresponsive teams"?
20:49:54 <sdague> 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 <ttx> 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 <dtroyer> I'm suggesting that thsi isn't a maintenace-mode-only thing
20:50:31 <fungi> 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 <dtroyer> agreed on not limiting it to that tag
20:50:33 <sdague> because a maintenance-mode project is not going to rekindle if all their bandwidth is on non project things
20:51:06 <ttx> 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 <dtroyer> fungi: exactly, as has already been said, I think we have what we need to day to cover this
20:51:51 <cdent> the impression I get is that the maintenance-mode tag is woefully under-defined
20:51:55 <fungi> 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 <ttx> basically I see maintenance-mode in a positive way -- going through a hard period so refocusing on the basic essentials
20:52:29 <ttx> I feel like saying that we half-expect to have to step up shines a negtive light on it
20:52:42 <sdague> 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 <sdague> I don't think that brings the project back
20:53:23 <ttx> sdague: so you are saying is that TC members are encouraged to step in to help maintenance-mode projects ?
20:53:26 <sdague> I personally see this as "we want you to recover, so we the TC will help"
20:53:26 <ttx> err
20:53:31 <sdague> yes
20:53:44 <fungi> 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 <ttx> but we can already do that without signing up the whole TC members as core members
20:53:47 <cdent> 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 <sdague> and if the TC membership doesn't want to take that one
20:53:59 <sdague> then we shouldn't put it into this state
20:54:01 <EmilienM> fungi: good question. Skills and time.
20:54:28 <ttx> sdague: basically, if you as a person want to commit time to help a struggling project, that's awesome
20:54:47 <cdent> we seem to conflating "helping a project" with "dealing with critical things that come up"
20:54:49 <ttx> I don't think we need to give every TC members core rights to make that happen
20:54:54 <fungi> and it's that sort of involvement which causes you to be elected to the tc in the first place
20:55:07 <dims> who is this text signalling to? the people left in the project? or the operators/users?
20:55:09 <dhellmann> cdent : some of what we're trying to do is write down those undocumented assumptions
20:55:47 <sdague> yeh, well, discussion point :)
20:55:59 <dims> dhellmann : are we making sure folks who want to apply the tag, we tell them we will back you up?
20:56:01 <cdent> dhellmann: sure, I guess I had assumed incorrectly that the global power to step in in emergencies was already documented
20:56:25 <dhellmann> cdent : that's a good question, and I'm not sure I know the answer.
20:56:26 <EmilienM> 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 <sdague> 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 <fungi> cdent: i believe it is (we already document what happens if a ptl disappears or nobody is nominated)
20:56:52 <ttx> oh well, let's continue on the review
20:56:53 <cdent> ha, that's three different answers :)
20:56:55 <dtroyer> EmilienM: the tag was proposed so it could be applied to trove
20:56:58 <ttx> and move to open discussion
20:57:02 <sdague> like if I explain to fungi something really needs to happen, with a good explanation, he'll typically do it
20:57:07 <EmilienM> dtroyer: right so, let's talk about trove case?
20:57:09 <dims> cdent : welcome again :)
20:57:14 <cdent> dims++
20:57:20 <sdague> because he knows I'm not off on crazy land, and I only ask when it's really needed
20:57:22 <ttx> #topic Open discussion
20:57:32 <fungi> 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 <ttx> Boston next week, feels like we could organize a TC dinner for those still standing on Thursday evening
20:57:44 <fungi> and we can appoint one (which could be a tc member i suppose)
20:58:02 <ttx> 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 <sdague> fungi: right, like the "no cores on sqlachemy-migrate" thing
20:58:10 <dims> ttx : +1 from me
20:58:16 <smcginnis> ttx: +1 would love to spend time with everyone.
20:58:20 <sdague> yeh +1
20:58:26 <cdent> very +1 on that. some face time to spitball
20:58:27 <ttx> alright, let's do it
20:58:39 <dims> blocked my calendar
20:58:45 <EmilienM> as long as it's not too expensive, +1
20:58:45 <ttx> Anything else, anyone ?
20:58:48 <fungi> 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 <cdent> you people are no fun at all!
20:59:13 <ttx> We likely won't have a sponsor, so it will be split tab
20:59:16 <dhellmann> EmilienM : the new folks have to pay, do don't worry about it ;-)
20:59:23 <smcginnis> Hah!
20:59:26 <EmilienM> reminder: some of our folks have to pay for their own expenses
20:59:29 <dims> ++ dhellmann
20:59:36 <cdent> 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 <dhellmann> yeah, low key is fine
20:59:50 <ttx> yeah, we usually have good samaritans to pick up the bill for them in those cases
21:00:00 <dtroyer> cdent:  \o/
21:00:10 <ttx> ok, time is up
21:00:15 <fungi> thanks ttx!
21:00:16 <smcginnis> Thanks
21:00:17 <dhellmann> see you all next week
21:00:21 <ttx> Thanks everyone and see you next week
21:00:26 <ttx> #endmeeting