20:01:42 #startmeeting tc 20:01:43 Meeting started Tue Jun 20 20:01:42 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:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:46 The meeting name has been set to 'tc' 20:01:53 Let's start the recording 20:02:05 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda 20:02:12 * dtroyer is alive 20:02:20 mordred indicated moments ago that his current flight is landing, but that he might be able to find wifi in the airport to talk about his goals partway into the meeting if all goes well 20:02:25 That makes 6 of us 20:02:44 #topic Review proposed Pike goals and come up with a proposed selection 20:03:00 Basically Gerrit is a horrible way to select n out of m 20:03:20 We already have one goal selected/approved (split-tempest-plugins) 20:03:29 clearly we should be doing condorcet 20:03:46 fungi: it's not a lot better, apples to oranges 20:04:41 I'm not sure how to address this, maybe we should give a personal view and see if there is convergence 20:04:45 I can start 20:04:46 yeh, it's more about conversation 20:05:21 The "continuing Py35 support" sounds a bit like we failed to reach the objectives and push it back to the next cycle 20:05:22 as i don't have a dog in most of those fights, i'm relying on this conversation to try and help me make up my mind ;) 20:05:47 ttx: I thought we did well for unit tests. we're now continuing on with functional 20:05:57 was functional part of the previous goal release? 20:06:00 thingee: except the goal was to get functional test 20:06:04 not unit test 20:06:05 ah k 20:06:12 we're probably failing to capture there the bite-size chunks of progress slotted into each release cycle? 20:06:24 so rather than admit defeat today I would rather reflect at the end of Pike 20:06:35 fungi: yeh, python 3.5 ends up being big 20:06:36 well, it sounds like maybe some teams went off in a slightly wrong direction 20:06:44 I think interop and python 3.5 are priorities 20:06:47 ttx: agreed. We'll do that in the feedback like EmilienM has done 20:06:48 so pike goal was really py3k integration testing, queens goal is py3k unit testing? 20:07:00 So I'd like us to do at least the collections link 20:07:05 feedback thread* 20:07:07 dhellmann: interesting... is there data there? 20:07:17 fungi : unit testing was a "you may also want to do" thing for pike, but not specified for a future cycle 20:07:20 dhellmann: I guess I didn't realize that was the the case 20:07:20 and if we do touch tempest-plugins anyway, why not do full-discovery 20:07:30 sdague : well, apparently some of them are working on unit tests instead of functional tests? 20:07:58 though tbh, I haven't had time to review the progress recently, so that could be wrong 20:08:05 I agree on interop, I am wondering if new attention of this sort might be helpful in raising awareness across the community on the paste and policy situations? 20:08:15 My personal pick would be to only do 2: split-tempest-plugin and full-discovery 20:08:29 there is no doubt the py25 work needs to continue though 20:08:44 do we have a sense yet of how many teams are likely to need to continue working on the py35 stuff? 20:08:54 ttx: the full-discovery actually feels vague to me 20:09:02 + look at the py35 gap at the end of Pike and see what we can do to help (R goal, or ad-hoc targets) 20:09:19 so, the thing I like about the policy in code proposal is that 2 teams have done it already, nova and keystone 20:09:24 sdague: It feels vague to me too... 20:09:25 openstack got a mention on the debian-python ml today in relation to filing bugs to track missing python3 support 20:09:29 * EmilienM late but here 20:09:31 so there is demonstration of what complete looks like 20:09:33 I would rather say that py35 is just carried over and folks should keep working on it, if it's not finished this cycle. why wait for r? 20:09:37 and what the transition plan looks like 20:09:50 dhellmann: ++ 20:09:51 sdague: it just indicates that the work would happen in the tempest plugin, and since we force teams to look into those already (with split-tempest-plugin goal)... 20:09:55 I feel like the collection links & discovery are actually vague 20:10:12 they don't demostrate having done it for any project yet 20:10:29 especially when there are concerns around microversioning the root document 20:10:38 which is non addressed 20:10:58 dhellmann: I meant "wait for R if we need to do another goal to complete it 20:11:05 I feel like goals are useful when it's already been done on N > 1 projects 20:11:23 sdague: +1 20:11:29 ttx: ok. we need to be careful about that messaging, so that teams don't stop during queens 20:11:38 sdague: let's see if mordred is still around to clarify it 20:11:44 sdague : yeah, we did say that relatively early on 20:11:55 we need examples, to prove out the idea 20:11:55 sdague: at least it helps to get directions and feedback (how it worked and how we can do better for other projects) 20:12:09 given that, do any of the other proposed goals have >1 example? 20:12:10 dhellmann: I would wait until end of Pike, then talk to teams who missed the mark and help them to get their stuff done ASAP 20:12:15 ttx: ++ 20:12:17 dhellmann: policy in code 20:12:19 if mordred does manage to pop in, it'll probably be in the second half of the hour i'm guessing 20:12:25 sdague : I know nova did that, who else did? 20:12:29 keystone 20:12:33 ok, cool 20:12:38 dhellmann: I just fear making it a Queens goal would be seen as a license to procrastinate 20:12:56 especially if voted on now 20:13:01 ttx: sure, makes sense 20:13:17 so, honestly, the python 3.5 work probably needs a different mechanism than decentralized team goals 20:13:18 similarly, saying 'we will revisit this for r' 20:13:27 Anyone wants to make a case for migrate-off-paste or moving policy in code ? 20:13:35 I felt like the policy goal was a bit heavy 20:13:36 it really needs project management, and harassing 20:13:50 might be reasonable to consider the pike py3k goal basically met (there are some notable services who couldn't get integration testing working yet, but on the whole most did) 20:13:51 sdague: we used to have a team 20:13:55 ttx: well, I'm arguing for policy in code, because 2 teams already did that 20:14:00 in single cycles 20:14:24 migrate-off-paste has the problem of not being proven yet 20:14:24 sdague: so you would suggest: policy-in-code and split-tempest-plugins ? 20:14:29 ttx: yes 20:14:35 yeah, migrate-off-paste seems a bit early 20:14:36 starting to wonder whether, for these goals which touch almost every project, whether we should consider "mostly done" to be good enough 20:14:50 fungi: it depends on if mostly done is good enough 20:15:04 do we want to address the questions about what goes in tempest directly vs. what goes into a plugin as part of that goal? 20:15:06 with python 3.5... I'm not convinced that mostly done is 20:15:08 ttx: +1 on the 2 proposals 20:15:21 EmilienM: which ? 20:15:31 ttx: policy-in-code and split-tempest-plugins goals 20:15:32 mostly done might be good enough to carry the goal into the next cycle to complete it, but not to give the impression to stop working on it 20:16:14 if "most" projects met the goal, then the goal has fallen in scope to no longer being broadly cross-project after that 20:16:21 EmilienM: I fear that's a step up compared to Pike in terms of work needed, but otherwise agree they make good goals 20:16:34 we still have some teams that haven't even responded to the py3 goal :-( 20:17:02 ttx: some projects already have met one of them (or both) - so we could at least start iterations for the projects who don't 20:17:18 do we know which projects have the heavy work yet to do for policy? or is it "all services not named keystone or nova"? 20:17:19 so taking the py3k example, the remaining projects who are now the only ones not tested running under python3.5 have an additional incentive to finish that work (they don't want to be seen as the only ones left behind) 20:17:35 I wonder if for these goals wet should identify a "team" that is willing to do the work for these projects that can't themselves. 20:17:54 smcginnis, dhellmann: yes, was wondering if we should not take another approach 20:18:04 like form a pop-up release goal team 20:18:12 +1 20:18:14 we tried it that way and teams pushed back on taking the patches. 20:18:17 that would actively push to get it done 20:18:21 smcginnis: so, honestly, is it that we need a team, or we need more active project management? 20:18:32 I think both. 20:18:38 dhellmann: they would still be "goals" and supposed to be prioritized in reviews 20:18:52 because honestly, bugging folks publicly on the request id thing (which is *much smaller* I realize) was really what got things moving 20:18:54 yeah both 20:19:06 sdague: yeah, that's what I'm coming to 20:19:27 we need to work with ptls so they know what the community expects 20:19:32 maybe 20:19:36 sdague, ++ and good job 20:19:38 * dhellmann doesn't have the time or energy to do that this cycle 20:19:44 which is I think one of the good aspects of having goals: exposing what we want to do as a community 20:19:50 Just throwing goals at projects is not getting the optimal results 20:20:06 ttx: right, the goals definitely need active project management I think to be successful. 20:20:09 I still think we should bless release goals, so that teams know what's coming their way 20:20:20 maybe we could do the other way around and let PTLs vote on the goals? 20:20:27 sdague: I fear they also need people to help write patches 20:20:38 ttx: maybe, and that might be fine 20:20:53 the ptls who don't bother to vote on goals will likely also be the ones who ignore or resist attempts to implement them as well 20:21:03 but i guess it's worth a try 20:21:04 frankly I'm surprised that even for simple goals ans answers we seem to be struggling 20:21:14 I don't thikn we can reach 100% of projects, I agree 20:21:19 ttx: it's about things falling through cracks 20:21:24 but we we work with those who contributed already 20:21:33 s/we we/if we/ 20:21:52 there is so much inbound being asked of teams, if someone's not helping paint picture of the next thing that is needed, no one knows to prioritize that review 20:22:08 maybe we can engage them more in this process (also they know better if the team has bandwith to work on it or not) 20:22:11 isn't that what we expect PTLs to do? 20:22:23 we expect ptls to do a lot 20:22:30 including delegate 20:22:36 dhellmann++ 20:22:54 yeh, well, not everyone is perfect 20:23:06 sdague: It's also easier to say "driving a goal is a meaningful contribution", than to say "every project must find a volunteer to cover that area this cycle" 20:23:12 we could think of having a Goal Liaison per project 20:23:23 ttx: that could be 20:23:29 and having a sub-team at TC making the connections and helping the liaisons 20:23:29 EmilienM: I fear that won't scale to smalkler teams 20:23:31 if people are being asked to do too much, I agree something needs to give. I just don't think it's the stuff that we claim is important to the whole community. 20:23:57 goal liaisons will also likely emerge organically if they're needed. the ptl is the goal liaison by default, and if they need to do so they should delegate that responsibility 20:24:11 maybe _tracking_ who they are per team is helpful, i don't know 20:24:33 Driving a goal across ~40 projects is a very significant task though, so not sure inverting the model will be a lot more successful 20:25:05 so, I think if someone is tracking and reporting on the weekly (bi-weekly) progress of a goal it becomes more clear where things are getting lost. Without that highlighting it's tough. And it's also tough for new folks to know where they could help. 20:25:38 because without that the only people that know what needs to be done are the people that are probably the busiest ones on the teams 20:25:50 Seriously, we can't get anyone to update the goal status once, I'm not sure asking for biweekly reports would work a lot better 20:26:05 ttx: it is different 20:26:17 ttx: thought sdague was proposing that 1 volunteer would track that info 20:26:17 can't remember now, but did we get ack's from the ptls that we're being defaulted to owning the goal? 20:26:23 dhellmann: ++ 20:26:23 ah, ok 20:26:31 that's why it's different 20:26:37 so one champion 20:26:58 (or a set, I don't think it needs to be exclusive 20:26:59 thingee: do you mean before we approve them, or after? 20:27:00 ) 20:27:02 unfortunately, with the python 3 work, the main person who was driving the work before has gotten fed up with it and the TC sponsor (me) is embroiled in the dissolution of the docs team 20:27:06 fungi: after 20:27:07 which also gives the global view of what the most important next thing is 20:27:11 so, ENOTIME 20:27:22 dhellmann: which is arguably sort of a goal 20:27:23 thingee: yes, every project has to update the goal with their scope details 20:27:33 dhellmann: (the docs dissolution) 20:27:34 after it merges 20:27:42 ttx: yeah, I didn't file the paperwork because it seemed like more of an emergency than goal 20:28:12 right, and I think also points out that there can be really important things to be done that aren't goals 20:28:21 So, should we go back to the drawing table and ask on each of those proposal if there is one or more champions to actively project-manage it ? 20:28:37 I'm pretty sure that would clear a few 20:28:56 I agree with sdague that we need someone coordinating with the projects on the goals. 20:29:10 beyond just having a tc sponsor i guess 20:29:25 fwiw the release team has been trying to ask for replies by the deadline, but that's about as far as we went 20:29:27 ttx: yeh, that would be good next step 20:30:01 sdague: should we ask one for the already-approved goal as well, and demote it if there isn't anyone ? 20:30:18 ttx: yeh, that seems fair if we're asking for it 20:30:18 that seems fair 20:30:20 given the conversation around that goal, yes 20:30:36 if there isn't anyone, there's no sense in beating around the bush on keeping the goal. just log where we left off 20:30:42 thingee: ++ 20:31:06 sdague: would you say the main issue with getting that kind of stuff done is... writing the patch, or getting eyes/priorities on the resulting reviews ? 20:31:11 yes, the approved goal needs a project management volunteer, i think 20:31:32 (though i suspect that won't be too hard to confirm in that one case) 20:31:53 what would be the expectation from the volunteer? 20:31:55 ttx: my experience is that most efforts touching > 1 project are lacking more on the project management side (meaning highlighting reviews and finding reviewers) than on the development side 20:32:04 #info Ask for one (or more!) champions for each goal, who would project-manage it to completion (and help/mentor people to do it) 20:32:17 and that you can speed up an effort by 2 - 3x by active project management 20:32:28 sdague: certainly. 20:32:35 I would be happy to help here if we set expectations 20:32:46 EmilienM: probably periodic communication to the community at large about the overall status (and checking in with some teams if needed to determine that status in some cases) 20:33:04 I feel like the champion approach is an incremental improvement, easy to set in place for Q 20:33:45 it's worth trying and we can see how it works - I volunteer to champion 1 or 2 goals for Queens 20:33:52 sdague: would we stop asking each project to submit their status snippet, and use some wiki page / etherpad / ethercalc updated by the champion ? 20:33:59 might make sense not to get too into the weeds on exact expectations for a goals champion until we see what works there 20:34:03 maybe we can take the opportunity to document what we're doing 20:34:16 fungi: fair enough 20:34:21 ttx: yeh I think so 20:34:34 so we no longer want any acknowledgement from teams that they even see the goals? 20:34:35 (I like that it feels a bit less like throwing work at teams, since someone has to care enough to drive it) 20:34:36 it would also make the consolidated information be of the same quality between projects 20:34:41 it's going to be left up to 1 person to drive all of that? 20:34:54 i would worry that if we insist on bi-weekly status update e-mails to the dev ml, for example, that could be putting the cart before the horse 20:34:56 dhellmann: I think we still want PTLs to discuss the goals 20:35:03 I think we still want the ptl ACK, they need to be aware of what is going on around their projects 20:35:24 the goal champion would check with PTL goals status, collect and share blockers with the community 20:35:26 but the "goals response" process was less than a success this time around 20:35:53 maybe 2 goals are too much also 20:36:05 dhellmann: I felt like the reason people wouldn't submit them was more due to process friction than laziness or ignorance 20:36:08 I'm disappointed that the only way we can get people to collaborate on these things is to hound them. 20:36:11 if majority of projects did py3 unit tests versus functional tests, was there somehow miscommunication? 20:36:11 for the projects who haven't met the 2 goals, and haven't enough people, 2 is really too much imho 20:36:35 ttx: I only heard 1 person say there was any friction in the process. Did you hear that from others? 20:36:37 dhellmann: tbh, it's a bit the same in some projects (when being PTL) 20:36:45 dhellmann: (personal experience :-)) 20:37:16 dhellmann: I know of several who are TC members and didn't submit their goal response, we could ask them 20:37:25 * dhellmann looks at smcginnis 20:37:43 My understanding is that iut's somethign you always set to prio 2 20:37:52 I'll submit that tomorrow 20:38:14 heck, even the release management response was not immediate :) 20:38:30 yeah, that guy was new ;-) 20:38:36 lol 20:38:59 i took embarrassingly too long to update infra's no-op entries on this cycles goals, but i did also reply to the ml thread explaining (certainly not making excuses for) my error :/ 20:39:02 dhellmann: but it's a fair point. I'd like people to know what they have to do without having to hound them 20:39:17 ttx: anyway. If we're looking for someone to project-manage one or 2 goals, I do volunteer to help 20:39:24 but I'm not sure a governance patch is the most frfictionless way to communicate that 20:39:50 EmilienM: you mean, whatever the goal ? 20:39:57 yea 20:40:04 The champion of champions :) 20:40:11 ok. let's find a better tool for having that conversation then, but I still think it's important for it to be a conversation 20:40:39 honestly i need to be hounded 20:41:01 with all of the stuff that's coming out of the TC lately, i lose track and start to go deaf to it 20:41:23 and get the impression things are happening in a vacuum, which i know they aren't - they are being communicated in the ML, i'm just not reading everything in the ML anymore b/c i can't 20:42:02 anyway, feel free to hound me at least 20:42:12 right, stop thinking about it as hounding, but as "there are a lot of demands on folks, I am here to make it easy on you and say this is the specific things I need from you this milestone" 20:42:32 right, e.g. i needed sdague asking me to review global request id patches 20:42:35 to keep those moving 20:42:44 OK, time check... Let me summarize a few findings so far 20:42:48 and knowing that the person with that ask has filtered out the noise so that it is really important 20:42:58 #info Goals need champions to project-manage them to completion 20:43:13 so maybe one of the things we should be asking sponsor companies for are actual PMs as contributors and not forcing dev-types to do all of those things? 20:43:15 * mordred waves 20:43:20 #info We'll ask for champions on proposed (and the already accepted) goal 20:43:41 dtroyer: interesting approach 20:43:43 #info Migrate off paste might be a bit early, a success story in one project is probably needed first 20:44:10 placement isn't using paste.ini i don't think... 20:44:11 #info Python 3.5 should go to completion in Pike rather than being "extended" now to Queens 20:44:13 i'd be hesitant to ask for traditional "project managers" as we're likely to end up with people who don't know much about the community or how we operate flung into this, and nobody listening to them because nobody knows them 20:44:29 dtroyer : I am no longer of the mind that we want to rely on companies to provide any resources other than devs. We build up processes around them, and then they disappear. 20:44:44 #info Full-discovery sounds vague to a few 20:45:02 #info Policy into code & Split tempest plugins seem to general have support 20:45:18 #info Only 2 goals for Queens is probably a reasonable target 20:45:22 Is that a good summary so far ? 20:45:23 ttx: I'll provide a follow up email to the list 20:45:39 this has been really helpful for me, thanks! 20:45:42 do we have examples of PMs involved (really) in OpenStack community 20:45:43 ? 20:45:45 it's the particular set of skills that I think we are looking for, the alternative is for the foundation to hire them? 20:45:52 ttx: yes, lgtm 20:45:56 EmilienM: I would consider myself a PM 20:46:22 solution: clone ttx 20:46:34 lol 20:46:36 EmilienM: that's part of the problem. the "traditional" project managers have mostly ended up in board working groups and then get frustrated at their inability to make traction herding development cats 20:46:50 I feel like the work that sdague and dhellmann have done on some inter-project work is very close to PMing a goal 20:46:58 (also others) 20:47:02 EmilienM, dtroyer : I have my PMP cert from way back when 20:47:27 thingee: you lucky :D 20:47:30 yeah, "project managers" who have emerged from within our contributor community have been far more effective than those injected from outside 20:47:33 mordred: so you want to address the "vagueness" in the discovery stuff ? 20:47:41 a large portion of it seems to be the combination of detailing steps, following up on them, being able to explain "why" on each step and driving for buy in as you do it 20:47:45 Also, would you be its champion (and actually have time for it in Q ?) 20:47:48 EmilienM: dark times :) 20:47:51 learned a lot 20:47:53 s/so/do 20:48:04 I'm not knocking anyones work here, trying to highlight that dev skills and PM skills are different and only a few of us have good polished sets of both 20:48:23 80% of PMing in OpenStack is beating the drum 20:48:30 dtroyer : that's fair. I just don't think "find more new people" is very realistic right now. 20:48:32 right, to be clear I'm talking about "project management" as a valuable task, which is different than project managers a roles 20:48:46 ttx: yes, I would be its champion. I mean, I'm going to be working on that topic regardless 20:49:06 yes 20:49:10 agreed, my answer was more to dtroyer's earlier suggestion of asking member companies to provide us with some project managers 20:49:10 maybe instead of saying project manager we keep going with champion or drum beater 20:49:24 thingee: ++ 20:49:27 dtroyer : I would rather find some existing contributors who want to expand and take on a new challenge, I guess. Someone who already has some cred. 20:49:32 thingee: dj! 20:49:37 mordred: The only difference is that by making it a goal, we make sure it's prioritized up for acceptance in every team 20:50:10 OpenStack champion no pmp or agile required 20:50:22 dhellmann: sure… the trick is (after watching how this works from the other side for two years now) is that isn't how resources are allocated in a lot of companies 20:50:33 ttx: yup. although it's honestly very little work per-project, so even if it's not a goal I doubt I'll be completely dead in the water or anything 20:50:44 sdague: did you want to ask mordred for clarification on discovery goal vagueness ? 20:50:52 dtroyer : and after watching all of the writers leave, I'm not sure relying on finding a bunch of new specialists is either :-/ 20:51:33 thingee: do you have everything you need for the next step ? 20:51:45 dtroyer : I mean, go for it, if you think there are people out there who'd be interested. I'm skeptical, but don't mind me. I'm also cranky today. 20:51:54 ttx: ah yeh 20:51:58 yes. I would like to understand more about the champion thing so it can be communicated on the list 20:52:03 ttx: ^ 20:52:16 or I can leave that out for now 20:52:23 mordred: I didn't see anything in there about the microversioning strategy for changing these root docs which impacts some projects 20:52:57 part of dtroyer, dhellmann the problem is as openstack gains adoption, contributing companies see less of a need to drive strategy, just keep cutsomers happy. much more tactical 20:53:10 thingee: I see the champion as the person who will push to get the goal completed, by providing help, keeping track of status, sometimes helping with the patches. 20:53:28 Currently we drop a goal and then pick it up at the end of the cycle and realize it's not done yet 20:53:35 sdague: fair question. the answer to that is that the contents of the links list is completely undefined other than "will have self link" - so the answer is "it's not" - and the consume side is "if there is a collections link, this is what it means" 20:53:49 the champion should have some trust with core project reviewers as have seen the implementation of the goal too 20:54:09 And the scoreboard on the goal doc is not really enough to figure out the state, tbh 20:54:33 rethink how we track goal progress 20:54:41 at a glance 20:54:48 mordred: I'm not sure I quite accept that in our current thinking on versioning. The contract has been any add or change requires versioning. I feel like there needs to be a story there before committing to it 20:54:58 ttx: thank you. I'm good 20:55:09 * thingee disappears into pdx 20:55:25 thingee: I'm happy to review email drafts if you want me to 20:56:39 sdague: ok. I'll write something on that topic. also, if it's not there, I've alreayd implemented "just pop crap off the url" for keystoneauth and have written it up for other api consumers too... 20:57:06 so if that's just the api people do, shrug. it'll be better than that behavior being hard-coded and not documented at least 20:57:38 alright, any other question / discussion on this topic ? 20:57:48 we have 3min left if needed 20:58:17 ttx: thanks 20:58:25 We did not exactly made progress in the direction I expected, but it's still progress 20:58:36 make* 20:58:45 ++ 20:58:52 I typo more at 11pm for some reason 20:59:09 i'm happy with it 20:59:18 #topic Open discussion 20:59:23 ttx: thanks, it was good discussion 20:59:38 don't forget, tc office hours at 01:00 utc! i hope i'm not the only one this week, last week was lonely 20:59:40 Alright, that probably concludes our second adhoc meeting 21:00:04 fungi: I'll miss that one 21:00:10 i expected that ;) 21:00:34 fungi: I'm planning to be here 21:00:34 I should tour the doc and sprinkle TC office hours info where needed 21:00:46 Currently not so many people know they can reach out then 21:00:54 We should mention it on the project-team-guide 21:01:02 yes 21:01:02 * ttx makes a note 21:01:06 OK, off time 21:01:08 #endmeeting