20:01:30 #startmeeting tc 20:01:31 Meeting started Tue Dec 17 20:01:30 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:35 The meeting name has been set to 'tc' 20:01:37 Last meeting for 2013 ! 20:01:44 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:01 #topic Becoming a Program, before applying for incubation 20:02:07 #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/022202.html 20:02:16 Let's discuss this first, as suggested by sdague at last meeting 20:02:28 So... the idea is to somehow bless the idea / scope / mission of a team or a project before it files for incubation 20:02:39 That way it can actually attract enough contributors to pass our ever-higher technical barriers to entry 20:02:49 Which solves the chicken-and-egg problem we had with various recent incubation proposals 20:02:52 o/ 20:02:56 Various solutions tossed in that thread: 20:03:05 1. Reuse "Programs" for that (original solution proposed on the thread) 20:03:13 2. Reuse "Programs" but make new ones go through a trial period ("emerging programs") 20:03:22 3. Bless teams/missions, but don't call them programs yet ("emerging efforts" badge) 20:03:30 4. Bless projects themselves rather than teams/missions ("emerging projects" badge) 20:03:39 5. Don't bless, just set up an "Emerging projects" page containing prose describing the TC feedback on it 20:03:47 Comments / thoughts ? 20:03:56 (personally I'm hesitating between (3) and (5) at that point) 20:03:59 I'm starting to like 5 myself 20:03:59 i think the suggestions on the thread to make this a very light-weight endorsement sound good. i think we should hold programs to a high standard, but if indicating that we think a project is a good idea and we'd like to encourage it helps, i think that's worthwhile. 20:04:05 so i think 5 fits the bill 20:04:13 o/ 20:04:19 yeh #5 seems reasonable to me 20:04:25 I like 5 20:04:32 I'm fine with trying (5) as a first incremental improvement. I fear that won't generate enough visibility to make them reach critical mass, but we can revisit later. 20:04:38 sure, it's a pretty light weight step in the direction 20:04:50 yeah, we could do #5 for now, and more later if we feel it's necessary and justified 20:04:53 o/ 20:05:02 I don't think blessing something without substantial momentum makes sense 20:05:17 tripleo only applied for incubation when it was already attracting developers 20:05:25 that's the difference between 3 and 5, right? 20:05:40 5 gives us a way to avoid having multiple groups going off and trying to do the same thing (ceilometer and healthnmon) 20:05:49 oh god yes 20:05:52 lifeless: tripleo applied to be a program, not incubation ;-) 20:06:00 dhellmann: yes, 3 in boolean, 5 is float 20:06:26 5 also doesn't necessarily pick a team only that the we like the direciton 20:06:31 russellb: actually, we started before programs existed; our application was part of the 'oh yeah, we should change this' discussion AIRI :) 20:06:37 OK, I'll work on documenting the process around (5) 20:06:48 Additional question: should we still auto-create programs for incubated projects, or should we wait until they graduate to being part of the integrated release ? 20:06:59 It affects ATC/voting rights on one side, and what level of commitment we want "program" to actually mean on the other. 20:07:06 I don't think an incubated project without a program makes any sense 20:07:19 I agree 20:07:22 agreed 20:07:28 if the project hasn't attracted the attention it needs to also qualify as a program, thats a red flag to me 20:07:31 the question of which program the project will be in should be part of the application 20:07:33 status quo would be "you shoudl have a program attached, even if that means creating it at incubation request time" 20:07:33 yeah, keep programs for incubated projects -- it makes sense -- they are actively working on a deliverable and making measurable progress! 20:07:46 OK, all clear to me 20:08:41 I'll propose a change which adds a reference/emerging-projects page full of prose that will be published somewhere 20:09:18 anything else on that subject ? 20:09:46 so the program springs into existence when they project is incubated? 20:09:56 or is the program incubated too? 20:10:05 * markmcclain isn't clear on the idea here 20:10:06 markmcclain: unless the project is already part of an existing program yes 20:10:46 we'd not have an incubation state for programs. We'd remove the program if the project fails to incubate 20:10:59 so what about 20:11:10 ttx: thanks for the clarification 20:11:11 incubation requires a program that has been around for > 3 months 20:11:37 give the program time to get out of the float area and be real before incubating a project 20:11:43 I thought we just said we don't want programs without real projects? and "real" means incubated or graduated 20:11:50 lifeless: that means back to option (1) up there 20:11:55 ttx: does it? 20:12:04 well 5+1 admittedly 20:12:15 where do programs without projects come from? 20:12:25 09:03 < ttx> 5. Don't bless, just set up an "Emerging projects" page containing prose describing the 20:12:28 TC feedback on it 20:12:31 oh, I see - emerging projects 20:12:37 * lifeless sits to think for a sec 20:12:44 lifeless: you'd require that incubation wannabees ask for a program before filing for incubation 20:12:57 which is what the whole thread was about 20:13:13 * mtaylor doesn't understand the point of emerging projects vs. programs 20:13:29 both require the TC to say "yup, that workstream seems great" 20:13:39 so both are a blessing, and we'll wind up wanting critera 20:13:41 criteria 20:13:53 we already have programs, and programs do not require any projects in the program to be incubated yet 20:14:05 mtaylor: (5) is a feedback, not a blessing. It's not yes/no 20:14:12 it's a blessing 20:14:17 it will be seen as a blessing 20:14:28 because it's official feedback from us 20:14:33 so - let me check constraints: programs that aren't /delivering/ something are problematic [what deliver means is open for debate]; new programs (implied by new projects) want blessing to ramp up interest faster; delivering something is then key; but we don't want to add things that aren't mature to incubation. 20:14:40 mtaylor: except anyone can ask for that feedback and receive it 20:14:44 editing a wiki page isn't a blessing, is it? 20:15:04 mtaylor: see markmc's posts on the thread 20:15:22 ttx: ok so I think 5 is fine : it's enough recognition to help force a collapse of the wave function from multiples to one; and its where things stay until they are really mature enough for incubation. 20:15:43 at the point they are that mature there should be enough interest and multi-vendor collaboration to make a program non contentious 20:16:27 mtaylor: 5 is different from 1-4 because the feedback is in shades of grey rather than black or white 20:16:36 I think it's overhead with no benefit. but I don't feel strongly enough about it to hold this up 20:16:56 I don't even think the TC needs to do anything for 5 other than direct people to how to edit the right page to list themselves 20:17:24 mtaylor: also in the thread there was the concern of making sure a "program" came with some reasonable expectation of staying there 20:17:34 so it should not be granted to lightly 20:17:38 too* 20:17:45 the problem as I see it is that designate does things that we clearly want, and it works, and it's participating to a degree - but it's not quite ready for incubation 20:17:59 so letting designate tell people that they're working on things solves nothing 20:18:12 and random feedback solves nothing 20:18:20 in the new world order, they would ask for feedback to the TC, which would be "very interesting, we want you, just mature a bit" 20:18:26 mtaylor: it doesn't? you don't think it drives people over there 20:18:37 so this page wouldn't be something anyone could edit, then? 20:18:39 the actual probelm is the chicken and egg problem of resources waiting for blessing and blessing waiting for resources 20:18:42 a TC curated list of projects we like seems like a good page to be able to go to and see what's coming 20:18:46 sdague: no. I do not 20:18:59 but there are two sorts of resources right? 20:19:04 I thought the problem was groups not having enough publicity to gain enough contributors to meet incubation requirements 20:19:07 what are we trying to solve? 20:19:08 TC curated meaning at least we're keeping it up to date, and it doesn't have stupid crap in it 20:19:09 I don't think it's publicity 20:19:10 mtaylor: I agree with you. I /fear/ that (5) won't give them the visibility they want either 20:19:13 there are volunteers and there are foundation sponsoed 20:19:19 but i'm fine with giving it a try 20:19:25 most of our devs are corporate sponsored 20:19:27 e.g. more people hacking vs -infra support when things go pearshaped 20:19:39 markmc: o/ 20:19:40 which means that most of them come from product efforts - we want those to wind up in good openstack things 20:19:43 to get more people hacking, as mtaylor says, it's a corporate engagement issue 20:19:49 (sorry, family stuff) 20:20:15 so if it's not "OpenStack" - the people providing the devs are less likely in some cases to pony up the people - I think we're seeing this more and more now that we have so many projects 20:20:16 markmc: mtaylor was unconvinced by your prose page, and thinks projects want to be blessed 20:20:32 hrm. why am I mtaylor? 20:20:37 sure projects want to be blessed :) 20:20:42 mtaylor: good question 20:20:55 mordred: I thought you were trolling us :) 20:20:56 mordred: thanks, i was worried about you 20:20:58 there'll always be some point we're not prepared to bless them though 20:21:16 * markmc likes the idea of giving concrete feedback rather than ever fine-grained levels of incubating status 20:21:35 so, if it's not a mechanism for us to 'bless' an effort or a direction, I think it's a waste and we should just do nothing because I dont' think it will appreciably change what's going on 20:21:47 and just adding overhead for the heck of it is the last thing we need 20:22:02 markmc: like I said, i'm fine with giving it a try, just fearing it won't get the projects what they want, so they will continue to rush incubation requests 20:22:10 people want to know what we think of e.g. Designate 20:22:13 what's our answer? 20:22:17 go read the irc logs ? 20:22:19 and preserve the chicken-and-egg issue we are trying to solve here 20:22:31 we might invent a "promising" status to give them and every other nascent project? 20:22:47 I mean, hell - let's try it - I might be wrong - I just think it's not going to work any better than the last time we tried it 20:22:51 I think the real question is: 20:22:52 people just want to know what we think of it, how it's likely to proceed, what we think it needs 20:23:04 - do we want other companies to compete with e.g. designate or 20:23:13 - do we want them to collaborate on e.g. designate 20:23:19 we used to have a special category for ecosystem projects - atlas lb wound up there 20:23:22 look at how that worked 20:23:25 is the "emerging projects" page proposed with #5 something maintained through the governance repo? 20:23:25 mordred: do you sense that designate is getting stalled because of the tc or other factors? 20:23:28 or is it just a random wiki page? 20:23:28 lifeless: the latter, at this point 20:23:34 And and *what point* do we signal to other companies that we want this to happen. 20:23:36 lifeless, whatever gets us a viable project, in the end 20:23:38 Blessing is all about that. 20:23:40 russellb: governance repo 20:24:08 markmc: ttx: It was a rhetorical question meant to frame discussion :) 20:24:13 ttx: if it's in our repo, then it's sure going to look like a blessing to some degree, right? 20:24:13 and I agree with lifeless's heart of the matter 20:24:28 lifeless, rhetorical question means implied answer - you just got two different answers :P) 20:24:35 markmc: :) 20:24:46 russellb: maybe. 20:24:46 So actually I think that shows up the issue 20:24:47 ... 20:24:50 OK, let's try it 20:24:55 there are two big phases we go through for new projects 20:24:56 lifeless, an issue, for sure 20:25:03 there is the thousand flowers blooming phase 20:25:09 nobody says it's wrong, seom people think it's not enough 20:25:18 fair enough. 20:25:18 let's try it and see 20:25:21 if we were sure designate was absolutely the way forward, why not incubate it? 20:25:24 where there are lots of independent attempts, some proprietary, some open and unaffiliated, some affiliated with openstack 20:25:27 ttx: +1 - I say try, and try to fail quickly if it's wrong 20:25:29 we're not - a community hasn't formed around it? 20:25:41 and then we incubate one and it all changes - it's a phase transition 20:26:02 I think the thing we're struggling with is just where we trigger the transition 20:26:05 let's go to practical exercise now, Barbican. 20:26:25 And having reframed it this way, I'm now changing my opinion on what we should do :) 20:26:33 ow. 20:26:50 ttx: go on, barbican ? 20:27:03 #topic Barbican incubation request 20:27:16 markmc: how many of our projects formed a community pre-blessing? 20:27:17 lifeless: thought you were disagreeing with way forward 20:27:19 markmc: honestly 20:27:21 #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/020830.html 20:27:21 ttx: Oh I am 20:27:26 #link https://wiki.openstack.org/wiki/Barbican 20:27:44 and 20:27:46 mordred: was there a blessing for ceilometer that I'm not aware of? 20:27:46 #link https://wiki.openstack.org/wiki/Barbican/Incubation 20:27:59 mordred, sure - that's what we want - and "blessing" becomes about recognizing that 20:28:14 markmc: I'm saying I think it might be unreasonable 20:28:19 lifeless: so should we continue to discuss it ? 20:28:33 mordred, oh, I see - so, were we unreasonable not to bless designate? 20:28:40 markmc: no - I'm not saying that 20:29:12 I'm saying that we might have a expectation that projects are going to grow vibrant communities outside of our context, and I'm not sure we have much evidence that that ever happens 20:29:23 as we are a lovely incubator for community formation 20:29:27 mordred: neutron, ceilometer, heat, trove, ironic, marconi, savanna, tripleo all formed communities before blessing. 20:29:33 jeblair: I disagree 20:30:03 jeblair: neutron was blessed by fiat back in the ppb days, heat was largely redhat, ironic was a nova splitout 20:30:49 mordred: let's go back to this if there is tima at the end of meeting 20:30:56 ok 20:31:04 so, second session on barbican 20:31:14 I don't think this week actually changed my view on this... quoting me from last week: 20:31:21 it looks like the scope of the project is well-defined and makes sense 20:31:28 there are some concerns about team size/diversity and some work to be done before filling all the current requirements for incubation 20:31:50 though +1 for the team working quickly on the incubation requirements in the last couple of weeks 20:31:54 I liked the recent discussions around whether it could belong to the Identity program or not - really appreciated 20:32:15 At this point, we've nailed down the technical reqs. Oslo.messaging has landed and after a rebase, pbr and global-reqs will land 20:32:20 ultimately barbican / secrets management warrants its own program... separate from identity/auth. 20:32:28 jraim: devstack-gate still pending right? 20:32:32 the relatively concrete tasks on testing (testr & d-g jobs) aren't done yet 20:32:40 russellb yeah, we needed pbr and globals first, which needed oslo 20:32:44 so a bit of a house of cards 20:32:46 k 20:33:06 testr is done in branch, but we need to work through the implications on our existing testing 20:33:13 should be soon (tm) 20:33:40 if I were to write feedback in prose, I'd say "we want that, and really close to meet technical incubation requirements" 20:34:14 but then, I have concerns with team diversity. And I fear not blessing them in any way won't give them an easy way to solve that one 20:34:28 so this is the bit mordred is talking about 20:34:33 and in a way me too 20:34:36 I did ask some people that have expressed interest to say so on the list 20:34:48 So we saw some traffic from RedHat, HP and Nebula 20:34:49 it's cheap to express interest, though 20:34:53 I think by saying 'you know, you're /nearly there/' we're well past the point where we want to see more competition 20:34:54 that doesn't mean a whole lot 20:34:54 so we just went through making technical requirements for the bar you had to pass to incubate 20:34:58 lifeless: yes, and why I think ultimately (5) won't give them enough visibility to reach critical mass 20:34:58 and we have an active contributor from eValut that strated recently 20:35:06 lifeless: ++ 20:35:06 I think we're into the 'we want collaboration' phase of the lifecycle. 20:35:08 the team diversity concern is why we are also discussing designate in a similar vein 20:35:28 so I really think those a requirements to complete first, and the whole thing is sort of moot until that's checked off. 20:35:48 sdague: some of our requirements are more social than technical 20:35:49 sdague: yeah but realistically they could have the rest of those requirements checked off by january 20:35:55 we're not questioning if we want this thing, and I don't think we actually are afraid it's going to top having devs this instant - I _do_ think that we dont' want to graduate it without a bunch of things 20:35:56 sdague: and the team can't do /those/ on their own. 20:35:56 and then we're back to the team diversity questions 20:35:59 lifeless, honestly, if we're past the point of wanting to entertain any competition - it's time to incubate 20:35:59 russellb that's our plan 20:36:09 lifeless: sure 20:36:11 markmc: I agree 20:36:13 markmc: ++ 20:36:25 mordred: I was leading there gently ;) 20:36:26 russellb: also, sure, but if today is an incubation vote, then it should be a clear "no" 20:36:26 fair point 20:36:27 bah 20:36:29 markmc: ^ 20:36:38 so maybe the team diversity question should be more about graduation than incubation? 20:36:43 russellb: yes! 20:36:46 sdague: yep, but might as well discuss 20:36:56 I think we would be fine picking this back up in Jan once we've merged the last technical bits 20:37:01 markmc, lifeless, mordred: so what you're saying is.. we should NOT have team diversity/size requirements in incubation requirements ? 20:37:15 ttx: Size yes, diversity no. IMO. 20:37:24 jraim: yeh, realistically that's what I'm proposing. 20:37:25 But as people have said, the team composition probably isn't going to change by then 20:37:26 and add diversity for graduation, yes? 20:37:29 russellb: ++ 20:37:40 that seems reasonable i think 20:37:48 I think diversity should be part of incubation 20:37:53 lifeless: could you expand on that in a way that would be fair to designate ? 20:37:53 it takes time to grow team, and it takes a decent investment by devs to earn that team status 20:37:53 i think diversity is important for incubation and we should hold our standards there 20:37:54 diversity is important, but more for graduation I think 20:38:01 otherwise we'll have large entities apply based on team size 20:38:09 Has anyone taken a look at if barbican is using all the bits of olso we think it should? 20:38:11 ttx: rationale: If a company sponsors a project that we are convinced makes sense for the project technically and scope wise, and they fund it to a sufficient degree... meet technical merits, and stability... 20:38:19 well we'll have to look at relative contributions when looking at size 20:38:21 incubation means devoting limited openstack-project-wide resources to a project 20:38:34 and i don't think that's appropriate to do when a project has only managed to get contributors from one vendor 20:38:41 lifeless: i'm easily convinced in my evenings 20:38:42 jeblair: +1 20:38:45 jeblair: +1 20:38:53 jeblair: +1 20:39:06 ttx: must be the dinner wine 20:39:09 I'm with jeblair on that 20:39:22 Has anyone taken a look at if barbican is using all the bits of olso we think it should? 20:39:22 I think with some of the smaller projects we're not going to get contributors from other vendors until it's incubated 20:39:26 why not? Ignore the single vendor aspect for a second 20:39:29 If: 20:39:32 - we want the project 20:39:36 I think there's a point between "single company dominated and controlled project" and diverse project 20:39:45 - we want collaboration at this point, not competition 20:39:46 and also - I argue all the time that nobody should care that I work for HP 20:39:52 mordred that's my concern 20:39:54 - it's the only one being offered up to us 20:40:05 i.e. a "totally open and meritocratic, in excellent shape, crying out for others to come along and play" project 20:40:05 => how is it inappropriate? 20:40:33 lifeless, diversity is important for long-term viability, is the point 20:40:36 lifeless: it could indicate a lack of viability 20:40:51 lifeless: I guess it boils down to: do we want 2 stages of incubation (tech + social requirements met) or just one 20:40:56 markmc: totally agreed, but the chicken and egg problem ttx describes is /all about collapsing the competition function/ 20:41:05 it might suggest there's something about how the project is run so that others are having trouble participating; or it could mean no one outside of that company is interested 20:41:18 HP funded infra single-handedly for a while - did that make any of us think that infra was somehow less OpenStack worthy? 20:41:29 right, if a project comes along in that state I wonder why that company hasn't *already* started trying to find other contributors 20:41:33 or did it mean that HP was the only one with a person who was fighting to put employees on it 20:41:36 jeblair: it could, and thats the question. Monty doesn't see a lot - any - evidence that viability correlates with diversity pre-incubation 20:41:41 in fact, I would point at neutron 20:41:42 mordred: I'd argue it's a bit of a corner case. 20:41:46 lifeless, so, do we do that only after diversity is achieved or in order to encourage diversity - that's the question 20:41:53 and say that diversity is at best a weak predictor of viability 20:41:56 ttx: I wouldn't - geting FTEs on a project is hard 20:42:02 * markmc is okay with using it to encourage diversity if everything else is in great shape 20:42:11 ttx: it's even harder when companies do not see product potential 20:42:13 markmc: yeah, thats where I have circled around to 20:42:21 and we believe the project is truly welcoming, meritocratic, etc. 20:42:22 lifeless: monty struck a number of projects from my quick list, but not all of them 20:42:23 we shouldn't go light on /technical requirements/ 20:42:34 and they have a BUNCH of openstack projects to contend with - so if they have to choose between putting people on barbican or on nova ... 20:42:49 i think we've switched back to the other topic. 20:43:03 yes, let's stop for a sec 20:43:14 I think we owe barbical an answer 20:43:18 Barbican* 20:43:21 lol 20:43:24 I like the new name 20:43:41 and I think it should be: come back to us when all tefchnical checkboxes are crossed, which should be anytime now 20:43:50 ttx: +1 20:43:57 ttx: I'd like to dig into oslo and barbican a bit more if I could 20:43:57 +1 20:43:59 ttx That's fine with us 20:44:02 rather than rush the decision today while they are not all crossed 20:44:24 is there an official checklist they are working from? 20:44:33 mikal If we take this back up in Jan, would that give you enough time to dig in a bit more? 20:44:39 jraim: hopefully we'll have gotten our mind together on the spcoam aspect in the mean time 20:44:41 #link https://wiki.openstack.org/wiki/Barbican/Incubation 20:44:42 jraim: sure 20:44:45 dhellmann: ^^^ 20:44:51 sdague: thanks 20:44:52 jraim: mostly I want to dicsuss it and reach a concensus 20:44:52 twards the bottom 20:44:52 s/spcoam/social 20:45:00 jraim: but that can wait, so long as we do it before voting... 20:45:22 mikal that's fine. We're on #openstack-barbican if you have questions 20:45:23 #topic incubation vs. recognition 20:45:37 ok, back to the bazaar 20:45:42 Heh 20:45:56 so, like I said, it boils down to... 20:46:20 tripleo was all HP when it got accepted, trove only picked up a second vendor because of internal herculean efforts by jcooley, savanna was questionable as to real diversity but we made a judgement call 20:46:27 mordred: i'm sensitive to what you're saying about getting companies to contribuet fte to a project; maybe you can help me understand how incubation helps there -- how does that make them see product potential and devote fte? 20:46:32 should we care about diveristy at incubation time 20:46:45 mordred: we had sigificant rackspace and bluebox interest - even a couple patches IIRC 20:46:47 jeblair: yes, it does 20:46:48 jeblair says yes 20:46:51 mordred: + some early redhat fixes 20:46:51 mordred says no 20:47:04 mordred: but we didn't have any non-HP -core. 20:47:07 jeblair: because it makes them se that they're going to need to engage with the project coming down the pipeline 20:47:20 could we be more explicit about long term viability - e.g. identify things that could prevent diversity ? 20:47:32 jeblair: I would say it doesn't help them see product potential. 20:47:34 rather than making it a numbers game 20:47:42 jeblair: also, it shows them that it's more costly to do internal private dev than to collaborate with openstack 20:47:47 jeblair: it helps them see where they need to collaborate vs wrap 20:47:54 markmc: a single vender changing their mind and retasking/laying off a team seems like a big risk 20:47:56 without that, it's the question of collaborating with 'random-open-source' - which does not carry the same weight right now 20:48:13 incubation triggers non-trivial support efforts from various programs in openstack... Should we require a minimum of diversity before granting those ? 20:48:14 jeblair: right. which is why I think it's _ESSENTIAL_ for graduation 20:48:25 jeblair: the mindset many vendors have is 'we need X for our customers, is X part of OpenStack? No -> spin up a team and build it in-house. Yes? Collaborate' 20:48:31 lifeless: ++ 20:48:35 jeblair, oh, it is - it's extremely important for graduation IMHO 20:48:51 I think there is no dissent that diversity is required for graduation, actually 20:48:55 mordred: half of our development infrastructure is now devoted to helping new projects bootstrap themselves in our environment 20:49:01 jeblair: some orgs build it in-house and open source it (which is how e.g. designate came about AIUI) 20:49:04 so we should probably be giving our existing incubating projects a report card on how they are doing there 20:49:06 jeblair: that is true 20:49:12 jeblair: others build it in-house and sell it as part of their offering. 20:49:26 I'm with jeblair on concerns about halving resources just to help out incubating projects 20:49:58 jeblair: either way, the lack of a 'this is part of OpenStack' creates a void, which for some companies is an opportunity, for others a weakness 20:50:02 * mordred still points out that other companies are welcome to contribute FTEs to Infra - which would help 20:50:08 we've seen difficulty with large projects like neutron getting vendor support but not core support, so there's some nugget of concern about too much diversity too. 20:50:30 jus' sayin' 20:50:39 annegentle_: +1. Though I wouldn't say 'too much diversity', I would say thats a cultural norm issue. 20:50:48 annashen: I think that's a different issue 20:50:51 I'm more leaning towards concerns about long term viability -- and user and operator uptake. 20:50:53 annegentle_: We want a norm of 'we're all building this together' within teams. 20:51:00 lifeless: +1 20:51:12 not, a 'ok there is an API shuim and ALL MY GOODNESS IS PROPRIETARY' 20:51:16 annegentle_: i agree, it does suggest that it's more than just numbers we need to consider 20:51:16 lifeless: yes I like collab models better than compete 20:51:25 jeblair: ++ 20:51:32 or, annegentle_ ++ rather 20:51:59 jeblair: so concretely, what I'm suggesting is tht when we - the TC - /want/ the project [vs it being pushed onto us] 20:52:13 jeblair: that all the questions about infra resources etc are moot: we've already decided *we want it* 20:52:14 One question is, would we punt projects from incubation because they fail to get more diverse ? 20:52:18 the questions that matter are: 20:52:37 - is it technically viable - all the stuff we seem to agree on 20:52:54 - and some thorny social assessment, do we expect it to play well with others and have good norms 20:53:17 All I'm saying is that we can't really assess the second via a hard rule of 'X vendors involved' because of the dynamics of how vendors get involved. 20:53:27 It's the heart of the chicken and egg issue. 20:54:17 lifeless: would you say we rejected designate on a diversity argument, or a size argument ? 20:54:33 mordred: ^ 20:54:38 I'd say both 20:54:45 diversity definitely came into it, though 20:55:04 if it was a larger team, it might have been a good discussion as to whether we could have passed on diversity 20:55:13 OK, 5min left, we need to move on, let's push that to a thread 20:55:45 mordred, lifeless: and since you seem to care about it, please participate to it 20:56:07 because nothing in the thread posted last week actually let us anticipate your concerns 20:56:13 heh 20:56:22 since you didn't post to it. 20:56:36 looking at barbican's irc meeting logs 20:56:38 http://eavesdrop.openstack.org/meetings/barbican_weekly_meeting/2013/barbican_weekly_meeting.2013-12-05-20.01.log.txt 20:56:44 there are 78 lines 20:56:51 #topic J naming determination process 20:56:57 #link http://lists.openstack.org/pipermail/openstack-tc/2013-December/000444.html 20:57:02 ttx: I hadn't gotten to the heart of it before 20:57:06 Unless there are objections, I'll follow the SurveyMonkey route with the 10 candidates mentioned on: 20:57:07 ttx: before the meeting it all sounded plausible. 20:57:08 how do we determine the viabality of a community based on so little evidence 20:57:14 ttx: then new data -> ideas -> changed opinion 20:57:17 #link https://wiki.openstack.org/wiki/ReleaseNaming 20:57:29 jeblair: perhaps we don't; perhaps we make it easy to handle failures instead? 20:57:30 ttx: +1 survey monkey 20:57:32 lifeless: apology accepted :) 20:57:33 ttx: ++ 20:57:45 Survey monkey ftw 20:57:48 ttx: +1 20:57:52 ttx: wfm 20:57:54 let's please not name a release after other major open source projects (jekyll) 20:58:12 Jenkins! 20:58:14 notmyname: I actually got the express authorization from Tom Preston-Warner 20:58:30 that we can reuse jekyll in that context 20:59:00 #link http://jekyllrb.com/ 20:59:13 * dhellmann doesn't think there's anything static about openstack 20:59:26 Nick Quaranto also agreed there was no namespace overlap 20:59:41 both were fine with us reusing it for a release cycle na�e 20:59:44 name 20:59:50 #topic Other governance changes in progress 20:59:53 quickly 20:59:57 60 seconds 20:59:58 Provide infrastructure for publishing docs to docs.openstack.org: https://review.openstack.org/#/c/61380/ 21:00:05 This one is more technical than governance, so I'm fine with approving it once infra / Anne vets it 21:00:12 Attach extra ATCs to programs: https://review.openstack.org/#/c/62009/ 21:00:14 so I don't get it 21:00:17 This one will be approved as soon as it reaches enough approvals 21:00:39 annegentle_: ask question 21:00:50 is the proposal to provide only sphinx/oslo infra for publishing docs? or to provide sphinx/oslo infa for publishing governance pages that are considered sources of truth? 21:01:09 annegentle_: one of the things we talked about when moving the tc motions into git was that we could publish what we produce 21:01:10 the latter, I think 21:01:13 that's at the heart of my comment about the commit message possibly being misleading. It made me read it twice. 21:01:24 annegentle_: it is providing infrastructure so that we can publish contents of the repository to the web 21:01:24 if it's the latter, then why not publish to the wiki? 21:01:24 annegentle_: so essentially governance is a doc repo only 21:01:27 annegentle_: so the latter 21:01:36 vs. sending people to git urls 21:01:40 which is what we do now 21:01:44 annegentle_: because it's not really simpler 21:01:52 I have concerns about publishing to docs.o.o: version tracking, keeping history, search capability, and where do bugs get tracked 21:02:01 ok, time is up, move discussion to corresponding review. 21:02:08 git is a perfectly good publishing system 21:02:08 and I'm -1 to publishing to wiki automatically anyway, because a wiki is a rw medium 21:02:10 and this isn't 21:02:20 #endmeeting