20:01:42 <ttx> #startmeeting tc
20:01:43 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:46 <openstack> The meeting name has been set to 'tc'
20:01:53 <ttx> Let's start the recording
20:02:05 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda
20:02:12 * dtroyer is alive
20:02:20 <fungi> 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 <ttx> That makes 6 of us
20:02:44 <ttx> #topic Review proposed Pike goals and come up with a proposed selection
20:03:00 <ttx> Basically Gerrit is a horrible way to select n out of m
20:03:20 <ttx> We already have one goal selected/approved (split-tempest-plugins)
20:03:29 <fungi> clearly we should be doing condorcet
20:03:46 <ttx> fungi: it's not a lot better, apples to oranges
20:04:41 <ttx> I'm not sure how to address this, maybe we should give a personal view and see if there is convergence
20:04:45 <ttx> I can start
20:04:46 <sdague> yeh, it's more about conversation
20:05:21 <ttx> 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 <fungi> 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 <thingee> ttx: I thought we did well for unit tests. we're now continuing on with functional
20:05:57 <thingee> was functional part of the previous goal release?
20:06:00 <ttx> thingee: except the goal was to get functional test
20:06:04 <ttx> not unit test
20:06:05 <thingee> ah k
20:06:12 <fungi> we're probably failing to capture there the bite-size chunks of progress slotted into each release cycle?
20:06:24 <ttx> so rather than admit defeat today I would rather reflect at the end of Pike
20:06:35 <sdague> fungi: yeh, python 3.5 ends up being big
20:06:36 <dhellmann> well, it sounds like maybe some teams went off in a slightly wrong direction
20:06:44 <ttx> I think interop and python 3.5 are priorities
20:06:47 <thingee> ttx: agreed. We'll do that in the feedback like EmilienM has done
20:06:48 <fungi> so pike goal was really py3k integration testing, queens goal is py3k unit testing?
20:07:00 <ttx> So I'd like us to do at least the collections link
20:07:05 <thingee> feedback thread*
20:07:07 <sdague> dhellmann: interesting... is there data there?
20:07:17 <dhellmann> fungi : unit testing was a "you may also want to do" thing for pike, but not specified for a future cycle
20:07:20 <sdague> dhellmann: I guess I didn't realize that was the the case
20:07:20 <ttx> and if we do touch tempest-plugins anyway, why not do full-discovery
20:07:30 <dhellmann> sdague : well, apparently some of them are working on unit tests instead of functional tests?
20:07:58 <dhellmann> though tbh, I haven't had time to review the progress recently, so that could be wrong
20:08:05 <dtroyer> 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 <ttx> My personal pick would be to only do 2: split-tempest-plugin and full-discovery
20:08:29 <dtroyer> there is no doubt the py25 work needs to continue though
20:08:44 <dhellmann> do we have a sense yet of how many teams are likely to need to continue working on the py35 stuff?
20:08:54 <sdague> ttx: the full-discovery actually feels vague to me
20:09:02 <ttx> + 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 <sdague> 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 <ttx> sdague: It feels vague to me too...
20:09:25 <fungi> 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 <sdague> so there is demonstration of what complete looks like
20:09:33 <dhellmann> 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 <sdague> and what the transition plan looks like
20:09:50 <dtroyer> dhellmann: ++
20:09:51 <ttx> 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 <sdague> I feel like the collection links & discovery are actually vague
20:10:12 <sdague> they don't demostrate having done it for any project yet
20:10:29 <sdague> especially when there are concerns around microversioning the root document
20:10:38 <sdague> which is non addressed
20:10:58 <ttx> dhellmann: I meant "wait for R if we need to do another goal to complete it
20:11:05 <sdague> I feel like goals are useful when it's already been done on N > 1 projects
20:11:23 <EmilienM> sdague: +1
20:11:29 <dhellmann> ttx: ok. we need to be careful about that messaging, so that teams don't stop during queens
20:11:38 <ttx> sdague: let's see if mordred is still around to clarify it
20:11:44 <dhellmann> sdague : yeah, we did say that relatively early on
20:11:55 <dhellmann> we need examples, to prove out the idea
20:11:55 <EmilienM> 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 <dhellmann> given that, do any of the other proposed goals have >1 example?
20:12:10 <ttx> 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 <dhellmann> ttx: ++
20:12:17 <sdague> dhellmann: policy in code
20:12:19 <fungi> if mordred does manage to pop in, it'll probably be in the second half of the hour i'm guessing
20:12:25 <dhellmann> sdague : I know nova did that, who else did?
20:12:29 <sdague> keystone
20:12:33 <dhellmann> ok, cool
20:12:38 <ttx> dhellmann: I just fear making it a Queens goal would be seen as a license to procrastinate
20:12:56 <ttx> especially if voted on now
20:13:01 <dhellmann> ttx: sure, makes sense
20:13:17 <sdague> so, honestly, the python 3.5 work probably needs a different mechanism than decentralized team goals
20:13:18 <dhellmann> similarly, saying 'we will revisit this for r'
20:13:27 <ttx> Anyone wants to make a case for migrate-off-paste or moving policy in code ?
20:13:35 <ttx> I felt like the policy goal was a bit heavy
20:13:36 <sdague> it really needs project management, and harassing
20:13:50 <fungi> 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 <ttx> sdague: we used to have a team
20:13:55 <sdague> ttx: well, I'm arguing for policy in code, because 2 teams already did that
20:14:00 <sdague> in single cycles
20:14:24 <sdague> migrate-off-paste has the problem of not being proven yet
20:14:24 <ttx> sdague: so you would suggest: policy-in-code and split-tempest-plugins ?
20:14:29 <sdague> ttx: yes
20:14:35 <ttx> yeah, migrate-off-paste seems a bit early
20:14:36 <fungi> 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 <sdague> fungi: it depends on if mostly done is good enough
20:15:04 <dhellmann> 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 <sdague> with python 3.5... I'm not convinced that mostly done is
20:15:08 <EmilienM> ttx: +1 on the 2 proposals
20:15:21 <ttx> EmilienM: which ?
20:15:31 <EmilienM> ttx: policy-in-code and split-tempest-plugins goals
20:15:32 <dtroyer> 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 <fungi> 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 <ttx> 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 <dhellmann> we still have some teams that haven't even responded to the py3 goal :-(
20:17:02 <EmilienM> 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 <dtroyer> 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 <fungi> 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 <smcginnis> 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 <ttx> smcginnis, dhellmann: yes, was wondering if we should not take another approach
20:18:04 <ttx> like form a pop-up release goal team
20:18:12 <smcginnis> +1
20:18:14 <dhellmann> we tried it that way and teams pushed back on taking the patches.
20:18:17 <ttx> that would actively push to get it done
20:18:21 <sdague> smcginnis: so, honestly, is it that we need a team, or we need more active project management?
20:18:32 <smcginnis> I think both.
20:18:38 <ttx> dhellmann: they would still be "goals" and supposed to be prioritized in reviews
20:18:52 <sdague> 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 <EmilienM> yeah both
20:19:06 <ttx> sdague: yeah, that's what I'm coming to
20:19:27 <EmilienM> we need to work with ptls so they know what the community expects
20:19:32 <dhellmann> maybe
20:19:36 <rockyg> sdague, ++ and good job
20:19:38 * dhellmann doesn't have the time or energy to do that this cycle
20:19:44 <EmilienM> which is I think one of the good aspects of having goals: exposing what we want to do as a community
20:19:50 <ttx> Just throwing goals at projects is not getting the optimal results
20:20:06 <sdague> ttx: right, the goals definitely need active project management I think to be successful.
20:20:09 <ttx> I still think we should bless release goals, so that teams know what's coming their way
20:20:20 <EmilienM> maybe we could do the other way around and let PTLs vote on the goals?
20:20:27 <ttx> sdague: I fear they also need people to help write patches
20:20:38 <sdague> ttx: maybe, and that might be fine
20:20:53 <fungi> 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 <fungi> but i guess it's worth a try
20:21:04 <ttx> frankly I'm surprised that even for simple goals ans answers we seem to be struggling
20:21:14 <EmilienM> I don't thikn we can reach 100% of projects, I agree
20:21:19 <sdague> ttx: it's about things falling through cracks
20:21:24 <EmilienM> but we we work with those who contributed already
20:21:33 <EmilienM> s/we we/if we/
20:21:52 <sdague> 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 <EmilienM> 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 <dhellmann> isn't that what we expect PTLs to do?
20:22:23 <sdague> we expect ptls to do a lot
20:22:30 <dhellmann> including delegate
20:22:36 <EmilienM> dhellmann++
20:22:54 <sdague> yeh, well, not everyone is perfect
20:23:06 <ttx> 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 <EmilienM> we could think of having a Goal Liaison per project
20:23:23 <sdague> ttx: that could be
20:23:29 <EmilienM> and having a sub-team at TC making the connections and helping the liaisons
20:23:29 <ttx> EmilienM: I fear that won't scale to smalkler teams
20:23:31 <dhellmann> 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 <fungi> 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 <fungi> maybe _tracking_ who they are per team is helpful, i don't know
20:24:33 <ttx> 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 <sdague> 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 <sdague> 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 <ttx> 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 <sdague> ttx: it is different
20:26:17 <dhellmann> ttx: thought sdague was proposing that 1 volunteer would track that info
20:26:17 <thingee> 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 <sdague> dhellmann: ++
20:26:23 <ttx> ah, ok
20:26:31 <sdague> that's why it's different
20:26:37 <ttx> so one champion
20:26:58 <ttx> (or a set, I don't think it needs to be exclusive
20:26:59 <fungi> thingee: do you mean before we approve them, or after?
20:27:00 <ttx> )
20:27:02 <dhellmann> 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 <thingee> fungi: after
20:27:07 <sdague> which also gives the global view of what the most important next thing is
20:27:11 <dhellmann> so, ENOTIME
20:27:22 <ttx> dhellmann: which is arguably sort of a goal
20:27:23 <fungi> thingee: yes, every project has to update the goal with their scope details
20:27:33 <ttx> dhellmann: (the docs dissolution)
20:27:34 <fungi> after it merges
20:27:42 <dhellmann> ttx: yeah, I didn't file the paperwork because it seemed like more of an emergency than goal
20:28:12 <sdague> right, and I think also points out that there can be really important things to be done that aren't goals
20:28:21 <ttx> 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 <ttx> I'm pretty sure that would clear a few
20:28:56 <thingee> I agree with sdague that we need someone coordinating with the projects on the goals.
20:29:10 <fungi> beyond just having a tc sponsor i guess
20:29:25 <ttx> 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 <sdague> ttx: yeh, that would be good next step
20:30:01 <ttx> sdague: should we ask one for the already-approved goal as well, and demote it if there isn't anyone ?
20:30:18 <sdague> ttx: yeh, that seems fair if we're asking for it
20:30:18 <dhellmann> that seems fair
20:30:20 <dtroyer> given the conversation around that goal, yes
20:30:36 <thingee> 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 <sdague> thingee: ++
20:31:06 <ttx> 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 <fungi> yes, the approved goal needs a project management volunteer, i think
20:31:32 <fungi> (though i suspect that won't be too hard to confirm in that one case)
20:31:53 <EmilienM> what would be the expectation from the volunteer?
20:31:55 <sdague> 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 <ttx> #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 <sdague> and that you can speed up an effort by 2 - 3x by active project management
20:32:28 <ttx> sdague: certainly.
20:32:35 <EmilienM> I would be happy to help here if we set expectations
20:32:46 <fungi> 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 <ttx> I feel like the champion approach is an incremental improvement, easy to set in place for Q
20:33:45 <EmilienM> it's worth trying and we can see how it works - I volunteer to champion 1 or 2 goals for Queens
20:33:52 <ttx> 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 <fungi> 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 <EmilienM> maybe we can take the opportunity to document what we're doing
20:34:16 <EmilienM> fungi: fair enough
20:34:21 <sdague> ttx: yeh I think so
20:34:34 <dhellmann> so we no longer want any acknowledgement from teams that they even see the goals?
20:34:35 <ttx> (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 <sdague> it would also make the consolidated information be of the same quality between projects
20:34:41 <dhellmann> it's going to be left up to 1 person to drive all of that?
20:34:54 <fungi> 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 <ttx> dhellmann: I think we still want PTLs to discuss the goals
20:35:03 <dtroyer> I think we still want the ptl ACK, they need to be aware of what is going on around their projects
20:35:24 <EmilienM> the goal champion would check with PTL goals status, collect and share blockers with the community
20:35:26 <ttx> but the "goals response" process was less than a success this time around
20:35:53 <EmilienM> maybe 2 goals are too much also
20:36:05 <ttx> dhellmann: I felt like the reason people wouldn't submit them was more due to process friction than laziness or ignorance
20:36:08 <dhellmann> I'm disappointed that the only way we can get people to collaborate on these things is to hound them.
20:36:11 <thingee> if majority of projects did py3 unit tests versus functional tests, was there somehow miscommunication?
20:36:11 <EmilienM> for the projects who haven't met the 2 goals, and haven't enough people, 2 is really too much imho
20:36:35 <dhellmann> ttx: I only heard 1 person say there was any friction in the process. Did you hear that from others?
20:36:37 <EmilienM> dhellmann: tbh, it's a bit the same in some projects (when being PTL)
20:36:45 <EmilienM> dhellmann: (personal experience :-))
20:37:16 <ttx> 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 <ttx> My understanding is that iut's somethign you always set to prio 2
20:37:52 <ttx> I'll submit that tomorrow
20:38:14 <ttx> heck, even the release management response was not immediate :)
20:38:30 <dhellmann> yeah, that guy was new ;-)
20:38:36 <EmilienM> lol
20:38:59 <fungi> 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 <ttx> 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 <EmilienM> ttx: anyway. If we're looking for someone to project-manage one or 2 goals, I do volunteer to help
20:39:24 <ttx> but I'm not sure a governance patch is the most frfictionless way to communicate that
20:39:50 <ttx> EmilienM: you mean, whatever the goal ?
20:39:57 <EmilienM> yea
20:40:04 <ttx> The champion of champions :)
20:40:11 <dhellmann> 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 <mriedem> honestly i need to be hounded
20:41:01 <mriedem> 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 <mriedem> 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 <mriedem> anyway, feel free to hound me at least
20:42:12 <sdague> 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 <mriedem> right, e.g. i needed sdague asking me to review global request id patches
20:42:35 <mriedem> to keep those moving
20:42:44 <ttx> OK, time check... Let me summarize a few findings so far
20:42:48 <sdague> and knowing that the person with that ask has filtered out the noise so that it is really important
20:42:58 <ttx> #info Goals need champions to project-manage them to completion
20:43:13 <dtroyer> 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 <ttx> #info We'll ask for champions on proposed (and the already accepted) goal
20:43:41 <EmilienM> dtroyer: interesting approach
20:43:43 <ttx> #info Migrate off paste might be a bit early, a success story in one project is probably needed first
20:44:10 <mriedem> placement isn't using paste.ini i don't think...
20:44:11 <ttx> #info Python 3.5 should go to completion in Pike rather than being "extended" now to Queens
20:44:13 <fungi> 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 <dhellmann> 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 <ttx> #info Full-discovery sounds vague to a few
20:45:02 <ttx> #info Policy into code & Split tempest plugins seem to general have support
20:45:18 <ttx> #info Only 2 goals for Queens is probably a reasonable target
20:45:22 <ttx> Is that a good summary so far ?
20:45:23 <thingee> ttx: I'll provide a follow up email to the list
20:45:39 <fungi> this has been really helpful for me, thanks!
20:45:42 <EmilienM> do we have examples of PMs involved (really) in OpenStack community
20:45:43 <EmilienM> ?
20:45:45 <dtroyer> 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 <EmilienM> ttx: yes, lgtm
20:45:56 <ttx> EmilienM: I would consider myself a PM
20:46:22 <dtroyer> solution: clone ttx
20:46:34 <EmilienM> lol
20:46:36 <fungi> 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 <ttx> 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 <ttx> (also others)
20:47:02 <thingee> EmilienM, dtroyer : I have my PMP cert from way back when
20:47:27 <EmilienM> thingee: you lucky :D
20:47:30 <fungi> yeah, "project managers" who have emerged from within our contributor community have been far more effective than those injected from outside
20:47:33 <ttx> mordred: so you want to address the "vagueness" in the discovery stuff ?
20:47:41 <mordred> 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 <ttx> Also, would you be its champion (and actually have time for it in Q ?)
20:47:48 <thingee> EmilienM: dark times :)
20:47:51 <thingee> learned a lot
20:47:53 <ttx> s/so/do
20:48:04 <dtroyer> 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 <ttx> 80% of PMing in OpenStack is beating the drum
20:48:30 <dhellmann> dtroyer : that's fair. I just don't think "find more new people" is very realistic right now.
20:48:32 <sdague> 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 <mordred> ttx: yes, I would be its champion. I mean, I'm going to be working on that topic regardless
20:49:06 <ttx> yes
20:49:10 <fungi> agreed, my answer was more to dtroyer's earlier suggestion of asking member companies to provide us with some project managers
20:49:10 <thingee> maybe instead of saying project manager we keep going with champion or drum beater
20:49:24 <mordred> thingee: ++
20:49:27 <dhellmann> 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 <fungi> thingee: dj!
20:49:37 <ttx> 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 <thingee> OpenStack champion no pmp or agile required
20:50:22 <dtroyer> 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 <mordred> 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 <ttx> sdague: did you want to ask mordred for clarification on discovery goal vagueness ?
20:50:52 <dhellmann> 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 <ttx> thingee: do you have everything you need for the next step ?
20:51:45 <dhellmann> 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 <sdague> ttx: ah yeh
20:51:58 <thingee> yes. I would like to understand more about the champion thing so it can be communicated on the list
20:52:03 <thingee> ttx: ^
20:52:16 <thingee> or I can leave that out for now
20:52:23 <sdague> mordred: I didn't see anything in there about the microversioning strategy for changing these root docs which impacts some projects
20:52:57 <rockyg> 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 <ttx> 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 <ttx> 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 <mordred> 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 <thingee> the champion should have some trust with core project reviewers as have seen the implementation of the goal too
20:54:09 <ttx> And the scoreboard on the goal doc is not really enough to figure out the state, tbh
20:54:33 <thingee> rethink how we track goal progress
20:54:41 <thingee> at a glance
20:54:48 <sdague> 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 <thingee> ttx: thank you. I'm good
20:55:09 * thingee disappears into pdx
20:55:25 <ttx> thingee: I'm happy to review email drafts if you want me to
20:56:39 <mordred> 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 <mordred> 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 <ttx> alright, any other question / discussion on this topic ?
20:57:48 <ttx> we have 3min left if needed
20:58:17 <thingee> ttx: thanks
20:58:25 <ttx> We did not exactly made progress in the direction I expected, but it's still progress
20:58:36 <ttx> make*
20:58:45 <rockyg> ++
20:58:52 <ttx> I typo more at 11pm for some reason
20:59:09 <fungi> i'm happy with it
20:59:18 <ttx> #topic Open discussion
20:59:23 <EmilienM> ttx: thanks, it was good discussion
20:59:38 <fungi> 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 <ttx> Alright, that probably concludes our second adhoc meeting
21:00:04 <ttx> fungi: I'll miss that one
21:00:10 <fungi> i expected that ;)
21:00:34 <dtroyer> fungi: I'm planning to be here
21:00:34 <ttx> I should tour the doc and sprinkle TC office hours info where needed
21:00:46 <ttx> Currently not so many people know they can reach out then
21:00:54 <ttx> We should mention it on the project-team-guide
21:01:02 <fungi> yes
21:01:02 * ttx makes a note
21:01:06 <ttx> OK, off time
21:01:08 <ttx> #endmeeting