20:02:32 #startmeeting tc 20:02:32 Meeting started Tue Feb 3 20:02:32 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:37 The meeting name has been set to 'tc' 20:02:50 Our agenda for today: 20:02:53 o/ 20:02:58 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:03:13 #topic Release naming process 20:03:19 #link https://review.openstack.org/150604 20:03:30 This is a clarification/standardization of the release cycle naming process 20:03:38 IIUC the idea here is to use that new process for the M naming campaign. 20:03:48 (We could actually start that campaign soon after the change merges, since we know where that summit will be held already) 20:03:53 and hopefully to reduce the amount of hate people give ttx 20:03:58 (except the proposed change currently says "no sooner than the opening of development of the previous release") 20:04:09 Current revision looks relatively good to me 20:04:11 there are some good comments on that, perhaps the most contentious one is whether it's okay to say "fun" in the resolution. 20:04:19 I have two main concerns left... 20:04:22 oh, sorry "cool" 20:04:23 not fun 20:04:26 * mordred disagrees with mikal about cool 20:04:30 1. I'm not sure annotations are the best way to integrate marketing team feedback, as I expect most voters won't read the attached data 20:04:35 A few alternatives have been proposed on the review 20:04:43 I've never been cool, so it saddens me 20:04:47 2. I'm very concerned that striking down the poll winner on trademark grounds *after* the campaign and the vote will be very unpopular and result in kill-the-messenger 20:05:00 That's more difficult to fix, since the concept of an open list is not really compatible with pre-vote trademark checks 20:05:16 ttx: I disagree there 20:05:25 yah - I think people have interacted with enough project name trademark issues that it won't be contentious 20:05:29 ttx: if its open (we checked these, they failed) 20:05:33 ttx: then I think that's ok 20:05:36 mikal: maybe because you've never been the messenger 20:05:45 ttx: true dat 20:06:01 we can let the professional messenger people be the messengers ... 20:06:11 they probably don't mind being shot as much 20:06:23 mordred: ummm, yeah, about that 20:06:26 I mean, the results of the poll will be out there while the checks are run 20:06:32 people will start using the winner name 20:06:45 I really do think we need to filter through the trade mark search before the vote 20:06:50 ttx: why do the results of the poll have to be published before the trademark check is done? 20:06:53 To stop a mutiny if the winner is excluded for some reason 20:06:55 dhellmann: ++ 20:06:57 and then someone (mle) will relay the trademark lawyers always-qeustionable opinion 20:06:58 dhellmann: ++ 20:07:01 I would agree we should pre-filter somehow 20:07:04 i suppose there could be a preliminary poll to choos ethe top n candidates, then vet them, then a second poll to select the winner 20:07:05 I think a prefiltered list is fine, the voting is the "fun" and the setup of the vote and the communication of the vote is the "work" 20:07:17 dhellmann: open voting platforms generally open the results immediately 20:07:31 dhellmann: but maybe you have a voting platform to suggest that wouldn't do that 20:07:31 fungi's idea is also potentially good 20:07:42 fungi: ++ 20:07:42 i think avoiding prefiltering is important. i think it's one of the things that makes this a truly open election 20:07:45 and would still support 16K voters 20:07:48 jeblair: ++ 20:07:48 ttx: no, I was just trying to understand the assumption implicit in your statement 20:07:49 but also "bad" because it's twice as many polls 20:07:50 Yeah, we just have a sentence in the email opening the vote saying: "We also considered the following names, but had trade mark problems: Mikal, Monty, Manchuria, Munchkin" 20:08:01 and i also think it's a benefit to the foundation to not have to do exceess trademark checks 20:08:12 fwiw the Fedora process is to have a wiki page that anyone can add suggestions to, and then one of the representative bodies (I forget which) goes through and leaves reasons (trademark problem, doesn't fit theme, &c.) why some aren't appropriate. the rest get voted on 20:08:17 yah - because they'd potentially have to trademark check 50 things 20:08:33 I don't think trade mark checks are very expensive? 20:08:37 oh! there is another group process we can model on? 20:08:39 then again we had a Fedora "Beefy Miracle" release, so... yeah 20:08:43 I've worked places where we did them for every _internal_ project name 20:08:46 contrast with debian, which delegates release naming to the release team (no fun for anyone else i guess) 20:08:48 zaneb: you had me there fora second... 20:08:57 maybe we shouldn't have 50 options 20:09:02 why not? 20:09:08 we have a ranking voting system 20:09:17 well, if we're worried about the cost of the checks 20:09:20 there's no reason to unnecssarily restrict people's expression 20:09:27 dhellmann: mikal it's expensive if the list ens up being long 20:09:43 ttx: do we know how much we pay per check? 20:09:56 mordred: I'm not certain it's unnecessary. Don't restrict my right to ask questions. ;-) 20:09:56 just trying to get an order of magnitude 20:09:58 mikal: no. It's also the time it takes 20:10:01 dhellmann: :) 20:10:28 dhellmann: I'm fine with restricting you personally - just not $people generally ;) 20:10:33 i mean _i'm_ not worried about the cost; i thought it was a nice benefit of the open list model, whose real benefit is in making the process as fair and open as we can. 20:10:42 To vet 4 it takes a week. Since that's our trademark lawyer, I expect vetting 50 would take at least 3 weeks 20:10:57 I think if we came up with a list of 50 options and they were *in order* and #50 was the only one without a trademark issue we would probably have noticed that before we started voting, right? 20:11:00 guh 20:11:25 so if we can hide the election results until the checks are done, we would only need to check a few 20:11:32 also - since we're drawing these from names of public places ... 20:11:46 the chances of trademark violation is probably lower than for other things? 20:12:02 mordred: not really, trademarks are per segment 20:12:04 dhellmann: I agree that if we can announce the winner before or at the same time as the poll results, the bad efect is mostly avoided 20:12:07 you're already prefiltering for length and character set. 20:12:08 sdague: good point 20:12:33 but you wanted an open process, and now that means some people have early access to the poll results 20:12:36 honestly, anyone with a web browser and 5 minutes to kill can rule stuff out on trademark grounds 20:12:42 so maybe instead of condorcet, we just do a popularity vote with a tool that lets us keep the results private 20:12:46 you only need a lawyer to rule stuff *in* 20:12:50 zaneb: you should definitely open a practice 20:13:13 so - at the risk of being this guy ... 20:13:21 zaneb: is right, and is, incidentally, the process they use at netflix 20:13:36 ttx: can we call the M release "Microsoft"? Answer: no. number of lawyers consulted: 0 20:13:50 zaneb: but can you call it Miyasaki ? 20:13:57 zaneb: so are you suggesting we pre-filter? 20:14:00 I feel like we're trying to optimize away a problem that has not occurred - namely that if we annoucne that we're going to do trademark checks on the sorted list of winners and will announce the results people will completely ignore that and just go crazy with the top name in the list 20:14:14 it's entirely possible that all of 10 people will even notice the results list 20:14:26 and of those people they'll be the people who will be involved in getting them vetted 20:14:29 zaneb: I for one don't know how Japanese law protects family names 20:14:30 dhellmann: yes. we can drastically reduce the odds of something being ruled out later by the lawyers 20:14:43 zaneb: yeah, I like that. We need some volunteers. 20:14:46 of course obvious existing stuff can easily be rules out 20:15:04 so that the average number of names we need to do a full shakedown on is in the range 1-2 20:15:14 i mean a lot of us make up names for the releases before they happen. no poll necessary. 20:15:24 that doesn't cause them to become the actual names 20:15:27 I'm looking forward to the lemming release 20:15:32 just like I was looking forward to the hood release 20:15:41 and I can't wait for OpenStack Monty 20:15:41 team lizard 20:15:49 mordred: so you say my concern is irrelevant? 20:15:55 I am not worried about it myself 20:15:56 i'm keen on Miyazaki (which is a city in japan) 20:16:12 I've been lobbying for Muppet 20:16:15 and I'm happy to be the messenger even to take the brunt of the hate mail if that would be helpful 20:16:16 But I'm not helpful with names 20:16:34 * ttx is tempted to let Monty defend the trademark lawyers call 20:16:41 ttx: I think an open process means trusting that the peopel involved will do things and it won't be the end of the world 20:16:45 So, in other news 20:16:53 mordred: ++ 20:16:53 It sounds like this thing needs another round of discussion on the review? 20:16:58 crowdsource the checks on the initial list, then finalize and vote 20:16:58 mikal: probably so 20:17:06 W're not going to resolve it now 20:17:13 ttx: I mean, I get what your'e saying and can see how it can be a valid concern 20:17:14 So let's argue in gerrit 20:17:23 "You all voted for Miyasaki, by a large margin. But someone nobody knows has said it's a bit risky because it's the name of a guy that has studios in Japan 20:17:25 ttx: I just think personally that having a wide open process would be an interesting thing to try 20:17:32 with not a huge amount of _Actual_ downside to failure 20:17:40 i will push up a new change with the minor changes suggested so far 20:17:47 jeblair: ++ 20:17:55 ttx: I believe most people are familiar with "the lawyeres said it's a trademark problem" 20:18:12 or at least they've never heard of quantum, moniker or savana 20:18:29 or RedDwarf 20:18:34 the list goes on ... 20:18:45 that didn't prevent them from choosing the name in the first place 20:18:51 of the list of legal issues we're sketchy on around here- we've got real history with dealing with bad trademark :) 20:18:57 so much for "checking on Google" 20:19:02 sure - but nobody revolted when it had to be changed 20:19:10 much less people in general 20:19:10 no, I see your point 20:19:11 ttx: it's pretty clear they did not do that 20:19:17 ++ 20:19:43 jeblair: btw why did you add "no sooner than when the previous cycle starts" ? 20:19:59 So... Moving on, right? 20:20:06 ttx: i think that was to keep some periodicity to the process 20:20:08 * mikal looks hopeful 20:20:09 mikal: ok, ok 20:20:14 ttx: so we don't chose the next 5 names at once 20:20:44 (knowing M now would be nice, knowing N at this point isn't as necessary) 20:20:56 and we may have all rage-quit by N 20:21:05 jeblair: I'd like to know the M name by Vancouver 20:21:10 mikal: we happen to have a relatively light agenda, so I figured we could discuss a bit of this directly 20:21:14 mikal: ++ 20:21:16 jeblair: heck, I'd like to know the L name 20:21:25 mikal: but if you are done with it, I guess we should move oni 20:21:30 on 20:21:38 ttx: well, other people are here too 20:21:42 mikal: bah 20:21:46 #topic Project structure reform 20:21:48 ttx: I just feel like we're not going to reach a concensus the way we're going 20:21:53 yay moving on 20:22:00 * Move from program-based structure to project-based (including new projects requirements) (https://review.openstack.org/145740) 20:22:05 I think we can make progress here. 20:22:13 We have dhellmann, jeblair and mordred +1, annegentle and vishy +1ed a previous version 20:22:19 no other TC member chimed in last time I looked 20:22:24 nor commented 20:22:29 Does that mean with one more vote it's good to go ? 20:22:51 i would love it if more of the committe voted on this 20:22:56 me too 20:23:05 So, want me to do that now? 20:23:08 i feel like we all ought to have opinions about it and go on record 20:23:15 i.e. if we're light for tstuff, let's pause and make people review this 20:23:17 mikal: ideally, you would have done it before, but.. 20:23:35 I'll take it :) 20:23:37 ttx: that's clearly not the case for much of the TC 20:23:52 mikal: and of those, at least you are present :) 20:24:07 just added my opinion, seems reasonable 20:24:07 I was fairly close to adding +1 last time I looked.. need to return and finish re-read 20:24:28 We can use the next 5-10 minutes to make progress on that 20:25:14 I expect it to be an initial version and to get amended as we go along anyway 20:25:38 mikal: the key part imho is the new projects requirements 20:26:02 The rest is more mechanical rip off of incubation and programs 20:26:10 as already discussed in the spec 20:26:30 the new projects requirements were vague in the spec though, and this defines them 20:26:56 I Think it's fine as is - but I can see a follow on discussion aroudn refining the oslo line 20:27:07 We have 7 now, but I'd like to give everyone a last chance to oppose it 20:27:32 mordred: yes I like the "we do X because we want to encourage Y" formula 20:27:32 ttx: I think there's still some room for problematic PTL definition 20:27:54 annegentle: as in booting a failed PTL? 20:27:57 for example, let's say translation, logging, and monitoring all want projects. Who would be the electorate for each ptl? 20:28:12 mikal: more like at what level is ptl? 20:28:17 ah. the questiojn of questionable electorate 20:28:29 annegentle: it's already the case though, not a new problem 20:28:49 Release Management PTl was elected by "contributors" to the stable branch for example 20:29:05 yeah renaming program to project didn't address it, but as long as we're renaming, should we discuss the problem? 20:29:11 but we also gave core reviewers would get a vote 20:29:19 broadening the electorate definition will in some cases require new tools for tracking contribution to a segment of the community 20:29:32 right fungi for translations for example 20:29:35 annegentle: I would discuss it as a separate change 20:29:43 (for example, a means of tracking translation activity in zanata) 20:29:44 since it applies to both the old and new 20:29:58 and is likely to trigger a completely separate debate 20:30:08 Agreed 20:30:14 Ditto the oslo thing 20:30:22 I'd like to talk more about it, but I don't think we need to block this for that 20:30:23 but I completely agree we might want to clarify that 20:30:25 ttx: ok 20:30:29 yep, agreed 20:30:41 I like jeblair's alternate wording for the Oslo question, so maybe he will submit a patch? 20:30:57 so perhaps projects come with definitions of their constituents which defaults to gerrit change owners of patches merged to covered repos, but could be something else as long as there's a clear metric and corresponding tracking mechanism 20:31:07 #info subsequent change should handle the case of a PTL where voters are not directly derived from repo commits 20:31:18 dhellmann: ++ 20:31:23 dhellmann: in that case, he just might :) 20:31:32 * dhellmann crosses his fingers 20:31:55 OK, let's say I'll approve it if it's still at 7 YES and no -1 tomorrow 20:32:09 if a -1 is raised we'll wait for next week 20:32:10 ttx: it's not "just" tracking mechanisms, it's also scope. As in should there be a training PTL and API Docs PTL, both of which would have different repos for electorate. 20:32:31 annegentle: that maps to teams 20:33:05 If training and docs are separate existing teams, I don't see why they wouldn't each have a lead 20:33:15 ttx: there's no API docs team for example 20:33:15 that gets back to the "let's get rid of the prohibition against similar fields of endeavor" reason for big-tenting 20:33:25 ttx: so it falls to the Docs PTL 20:33:49 annegentle: who handles the API Docs ? The doc team ? Some other team ? 20:34:01 fungi: right but with continuing to have PTL elections you still have a first in winner of sorts 20:34:16 ttx: the Docs PTL currently has them in the program 20:34:36 ttx: just figuring out the mechanism for when you'd know to have a 2nd PTL election 20:34:37 but who handles them ? Some subteam of Docs team ? Or a completely separate team ? 20:34:59 some of the oslo libs are similar -- we have a single cross-lib core team, but also have specialist teams that don't tend to contribute to more than one library 20:35:12 dhellmann: yes, that would be the subteam case 20:35:14 we just sort of evolved that way, but we could theoretically split those groups out into their own teams 20:35:29 annegentle: actually the case of the release management program is very interesting here 20:35:45 because it's a pack with stable, release management and vulnerability management 20:35:51 which actually are 3 separate teams 20:36:02 yeah so in all those cases, do we need to codify/write down the guideance for the split 20:36:06 under this model, if some new team wanted to write all new api docs, they could presumably petition to become a project. if they wanted to take over maintenance of existing api docs then they'd need to coordinate that choice with the existing team controlling those specific repositories 20:36:07 (I can't spell) 20:36:18 It wouldn't be completely crazy to consider them 3 teams 20:36:27 yep it would be fine 20:36:32 annegentle: agree on the need 20:36:43 annegentle: yeah, definitely Write Things Down (TM) 20:36:48 OK, any more remarks on that one ? 20:36:49 yep 20:36:57 let's move on to the next 20:37:02 * Adds service to indicate a user-readable and understandable name (https://review.openstack.org/150030) 20:37:16 That's a followup change to keep the "service name" information somewhere, I think it's pretty straightforward 20:37:22 mordred brought up interesting points that made me think back to the history 20:37:42 mordred has a good point, but this change is more putting back what was there than coming up with new names, no ? 20:38:02 ttx: do you recall if Image Service was a legal requirement? Or was it caused by the alleviation of confusion I mention ? 20:38:19 I'm TOTALLY fine with not 'fixing' right now 20:38:21 annegentle: don't remember... 20:38:25 it just read strangely 20:38:33 I think whatever was there before was more confusing ? 20:38:48 was it "Image discovery and delivery service" ? 20:38:54 ttx: ha maybe? 20:39:05 a bit of a mouthful for docs 20:39:12 for sure 20:39:27 so i think it it was contracted 20:40:05 so should I patch to drop the second "service" ? 20:40:38 I don't really care tbh 20:40:43 or are these legally vetted names already? 20:40:49 you are the first consumer of that info 20:40:54 in the docs 20:41:03 I'm fine with what is fine for you 20:41:03 ttx: can you find out the legal status easily? I can ask too 20:41:27 I can ask. Doesn't ring any bell though. 20:41:50 annegentle: can you sned me an email with the question ? I'll pass it around historians 20:42:01 ttx: you got it 20:42:15 OK, moving on, unless someone has another comment on that one 20:42:20 #action annegentle to send ttx email asking about existing trademark status of list of service names 20:42:38 #topic Other governance changes 20:42:45 * Adding Chuck Short to extra-atcs (https://review.openstack.org/150763) 20:42:51 I'll approve this one when (if) it reaches 7 YES 20:43:05 * Move oslo.version to openstack-attic (https://review.openstack.org/151772) 20:43:10 I abandoned that in favor of https://review.openstack.org/152654 from fungi 20:43:10 This change has a -1 from mikal 20:43:17 ah, recent 20:43:28 that just deletes it, which in retrospect is more accurate 20:43:42 dhellmann: oh, yours was earlier--sorry i didn't even see it for some reason. my grep must have been broken, that was it 20:43:43 and also has a +1 from mikal 20:44:00 fungi: I just renamed it, and I should have removed it, so no worries 20:44:00 Yeah 20:44:08 I just thought it was weird to track the attic repo 20:44:19 * annegentle has to step out breifly, sorry 20:44:20 fungi's change didn't do that, so won the popularity contest 20:44:24 mikal: yeah, I didn't understand your comment until I saw fungi's patch -- brain hiccup 20:44:26 mikal: ++; fungi's change lgtm 20:44:43 See, I do read these things before rubber stamping 20:44:54 * dhellmann never doubted it 20:44:58 :) 20:45:11 The others are repository additions, all proposed by the local PTL and which I'll all approve tomorrow unless someone complains: 20:45:16 * Add oslo.versionedobjects to the Oslo program (https://review.openstack.org/151771) 20:45:19 * Add infra puppet repos (https://review.openstack.org/151100) 20:45:23 * Add shade to infra program (https://review.openstack.org/151102) 20:45:27 * Adds openstackdocstheme to the Documentation Program (https://review.openstack.org/151773) 20:45:29 Can we talk about the puppet one quickly? 20:45:44 https://review.openstack.org/#/c/151100/ that is 20:45:45 mikal: sure 20:45:48 mikal: no talking. only voting. 20:45:51 jeblair: dude, that's a lot of repos 20:45:56 Ok, conversation done 20:46:01 mikal: dude. 20:46:18 * ttx expects some dirty conflicts with the governance change which also touches the program.yaml 20:46:28 mikal: amazingly, that's actually the thing needed to make things _easier_ 20:46:32 mikal: also ... dude 20:46:37 Heh 20:46:53 I just want it minuted that jeblair is trying to win the "most repos" competition 20:46:58 he wins 20:46:59 I move that ttx be allowed to rebase and fix any conflicts for patches that are already approved without us needing to vote again. 20:47:11 dhellmann: that seems sensible to me 20:47:16 dhellmann: ++ 20:47:55 dhellmann: ++ 20:47:56 I move that future incarnations of this file (if any) should use multiple files to avoid unnecessary conflicts 20:48:06 ttx: if you want help with that, I'll do the rebasing and you can approve them 20:48:14 dhellmann: noted 20:48:16 ttx: i'm not opposed, but i fear it won't help 20:48:17 and appreciated 20:48:32 jeblair: it won't help you and your damn list of 145 repos 20:49:09 you wioll be in rebase hell forever 20:49:16 * dhellmann can't wait to see what the rendered repo list looks like when he restores https://review.openstack.org/125788 20:49:39 dhellmann: heh 20:49:40 #topic Open discussion 20:49:51 We still have no answer from the Lil'wat tribe and pressure to get a name for L is at an all-time high 20:50:01 Especially with some projects like Nova planning to "defer to L" a number of blueprints this week 20:50:11 I think we may have to count that as a lost opportunity 20:50:14 So if you give me your approval I'll start the poll (Juno/Kilo-style open-to-everyone SurveyMonkey poll) this week 20:50:23 Short list was vetted/sponsored by TC members last week: Lizard, London, Liberty, Love 20:50:28 (in my personal order of preference :) 20:50:35 (campaign starts) 20:50:45 Anything else, anyone ? 20:50:47 Yes, please do that thing 20:50:59 ttx: +1 let's start the poll 20:51:19 agree, just run the poll 20:52:06 ttx: +1 for running the poll 20:52:28 In other news, I'll try to look at some projects activity to judge if none of them died while we were looking the other way 20:52:55 ttx: maybe they just finished? 20:53:41 jeblair: maybe. I received pings from people having trouble to contact certain projects 20:53:50 maybe it's just a blip 20:54:10 ttx: sounds like a worthy effort 20:54:16 we had some concern about landing some oslo updates; looking into it, I think it's probably going to work out, but it raised the question of what we would have done if that hadn't been the case 20:54:37 we may want to consider, for example, a PTL mentoring program for new PTLs 20:55:05 we may also want to put a policy in place that allows us to add cores to a project to unblock issues -- esp. security problems 20:55:07 More generally I think it's not totally irrelevant for the future TC to ask some projects to get their shit in order, when such shit is identified 20:55:12 but I don't think we need that right now 20:55:25 ttx: yes, that, too 20:55:34 When I talk 1:1 with people they all have one or two projects they consider a lost cause 20:55:43 but collectively we are not so forthcoming 20:55:55 I think giving advice is part of our role 20:56:00 ++ 20:56:03 ttx: +1 20:56:12 as well as raising red flags 20:56:16 indeed 20:56:36 sometimes it's just that the PTl is struggling in an ocean of solitude and nobody raised the flag that might give him more resources 20:56:45 or her 20:57:18 So we should get better at putting the dead fish on the table 20:57:23 sometimes having a 1:1 mentor works better for sussing out those sorts of issues than the cross-project meeting or this meeting would 20:57:44 ttx: yeah.. do you think that would be good topic for an inperson TC gathering around the summit? 20:57:54 we do have some folks in the community for whom this is their first "big leadership" role 20:57:57 dhellmann: right, I don't think the way we operate now lets us provide that good feedback and look reality in the eye 20:58:13 and as we gain more projects, that's going to become more common 20:58:25 markmcclain: it is a good topic for various in-person gatherings we accidentally have 20:58:31 yah - and especially as being a project no longer conveys immediate attention 20:58:54 so one can be a PTL and working on a project that people have forgotten exists in the new world order 20:59:05 also true 20:59:15 but I agree with ttx about dead fish and tables 20:59:16 the fun part being, the "doomed projects list" is different for everyone :) 20:59:19 fwiw, I do reach out to people for advice. In my experience though, people are busy. 20:59:26 i would like to see the project requirements address what happens when the criteria for being a project are not sustained over the long term 20:59:33 thingee: nobody said cinder was dead though. Weird. 20:59:59 i think that would go a long way to addressing the "dead project" concern 21:00:02 ttx: regardless, I find people are busy. I'm glad this is being discussed though 21:00:09 thingee: that's a given, but I do think it's our responsibility to make time for this sort of thing 21:00:18 ttx: yeah accidental conversations are ok, but wonder if something more public and scheduled is in order 21:00:18 dhellmann: +1 21:00:50 In summary, I think the new governance removes the incubation ladder as a feedback mechanism, we need to replace it with something that will even work on projects on top of the ladder 21:01:03 I think there's a large difference when the previous PTL leaves the community as well. The built in mentoring process is gone 21:01:09 a bit like what we did with gap analysis, only smarter 21:01:14 david-lyle: excellent point 21:01:37 david-lyle: I've been really thankful for jdg helping me. 21:01:43 I hope to remove enough useless release management work in the future to be able to do a better job at PTL mentoring 21:02:06 ok, time is up 21:02:13 #endmeeting