20:02:44 <ttx> #startmeeting tc
20:02:45 <openstack> Meeting started Tue Aug 18 20:02:44 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:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:48 <openstack> The meeting name has been set to 'tc'
20:02:52 <ttx> Our agenda for today:
20:02:57 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:03 <ttx> #topic Using topics to classify governance changes
20:03:15 <ttx> 3 weeks ago sdague asked that we use Gerrit topics to mark governance changes that do not actually require formal votes
20:03:21 <ttx> so that we can filter them
20:03:30 <ttx> I sent an email to the -tc list proposing to do the reverse (mark those who actually require formal votes), since there are lots of corner cases:
20:03:37 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2015-July/001005.html
20:03:45 <ttx> No answer to that proposal... yet
20:03:51 <russellb> seemed reasonable to me
20:03:53 <ttx> not sure that means "go ahead"
20:03:57 <flaper87> I think we silently agreed
20:03:57 <ttx> russellb: ok
20:03:58 <flaper87> yeah
20:04:00 <russellb> i didn't have anything to add
20:04:09 <russellb> so yeah, my silence was +1 :)
20:04:09 <flaper87> extreme lazy consensus
20:04:24 <ttx> #action ttx to mark things that we actually need to vote on, for easier filtering
20:04:30 <dhellmann> yeah, mark the subset -- the point was to just be able to filter
20:04:38 <ttx> just hoping that doesn't mean nobody will pay any attention to other changes
20:04:54 <russellb> i'll still have all changes hitting my inbox personally
20:04:55 <jeblair> o/
20:04:55 <flaper87> it'll help me prioritize
20:05:00 <annegentle> a search filter sounds great
20:05:01 * dhellmann subscribes to all
20:05:13 <ttx> #topic Add and apply tag team:size-large
20:05:14 <dhellmann> I could add it to the TC dashboard query, too
20:05:14 * flaper87 uses gertty
20:05:20 <flaper87> YEs, I'm one of those
20:05:25 <russellb> so this tag came up in the next tags WG
20:05:28 <russellb> or rather, this family of tags
20:05:30 * jeblair high-fives flaper87
20:05:33 <ttx> #link https://review.openstack.org/208029
20:05:35 <russellb> the idea of tagging info around team sizes
20:05:36 <ttx> #link https://review.openstack.org/208030
20:05:42 <ttx> In the discussion emerged the need for a team:very-small tag, which is what consumers of that data are actually looking for
20:05:56 <ttx> "Is a project maintained by enough people to be there tomorrow" (same as diverse-affiliation)
20:05:56 <flaper87> jeblair: :D
20:06:06 <russellb> right, happy to propose "very-small" as a red flag tag
20:06:08 <ttx> That said, that doesn't mean a team:very-large tag isn't useful, to distinguish projects with a giant group behind them...
20:06:17 <ttx> russellb: I guess that still answers a question people might have ?
20:06:18 <russellb> curious if anyone else finds "very-large" useful
20:06:25 <russellb> it seems somewhat interesting to me
20:06:33 <flaper87> mmh, have we considered using number-ranges ?
20:06:35 <russellb> but is it just interesting, or is it useful?
20:06:37 * russellb shrugs
20:06:38 <flaper87> throwing it out there
20:06:40 <annegentle> I think that activity-level:high is more accurate for this?
20:06:41 <ttx> Yeah, I can see how *I* would use iut, not sure about others though
20:06:47 <flaper87> rather than small/very-small/big
20:06:47 <jgriffith> russellb: so it is intended to be different than "diverse"?
20:06:50 <dhellmann> annegentle: ++
20:06:57 <russellb> jgriffith: yes
20:07:02 <ttx> flaper87: "medium" doesn't answer any question
20:07:03 <annegentle> not trying to paint a bike shed, but it seems like this isn't about team size but activity / scope
20:07:05 <russellb> jgriffith: diversity vs # of people doing the work
20:07:07 <flaper87> At least we know how many we're talking about (not sure if that makes sense)
20:07:17 <jgriffith> russellb: thanks
20:07:26 <russellb> is a diverse group of 5?  or is it a diverse group of 50?
20:07:41 <markmcclain> doesn
20:07:51 <jgriffith> russellb: yeah, I see the difference now.  Thank you
20:07:53 <edleafe> it's about warning for potential problems, no?
20:07:54 <ttx> annegentle: it's arguably az comabo. One very active person is certainly more fragile than 3 moderately-active persons
20:08:04 <ttx> az comabo ?
20:08:06 <flaper87> ttx: agreed, which is why I'm wondering if we've considered rage numbers
20:08:08 <ttx> what am I typing
20:08:17 <ttx> "a combo".
20:08:17 <russellb> rage numbers?  sounds fun
20:08:27 <lifeless> flaper87: do you mean drive-by fixes?
20:08:32 <jeblair> also, the necessary team size may vary by project moreso than diversity
20:08:39 <flaper87> <=10, <= 20, >20
20:08:41 <lifeless> also maturity
20:08:43 <russellb> jeblair: fair
20:08:53 <lifeless> a mature specialised thing needs many less changes
20:09:03 <russellb> is there some # that's "very-small" / "too-small" regardless of project?
20:09:06 <ttx> flaper87: I don't think <=20 answers any question anyone has
20:09:15 <russellb> if not, then maybe the whole tag category should be dropped
20:09:28 <annegentle> also the 6 commits and 30 reviews, is that a known ratio from a given team?
20:09:33 <flaper87> ttx: what does very-small say? What do we base that on?
20:09:42 <ttx> I feel like people want to know if "enough" people support their project. They may want to know if the project is giganormous, but I'm not sure of that
20:09:45 <russellb> annegentle: completely arbitrary starting point
20:09:52 <ttx> flaper87: bus factor
20:09:52 <annegentle> russellb: ok
20:10:17 <ttx> flaper87: A project with only one active person is extremely fragile.
20:10:19 <russellb> i picked those numbers out of the air, and they seemed to capture the biggest handful of projects
20:10:20 <markmcclain> yeah.. I think small is more of a concern
20:10:23 <ttx> there are some of those in openstack today.
20:10:29 <annegentle> I ran these numbers for docs, and only one specialty areas will be above that ratio I think... will have to double check
20:10:37 <ttx> I think people should know about them.
20:10:38 <flaper87> ttx: sure, doesn't <= 10 same the same thing?
20:10:49 <ttx> <= 10 what?
20:10:52 <flaper87> my point is, we gotta get those "quantifications" from somewhere
20:10:58 <fungi> also curious how to aggregate that across all the repos for all the deliverables in a project, assuming it's based on core review/approver group membership or commit activity or...
20:11:08 <flaper87> ttx: whatever very-small is made of, I guess
20:11:18 <russellb> fungi: the union of all activity in all repos for a team
20:11:20 <russellb> is how it works right now
20:11:22 <jgriffith> If they're not large they're small(ish) :)
20:11:26 <fungi> russellb: thanks
20:11:28 <ttx> flaper87: russellb uses "'active contributors" as a metric
20:11:42 <ttx> I thiknk under 3 the project is at risk at that should be communicated.
20:12:08 <russellb> so if nothing else, seems to be agreement that "very small" is the most valuable thing
20:12:14 <russellb> so as a next step i'll propose that
20:12:19 <ttx> yeah, maybe we shjould start with this one
20:12:23 <russellb> and then once we work through that, we can revisit "large" (maybe)
20:12:33 <ttx> I blame philosophers and their wine for all the typos I make today
20:12:38 * flaper87 goes to os-zaqar and starts counting ppl
20:12:42 <flaper87> </jk>
20:12:48 <annegentle> my gut says highly active could be valuable, to set expectations for review time perhaps, but won't tell much to people who use or operate a service
20:12:51 <russellb> flaper87: script is already merged iirc
20:12:55 <dhellmann> russellb: very large might be an indication that the project may move pretty slowly, too, so it could be useful
20:13:04 <annegentle> dhellmann: right, my thinking also
20:13:06 <flaper87> russellb: damn :P
20:13:15 <fungi> review tie is actually something we _can_ measure, if that's a useful metric to build a tag around
20:13:19 <fungi> er, review time
20:13:24 <russellb> fungi: that sounds interesting
20:13:29 <ttx> dhellmann: In all cases we need to define the question before we define the tag that would help answer it
20:13:31 <russellb> already measuring that with bitgeria
20:13:48 <dhellmann> ttx: sure, and measuring review time directly is likely better
20:13:50 <russellb> not sure how easy it would be to get that data on demand
20:13:56 <ttx> In the current case, the question is "is the project supported by enough people that it will survive individual accidents
20:14:08 <ttx> like people burning out
20:14:09 <annegentle> #link http://activity.openstack.org/dash/browser/
20:14:29 <fungi> and also reviewstats data, and similar data to that in stackalytics
20:14:35 <flaper87> ok, I think I see the point of using very-small rather than numbers
20:14:38 <flaper87> sorry, took me a bit
20:14:39 <flaper87> :D
20:14:43 <ttx> I feel like if you have less than 5 the project would seriously suffer if they lost one person.
20:14:46 * flaper87 is slow today, ask everyone
20:14:50 <markmcclain> ttx: +1
20:15:04 <ttx> suffer to the point where there could be cascading failure.
20:15:05 <flaper87> ttx: I can say, from my own experience, that's true
20:15:08 <flaper87> :)
20:15:14 <ttx> that is the risk I want the tag to communicate
20:15:15 <dougwig> <=2 is an obvious low limit, because then your cores can't submit code. :)
20:15:25 <russellb> dougwig: ha
20:15:31 <ttx> doesn't mean people won't use the project. Just helps them make their own idea
20:15:39 <flaper87> dougwig: been there too :P
20:15:41 <fungi> for very small team sizes, it's convention to just self-approve or single-core approve changes
20:15:52 <dougwig> flaper87: still there (fwaas and vpnaas).
20:15:58 <flaper87> dougwig: :(
20:15:59 <fungi> so they're not _exactly_ blocked on submitting changes to merge
20:16:20 <markmcclain> there is a component of diversity within low numbers... a team of10 people and 8 work for same company is at serious risk of collapse too if company changes direction.. should probably be considered small
20:16:21 <lifeless> when we say project here
20:16:23 <russellb> dougwig: those imply it might be valuable to call this out on a per-repo basis
20:16:30 <lifeless> do we mean 'code tree' or 'group of people' ?
20:16:30 <ttx> anyway, I think Russell has a way forward
20:16:34 <russellb> this tag right now is focused on teams, so it'd be Neutron overall
20:16:39 <ttx> lifeless: project team
20:16:56 <lifeless> things like openstack/requirements have ill-defined teams IME
20:16:57 <russellb> anyway, yes, i have a way forward
20:17:01 <ttx> although it doesn't have to be a team tag I guess
20:17:09 <lifeless> ttx: could it be a tag team?
20:17:22 <ttx> or a tag team tag ?
20:17:35 <ttx> team tag� ?
20:17:44 <russellb> tagception
20:17:47 <jgriffith> +1 for squared
20:17:50 * flaper87 rofl
20:17:52 <russellb> i think we should move on
20:18:05 <annegentle> wow squared
20:18:08 * annegentle is impressed
20:18:12 <dougwig> russellb: agree on calling out per team somehow (where team may be a larger project subteam).  sorry for delay, at ops meetup.
20:18:37 <fungi> keeping in mind that the tc abandoned the concept of per-repo tags, so i don't see how doing it on a per-repo basis would be feasible
20:18:38 <russellb> dougwig: all good, glad you're there!  would love to hear your feedback after
20:18:55 <russellb> fungi: yar
20:18:57 <ttx> russellb: it's true that it could be an per-repo tag. After all some of the neutron circus things might be supported by only one person
20:19:23 <russellb> ttx: but someone could make the same argument about components of a project in a single repo
20:19:26 <russellb> so not sure we need to worry too muhc
20:19:39 <fungi> seems like at a minimum you'd need to aggregate across all repos for a given deliverable
20:19:40 <ttx> you'll come up with something :)
20:19:42 <russellb> we're not going to capture "maintainers of a feature in a project" at this level
20:19:43 <russellb> yup
20:19:44 <ttx> Let's move on
20:19:58 <ttx> #topic Add new openstack kiloeyes repository
20:19:59 <dhellmann> fungi: ++
20:20:01 <ttx> #link https://review.openstack.org/210175
20:20:13 <ttx> Summary of the feedback is that this is pretty new, so it's way too early to be considered "one of us"
20:20:27 <ttx> It also shows that competition between openstack projects is fine, but only as long as the alternative provides a different value proposition *and* collaboration is not an option
20:20:40 <ttx> here it seems avenues for collaboration have not been explored yet, and the value proposition is unclear
20:20:59 <dhellmann> fwiw, I'm not at all concerned that the API is the same. Compatibility is a feature.
20:21:03 <ttx> so I think asking for it to live a bit in stackforge is not too much too ask
20:21:16 <ttx> dhellmann: agreed
20:21:21 <lifeless> stackforge is going away
20:21:24 <clarkb> ttx: except ya ^
20:21:29 <ttx> lifeless: no it's not.
20:21:29 <jeblair> no its not
20:21:31 <dhellmann> the name is, but not the concept
20:21:39 <lifeless> arg
20:21:53 <lifeless> can we please pick a new name for the concept then ?
20:21:59 <ttx> it's just living in the same git prefix for convenience
20:21:59 <dhellmann> this project can live as an unofficial project
20:22:05 <ttx> "unofficial"
20:22:19 <ttx> I stand corrected
20:22:42 <lifeless> sure, that won't make my brains leak out my ears :)
20:22:56 <ttx> anyone disagreeing with that outcome at this stage ?
20:23:03 <jaypipes> nope
20:23:08 <edleafe> tentforge?
20:23:12 <ttx> (asking them to live a bit before applying for official projetc team ?)
20:23:15 <jaypipes> edleafe: lol
20:23:19 <flaper87> not me, I hope Tong li will also come back with some answers to my qeustions
20:23:20 <annegentle> project can live in any github org it wants to, and observe the OpenStack way, do we need to give them a timeline?
20:23:42 <flaper87> s/not me/no objections from me/
20:23:45 <jaypipes> flaper87: agreed. I'm not going to gang up on the review, but I had almost identical questions as mordred
20:23:57 <annegentle> jaypipes: yeah, me too
20:23:58 <ttx> I like to see a project exist for at least 3 months (and/or doing an initial release) before evaluating if they behave like an openstack project
20:24:05 <dhellmann> annegentle: I think we want to see what happens and let them come back
20:24:10 <annegentle> ttx: initial release might be good
20:24:11 <ttx> (different for horizontal teams)
20:24:17 <annegentle> deliverable maybe?
20:24:27 <annegentle> dhellmann: sounds good
20:24:37 <ttx> ok, I'll write up somthing on the review
20:24:48 <flaper87> I don't just want to see what happens, I want to make sure the get the right guidance too
20:25:02 <ttx> #action ttx to close the kiloeyes request by directing them to unofficial/stackforge space for the time being
20:25:18 <ttx> Moving on...
20:25:21 <jeblair> flaper87: yeah, "talk with monasca and see what comes of that" sounds really good
20:25:37 <ttx> #topic Deprecation policy tags
20:25:39 <flaper87> jeblair: ++
20:25:49 <ttx> First part
20:25:51 <ttx> #link https://review.openstack.org/207467
20:25:55 <ttx> So I updated this to match N+2 deprecation, as several of you requested. I had two questions left
20:26:03 <ttx> First question is do we really want to describe a "never deprecate, always support" model
20:26:14 <ttx> I kind of went back-and-forth on this one, and I tend to think now that saying you won't ever change is not really honest anyway, so the value of asserting that is limited
20:26:16 <russellb> "never" is a long time
20:26:22 <russellb> i don't think it's honest
20:26:25 <dhellmann> agreed
20:26:27 <ttx> There is more value in describing a "common deprecation policy" which sets a minimal standard and then ask projects if they want to assert that they follow (at least) that level
20:26:35 <ttx> Set a baseline, basically
20:26:42 <dhellmann> ++
20:26:45 <russellb> ++
20:26:51 <flaper87> ++
20:26:58 <jgriffith> ++
20:27:00 <ttx> OK, so I'll amend the proposal to remove the "never say never" one
20:27:21 <annegentle> yep
20:27:31 <ttx> #action ttx to amend 207467 to remove will-support-everything-forever variant
20:27:37 <ttx> Second question is... should we (the TC) top-down define what we mean by "deprecation policy baseline" and ask projects to assert if they will follow it... or should we somehow open the definition for ML consensus
20:27:46 <lifeless> does *any* openstack project gurantee forever?
20:27:47 <ttx> One part of me thinks that we should open the discussion, another part of me thinks this needs to be opinionated and not be the lowest common denominator
20:27:56 <ttx> lifeless: I heard Swift claim that
20:28:09 <annegentle> lifeless: I could see it being valuable for CERN and object storage
20:28:10 <jgriffith> ttx: personally I prefer opinionated and just have it
20:28:15 <lifeless> notmyname: ^
20:28:15 <dhellmann> ttx: we have an established community standard here, so I think it's reasonable to start with that. If projects want to propose other models, that is also reasonable.
20:28:15 <markmcclain> ttx: I do have a question about the migration requirement... would an acceptable answer be something is deprecated and has no migration?
20:28:17 <ttx> sometimes in the past. They might have been drunk though
20:28:32 <jgriffith> ttx: I think there's good representation of the projects here on the TC to justify that
20:28:41 <russellb> i don't think the N+2 is least common demoninator, it's a reasonable common policy
20:28:47 <russellb> seems like a good place to start
20:29:01 <ttx> markmcclain: I think you need to provide a way out
20:29:15 <flaper87> That's what we've been following somehow
20:29:28 <flaper87> or at least tried to follow to the best of our capacities
20:29:29 <jgriffith> flaper87: +1
20:29:32 <markmcclain> right but what if we support a feature that just does not make sense in the future?
20:29:33 <ttx> not necessarily a migration tool or anything. Then you need to survey your users and see how much time they need to implement that migration
20:29:44 <jgriffith> flaper87: at least it's been our minimum
20:29:53 <jgriffith> flaper87: reality has been a different story :(
20:29:57 <flaper87> so, lets be opinionated here since N+2 has proven to be a good policy so far
20:29:59 <flaper87> jgriffith: yeah
20:30:01 <flaper87> :(
20:30:14 <ttx> markmcclain: migration can be "that feature was stupid, so you should stop using it" but then survey needs to confirm that everyone agrees it was stupid
20:30:24 <flaper87> and the community is not strange to the concept and policy
20:30:30 <jgriffith> could be more... shouldn't be less
20:30:41 * flaper87 should write longer messages rather than using IRC as if it were whatsapp
20:30:53 <ttx> markmcclain: so I guess the answer to your question is "it depends"
20:31:06 <flaper87> jgriffith: +1
20:31:14 <markmcclain> ttx: ok.. as long as that option should available... concerned that if we require even a minimum migration we never be able to get rid things many would consider mistakes
20:31:33 <jeblair> opinionated++
20:31:43 <ttx> markmcclain: I think what we require is discussion of the proposed migration with the users
20:31:55 <markmcclain> makes sense
20:31:58 <ttx> even if "proposed migration" =~ "stop using it"
20:32:31 <ttx> Let's move to the second change here: config option deprecation policies
20:32:35 <ttx> #link https://review.openstack.org/207584
20:32:43 <ttx> we have two options: we can track it separately from API/feature deprecation policy assertion
20:32:50 <ttx> or we can amend the API/feature tag to make clear config options are part of the user-visible stuff that is covered
20:33:04 <flaper87> ttx: merge them!
20:33:05 <ttx> Personally I think the latter makes more sense and is less confusing. I just don't picture a project would have one but not the other
20:33:17 <ttx> +which
20:33:23 <lifeless> well
20:33:34 <lifeless> I can see placing a different standard of burden on users and operators
20:33:39 <ttx> or rather, not sure we need that granularity
20:33:46 <flaper87> To me, by default, everything the user can interact with should follow the same deprecation path. There may be exceptions, sure, but...
20:33:50 <lifeless> operator churn doesn't affect workload portability, for instance
20:33:55 <ttx> lifeless: that's a good point
20:34:23 <annegentle> I think api compat is much more "watched" by users but that may be from where I sit maintaining API docs
20:34:30 <ttx> so it's more operator-visible features deprecation and users-visible feature deprecation ?
20:34:43 <flaper87> annegentle: no really, just different users.
20:34:56 <annegentle> I see a separation myself -- each user type has different expectations
20:35:07 <flaper87> When it comes to deprecating things, I prefer to consider everyone as users
20:35:15 <flaper87> without any separation
20:35:23 <ttx> flaper87: yeah, I lean towards that too
20:35:28 <annegentle> flaper87: I suppose so, you can avoid consternation for all parties then
20:35:28 <lifeless> ttx: I would assert so yes. Its entirely possible we'll treat everyone the same in future, but that hasn't been the case so far
20:35:49 <annegentle> honestly APIs that are extensible are at the mercy of provider decisions anyway
20:36:13 <ttx> who is with flaper87, who is with lifeless ?
20:36:14 <annegentle> so, same deprecation everywhere
20:36:23 <flaper87> flaper87 flaper87 flaper87 flaper87
20:36:24 <ttx> annegentle is with flaper87
20:36:25 * flaper87 stops that
20:36:31 <lifeless> I don't think our tags should be aspirational :)
20:36:35 <dhellmann> do we actually anticipate different policies at this point?
20:36:42 <lifeless> they should be reflecting useful differences we already have
20:36:53 <ttx> dhellmann: currently we expect all ex-integrated projects to assert both
20:37:08 <ttx> since it was an unofficial rule for them anyway
20:37:09 <dhellmann> ttx: i mean would the timelines be different
20:37:16 <lifeless> right
20:37:17 <annegentle> dhellmann: I was thinking of microversions versus nova.conf
20:37:23 <lifeless> nova API deprecations are yyyyears long
20:37:26 <russellb> 393355
20:37:29 <lifeless> nova.conf deprecations are cycles long
20:37:48 <lifeless> russellb: 11007663
20:37:56 <russellb> :)
20:38:02 <flaper87> lifeless: many times is because people simply forget to remove deprecated things
20:38:09 <flaper87> but I don't know about nova
20:38:13 <flaper87> :P
20:38:29 <ttx> due to their nature, assertions are a bit difficult to tweak once they are defined (you have to confirm any mod with all the projects that asserted the tag, so I'd prefer to get them right
20:38:32 <dhellmann> lifeless: could we agree to put both of those timelines in one tag?
20:39:33 <ttx> I think it's fine to have them both in a single tag. If we need to split it in the future that's easier than the other way around
20:39:43 <lifeless> sure
20:39:48 <annegentle> yep
20:40:01 <ttx> If we realize there is need to track/communicate something more... granular, we can split it then
20:40:16 <ttx> but I'll make sure I talk about operator-facing and enduser-facing stuff
20:40:23 <ttx> in whatever language I come up with
20:40:35 <ttx> so that it's clear that the tag currently asserts both
20:40:42 <flaper87> mmh, I'm still not convinced we should separate them from a deprecation perspective
20:40:49 <flaper87> I guess I'll comment on the review
20:40:50 <ttx> flaper87: we aren't
20:40:55 <flaper87> oh ok
20:40:59 <flaper87> I was confuised by your comment
20:41:03 <flaper87> sorry
20:41:17 <flaper87> confused, even
20:41:26 <ttx> Alright, I'll take care of the big merging
20:41:34 <ttx> next topic
20:41:40 <ttx> #topic Adds and apply guidelines for project and service names
20:41:42 <ttx> #link https://review.openstack.org/201160
20:41:45 <ttx> #link https://review.openstack.org/201670
20:41:49 <ttx> annegentle: are we making progress or is it just a neverending circle of rebases ?
20:42:20 <flaper87> annegentle: I left a "-1 I have a question, I'm sorry it shouldn't be -1 please don't hate me" comment
20:42:32 <annegentle> ttx: Had a breakthrough this week; keep Block Storage
20:42:41 <annegentle> ttx: so the updates have been to support initial caps
20:42:54 <annegentle> ttx: I sense this is where most people want naming to land
20:42:58 <annegentle> flaper87: no worries
20:43:13 <ttx> "Block Storage service" ?
20:43:25 <annegentle> ttx: check
20:43:26 <dhellmann> annegentle: we should talk about auto-generating expansion macros for sphinx from the projects.yaml file
20:43:43 <annegentle> expansion macros?
20:44:13 <russellb> 702487
20:44:17 <russellb> 722228
20:44:28 <russellb> dangit
20:44:41 <annegentle> flaper87: so kiloeyes could be the metric measurement I spose... I don't think release names are "reserved"
20:44:42 <ttx> russellb turned into a WWII number station
20:44:48 * dhellmann thinks russellb is multi-tasking
20:44:49 <annegentle> flaper87: I honestly didn't make the connection for a bit
20:45:10 <flaper87> annegentle: I did, to be honest. When dhellmann mentioned I was like "So, I was not the only one"
20:45:21 <flaper87> annegentle: but I see your point
20:45:32 <lifeless> I'm sorry, I can't read kiloeyes and not think of the 5-eyes spy network... if thats deliberate its most unfortunate
20:46:28 <annegentle> flaper87:  That said, I wonder if we should talk about "reserved words that cannot go into a service name such as copyrighted names?"
20:46:41 <ttx> annegentle: so.. you have all you need to make progress ?
20:46:42 <annegentle> does the list of "don't do" belong in the guidelines?
20:46:47 <annegentle> ttx: I think so
20:47:00 <lifeless> can a name be copyrighted?
20:47:22 <flaper87> annegentle: I believe that list should be there
20:47:23 <annegentle> lifeless: um did I verb a noun?
20:47:25 <ttx> IANAL but I don't think so.
20:47:36 <flaper87> if anything, it'll help us to review names properly
20:47:51 <lifeless> annegentle: I think you hopped intellectual property tracks :)
20:48:00 <annegentle> lifeless: right
20:48:11 <annegentle> flaper87: yeah, and the point of the guidelines is for reviewing
20:48:27 <annegentle> lifeless: was thinking of the Chef/Puppet permissions
20:48:48 <ttx> other questions on that one ?
20:49:51 <ttx> I guess not
20:49:54 <ttx> #topic Workgroup reports
20:49:58 <ttx> * Project team guide
20:50:03 <ttx> I approved the initial version for the missing chapter, so the initial version of the guide is now complete
20:50:09 <ttx> We just need to publish it.
20:50:11 <jeblair> that means i need to publish it
20:50:13 <flaper87> ttx: danke and sorry for the dely
20:50:18 <ttx> jeblair: indeed
20:50:23 <flaper87> jeblair: <.<
20:50:32 * jeblair stops hiding behind flaper87
20:50:43 <flaper87> HA! I knew you were there
20:50:53 <annegentle> nice!! Way to go.
20:50:58 <annegentle> that's really impressive
20:51:23 <ttx> for the curious ones, let me get a URL
20:51:40 <ttx> http://docs-draft.openstack.org/67/194567/3/gate/gate-project-team-guide-docs/7a3af25//doc/build/html/
20:51:58 <ttx> (that's the gate build for the latest merge)
20:52:01 <russellb> dhellmann: ttx yubikey nano.  convenient, except easy to hit when moving laptop around
20:52:37 <fungi> emulates a keyboard, types one-time passwords into your irc client ;)
20:52:41 <ttx> jeblair: any idea when you can work on that ? Or should someone else take the job ?
20:52:54 <jeblair> ttx: can do this week.
20:52:58 <ttx> awesome
20:53:02 <ttx> * Comms
20:53:04 <ttx> annegentle, flaper87: o/
20:53:11 <flaper87> 'sup ?
20:53:12 <annegentle> holla
20:53:23 <russellb> fungi: yeah..
20:53:37 <ttx> annegentle, flaper87 not sure we need another post right now
20:53:38 <annegentle> I got a blog post out, late, last 2 week intervals.
20:53:40 <annegentle> #link http://www.openstack.org/blog/2015/08/technical-committee-highlights-august-11-2015/
20:53:48 <flaper87> I've been lacking in the last couple of weeks. annegentle, sorry about that.
20:53:50 <annegentle> two 2-week intervals
20:53:53 <ttx> given that we didn't have a meeting last week and this week(s is very transitional
20:53:53 <annegentle> flaper87: no worries
20:53:58 <annegentle> ttx: agreed
20:54:07 <ttx> * Next tags
20:54:09 <annegentle> keep getting input on whether those are useful
20:54:12 <ttx> We still are processing the first wave of new tags, so no new things here
20:54:27 <ttx> * Other
20:54:37 <ttx> Two weeks ago we discussed two areas of focus for the rest of the cycle: making progress on the service catalog, and improving cross-project discussion in general
20:54:46 * flaper87 loves ttx's quote on that post
20:54:48 <ttx> How should we make that happen ? Should we form *other* workgroups that would meet outside of the weekly TC meeting ?
20:54:51 <annegentle> flaper87: :)
20:55:06 * ttx needs to work on the successbot
20:55:16 <ttx> An IRC bot to celebrate little successes
20:55:24 <annegentle> ttx: do you think we could move the weekly cross project meeting as an experiment?
20:55:37 <annegentle> ttx: nice
20:55:39 <ttx> annegentle: move to ?
20:55:46 <jeblair> #fail jeblair hasn't made a failbot yet either
20:56:01 <ttx> #success The initial project team guide is now complete !
20:56:11 * flaper87 does the success dance
20:56:25 <annegentle> ttx: earlier in the day -- if the history is that we held it after the TC meeting for a reason (Chair responsibilities? The original timing escapes me) could we try another day/time?
20:56:45 <annegentle> ttx: I know, I know, it sucks to move meetings
20:56:58 <flaper87> I'd be happy to have it moved, really
20:57:09 <flaper87> but if that ends up in fewer CPL attending, then no.
20:57:09 <ttx> annegentle: it's worth having the discussion I guess. You could start it on the ML. We could certainly rotate
20:57:22 <ttx> any time before would be very APAC-unfriendly
20:57:32 <ttx> the current one already kinda is
20:57:38 <flaper87> right
20:57:53 <annegentle> right
20:57:58 <annegentle> ttx: ok
20:58:05 <ttx> the current timing opts to be a pain from Russia to China
20:58:07 <flaper87> I've a quick Open Discussion topic
20:58:12 <ttx> #topic Open discussion
20:58:28 <annegentle> #acton annegentle to bring cross-project meeting time to -dev mailing list
20:58:45 <flaper87> So, I've been contacted by Cindy Pallares. She's working with a submcmittee to improve OpenSTack's CoC
20:58:50 <annegentle> I had a question about extra ATC, they don't seem to be publishing to project pages on governance.openstack any more
20:59:06 <flaper87> One thing she asked me is how we can help enforcing it and who, from the governance side, can help with that
20:59:08 <ttx> I just want something to emerge from our discussion on priorities at the last meeting. Saying we need to complete the service catalog changes is one thing, doing it would be better
20:59:15 <flaper87> I'll invite her next week to share what they are doing
20:59:23 <flaper87> where they are at, etc.
20:59:24 <annegentle> See http://governance.openstack.org/reference/projects/keystone.html for an example
20:59:34 <flaper87> That way we can provide some guidance/support from our side
20:59:37 <ttx> but I have my hands full with various other workgroups and TC initiatives, so I can't lead either
20:59:51 <flaper87> turns out our CoC is not good enough
20:59:54 <annegentle> flaper87: I thought there was an ombudsman group on the board that provided governance for CoC?
20:59:56 <flaper87> #link https://www.openstack.org/legal/community-code-of-conduct/
21:00:19 <ttx> flaper87: probably just a bug
21:00:27 <flaper87> annegentle: I believe she's working with them as well
21:00:28 <EmilienM> it's crossproject meeting time
21:00:28 <flaper87> ttx: LOL
21:00:30 <annegentle> ttx: agreed on the doing it...
21:00:35 <flaper87> EmilienM: 1 minute
21:00:36 <flaper87> :P
21:00:39 <annegentle> :)
21:00:44 <flaper87> ttx: just saying, lets give her some time next week
21:00:54 <ttx> flaper87: sure, add it to the agenda this week
21:00:55 <flaper87> It should be good to support the effort from our side
21:01:01 <markmcclain> ++
21:01:09 <ttx> and that concludes our meeting
21:01:10 <flaper87> would*
21:01:12 <flaper87> :P
21:01:13 <ttx> #endmeeting