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