20:03:17 #startmeeting tc 20:03:18 Meeting started Tue Nov 19 20:03:17 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:22 The meeting name has been set to 'tc' 20:03:27 Our agenda today: 20:03:31 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:36 busy busy 20:03:43 #topic Manila incubation request: final discussion 20:03:51 #link http://lists.openstack.org/pipermail/openstack-dev/2013-October/016370.html 20:03:52 first off I'd like to apologize for missing last week -- I was on a plane because I stayed in HK a few days after the conference 20:03:59 #link https://wiki.openstack.org/wiki/Manila_Overview 20:04:06 bswartz, did you see the logs and https://etherpad.openstack.org/p/ManilaIncubationApplication ? 20:04:10 also I was under the impression that manila incubation wouldn't come up for consideration until today because I simply misread the email from ttx -- sorry about that 20:04:11 lots of questions in there 20:04:16 markmc: yes I did 20:04:27 bswartz: I think I can summarize by saying the strongest objection to incubation in last week's discussion was about the maturity of the project 20:04:29 I'm happy to answer those today 20:04:35 Both in terms of number of commits and number of developers involved 20:04:42 (We rejected Designate on similar grounds over the last cycle) 20:04:54 o/ 20:05:02 Also seemed like Manila could benefit from another round of discussion regarding its relationship with Cinder 20:05:04 o/ here 20:05:10 so I understood that designate was basically a one-company effort 20:05:15 So all in all it appeared to be a bit early to consider incubation. 20:05:21 there is broad interst in Manila, if not active participation as of yet 20:05:40 bswartz: yah. that was the main thing with designate too 20:05:50 broad support, not tons of multi-company participation yet 20:06:15 That said... I think we need a more formal way to designate (haha) projects where the topic is promising and we'd like to encourage more people to participate 20:06:15 so we have several companies interested in working on back ends 20:06:23 ttx: +1 20:06:29 The soft encouragement we used for Designate did not really attract the masses, which is why I was thinking about a more shiny badge they could wear 20:06:37 the main thing stopping them is that we recognized some archtectural limitations and we're working on addressing those 20:06:37 Like "OpenStack Emerging Technology project" 20:06:46 i read the logs and i agree with ttx's assesment; i personally think it's a great idea and it should be in openstack; the project should grow a bit, and i'd really like to see jgriffith and russellb weigh in on the integration/overlap points 20:06:48 nurtured? 20:06:52 We could grant that category extra resources at summits to make sure more people converge to what sounds like a good idea. 20:08:59 o/ 20:08:59 ttx: we should be _really_ _really_ careful with that 20:08:59 ttx: I'm not interestined in a badge or publicity -- we have more publicity than we need at this stage of development 20:08:59 bswartz: it might be relevant to address those issues before getting into incubation 20:08:59 yeah - I'm not sure we need new catagories 20:08:59 what we want is to be allowed to integrate with things such as devstack/tempest 20:08:59 you just need more contributors :) 20:08:59 o/ 20:08:59 I think the TC even saying "hey man, we like that, good job" 20:08:59 so how do we help you get more contribution? 20:09:12 ttx: there's already a tendency for stackforge projects to overstate their involvement in openstack 20:09:12 it makes things a lot easier when we can fit into the mold that other projects use 20:09:12 jeblair, mordred: yes... I just don't feel us syaing "nice idea, please come back when you mature" was *that* succcessful in getting more people to contribute to designate 20:09:12 you can already integrate with devstack, and even devstack-gate, easily 20:09:59 so I hesitate in proposing that for manila 20:09:59 ttx: it's either that, or lowering the bar for incubation, right? 20:09:59 I want to hear from jgriffith 20:09:59 also I think I'd like us to adopt sdague's constraints on new incubated projects sooner rather than later 20:09:59 annegentle: haha 20:09:59 should we have the meta-discussion about badges first? 20:09:59 we don't need help increasing our contribution level -- that will come as soon as we get past the technical hurdes we face (I'm estimating 4-6 weeks on that) 20:09:59 since it's ok for projects to be incubated for more than 1 release cycle, I think it'd be fair to incubate projects that are definitely a good idea and give them the time to mature 20:09:59 so we seem to have skipped past that initial discussion/convo 20:09:59 ttx, yeh, I'd really like to not add another project to incubation until we decide on that 20:09:59 while being incubated 20:09:59 bswartz: while it is a recent change, devstack, devstack-gate, and tempest are all now modular enough that any stackforge project can do it; wsme and sqlalchemy-migrate are working on that now. 20:09:59 bswartz: what are the technical hurdles? 20:10:00 jgriffith: I think yes we need technical discussion :) 20:10:05 * annegentle needs to type faster 20:10:08 I'd like a better idea of scope/direction of the project 20:10:11 russellb: I'll talk to you offfline about the devstack stuff - I wasn't aware there was a path to use devstack pre-incubation 20:10:24 yeah i just did it with a couple hours work for solum yesterday 20:10:27 bswartz: see the patchset to enable it in solum 20:10:33 bswartz: it's pretty self explanatory 20:10:41 bswartz: see my comment above ^^ 20:10:54 bswartz: https://review.openstack.org/#/c/57036/ 20:11:08 lifeless: thanks 20:11:27 bswartz: what are the technical hurdles you face? 20:11:37 bswartz: I know we talked about the LVM question 20:11:43 bswartz: and related, https://review.openstack.org/#/c/57098 20:11:50 bswartz: so it's extremely likely that we'd require you to have gate jobs before being accepted into incubation 20:11:55 regarding "technical issues" it's clear that the code we wrote initially only works for single tenant environments -- properly supporting multitenant environments requires a different design 20:12:10 we've been working for the last 3 months on designing that and it's about ready to go in 20:12:13 ttx: bswartz can we first get a better idea of what the goal is here? 20:12:21 bswartz: wow 20:12:23 that's a pretty fundamental requirement for openstack things :) 20:12:29 if that's not there yet ... 20:12:37 ttx: bswartz the code is not necessarily idicative right now based on conversations I had with bswartz 20:12:50 s/idicative/indicative/ 20:13:02 jgriffith: now I'm scared. there is stuff going on that I don't see ? 20:13:14 ttx: good things (I think) 20:13:17 russellb: it's still useful in many application in a single tenant mode -- but solving it for multi tenant is dramatically more difficult 20:13:23 So incubation is the process of taking a functional project and getting it fully integrated; I am feeling more and more that this is premature. 20:13:23 bswartz: cmiw... 20:13:31 the block management code/drivers won't stay 20:13:38 lifeless: same here 20:13:38 manilla will actually consume cinder resources 20:13:41 it's only since establishing the project that we've gotten the kinds of ideas and participation that have allowed us to come up with solutions 20:13:52 bswartz, you won't be able to run in the gate in any real way without multi tenancy, so that's really table stakes 20:13:57 lifeless: +1 for functional projects 20:14:13 The question i have is what can we do to help you get ready for integration? 20:14:19 AFAIK, one of the requirements for a project to be incubated is to have a stable API 20:14:24 lifeless: ++ 20:14:31 Is it a mentoring issue? Resources? Architecture? 20:14:50 I'm very excited by the idea of in the cloud fs's on demand :) 20:15:20 me too 20:15:21 if having a stable API is a requirement then we definitely don't have that 20:15:31 lifeless: I'm still trying to confirm that's the plan and what it *means* to manilla 20:15:31 sounds like we're not at the point of architectural stability, though 20:15:35 I didn't see that requirement listed anywhere 20:15:40 jgriffith: ack; thats important1 20:16:02 bswartz: https://wiki.openstack.org/wiki/Governance/Approved/NewProjectProcess#Process 20:16:05 so gating/devstack etc is kinda secondary right now IMO 20:16:05 markmc: it sounds to me like we aren't even sure what the feature set is 20:16:06 bswartz, gathering requirements here: https://etherpad.openstack.org/incubation-and-integration-requirements 20:16:09 bswartz: ok, so lets loop back around to jgriffith's point, which is the start of it all :) 20:16:10 bswartz: "incubation" is actually about integration with other openstack bits and the ability to deliver stuff in the common release every 6 months -- not really about project maturation 20:16:16 "The maturity of the project. Has it been used in production and deployed at scale?" 20:16:23 nothing about a stable API specifically 20:16:35 bswartz, so e.g. "Technical stability and architecture maturity" 20:16:46 * markmc has to drop off, sorry 20:17:18 but "need to rewrite in order to handle multi-tenant" is hard to reconcile with "mature" 20:17:30 okay so I'm hearing that this group expects projects to basically be complete by the time they enter incubation 20:17:54 base functional complete 20:18:00 I think it's safe to say at this point that this incubation request is a bit early. We can issue a statement that it sounds like a very interesting thing to have in openstack, though. 20:18:10 ttx: agreed 20:18:11 well, nothing is ever complete 20:18:17 bswartz: base functionality must exist 20:18:18 zaneb: +1 :) 20:18:24 ttx: +1 20:18:28 ttx: +1 20:18:35 ttx: + 20:18:37 ttx: +1 20:18:39 and ttx +1 20:18:39 ttx: +1 20:18:49 and I think we owe the community in general more clear incubation expectations 20:18:52 ttx: what about your proposal for a "OpenStack Emerging Technology project" designation 20:18:55 which is something we have in progress 20:18:58 I have to drop off in a few mins but will be back I hope 20:19:10 honestly, I think we'll end up with a better formal definition of the incubation / integration bars in the near term 20:19:15 ttx: +1 20:19:15 Just to throw a wrench in the works ;) 20:19:22 bswartz: it's a separate topic, we haven't discussed if that was actually a good idea. 20:19:24 russellb: +1 too :) 20:19:35 many people are looking for some kind of official blessing of the project 20:19:38 bswartz: but I'm fine with a formal statement saying the same we said to designate 20:19:41 my interests are only to build something that works 20:19:43 bswartz: I am so glad to hear you're getting good ideas before incubation though, keep it up 20:19:46 I think some good points were raised last week regarding what the *right* path is here 20:19:54 "looks awesome, come back when you're more ready" 20:20:05 + 20:20:15 "hey everyone, htat souhnds like a very nice project to spend time on" 20:20:23 err... "that sounds" 20:20:44 bswartz: in particular, no one has said "this is out of scope"; "we would like this in openstack" is a significant thing to take away from this. 20:21:15 jeblair: yeah that's the impression I've gotten for quite some time 20:21:20 bswartz: if we get to establish a "emerging tech" label, I'd definitely apply it to Manila 20:21:29 (and Designate) 20:21:49 Other comments before we move to next topic ? 20:22:03 okay so I heard we have a solution for devstack inclusion 20:22:13 what can we do with our tempests tests before we can be incubated? 20:22:31 tempest* 20:23:12 sdague: wanna answer this one ? 20:23:16 bswartz, that's a little more complicated, because tempest doesn't have a stable internal API. But we can chat in -qa later about options 20:23:26 sdague: thanks 20:23:47 sdague: i'm interested there too btw 20:24:10 russellb, sure. Though it's not really a great answer at this point. But lets take that there 20:24:16 yep] 20:24:19 and let ttx move on 20:24:21 #agreed We would like to have Manila in OpenStack one day, needs more maturation, solve multi-tenant concerns and get devstack-gate integration before revisiting incubation request 20:24:33 does that sum it up well enough ? 20:24:47 +1 20:24:50 +1 20:24:51 +1 20:24:52 Works for me 20:24:57 ok, moving on 20:25:02 #topic Program proposal: OpenStack User Experience 20:25:11 #link https://wiki.openstack.org/wiki/UX/ProgramProposal 20:25:20 So... Personally I'm a bit torn on this... I think UX should be a primary concern in every program... not necessarily needing a specific, separate program 20:25:31 IMHO "good user experience" is like "massive scalability", it's a design goal. Are we going to create a program for each design goal ? 20:25:45 ttx: s/UX/docs/ ? 20:25:46 So in the same way I want people caring about security and scalability in every project, I want UX-caring devs *in* every project 20:25:49 it's a bit like it 20:25:53 bit its also different 20:26:05 zaneb: docs end up producing stuff in a separate repo 20:26:06 zaneb: docs has specific output that exceeds the specific projects 20:26:09 massive scale is easier for technical devs to understand and execute (and even then its not easy) 20:26:15 so, we've said before that programs are largely about groups of people working together on some effort 20:26:16 true 20:26:20 what does the group of people look like here? 20:26:26 Having design goals under specific programs/teams doesn't look like the best way to get those concerns prioritized in each project core team 20:26:36 I see how separate teams could just create conflicts 20:26:39 it seemed pretty gui focussed as well. I was kind of wondering whether something like logging harmonization would fit there, or was considered by the group 20:27:26 so basically at this moment we are much more focused on GUI, it's the most obvious are where we can help 20:27:28 and CLIs 20:27:30 russellb: from the program proposal, it looks like it's mostly a group of devs focused on horizon 20:27:41 jeblair: yeah ... 20:27:47 but I'd like to hear an answer to russellb question 20:27:59 I don't really mind if people with UX experience work on various projects... I just question the need for an official progral to support this work 20:28:07 program* 20:28:08 but in general this is also about unification of command in CLI or API, where we didn't put much focus yet 20:28:13 they do talk about the CLI, and I talked to dtroyer about the work he has already done there -- he's interested in their input, but has already done a lot of the analysis for the cli 20:28:24 ttx: +1 20:28:27 the lack of a progral so far didn't prevent UX people to get involved in horizon 20:28:35 proograM, damn you keyboard 20:28:38 i'm not sure the unified CLI fits into this 20:28:38 right, I guess that was my question, what does being a program do to make it better, vs. just doing it? 20:28:50 i actually have been thinking that a program around clients could make sense 20:29:02 russellb, I was thinking the same thing re: clients 20:29:05 russellb: they specifically call out the cli work in the proposal 20:29:14 i know they do, just saying i'm not sure it makes sense 20:29:21 ttx: well one of the things is, that these people doesn't have to have much code contribution 20:29:39 ttx: and they deserve to be also recognized 20:29:45 russellb: hmm, why not? 20:29:46 jcoufal: did you see sdague's question about logs? more generally: would you consider "operator experience" part of UX? 20:30:05 jcoufal: we have a process set up to recognize those contributions though, you benefitted from it 20:30:12 internet failure :( 20:30:15 furthermore on sumit we have so little place to discuss various issues and it was very welcome to talk about those topics, but we were stealing slots from other projects 20:30:43 so summit session time is a tangle, I can understand that concern 20:30:46 jcoufal: i don't think it's stealing at all. projects _should_ be considering ux as part of their design... 20:30:48 jcoufal: I'd rather have UX concerns discussed in projects slots rather than on a specific track tbh 20:30:49 jeblair: not yet, but it sounds like it might belong into our are as well 20:30:52 tangible... also typing issues 20:30:56 ttx: +1000 20:31:05 ttx: +1 20:31:07 ttx: +1 20:31:15 this does get us back into the weeds on the need for some cross project tracks 20:31:16 russellb: one of the targets is also to setup official group of users/clients for testing 20:31:19 jcoufal: last thing you want is discuss UX in an echo chamber and then come and ask devs to do it 20:31:19 jcoufal: I'm just not sure how you separate the two effectively 20:31:27 jcoufal: other than providing valuable feed-back 20:31:45 jcoufal: if you're trying to drive the projects from this program I don't know how effective that would be 20:31:50 sdague: yes, I think there are smarter ways to address that concern 20:31:58 I think the main concern is that a lot of the user experience issues are cross project, focusing efforts in individual projects results in the inconsistencies we have today 20:32:06 jgriffith: we want to be very close to projects and support them, not driving actually 20:32:06 ttx: agreed 20:32:18 jcoufal: right, so why not participate directly? 20:32:26 jcoufal: rather than have a "separte" category 20:32:27 david-lyle: I agree with that, we need to have some cross-project time carved into next summit 20:32:30 we have had some success with technology choices across programs 20:32:36 e.g. pecan 20:32:37 jgriffith: because of the cross-project relations 20:32:49 jcoufal: I suspect we're talking in a circle :) 20:32:57 is there something about UX that works differently? 20:33:02 david-lyle: that's fair, I think however we can tackle it without a program per say. My intent with the log harmonizing was to just tiger team it for the cycle, grab a handful of interested folks and go after multiple projects 20:33:16 lifeless: differently then what? 20:33:26 ttx +1 for cross-project time 20:33:45 sdague: yes, and I don't think we need a log harmonization program to make it happen 20:33:50 sdague: and what keeps that effort going once logging has been normalized for now? 20:33:51 ttx: agreed 20:34:11 david-lyle: guidelines for the projects, which lead to reviewing rules 20:34:22 conceptually like HACKING.rst 20:34:25 jcoufal: I guess my point was if you have folks interested in doing this why can't they participate in the projects? 20:34:26 sdague: who do new projects go to with questions regarding logging standards, api standards, 20:34:26 If the key rationale behind this program request is to make sure there is time for cross-project UX discussion at the summit, I think that's the wrong solution for a real problem 20:34:30 fix the issue, set the guidelines, change the culture 20:34:34 jcoufal: regardless you're going to have to do that anyway IMO 20:34:39 jcoufal: how would folks be recognised as ATCs for this program? (for other programs it's from patches landed) 20:34:43 jcoufal: differently than the way we code convergence on technology stack 20:35:05 jcoufal: which was folk having discussions on the list and IRC and doing the odd experiment + reporting back. 20:35:25 I think the hope here is to help user experience, via testing/surverys/design guide future practices 20:35:41 zaneb: yes, that was my concern #2 about this : who would be considered an ATC under this program ? Who would vote in its PTL election ? What would constitute "contribution" to it ? 20:35:43 that the results are documented in a common location 20:36:36 zaneb: I'd rather have existing PTLs proposing UX people for ATC in their own program, like Gabriel did for Jaromir last cycle 20:36:39 I think most of the arguments related to this program could be discussed in the mailing-list and that'd benefit the community overall 20:36:44 zaneb: we don't have it decided yet, I need to have a look and agree on that, but I expect contribution in delivered solutions, supporting questions, contributing in duscussion, then the person should be proposed and accepted 20:36:44 ttx: +1 20:37:12 ttx: yes, something similar, nothing automatic 20:37:42 jcoufal: it's actually easier to do if you don't have a program and a PTL yourself 20:38:41 so my summary so far is that no TC member is really excited by this, and we'd rather fix summit to make sure UX is properly prioritized and discussed, rather than create a program for it ? 20:38:47 ttx: yeah, you don't have to bootstrap some source of legitimacy that way ;) 20:39:27 ttx: mmm 20:39:28 so 20:39:37 UX is something that I'd prefer all projects to take under consideration - I'm not saying this is not the case - rather than having a single program that takes care of it. I'd like to see all this discussions - UX ones - happening in the mailing list and have projects chiming in 20:39:42 I think UX is important, often poorly understood and hard for non-experts to deliver on. 20:39:53 I think we need to do more than say 'yeah, talk @ the summit.' 20:39:55 jcoufal: I know having to crash into horizon slots was unconfortable last summit, but we want to have time for cross-project stuff next time 20:40:13 e.g. I'd like to put some guidance directly to programs to engage with UX in the same way we do for engaging with docs. 20:40:46 lifeless: yeah, I wanted to use docs example as well 20:41:12 I have questions about having this as a separate program, but I also have questions about the proposal in front of us. It looks like a lot of things that will be done, but not things that have been done. We just told the Manilla folks we wouldn't incubate them under similar circumstances. Should we let the team start doing some of the work they have planned before we decide on whether it should be a program? 20:41:20 dhellmann: +1 20:41:29 lifeless: the end result for docs is that it's almost a completely separate team though. I feel like having UX people infiltrating projects rather than bing a standalone expert group makes more sense 20:41:39 ttx: I agree with that. 20:41:52 ttx: It doesn't conflict with what I said AFAICT. 20:41:52 ttx: there definitely is a need for an embedded nature 20:42:20 lifeless: so I see them as the OSSG (opensatck security group). They have a list, a meeting, people can tap in it. Not a progral though. 20:42:34 program* 20:42:42 ttx: is there a chance that having a UX program would encourage more companies to hire UX folks to work on OpenStack? 20:43:00 zaneb: that would also make a poor reason for creating it 20:43:01 * anteaya hands ttx a new keyboard with an M 20:43:06 ttx: I think we're talking past each other. 20:43:23 lifeless: that happens 20:43:23 ttx: I'm not talking about how it's structured. I'm talking about how we help achieve success within the programs. 20:43:45 zaneb: I believe it might encourage companies to being more involved 20:43:52 lifeless: concrete steps is the only way to achieve success imo 20:44:03 ttx: I have not disagreed with any of your comments on structure. But it seems clear to me that structure alone won't be very successful, based on previous observation of UX <-> programmer interactions. 20:44:15 vishy: yup; actionable items! 20:44:25 take an idea like standardize logs or implement pagination in all apis 20:44:25 ttx: it's entirely possible that a lot of companies don't even know there's a place/need for UX folks 20:44:28 and make it happen 20:44:54 the only way to gain cross-project respect is to actually achieve something 20:45:00 hmm, looks like we may need to continue this one next week, I want to cover a bit more ground today 20:45:05 vishy: we have a launchpad at the moment of stuff which we need to attack, currently full of horizon / tuskar stuff (GUI) 20:45:11 since the projects are all technical meritocracies 20:45:19 but should get filled with logs, etc 20:45:34 once the projects see value, then there is room for turning it into a program or some such 20:45:35 jcoufal: is it a separate project, or a tag ? 20:45:45 ttx: separate launchpad 20:45:53 until then it will just seem like a degree from on high and it won't go anywhere 20:45:53 https://launchpad.net/openstack-ux 20:46:01 vishy: decree? 20:46:05 *decree 20:46:06 aye 20:46:09 jcoufal: and I think that's symptomatic of the problem here. You want to evangelize UX, not do it separately 20:46:13 but it's very new 20:46:30 yeh, it seems like this should be a tag on existing bug trackers 20:46:32 not it's own 20:46:35 if you have bugs that "normal" developers never see... not the vbest way to get them to care about ux 20:46:37 if this is about cross project things 20:46:52 +1 to tags 20:47:08 that said you can also target the bug at both projects 20:47:12 Basically I see UX as an advocacy thing. Maybe I'm wrong, but like for security, I'd like for everyone to care about it a bit 20:47:19 +1 20:47:26 ttx: +1 20:47:32 and making a separate team is not the best way to achieve that 20:47:33 ttx: I agree that everyone should care about it, but someone has to set the standards 20:47:44 and that needs to be actionable items 20:47:49 vishy: +1 20:47:51 ttx: who will be creating the guidlines? 20:47:58 you still need champions 20:48:00 or we will have another year of "boy wouldn't it be great if the logs in nova didn't suck" 20:48:01 vishy: and teach others what those standards are 20:48:39 jcoufal: UX-caring people, discussing on [UX] threads on the ml ? 20:49:05 jcoufal: honestly, I think you can champion it without being an official program. In most cases people are looking for guidance, and if there are solid recommendations out there, people will follow them instead of doing their own thing 20:49:09 i would say write a plan for one area and start implementing it 20:49:29 vishy: +1, start on something concrete 20:49:31 vishy: +1 20:49:43 jcoufal: if people know where to find you they will come to you 20:50:04 so I propose, as the next step, to push this discussion to the ML (the original post didn't trigger anything) -- at the very least it should show that we care about UX so much that we prefer it everywhere rather than somewhere 20:50:07 * dhellmann sees baseball fields 20:50:29 dhellmann: ha 20:50:43 jcoufal: bring up UX issues to the mailing list 20:50:52 jcoufal: a "how to push for better UX in projects" thread. 20:51:06 I'm pretty sure there are common UX issues among several of OS projects 20:51:20 then if consensus is that a program is the best way to achieve that, then why not. But I think there are better ways of achieving those goals 20:51:43 alright, let's move to ML 20:52:19 ok, let's skip next topic and cover the governance repo schanges in progress before the end of the meeting 20:52:23 #topic Other governance changes in progress 20:52:33 We have a set of changes for review on the governance repo, which I'll accept once they get YES from the majority of voters 20:52:39 Amend TC charter language to reflect Gender Parity: https://review.openstack.org/#/c/56150 20:52:50 less bias FTW 20:52:57 that one is pretty obvious, yes 20:53:02 Change Ceilometer official name to OpenStack Telemetry: https://review.openstack.org/#/c/56402/ 20:53:13 So, about this one -- the responsibility for picking the OpenStack official name is a bit of a grey area, so we need to make sure we also include folks like the marketing team in the naming loop 20:53:50 so I'd hold until they bless it 20:53:54 holy mixed metaphor, batman! 20:54:01 it's a generic term, so hopefully it won't cause any trouble ... 20:54:04 ttx: i'm not sure about the responsibility being a grey area, but i'm supportive of including the marketing team's input. 20:54:11 friendly hint to jd__ to update the wiki with all the refs 20:54:22 isn't it a legal question? 20:54:23 it's still called the metering meeting, for instance 20:54:26 trademark search etc? 20:54:38 sdague: I think we're waiting for approval before changing everything 20:54:41 lifeless: generally not because it's a function, but yeh 20:54:47 dhellmann: ok, fair 20:55:09 anyway, it's just a question of waiting a few more days to let Lauren come back from vacation 20:55:16 ttx: was Metering thrown out by the ceilometer team itself? 20:55:22 (by thrown out I mean discarded) 20:55:27 annegentle: I think so yes 20:55:34 no longer reflected their full scope 20:55:39 rats, I was rooting for not having to change docs 20:55:44 so far those names were mostly some form of consensus 20:56:09 last one on the board is Update PTLs: https://review.openstack.org/#/c/57079/ 20:56:34 pretty obvious cleanup too, will APRV it once it gets 7 +2s 20:56:34 i'll have another one soon ... adding a mission statement for the compute program 20:56:37 ttx: do we need a full TC vote on that one? it seems pretty mechanical 20:56:46 posted to the ML for feedback before submitting to the governance repo ... http://lists.openstack.org/pipermail/openstack-dev/2013-November/019677.html 20:57:16 mordred: good point, that one seems like it's just updating a statement of the outcome of the election, which is already published and accepted 20:57:16 mordred: then it should get 7 +2s quite easily :) Not suire how I can make calls on what needs a formal vote and what doesn't 20:57:48 mordred: if you trust me, I'll make those calls as chair, but I don't want to abuse my APRV power 20:58:00 * russellb trusts you fwiw 20:58:03 ttx: I think we can trust you 20:58:08 and if you abuse, we'll remove you 20:58:11 right :) 20:58:14 pitchforks and all 20:58:18 * dhellmann cracks knuckles 20:58:19 we really need autopublish to the wiki soon with all these changes, what's the latest on that? 20:58:24 ttx: i think factual updates and typos are ok for the chair to update without votes 20:58:26 hahahahaha. my evil plan worked 20:58:27 ++ 20:58:39 jeblair: ++ 20:58:51 +1 20:58:56 I can now rule the galaxy^W^W^Wpush changes to a repo 20:58:57 annegentle: do we really want to autopublish to the wiki, or do another docs tree instead for some of the more official docs? 20:59:14 it feels weird to publish static documents to a wiki 20:59:23 sdague, annegentle: yeah, i think we wanted more of a docs-publish location and deprecate the wiki... 20:59:26 yeh, I think that's a discussion for anotehr day 20:59:27 link to cgit from the wiki? 20:59:33 jeblair: sdague: oh, ok 20:59:38 dhellmann: one side of the issue is that we have URLs we'd like to preserve 20:59:47 some of them bing in the damn BYLAWS. 20:59:47 edit the pages with links to the new locations 20:59:54 annegentle: but I'm with you on using these as the source of truth 21:00:13 (well, in bylaws appendixes, but you get the idea) 21:00:17 ttx: also on that subject, i'd like to change the acls (as i suggested in my message on this way back) so that tc members can vote +/-1, and non members may only leave comments; chair can vote +/-2 and aprv 21:00:34 jeblair: hmm, why ? 21:00:43 that would make it easier to count the votes 21:01:12 for two reasons: dhellmann's is the first. and second: i do not believe the tc membership has a right to veto motions, which is what a -2 is. 21:01:16 dhellmann: I kinda liked giving ordinary people the right to express their opinion though 21:01:27 jeblair: ++ 21:01:30 ttx: definitely not suggesting that people can't or should not express their opinion 21:01:32 ttx: everyone can comment 21:01:36 ttx: only saying they shouldn't vote. 21:01:36 can we just remove -2? 21:01:43 and only have +2 (and +/-1) 21:01:46 russellb: that's how I count "no" 21:01:54 we need to count 'no' 21:02:00 russellb: we can, but then why would we vote +1 ever? it seems odd 21:02:09 right 21:02:24 jeblair: so... ok, better do it now while nobody is actually attached to that 21:02:31 and we are way over time 21:02:32 ttx: i believe you have just expressed the most succinct reason this needs to be done 21:02:43 if there were a controversial measure, wouldn't it be nice to see a summary of how many non-tc folks were for or against? 21:02:52 * jd__ nods 21:02:58 markwash: yeah, that was my concern 21:03:01 (-2 is not possible, and member -1 is not distinguishable from non-member -1) 21:03:19 unless you refer to the TC member list 21:03:19 jeblair: you and ttx are interpreting -2 in different ways 21:03:27 I think a high comment volume would get our attention 21:03:33 -2 has a meaning in gerrit that we can't avoid 21:03:40 dhellmann: gerrit is interpreting it differently. :) 21:03:40 it's not about interpretation 21:03:49 jeblair: fair enough 21:03:52 we have a problem if some members vote "no" using their -2s but there are more YES and the motion should be approved. 21:04:02 once we're on 2.8, we might be able to re-add non-member votes 21:04:05 those -2s will prevent us from approving 21:04:12 jeblair: so fix it. 21:04:17 ttx: will do. 21:04:17 #endmeeting