20:01:04 <ttx> #startmeeting tc
20:01:07 <openstack> Meeting started Tue Mar 17 20:01:04 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:10 <openstack> The meeting name has been set to 'tc'
20:01:12 <mordred> o/
20:01:15 <markmcclain> o/
20:01:17 <ttx> Our agenda for today:
20:01:22 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:32 <mikal> Hi
20:01:35 <ttx> #topic (Final) Final rubberstamping of "Cross-Project spec to eliminate SQL Schema Downgrades"
20:01:42 <ttx> #link https://review.openstack.org/#/c/152337/
20:01:50 <ttx> That was pending on the Ops Meetup and we got a clear go-ahead there
20:02:00 <ttx> So unless someone violently opposes now, I'll consider there is consensus on this one and final-approve it now
20:02:18 <sdague> +1 for final approve
20:02:21 <mordred> ttx: what if I'm just violent?
20:02:33 <devananda> o/
20:02:45 <ttx> mordred: you do have a history of violence
20:03:01 <russellb> glad this is a virtual meeting then
20:03:11 * dhellmann sits back from the screen
20:03:17 <ttx> last 10 seconds to register your +2 if you want it in
20:03:34 <ttx> approved
20:03:41 <ttx> #topic Tags
20:03:47 <ttx> * Definition of the release:* tags (https://review.openstack.org/157322)
20:03:59 <ttx> Looks like there is no opposition anymore on those, so it would be great if we could gather some approvals and move on
20:04:05 <ttx> dhellmann and devananda +1ed an earlier version of the proposal
20:04:46 <devananda> ttx: you removed the deprecation section?
20:04:59 <ttx> devananda: yes, since there were no deprecation rules
20:05:07 <ttx> and my wording there was confusing anne
20:05:14 <devananda> *nod*
20:05:19 * devananda reapplies +1
20:05:42 * dhellmann ditto
20:05:48 <ttx> While you vote, moving on to next topic
20:05:52 <ttx> * Next WIP tags (http://ttx.re/facets-of-the-integrated-release.html) (https://review.openstack.org/163851) (https://review.openstack.org/163236)
20:05:59 <ttx> There are several other tags being worked on
20:06:08 <ttx> russellb works on a "team:diverse-affiliation" tag at https://review.openstack.org/163851
20:06:25 <ttx> russellb: how is that going ?
20:06:43 <russellb> fine, the feedback so far is positive, but just from a few folks
20:06:58 <russellb> there's a few things to integrate, including your suggestion of adding a core reviewer diversity requirement
20:06:59 <ttx> need more reviews before proposing final patchset ?
20:07:13 <devananda> russellb: core diversity ++
20:07:17 <sdague> russellb: have you considered categorizing git trees instead of program groups?
20:07:27 <russellb> sdague: that was another thing ttx brought up
20:07:33 <ttx> sdague: I can see value in both approaches
20:07:43 <russellb> since tags apply to projects ... i was proposing the tag is based on the overall diversity of the repos the team looks after
20:07:56 <jeblair> has anyone run the heuristic on existing key projects?
20:08:09 <ttx> jeblair: it's in the patch iirc
20:08:10 <jgriffith> russellb: that seems valid to me
20:08:10 <russellb> jeblair: i did a pass in the existing proposal, yeah
20:08:17 <russellb> not using proposed changes (like core team)
20:08:26 <russellb> i scripted it after doing it manually once, heh
20:08:29 <jgriffith> russellb: I like it by the way, even moreso with the core add
20:08:30 <jeblair> hah, it was _just_ below the point to which i had scrolled, sorry.
20:08:30 <devananda> speaking for ironic, we have several repos in the project that have very different contributor diversity than the main server tree, or the group taken as a whole
20:08:33 <ttx> but then it's also about fragility, and a repo which has just one company looking after it is more brittle
20:08:58 <russellb> ttx: but a less active repo would be easier to save
20:09:07 <jgriffith> ttx: I'm mixed on what i think the tag "means" but regardless
20:09:08 <russellb> so overall diversity a better indication of overall health, i think
20:09:14 <ttx> If you take a project team like iNfra, projects under it have a very different story
20:09:23 <russellb> ttx: yes, that's a good counter example
20:09:27 <russellb> not sure that's the case for any other team
20:09:32 <jgriffith> russellb: I don't know if I'd agree, kinda think that should be left to other stats
20:09:42 <devananda> I would suspect that oslo also has less diversity within some of the individual libraries
20:09:45 <sdague> ttx: right, echoing a thing vishy said previously, oslo.messaging is a good instance of something which is very important but seems to not have many folks engaged on it, and I think that gets hidden if we lump all of oslo together
20:09:51 <russellb> jgriffith: not embedding that into the tag definition
20:09:51 <dhellmann> russellb: this is an example of a tag that looks useful, but is so easy to find from stackalytics that I wonder if we actually need to keep track of it manually?
20:10:19 <russellb> dhellmann: we could expand that to abandoning this entire catalog
20:10:26 <dhellmann> russellb: now you're talking
20:10:28 <ttx> dhellmann: it's not that easy to find. If you combine commits/contributors/core stats
20:10:29 <russellb> either there's value in making it easier to figure all this out
20:10:35 <russellb> or not
20:10:37 <russellb> i think there is
20:10:53 <zaneb> I think projects themselves are capable of handling non-diversity issues on their own repos (in the worst case by voting them off the island)
20:10:58 <russellb> if people want to abandon the whole catalog, then i would question whether the proposed governance change is the right direction at all
20:11:02 <russellb> but anyway ...
20:11:03 <ttx> dhellmann: but then I expect some tags to be generated automatically (something like the requirements bot)
20:11:04 <devananda> russellb: it's also prone to rapid fluctuations which may not reflect the project's usefulness, particularly in smaller trees
20:11:06 <dhellmann> russellb: so let's build a page that pulls the data live, and let that be the info we show. Why track it manually?
20:11:08 <fungi> ttx: russellb: keep in mind that all the openstack-infra projects' core groups have infra-core included in them
20:11:13 <fungi> which brings back the diversity
20:11:14 <zaneb> so it makes more sense to me for the TC to be looking at projects as a whole
20:11:16 <russellb> dhellmann: in the proposal i said it should be automated
20:11:20 <ttx> fungi: I know some projects that this won't save
20:11:27 <dhellmann> russellb: ok, I haven't hit the bottom yet, sorry
20:11:37 <devananda> russellb: I think diversity of core team is a useful tag, and diversity of reviews and/or contribution to a project group overall is also useful
20:11:45 <russellb> devananda: separate?
20:12:05 <devananda> russellb: as a contributor, the "core diversity" tells me how likely my contributions are to be respected // or inversely if t's just one company running the show
20:12:13 <ttx> Now that I've spiked your interest, I think the discussion should move to the review
20:12:14 <jeblair> russellb, dhellmann: i think it is important to _surface_ this information; i agree with dhellman that it seems we are moving information from one system of record to another.
20:12:17 <devananda> russellb: as an operator, it tells me how likely this project is to die if one company pulls out
20:12:22 <ttx> since we have a lot of ground to cover in meeting today
20:12:33 <dhellmann> jeblair: you said it better than I did
20:12:34 <mordred> and as a consumer, how likely I'm going to be in trouble if obe company makes a shift in intent
20:12:35 <russellb> ttx: sounds good
20:12:35 <devananda> russellb: but breaking down to individual git trees is far less useful to me in either csae
20:12:36 <mordred> one
20:12:38 <sdague> devananda: more than the review / contrib stats?
20:12:39 <mordred> devananda: yeah
20:12:50 * mordred lets devananda speak more
20:12:53 <ttx> please continue discussion on the review
20:12:56 <lifeless> devananda: it doesn't really... it just gives a data point
20:12:57 <sdague> the actually core team membership seems less relevant to me than core team actions
20:13:04 <devananda> while I can get that info from the various authoritative sources if i really want, eg. gerrit or git log
20:13:10 <ttx> devenanda works on role tags, which are a bit of an opinionated taxonomy
20:13:14 <ttx> that said from the feedback at the Ops Meetup, those are badly needed
20:13:18 <devananda> I do think having documentation of it is helpful toour downstream consumers
20:13:36 <ttx> There is room for other tags to be worked on
20:13:38 <devananda> sdague: also, that. glance is a good example ...
20:13:43 <ttx> For those who want to help, I described the various facets of the integrated-release comboconcept that we might want to independently describe as tags at
20:13:47 <ttx> #link http://ttx.re/facets-of-the-integrated-release.html
20:13:48 <mordred> I think what the TC woudl be vetting in this case is that the automated tag does reflect the data it says it reflects, yeah?
20:13:48 <russellb> i'm in favor of opinionated tags personally :)
20:13:53 <ttx> - Release model is now covered
20:13:57 <mordred> russellb: ++
20:13:58 <ttx> - Co-gating is likely to emerge from sdague's work at https://review.openstack.org/#/c/150653/
20:14:02 <russellb> being opinionated is where we can actually add value
20:14:12 <devananda> ttx: I was hoping to get back to that proposal more last week, but have been consumed by kilo-3 // feature freeze
20:14:15 <ttx> - Supported-by should be proposed by all horizontal teams, to clarify what they actually support (defaults to "all")
20:14:16 <russellb> if we're not opinionated *at all*, i don't know what our point of existence is anymore
20:14:21 <ttx> russellb: ++
20:14:22 <devananda> russellb: ++
20:14:32 <ttx> - Stability should probably be expressed as opt-in feature/API deprecation contracts, I plan to work on that unless someone beats me to it
20:14:36 <dhellmann> russellb: ++
20:14:38 <ttx> - For maturity, we now have an ops workgroup planning to work on that
20:14:56 <ttx> So feel free to help in any of those areas
20:14:58 * russellb is very happy to see ++ on that, wasn't sure honestly ...
20:15:06 <sparkycollier> existentialist russellb
20:15:07 <russellb> ttx: good write-up
20:15:13 <ttx> russellb: but then jay is not around
20:15:15 * mordred hands russellb a fluffy llama
20:15:30 <devananda> if anyone wants to take a stab at adding more role / usecase tags on top of my proposal, I wont object. otherwise, I will try to get to it in the next week
20:15:41 <ttx> Which leads us to the next question
20:15:45 <ttx> * Moving tags to a separate project-catalog repository
20:15:56 <ttx> Once we have bootstrapped this framework, I think it should move to its own repository and be maintained by a specific team of people
20:16:01 <mikal> What is the value in that?
20:16:02 <russellb> i'm torn on this
20:16:02 <ttx> A team interested in documenting project attributes
20:16:09 <ttx> Because this is closer to documentation/reporting than to governance
20:16:12 <mikal> Isn't that the TC?
20:16:14 <russellb> partly because having it all together is convenient
20:16:20 <russellb> and also because of the point i just made about being opinionated
20:16:26 <russellb> and the importance of still being opinionated at times
20:16:33 <russellb> it's not just a trivial task to pass off
20:16:43 <mikal> I agree
20:16:46 <russellb> if it is, again, our value is pretty minimal
20:16:47 <ttx> well, that's about "stepping out of the way" I guess, and focusing on more critical tasks
20:16:50 <dhellmann> most of the tags proposed so far are objective enough that there's no "opinion" involved
20:16:52 <mikal> But also, its super important, so we should be shy about delegating it
20:17:16 <dhellmann> we should keep things like whether we consider a project official, and whether we want the board to let them use the trademark. The rest of this is just "tell me what openstack is" documentation.
20:17:20 <devananda> i did a bunch of thinking about this when I wrote up the roles / use cases tags ...
20:17:21 <mikal> ttx: there's nothing stopping a community member from proposing a tag now...
20:17:24 <russellb> it kind of comes back to, what tags actually exist
20:17:29 <mikal> ttx: so how are we "in the way" at the moment?
20:17:36 <jbryce> ttx: i would think that even if the tc coordinates the efforts, they can still allow tags and input from other groups like ops/user committtee
20:17:44 <ttx> mikal: I fear we spend all of our time rubberstamping stuff
20:17:47 <devananda> I think by defining the set of tags ,what the criteria are, we're creating a policy
20:17:50 <devananda> that's our governance
20:18:07 <dhellmann> devananda: so we govern through taxonomy? :-(
20:18:10 <jeblair> so maybe we should keep it in governance until we find we're just rubberstamping all the time and deal with it then
20:18:10 <ttx> we'll spend a lot of time approving tag changes
20:18:14 <devananda> some of the tags are just informational, and could be delegated to automation
20:18:22 <ttx> jeblair: good point
20:18:23 <devananda> some will be opt-in, and the PTLs can self apply them
20:18:30 <jeblair> right now at least, i think the discussion around them is still useful
20:18:42 <devananda> and some may well be set by other teams (like docs-supported, required-by-nova, or what ever)
20:18:54 <sdague> yeh, I'm fine with keeping them in tree for now. Later migration can always be contemplated
20:18:55 <russellb> could differentiate between tags that are obvious and don't need a full vote, vs. ones that are opinionated and need actual discussion and vote
20:18:57 <ttx> I heard some feedback that nobody should touch tags because it's a TC thing
20:19:00 <dhellmann> jeblair: we have several cross project specs that this group needs to approve. We're spending way way more time on tags than those technical issues.
20:19:07 <devananda> the TC is still the arbiter if three's a disagreement, but we dont need to apply every single tag with a majority vote
20:19:09 <ttx> so we need to better communicate how open the process is
20:19:13 <anteaya> there are some decisions asked of project-config reviewers that belong in the tc
20:19:33 <anteaya> as a project-config reviewer I am for keeping these decisions with the tc, re: tags
20:19:38 <jeblair> dhellmann: yeah, i could see us getting there; i'm just not sure we're there yet
20:19:48 <ttx> It may be too early to spin it off
20:19:55 <russellb> we haven't approved any tags yet :)
20:20:06 <ttx> russellb: I can fix that now
20:20:06 <russellb> so yeah, i think revisiting in a few months would be good
20:20:08 <mordred> russellb: yup. we're approving too many of them
20:20:15 <mordred> russellb: :)
20:20:26 <devananda> ttx: in addition to better communication, I think we need to accept that there is a 6 to 12 month communication lag
20:20:26 <russellb> mordred: not sure what you mean
20:20:39 <mordred> russellb: me either- I was going for a droll joke, but it did not work
20:20:45 <russellb> mordred: ok!
20:20:50 <dhellmann> maybe when we're together in person someone will be able to explain why we're so excited about tags. They still feel like mostly a waste of this group's time.
20:21:05 <dhellmann> but I'll stop harping on it, I guess
20:21:13 <devananda> ttx: short of a keynote at the summit (or something similarly monumental) it's going to take a LONG TIME for these sorts of changes to trickle down to all the operators, driver contributors, etc
20:21:16 <russellb> and *that* is why i'm hesitant to approve projects
20:21:22 <russellb> we disagree on such fundamental things about this governance change
20:21:32 <devananda> ttx: so the kind of participation that I think we need for this to work will not happen overnight
20:21:32 <russellb> that i'm not convinced anymore we're in the right direction at all
20:21:43 <jbryce> devananda: come to day 2 in vancouver = )
20:21:54 <devananda> jbryce: ;)
20:21:57 <mordred> russellb: I thnk the two are completely orthogonal - but that might be derailing this
20:22:15 <ttx> OK, let's keep it in governance for the time being
20:22:18 <mikal> russellb: so do we need a plan to get in sync again? If so, what is it?
20:22:19 <jbryce> and day 1 actually as well. but we have to have something understandable to present
20:22:47 <russellb> mikal: i don't know ... maybe we should all write a bunch of blog posts :-p
20:22:53 <mikal> russellb: sigh
20:22:54 <ttx> NOOOO not again
20:22:56 <devananda> russellb: that's definitely the right thing ....
20:23:10 <russellb> ttx just wrote one!
20:23:13 <mordred> I think maybe big tent was the wrong choice, and it should have been big yurt
20:23:17 <devananda> so, really, perhaps an etherpad where we just get a sense of who agrees/disagrees on what
20:23:23 <lifeless> communication is important... not sure that a mass of blog posts is that
20:23:30 <jbryce> is there a single authoritative document that explains what the new structure is?
20:23:33 <ttx> devananda: I'm tryin g to keep tabs on that
20:23:34 <sparkycollier> +1 to big yurt
20:23:34 <russellb> lifeless: right, i was mostly kidding
20:23:39 <devananda> then we set up some higher bandwidth disucssions to facilitate sorting that out
20:23:40 <ttx> jbryce: yes
20:23:59 <jeblair> http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html
20:24:00 <russellb> we got some negative feedback about high bandwidth sessions we had on this before
20:24:01 <ttx> devananda: the spin-off disucssion was triggered with several discussions I had with dhellmann
20:24:03 <anteaya> devananda: I think the question is what higher bandwidth
20:24:04 <devananda> we did some video calls at the beginning of the big tent discussions
20:24:09 <russellb> fwiw
20:24:13 <russellb> or i did anyway
20:24:17 <lifeless> russellb: clique concerns?
20:24:20 <russellb> yes
20:24:22 <devananda> russellb: I'm aware of that, and I can't for the life of me understand why
20:24:28 <russellb> and the fact that they weren't open, just etherpad notes
20:24:31 <dhellmann> it's a bit sparse, but here's a skeleton "product guide" repo I set up while talking with ttx about spinning this stuff out: https://github.com/dhellmann/openstack-product-catalog/tree/master/doc/source
20:25:02 <devananda> I mean, people talk to each other. some times the medium gets in the way of actually sharing understanding and we need to use a different medium
20:25:06 <anteaya> the problem is we are so afraid of being accused of not open we can't get teh time to talk and understand each other
20:25:08 <dhellmann> russellb: we might have to live with people seeing documentation after the fact if we want to resolve some of these bigger questions
20:25:27 <mikal> Could we lock ourselves in a room before the summit and talk it through?
20:25:33 <russellb> don'
20:25:35 <dhellmann> mikal: ++
20:25:37 <anteaya> there is so much noise we can't hear each other, or even ourselves
20:25:37 <mikal> The morning before the board meeting perhaps?
20:25:37 <devananda> if I have to fly somewhere to talk with someone in person, because we just can't sort it out on the phone .... I mean, that's lame, but I do it.
20:25:39 <russellb> i don't want to wait until summit
20:25:44 <jbryce> ttx: thanks. i’ve actually followed these changes and that is another link i hadn’t seen yet. i think that’s really a big piece of the confusion out there is people have gotten bits and pieces from a mailing list thread here, an irc log there, a blog post on the other side
20:25:45 <russellb> that's such a bad habit in openstack, heh
20:25:52 <devananda> I think we can't wait until the summit, frankly
20:26:02 <devananda> because we need clear signalling (eg, to jbryce ) before then
20:26:20 <ttx> jbryce: the blog posts were all referencing the reference document (which was the spec)
20:26:26 <Rockyg> jbryce:  ++
20:26:37 <ttx> you should click links more :)
20:27:01 <Rockyg> tfm links
20:27:15 <ttx> So, about syncing... The thing is, every time I speak with someone supposedly disagreeing, they are actually not disagreeing
20:27:29 <ttx> so it's more unfamiliarity than disagreement
20:27:33 <mikal> ttx: that's an indicator we need to talk more I think
20:27:36 <mordred> I agree with that
20:27:39 <mordred> I have had the same experience
20:27:55 <ttx> mikal: I think you should move to Europe
20:28:02 <devananda> dhellmann: when we talked about a week ago, IIRC the only thing you disagreed on was where the tags are hosted, which boiled down to whether or not the TC should be governing them
20:28:10 <devananda> or s/governing/required to vote on/
20:28:11 <russellb> i also worry that if we have a hard time understanding things among each other, good luck to the rest of the world
20:28:13 <Rockyg> Don't talk.  Post the doc on the front webpage of os.org
20:28:22 <jbryce> russellb: exactly
20:28:23 <mordred> Rockyg: we don't control that
20:28:33 <zaneb> devananda: what has actually changed? there were a bunch of projects (including user-facing ReST APIs) that weren't incubated of integrated in the openstack/ namespace before, and soon there'll be a few more...
20:28:36 <dhellmann> devananda: so far, 99% of the tags I have seen proposed are characteristics I would expect a product documentation team to be using to describe products. We're not a product documentation team.
20:28:45 <Rockyg> mordred:  if we asked nicely?
20:29:02 <dhellmann> devananda: the only 2 tags so far that don't meet that criteria are "is it an official project" and "should it use the trademark"
20:29:03 <zaneb> likewise, we had a bunch of integrated projects before, and now we have an integrated tag. no change (yet)
20:29:05 <russellb> dhellmann: i went after low hanging fruit, since it was proposed as a base requirement to start with ...
20:29:20 <ttx> The only clear disagreement I heard was Doug thinking we the TC should get out of the product description business
20:29:31 <ttx> Any other disagreement ?
20:29:32 <dhellmann> russellb: right, and I think we all got tied up in the fact that Jay's blog post talked about tags and governance changes, but I don't think they're actually related at all
20:29:36 <anteaya> Rockyg: https://bugs.launchpad.net/openstack-org
20:29:51 <russellb> dhellmann: i think some think it's related and others don't
20:29:56 <Rockyg> anteaya:  Thanks;-)
20:30:07 <russellb> depends if you think tags are purely objective, or whether they're a means of providing more detailed opinions and guidance as well
20:30:09 <russellb> i think..
20:30:15 <ttx> dhellmann: and the spec clearly presents them as separate efforts
20:30:20 * russellb tied them together
20:30:26 <jbryce> Rockyg mordred: we have been working on an update plan for openstack.org to cover these changes, but to be honest it’s been hard to even wrap my head around it and get a fully consistent description of it from the people i’ve talked to.
20:30:30 <russellb> ttx: 2 points in the same spec though
20:30:33 <ttx> We had a problem and took two efforts to solve it
20:30:42 <ttx> (expand and focus)
20:30:48 <dhellmann> russellb: sure, the guidance stuff is what I mean by product documentation though
20:31:17 <dhellmann> ttx: I think I'm the only one who feels this way, and so I'm just going to shut up and let you get on with the meeting.
20:31:30 <russellb> dhellmann: i feel like we're elected to be the ones to have opinions on behalf of openstack tech community, and communicate those
20:31:32 <ttx> yay, no more disagreement, just a bit of confusion.
20:31:42 <jgriffith> russellb: I'd agree with that
20:31:48 <devananda> dhellmann: I'm probably misunderstanding you, because it sounds like you're saying the TC is not responsible for providing guidance about the projects that make up OpenStack...
20:31:50 <anteaya> russellb: me too
20:31:54 <Rockyg> sounds like a doc sprint is needed to thrash out the two separate efforts, how they interact, and the vision thing, along with the spec.
20:31:54 <devananda> russellb: yup
20:31:58 <zaneb> I think tags should be about guiding the project as to what the TC expects of them, rather than a 1-bit replacement for documentation
20:32:12 <devananda> zaneb: yes
20:32:15 <russellb> and to me, the tags thing was the new framework we were setting up for us to communicate those opinions
20:32:19 <dhellmann> devananda: You are. We decide what projects are "in" the tent. After that, the entire community is responsible for properly documenting what we're building.
20:32:33 <ttx> OK everyone, I'd like us to focus back on the agenda
20:32:39 * russellb sits down
20:32:41 <dhellmann> zaneb: OK, that's not how they're being presented.
20:32:43 <devananda> so that's what I meant earlier by we govern through creating tags and delegating the application of tags to the appropriate trusted / responsible parties
20:32:43 <ttx> and move to the next (related) topic
20:32:45 <jgriffith> sigh.. I was going to say something profound
20:32:52 <ttx> jgriffith: bad timing
20:32:53 * annegentle is here, listening. Nothing profound about docs here.
20:32:54 * russellb takes it to a blog post
20:32:55 <russellb> :-p
20:32:57 <jgriffith> ttx: :)
20:32:58 <devananda> russellb: heh
20:33:00 <sparkycollier> +1 to devananda
20:33:11 <ttx> +1 to devananda too
20:33:12 * devananda sits down as well, lets ttx continue with agenda
20:33:36 <ttx> (to end this discussion, I really think we are not very far away, and just need to talk more about it)
20:33:45 <ttx> far from each other I mean
20:33:47 <ttx> #topic New project teams additions
20:33:55 <ttx> * Freezing or slowly considering (http://lists.openstack.org/pipermail/openstack-dev/2015-March/058689.html)
20:34:22 <ttx> So I think it's pretty critical *not* to freeze the process, otherwise we won't make any progress in the next 3 months
20:34:34 <ttx> Looks like most people on the thread agreed to slowly consider new project team additions, rather than freezing
20:34:40 <ttx> We should go slowly enough so that we can refine rules as we go
20:34:47 <russellb> i think we're making progress for the sake of making progress, even though there's a lot of confusion and potentially disagreement
20:34:58 <ttx> on the project team addition side ?
20:35:03 <russellb> yes
20:35:16 <ttx> what disagreement is there there ?
20:35:26 <jgriffith> russellb: I'd kind of agree, I don't see what it matters if new projects sit for a few months or not
20:35:31 <russellb> but it goes back to different views on what the tag part of the spec means, how important it is, what things are included
20:35:32 * ttx doesn't see any patch proposed to the new-projects-requirements
20:35:38 * russellb sighs
20:35:48 <ttx> That said, it's worth noting that the requirements as stated are base requirements we all agree on
20:35:49 <russellb> i think we've half implemented our spec is all
20:35:52 <jeblair> i think evaluating the new additions is helping us see the system at work and understand what works and where we have disagreement.  therefore, i think making slow progress should be our goal for the next little while.
20:36:01 <ttx> but we always retain our ability to arbitrarily reject projects -- that is also why we were elected: to make the right call when needed
20:36:07 <jbryce> russellb: i agree that there’s some confusion and when i’ve watched the last few tc meetings it seems like different people have a different opinion of what has been agreed to
20:36:16 <russellb> jbryce: that's my objection, yes
20:36:28 <russellb> i wish i had a clear way to fix it up
20:36:32 <jbryce> i also think working through it slowly to bootstrap it could provide concrete examples of what needs to be answered
20:36:37 <russellb> maybe a clear date to tidy things up by
20:36:58 <mordred> I disagree with delaying project additions
20:37:02 <mordred> categorically
20:37:04 <devananda> russellb: "half implemented our spec" << yup, I agree
20:37:23 <ttx> russellb: I think the spec is fully implemented. We added criteria for approving projects, and created a framework to describve projects
20:37:28 <sdague> I'd agree with jeblair, in bound project consideration is kind of unit tests for whatever we're doing. I'm fine with going slow, but it seems like useful data.
20:37:32 <devananda> russellb: but folks are still looking to us the TC to bless projects, despite some confusion about this whole big tent thing
20:37:36 <russellb> ttx: see, there's disagreement after all :)
20:37:46 <mordred> I think the only way we can get past people expecting us to bless projects
20:37:48 <mordred> is to open the door
20:37:51 <mordred> and stop blessing projects
20:37:54 <devananda> if we add one or two projects, that's going to increase confusion, I think, because it loks like we will have blessed them
20:37:56 <ttx> russellb: the spec was never about "finishing tags"
20:38:09 <ttx> russellb: heck, I know. I wrote it
20:38:16 <russellb> we can't agree on low hanging fruit, much less things that are actually more useful original bits of information
20:38:17 <jeblair> i think we should add 1, then 2, then 3, then a lot.
20:38:21 <russellb> (tags that is)
20:38:25 <mordred> by applying the criteria very broadly that we have agreed on
20:38:27 <ttx> It was about setting criteria for new projects and set up a tag framework
20:38:27 <devananda> OTOH if we rip off the bandaid and let in everything that meets our least common denominator,  it's a very clear what we've just done
20:38:29 <dhellmann> mordred: we are bound by the bylaws to bless projects for trademark use. Do you mean to apply that rule to that level of blessing as well?
20:38:37 <jbryce> jeblair: yeah i kind of agree
20:38:38 <russellb> in any case, i'll abstain on new projects, not -1
20:38:44 * jogo finds it ironic we are weakening the openstack community software trademark while pushing hard for better commercial trademark usage, defcore
20:39:16 <mordred> dhellmann: I do not think that letting a project "in" carries any implication about the use of the trademark - that's what defcore is working on
20:39:36 <dhellmann> mordred: we are supposed to propose to the defcore committee which projects they consider, though, and so we're still a gatekeeper in that process.
20:39:41 <dhellmann> we're just moving the gate
20:39:43 <mordred> dhellmann: nor do I think it automatically confers in any of the documents I've see a suggestion from us to defcore or the board that we recommend these projects for trademark use
20:39:49 <russellb> the "tc approved release"
20:40:11 <mordred> I believe us "approving" projects has no bearing on that whatsoever
20:40:12 <devananda> that said, i would like us to have a tag system in place before we rip off the bandaid.
20:40:18 <mordred> I do not
20:40:18 <dhellmann> mordred: I'll have to find it, but I do remember that being our responsibility to suggest which of *all* of the projects should be included in any trademark policy.
20:40:19 <russellb> is the base they work from, in the updatedd bylaws
20:40:22 <russellb> iirc
20:40:25 <ttx> OK, let's focus on agenda again -- do we need a vote between freezing and slowly considering ?
20:40:29 <mordred> I do not want to wait for a tag system for us to implement the system we have already approved
20:40:36 <mordred> that is just us being policy wankers
20:40:37 <devananda> mordred: i do not mean that we should have all the tags IN that system
20:40:39 <mikal> ttx: I think a vote is a good idea
20:40:41 <mordred> let's get it done
20:40:44 <mordred> and do something
20:40:44 <russellb> i think a tag system is useless without concrete things we've agreed on that fit int he system
20:40:45 <mordred> for once
20:41:00 <mordred> I mean - we already voted on thnis
20:41:02 <mordred> this
20:41:09 <ttx> how does #startvote work again
20:41:12 <mordred> how many more times do we need to vote on voting on voting on things
20:41:13 <annegentle> I'm fine with test and iterate. If that's "slow" then that's okay.
20:41:14 <mikal> Heh
20:41:14 <ttx> #startvote
20:41:14 <openstack> Unable to parse vote topic and options.
20:41:28 <zaneb> devananda: why do we need a tag system _before_ admitting new projects? new projects would join without the integrated-release tag, so they start at the bottom
20:41:32 <jeblair> ttx: http://ci.openstack.org/irc.html#voting
20:41:33 <morganfainberg> ttx, #startvote <question>? option1,option2,etc
20:41:37 <ttx> #startvote Freezing or slowly considering ? freezing, slowly, abstain
20:41:38 <openstack> Begin voting on: Freezing or slowly considering ? Valid vote options are freezing, slowly, abstain.
20:41:39 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:41:46 <ttx> #vote slowly
20:41:47 <mikal> slowly
20:41:48 <mordred> #vote slowly
20:41:48 <russellb> #vote freezing
20:41:51 <mikal> #vote slowly
20:41:52 <dhellmann> #vote slowly
20:41:52 <jgriffith> Can't we just focus and start with a well defined base
20:41:52 <jeblair> #vote slowly
20:41:56 <sdague> #vote slowly
20:41:56 <markmcclain> #vote slowly
20:41:56 <jgriffith> grr
20:41:59 <devananda> #vote slowly
20:42:01 <russellb> yay
20:42:07 <ttx> 30 more seconds
20:42:13 <jgriffith> #vote abstain
20:42:31 <devananda> ttx: you didn't have a rip off the bandaid option :)
20:42:34 * jbryce finds something funny about everyone “voting slowly”
20:42:37 <ttx> #endvote
20:42:38 <openstack> Voted on "Freezing or slowly considering ?" Results are
20:42:39 <openstack> freezing (1): russellb
20:42:40 <openstack> abstain (1): jgriffith
20:42:40 <mordred> jbryce: :)
20:42:41 <openstack> slowly (8): ttx, devananda, jeblair, sdague, mikal, mordred, dhellmann, markmcclain
20:42:45 <jgriffith> jbryce: LOL
20:42:45 <ttx> OK, let's proceed
20:42:56 <ttx> I'd like us to spend some of the remaining time in the meeting to discuss the next addition in the pipe:
20:43:08 <ttx> * Add OpenStackClient project (https://review.openstack.org/161885)
20:43:15 <ttx> Last week we delayed final consideration of the Magnum addition to March 24 meeting
20:43:27 <ttx> OpenStackClient is imho "an OpenStack project" and "one of us"
20:43:28 <zaneb> I'd suggest we set an application deadline, consider all projects who apply before the deadline as a batch, and then rip off the bandaid in one go
20:43:34 <mordred> ttx: ++
20:43:38 <ttx> And being "officially part of OpenStack" might give it a nice contributors push
20:43:41 <ttx> So I'm +1 on it
20:43:52 <devananda> ttx: +1
20:43:54 <dhellmann> yeah, this project has been around for a while now and although it's small the contributor base is diverse
20:43:56 <mordred> it's also had part of itself in openstack/ since before any of this system was in place :)
20:44:15 <ttx> I think if we disagree on that one, then YES we have a pretty differing view of what we are trtying to achieve here
20:44:56 <annegentle> I would love to see a contributor uptick there.
20:45:06 <dtroyer> annegentle: so would I
20:45:10 <annegentle> dtroyer: :)
20:45:10 <stevemar> dtroyer, me too
20:45:26 * jogo wonders how moving OSC from openstack namespace to openstack namespace would help with contributors
20:45:36 <dtroyer> I don't expect it will
20:45:37 <annegentle> heh
20:45:44 <stevemar> jogo, we can hope
20:45:46 <ttx> it's already there
20:45:53 <anteaya> jogo: they get in projects.yaml in governance, right now contributions to the repo doen't get ptl votes
20:45:59 <dtroyer> proof that namespace alone isn't magic
20:46:00 <annegentle> it's a good iterative test
20:46:04 <ttx> jogo: some companies only contribute to "openstack project"
20:46:14 <stevemar> ^
20:46:18 <ttx> I could name names but I won't
20:46:28 <devananda> ttx: and that continues to make me very, very sad
20:46:30 <jogo> ttx: its really hard to tell that it isn't part of 'openstack project' now ...
20:46:50 <jogo> bit that is neither here nor there
20:47:01 <sdague> jogo: you haven't met enough lawyers
20:47:11 <ttx> jogo: once example of such companies has plenty of lawyers
20:47:22 <ttx> but I won't name names.
20:47:32 <anteaya> I want that on a shirt
20:47:40 <zaneb> ttx: that's actually not entirely unreasonable, because it assures them that everyone involved has an incentive not to mess with the governance in ways that would get it kicked out by the TC
20:47:40 <annegentle> to me it's more interesting to see if jumping to user inclusion instead of contributor dev inclusion does anything
20:47:59 <ttx> Anyone opposing OpenStackClient ? I think that's a good one to start with, level 1 difficulty
20:48:08 <jgriffith> annegentle: I like the user inclusion slant
20:48:18 <ttx> annegentle: frankly, I care more about no longer considering them second-class
20:48:26 <annegentle> Yep!
20:49:05 <ttx> Silence... does that mean we should just vote on that one ?
20:49:16 <mordred> ttx: it's got 9 yes votes
20:49:27 <ttx> damn, things move while I talk
20:49:35 <ttx> 10 last seconds to register your vote
20:50:28 <ttx> ok, approving now
20:50:40 <stevemar> \o/
20:50:50 * ttx is kind of surpised nobody asks to wait one more week
20:51:06 <jgriffith> ttx: you shouldn't tempt fate like that
20:51:06 <ttx> sicne we are so in disagreement and all
20:51:16 <ttx> bah, approved
20:51:28 <dtroyer> thank you everyone
20:51:28 <ttx> dtroyer: You win the first big-tent addition award
20:51:39 * mordred hands dtroyer a fluffy bunny
20:51:47 <lifeless> yurt please
20:51:55 <ttx> #topic Other governance changes
20:52:03 <ttx> * Add the new developer-reference repo to the TC list (https://review.openstack.org/161451)
20:52:09 <ttx> This is about where to put developer guidelines -- in openstack-specs or in a separate repo
20:52:33 <ttx> I don't really care that much about a location, we just need to setlle on one
20:52:52 <dhellmann> last week there was enough agreement that we didn't want to do this, that I'll probably abandon the proposal and tell the cross-project team we want them to put policies in the existing specs repo
20:53:07 <dhellmann> unless someone wants to argue in favor of a separate repo?
20:53:14 <ttx> looks like there is no consensus on moving, so maybe let's just keep it where it is
20:53:37 <ttx> dhellmann: feel free to abandon patch is nobody argues
20:53:43 <ttx> Skipping https://review.openstack.org/#/c/162789/ since it was marked WIP
20:53:52 <ttx> * Add proposal to rename core teams as ? (https://review.openstack.org/163660)
20:54:03 <ttx> This was initially about renaming core teams to "maintainer teams", and is now evolving to renaming them to "core reviewers teams"
20:54:10 <ttx> Which is one of the names we used for those teams already
20:54:18 <ttx> and imho nicely insists on the duty rather than the caste aspect
20:54:21 <mikal> jogo says he is holding off there
20:54:40 <jogo> mikal: it should say I am holding off waiting for more feedback
20:54:44 <ttx> mikal: holding on the "maintainer" proposal, likely switching to "core reviewers team"
20:54:44 <jogo> mikal: before I rev the patch
20:54:49 <mikal> Ahhh, I see
20:54:50 <mikal> Ok
20:54:54 <ttx> welcoming reviews
20:55:10 <ttx> so please voice your opinion there so that jogo knows where to go
20:55:12 <mikal> Do we really think that change will work?
20:55:17 <mikal> People will keep calling them core teams
20:55:24 <mikal> Cause humans
20:55:30 <russellb> and have exclusive parties?  :)
20:55:46 <ttx> mikal: at least we can point them to somewhere were we say they how they should be called... but yeah, no miracle expected
20:55:53 <jogo> mikal: that is why I wanted maintainers I think it better reflects what we actually do
20:55:59 <ttx> russell_h: low kick, 1 point
20:56:03 <ttx> russellb: ^
20:56:16 <russellb> +1 point or -1 point
20:56:24 <devananda> so i'm -1 on maintainers because it denotes maintenance, and these teams are not maintaining - they're predominantly filled with active developers
20:56:29 <mikal> My point being, a subtle change wont work
20:56:33 <mikal> People will ignore it
20:56:33 <jogo> maintainers just like the kernel has maintainers etc.
20:56:41 <mikal> The name needs to be radically different if you want it to stick
20:56:47 <ttx> mikal: alternate wording welcome, I think
20:56:48 <anteaya> what problem is this solving?
20:56:53 <jogo> devananda: but the team isn't a team of developers
20:56:57 <jogo> we are there to review and maintain
20:56:57 <devananda> anteaya: i am wondering the same thing ...
20:57:06 <mikal> "Future defendants"
20:57:13 <devananda> jogo: how many folks on these teams actively contribute back fixes to stable branches?
20:57:18 <jogo> anteaya: making non core feel second class
20:57:29 <anteaya> they will just pick other words
20:57:32 <jogo> devananda: stable maint != maintaining master
20:57:44 <anteaya> it is because they don't feel empowered by their managers to do what they want
20:57:45 <devananda> jogo: no, but using the same word will make that confusing
20:57:45 <ttx> that's the well-accepted meaning of "maintenance" though
20:57:49 <anteaya> that is the problem
20:57:55 <anteaya> wording changes nothing
20:57:57 <jogo> ttx: so is the other case
20:58:03 <mordred> devananda: at the ops summit, it was requested by the operators taht we relax the "must be in master first" requirement for stable branches, btw
20:58:06 <ttx> OK, we need to move on, please contribute tothe review if you care
20:58:09 <jogo> anteaya: so my secret plan, is to make it easier to introduce subsystem maintiners
20:58:13 <ttx> #topic Housekeeping
20:58:15 <jogo> like other projects have
20:58:17 <ttx> * Publish the extra ATCs for projects (https://review.openstack.org/161465)
20:58:18 <russellb> jogo: +100 :)
20:58:19 <devananda> jogo: changing a name isn't going to suddenly change the culture, especially when it isn't actually changing the power dynamic between folks with +2 powers and folks without it
20:58:33 <jeblair> jogo: so how about a proposal to do that instead? :)
20:58:34 <ttx> annegentle: would you remove your -1 on that one ?
20:58:41 <russellb> jogo: though i think tooling/workflow is the biggest hurdly, though culture a big part too
20:58:43 <asalkeld> devananda: +1
20:58:47 <russellb> hurdle*
20:58:53 <devananda> jogo: but I'm +100 on delegating merge powers on subsystems to trusted subteams
20:58:54 <ttx> your question was answered, not sure if that's satisfying though
20:58:54 <jogo> jeblair: I thought there would be a lot more pushback to that, but I am happy to do that instead
20:59:05 <fungi> i'm excited about https://review.openstack.org/161465 because it hopefully means the format of that file will stabilize some
20:59:07 <russellb> jogo: i'm not sure we need TC involved in that
20:59:10 <russellb> i'd rather see a project just go do it
20:59:15 <russellb> hint hint nova!  :)
20:59:20 <devananda> jogo: fwiw, Ironic already has subsystem maintaner teams
20:59:22 <russellb> or any project really, i don't care
20:59:26 <russellb> someone needs to prove it out
20:59:28 <russellb> devananda: orly!
20:59:32 <devananda> jogo: see ironic-python-agent, ironic-discoverd, pyghmi, ....
20:59:33 <ttx> Hmm, topic please
20:59:34 <jeblair> jogo, russellb: i don't think tooling is a blocker
20:59:35 <mordred> infra has had subsystem teams for a while
20:59:41 <russellb> without having to split into repos
20:59:44 <jogo> jeblair: I agree!
20:59:48 <devananda> russellb: nope! separate repos
20:59:57 <russellb> i'd love to see it done without splitting
20:59:58 <sdague> right, the separate repo thing is the issue
21:00:00 <ttx> One minute left, can we switch to last topic please
21:00:01 * russellb sits down at ttx's request
21:00:02 <devananda> we now also have some drivers maintaining the majority of their code out of tree // on stack forge with their own teams
21:00:04 <mordred> sure- but that's not a TC thing
21:00:10 <russellb> mordred: agree
21:00:10 <jogo> anyway I will revise this
21:00:17 <lifeless> we could trust folk...
21:00:17 <ttx> argue on the review, please
21:00:21 <ttx> The last 4 are repo housekeeping and have PTL+1, so will approve all unless someone objects now:
21:00:24 <ttx> * Add the bindep repo to Infrastructure Project (https://review.openstack.org/161771)
21:00:27 <ttx> * Add devstack-plugin-cookiecutter to QA (https://review.openstack.org/161886)
21:00:30 <ttx> * Add Gnocchi repository to Ceilometer (https://review.openstack.org/162145)
21:00:36 <ttx> * Add new project puppet-openstackci to infra (https://review.openstack.org/163246)
21:00:43 <devananda> ttx: ++ to you just doing the house keeping things :)
21:00:48 <sdague> devananda: ++
21:00:51 <ttx> i'll approve https://review.openstack.org/161465 when annegentle removes her -1
21:00:54 <mordred> ttx: ++
21:00:55 <ttx> #topic Open discussion
21:01:07 <ttx> I guess that topic started around :25
21:01:12 <ttx> so it's safe to close
21:01:17 <mikal> Heh
21:01:23 <ttx> unless someone has an express announcement
21:01:32 <russellb> i still love you all, even if we disagree (or i'm confused, or whatever) :)
21:01:36 <ttx> #endmeeting