20:03:17 <ttx> #startmeeting tc
20:03:18 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:22 <openstack> The meeting name has been set to 'tc'
20:03:27 <ttx> Our agenda today:
20:03:31 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:36 <ttx> busy busy
20:03:43 <ttx> #topic Manila incubation request: final discussion
20:03:51 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-October/016370.html
20:03:52 <bswartz> 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 <ttx> #link https://wiki.openstack.org/wiki/Manila_Overview
20:04:06 <markmc> bswartz, did you see the logs and https://etherpad.openstack.org/p/ManilaIncubationApplication ?
20:04:10 <bswartz> 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 <markmc> lots of questions in there
20:04:16 <bswartz> markmc: yes I did
20:04:27 <ttx> 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 <bswartz> I'm happy to answer those today
20:04:35 <ttx> Both in terms of number of commits and number of developers involved
20:04:42 <ttx> (We rejected Designate on similar grounds over the last cycle)
20:04:54 <mordred> o/
20:05:02 <ttx> Also seemed like Manila could benefit from another round of discussion regarding its relationship with Cinder
20:05:04 <annegentle> o/ here
20:05:10 <bswartz> so I understood that designate was basically a one-company effort
20:05:15 <ttx> So all in all it appeared to be a bit early to consider incubation.
20:05:21 <bswartz> there is broad interst in Manila, if not active participation as of yet
20:05:40 <mordred> bswartz: yah. that was the main thing with designate too
20:05:50 <mordred> broad support, not tons of multi-company participation yet
20:06:15 <ttx> 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 <bswartz> so we have several companies interested in working on back ends
20:06:23 <russellb> ttx: +1
20:06:29 <ttx> 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 <bswartz> the main thing stopping them is that we recognized some archtectural limitations and we're working on addressing those
20:06:37 <ttx> Like "OpenStack Emerging Technology project"
20:06:46 <jeblair> 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 <dhellmann> nurtured?
20:06:52 <ttx> 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 <jgriffith> o/
20:08:59 <jeblair> ttx: we should be _really_ _really_ careful with that
20:08:59 <bswartz> 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 <ttx> bswartz: it might be relevant to address those issues before getting into incubation
20:08:59 <mordred> yeah - I'm not sure we need new catagories
20:08:59 <bswartz> what we want is to be allowed to integrate with things such as devstack/tempest
20:08:59 <russellb> you just need more contributors :)
20:08:59 <vishy> o/
20:08:59 <mordred> I think the TC even saying "hey man, we like that, good job"
20:08:59 <russellb> so how do we help you get more contribution?
20:09:12 <jeblair> ttx: there's already a tendency for stackforge projects to overstate their involvement in openstack
20:09:12 <bswartz> it makes things a lot easier when we can fit into the mold that other projects use
20:09:12 <ttx> 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 <russellb> you can already integrate with devstack, and even devstack-gate, easily
20:09:59 <ttx> so I hesitate in proposing that for manila
20:09:59 <russellb> ttx: it's either that, or lowering the bar for incubation, right?
20:09:59 <annegentle> I want to hear from jgriffith
20:09:59 <ttx> also I think I'd like us to adopt sdague's constraints on new incubated projects sooner rather than later
20:09:59 <jgriffith> annegentle: haha
20:09:59 <dhellmann> should we have the meta-discussion about badges first?
20:09:59 <bswartz> 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 <flaper87> 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 <jgriffith> so we seem to have skipped past that initial discussion/convo
20:09:59 <sdague> ttx, yeh, I'd really like to not add another project to incubation until we decide on that
20:09:59 <flaper87> while being incubated
20:09:59 <jeblair> 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 <lifeless> bswartz: what are the technical hurdles?
20:10:00 <annegentle> jgriffith: I think yes we need technical discussion :)
20:10:05 * annegentle needs to type faster
20:10:08 <jgriffith> I'd like a better idea of scope/direction of the project
20:10:11 <bswartz> 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 <russellb> yeah i just did it with a couple hours work for solum yesterday
20:10:27 <lifeless> bswartz: see the patchset to enable it in solum
20:10:33 <lifeless> bswartz: it's pretty self explanatory
20:10:41 <jgriffith> bswartz: see my comment above ^^
20:10:54 <lifeless> bswartz: https://review.openstack.org/#/c/57036/
20:11:08 <bswartz> lifeless: thanks
20:11:27 <lifeless> bswartz: what are the technical hurdles you face?
20:11:37 <jgriffith> bswartz: I know we talked about the LVM question
20:11:43 <russellb> bswartz: and related, https://review.openstack.org/#/c/57098
20:11:50 <ttx> bswartz: so it's extremely likely that we'd require you to have gate jobs before being accepted into incubation
20:11:55 <bswartz> 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 <bswartz> we've been working for the last 3 months on designing that and it's about ready to go in
20:12:13 <jgriffith> ttx: bswartz can we first get a better idea of what the goal is here?
20:12:21 <lifeless> bswartz: wow
20:12:23 <russellb> that's a pretty fundamental requirement for openstack things :)
20:12:29 <russellb> if that's not there yet ...
20:12:37 <jgriffith> ttx: bswartz the code is not necessarily idicative right now based on conversations I had with bswartz
20:12:50 <jgriffith> s/idicative/indicative/
20:13:02 <ttx> jgriffith: now I'm scared. there is stuff going on that I don't see ?
20:13:14 <jgriffith> ttx: good things (I think)
20:13:17 <bswartz> 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 <lifeless> 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 <jgriffith> bswartz: cmiw...
20:13:31 <jgriffith> the block management code/drivers won't stay
20:13:38 <ttx> lifeless: same here
20:13:38 <jgriffith> manilla will actually consume cinder resources
20:13:41 <bswartz> 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 <sdague> 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 <flaper87> lifeless: +1 for functional projects
20:14:13 <lifeless> The question i have is what can we do to help you get ready for integration?
20:14:19 <flaper87> AFAIK, one of the requirements for a project to be incubated is to have a stable API
20:14:24 <russellb> lifeless: ++
20:14:31 <lifeless> Is it a mentoring issue? Resources? Architecture?
20:14:50 <lifeless> I'm very excited by the idea of in the cloud fs's on demand :)
20:15:20 <markmc> me too
20:15:21 <bswartz> if having a stable API is a requirement then we definitely don't have that
20:15:31 <jgriffith> lifeless: I'm still trying to confirm that's the plan and what it *means* to manilla
20:15:31 <markmc> sounds like we're not at the point of architectural stability, though
20:15:35 <bswartz> I didn't see that requirement listed anywhere
20:15:40 <lifeless> jgriffith: ack; thats important1
20:16:02 <zaneb> bswartz: https://wiki.openstack.org/wiki/Governance/Approved/NewProjectProcess#Process
20:16:05 <jgriffith> so gating/devstack etc is kinda secondary right now IMO
20:16:05 <dhellmann> markmc: it sounds to me like we aren't even sure what the feature set is
20:16:06 <markmc> bswartz, gathering requirements here: https://etherpad.openstack.org/incubation-and-integration-requirements
20:16:09 <lifeless> bswartz: ok, so lets loop back around to jgriffith's point, which is the start of it all :)
20:16:10 <ttx> 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 <zaneb> "The maturity of the project. Has it been used in production and deployed at scale?"
20:16:23 <zaneb> nothing about a stable API specifically
20:16:35 <markmc> bswartz, so e.g. "Technical stability and architecture maturity"
20:16:46 * markmc has to drop off, sorry
20:17:18 <zaneb> but "need to rewrite in order to handle multi-tenant" is hard to reconcile with "mature"
20:17:30 <bswartz> okay so I'm hearing that this group expects projects to basically be complete by the time they enter incubation
20:17:54 <jgriffith> base functional complete
20:18:00 <ttx> 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 <jeblair> ttx: agreed
20:18:11 <zaneb> well, nothing is ever complete
20:18:17 <flaper87> bswartz: base functionality must exist
20:18:18 <jgriffith> zaneb: +1 :)
20:18:24 <sdague> ttx: +1
20:18:28 <russellb> ttx: +1
20:18:35 <markmcclain> ttx:	+
20:18:37 <dhellmann> ttx: +1
20:18:39 <flaper87> and ttx +1
20:18:39 <markmcclain> ttx: +1
20:18:49 <russellb> and I think we owe the community in general more clear incubation expectations
20:18:52 <bswartz> ttx: what about your proposal for a "OpenStack Emerging Technology project" designation
20:18:55 <russellb> which is something we have in progress
20:18:58 <annegentle> I have to drop off in a few mins but will be back I hope
20:19:10 <sdague> honestly, I think we'll end up with a better formal definition of the incubation / integration bars in the near term
20:19:15 <lifeless> ttx: +1
20:19:15 <jgriffith> Just to throw a wrench in the works ;)
20:19:22 <ttx> bswartz: it's a separate topic, we haven't discussed if that was actually a good idea.
20:19:24 <lifeless> russellb: +1 too :)
20:19:35 <bswartz> many people are looking for some kind of official blessing of the project
20:19:38 <ttx> bswartz: but I'm fine with a formal statement saying the same we said to designate
20:19:41 <bswartz> my interests are only to build something that works
20:19:43 <annegentle> bswartz: I am so glad to hear you're getting good ideas before incubation though, keep it up
20:19:46 <jgriffith> I think some good points were raised last week regarding what the *right* path is here
20:19:54 <ttx> "looks awesome, come back when you're more ready"
20:20:05 <ttx> +
20:20:15 <ttx> "hey everyone, htat souhnds like a very nice project to spend time on"
20:20:23 <ttx> err... "that sounds"
20:20:44 <jeblair> 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 <bswartz> jeblair: yeah that's the impression I've gotten for quite some time
20:21:20 <ttx> bswartz: if we get to establish a "emerging tech" label, I'd definitely apply it to Manila
20:21:29 <ttx> (and Designate)
20:21:49 <ttx> Other comments before we move to next topic ?
20:22:03 <bswartz> okay so I heard we have a solution for devstack inclusion
20:22:13 <bswartz> what can we do with our tempests tests before we can be incubated?
20:22:31 <bswartz> tempest*
20:23:12 <ttx> sdague: wanna answer this one ?
20:23:16 <sdague> 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 <bswartz> sdague: thanks
20:23:47 <russellb> sdague: i'm interested there too btw
20:24:10 <sdague> russellb, sure. Though it's not really a great answer at this point. But lets take that there
20:24:16 <russellb> yep]
20:24:19 <sdague> and let ttx move on
20:24:21 <ttx> #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 <ttx> does that sum it up well enough ?
20:24:47 <dhellmann> +1
20:24:50 <markmcclain> +1
20:24:51 <sdague> +1
20:24:52 <mikal> Works for me
20:24:57 <ttx> ok, moving on
20:25:02 <ttx> #topic Program proposal: OpenStack User Experience
20:25:11 <ttx> #link https://wiki.openstack.org/wiki/UX/ProgramProposal
20:25:20 <ttx> 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 <ttx> 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 <zaneb> ttx: s/UX/docs/ ?
20:25:46 <ttx> 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 <lifeless> it's a bit like it
20:25:53 <lifeless> bit its also different
20:26:05 <ttx> zaneb: docs end up producing stuff in a separate repo
20:26:06 <jeblair> zaneb: docs has specific output that exceeds the specific projects
20:26:09 <lifeless> massive scale is easier for technical devs to understand and execute (and even then its not easy)
20:26:15 <russellb> so, we've said before that programs are largely about groups of people working together on some effort
20:26:16 <zaneb> true
20:26:20 <russellb> what does the group of people look like here?
20:26:26 <ttx> 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 <ttx> I see how separate teams could just create conflicts
20:26:39 <sdague> 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 <jcoufal> 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 <flaper87> and CLIs
20:27:30 <jeblair> russellb: from the program proposal, it looks like it's mostly a group of devs focused on horizon
20:27:41 <russellb> jeblair: yeah ...
20:27:47 <flaper87> but I'd like to hear an answer to russellb question
20:27:59 <ttx> 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 <ttx> program*
20:28:08 <jcoufal> 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 <dhellmann> 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 <flaper87> ttx: +1
20:28:27 <ttx> the lack of a progral so far didn't prevent UX people to get involved in horizon
20:28:35 <ttx> proograM, damn you keyboard
20:28:38 <russellb> i'm not sure the unified CLI fits into this
20:28:38 <sdague> right, I guess that was my question, what does being a program do to make it better, vs. just doing it?
20:28:50 <russellb> i actually have been thinking that a program around clients could make sense
20:29:02 <sdague> russellb, I was thinking the same thing re: clients
20:29:05 <dhellmann> russellb: they specifically call out the cli work in the proposal
20:29:14 <russellb> i know they do, just saying i'm not sure it makes sense
20:29:21 <jcoufal> ttx: well one of the things is, that these people doesn't have to have much code contribution
20:29:39 <jcoufal> ttx: and they deserve to be also recognized
20:29:45 <dhellmann> russellb: hmm, why not?
20:29:46 <jeblair> jcoufal: did you see sdague's question about logs?  more generally: would you consider "operator experience" part of UX?
20:30:05 <ttx> jcoufal: we have a process set up to recognize those contributions though, you benefitted from it
20:30:12 <vishy> internet failure :(
20:30:15 <jcoufal> 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 <sdague> so summit session time is a tangle, I can understand that concern
20:30:46 <jeblair> jcoufal: i don't think it's stealing at all.  projects _should_ be considering ux as part of their design...
20:30:48 <ttx> jcoufal: I'd rather have UX concerns discussed in projects slots rather than on a specific track tbh
20:30:49 <jcoufal> jeblair: not yet, but it sounds like it might belong into our are as well
20:30:52 <sdague> tangible... also typing issues
20:30:56 <jgriffith> ttx: +1000
20:31:05 <markmcclain> ttx: +1
20:31:07 <flaper87> ttx: +1
20:31:15 <sdague> this does get us back into the weeds on the need for some cross project tracks
20:31:16 <jcoufal> russellb: one of the targets is also to setup official group of users/clients for testing
20:31:19 <ttx> jcoufal: last thing you want is discuss UX in an echo chamber and then come and ask devs to do it
20:31:19 <jgriffith> jcoufal: I'm just not sure how you separate the two effectively
20:31:27 <jgriffith> jcoufal: other than providing valuable feed-back
20:31:45 <jgriffith> jcoufal: if you're trying to drive the projects from this program I don't know how effective that would be
20:31:50 <ttx> sdague: yes, I think there are smarter ways to address that concern
20:31:58 <david-lyle> 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 <jcoufal> jgriffith: we want to be very close to projects and support them, not driving actually
20:32:06 <sdague> ttx: agreed
20:32:18 <jgriffith> jcoufal: right, so why not participate directly?
20:32:26 <jgriffith> jcoufal: rather than have a "separte" category
20:32:27 <ttx> david-lyle: I agree with that, we need to have some cross-project time carved into next summit
20:32:30 <lifeless> we have had some success with technology choices across programs
20:32:36 <lifeless> e.g. pecan
20:32:37 <jcoufal> jgriffith: because of the cross-project relations
20:32:49 <jgriffith> jcoufal: I suspect we're talking in a circle :)
20:32:57 <lifeless> is there something about UX that works differently?
20:33:02 <sdague> 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 <jcoufal> lifeless: differently then what?
20:33:26 <anteaya> ttx +1 for cross-project time
20:33:45 <ttx> sdague: yes, and I don't think we need a log harmonization program to make it happen
20:33:50 <david-lyle> sdague: and what keeps that effort going once logging has been normalized for now?
20:33:51 <sdague> ttx: agreed
20:34:11 <sdague> david-lyle: guidelines for the projects, which lead to reviewing rules
20:34:22 <sdague> conceptually like HACKING.rst
20:34:25 <jgriffith> 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 <david-lyle> sdague: who do new projects go to with questions regarding logging standards, api standards,
20:34:26 <ttx> 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 <sdague> fix the issue, set the guidelines, change the culture
20:34:34 <jgriffith> jcoufal: regardless you're going to have to do that anyway IMO
20:34:39 <zaneb> jcoufal: how would folks be recognised as ATCs for this program? (for other programs it's from patches landed)
20:34:43 <lifeless> jcoufal: differently than the way we code convergence on technology stack
20:35:05 <lifeless> jcoufal: which was folk having discussions on the list and IRC and doing the odd experiment + reporting back.
20:35:25 <david-lyle> I think the hope here is to help user experience, via testing/surverys/design guide future practices
20:35:41 <ttx> 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 <david-lyle> that the results are documented in a common location
20:36:36 <ttx> 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 <flaper87> 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 <jcoufal> 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 <flaper87> ttx: +1
20:37:12 <jcoufal> ttx: yes, something similar, nothing automatic
20:37:42 <ttx> jcoufal: it's actually easier to do if you don't have a program and a PTL yourself
20:38:41 <ttx> 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 <zaneb> ttx: yeah, you don't have to bootstrap some source of legitimacy that way ;)
20:39:27 <lifeless> ttx: mmm
20:39:28 <lifeless> so
20:39:37 <flaper87> 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 <lifeless> I think UX is important, often poorly understood and hard for non-experts to deliver on.
20:39:53 <lifeless> I think we need to do more than say 'yeah, talk @ the summit.'
20:39:55 <ttx> 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 <lifeless> 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 <jcoufal> lifeless: yeah, I wanted to use docs example as well
20:41:12 <dhellmann> 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 <lifeless> dhellmann: +1
20:41:29 <ttx> 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 <lifeless> ttx: I agree with that.
20:41:52 <lifeless> ttx: It doesn't conflict with what I said AFAICT.
20:41:52 <david-lyle> ttx: there definitely is a need for an embedded nature
20:42:20 <ttx> 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 <ttx> program*
20:42:42 <zaneb> 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 <ttx> 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 <lifeless> ttx: I think we're talking past each other.
20:43:23 <ttx> lifeless: that happens
20:43:23 <lifeless> 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 <jcoufal> zaneb: I believe it might encourage companies to being more involved
20:43:52 <vishy> lifeless: concrete steps is the only way to achieve success imo
20:44:03 <lifeless> 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 <lifeless> vishy: yup; actionable items!
20:44:25 <vishy> take an idea like standardize logs or implement pagination in all apis
20:44:25 <zaneb> 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 <vishy> and make it happen
20:44:54 <vishy> the only way to gain cross-project respect is to actually achieve something
20:45:00 <ttx> hmm, looks like we may need to continue this one next week, I want to cover a bit more ground today
20:45:05 <jcoufal> 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 <vishy> since the projects are all technical meritocracies
20:45:19 <jcoufal> but should get filled with logs, etc
20:45:34 <vishy> once the projects see value, then there is room for turning it into a program or some such
20:45:35 <ttx> jcoufal: is it a separate project, or a tag ?
20:45:45 <jcoufal> ttx: separate launchpad
20:45:53 <vishy> until then it will just seem like a degree from on high and it won't go anywhere
20:45:53 <jcoufal> https://launchpad.net/openstack-ux
20:46:01 <lifeless> vishy: decree?
20:46:05 <vishy> *decree
20:46:06 <vishy> aye
20:46:09 <ttx> jcoufal: and I think that's symptomatic of the problem here. You want to evangelize UX, not do it separately
20:46:13 <jcoufal> but it's very new
20:46:30 <sdague> yeh, it seems like this should be a tag on existing bug trackers
20:46:32 <sdague> not it's own
20:46:35 <ttx> if you have bugs that "normal" developers never see... not the vbest way to get them to care about ux
20:46:37 <sdague> if this is about cross project things
20:46:52 <vishy> +1 to tags
20:47:08 <vishy> that said you can also target the bug at both projects
20:47:12 <ttx> 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 <markmcclain> +1
20:47:26 <flaper87> ttx: +1
20:47:32 <ttx> and making a separate team is not the best way to achieve that
20:47:33 <vishy> ttx: I agree that everyone should care about it, but someone has to set the standards
20:47:44 <vishy> and that needs to be actionable items
20:47:49 <sdague> vishy: +1
20:47:51 <jcoufal> ttx: who will be creating the guidlines?
20:47:58 <sdague> you still need champions
20:48:00 <vishy> or we will have another year of "boy wouldn't it be great if the logs in nova didn't suck"
20:48:01 <flaper87> vishy: and teach others what those standards are
20:48:39 <ttx> jcoufal: UX-caring people, discussing on [UX] threads on the ml ?
20:49:05 <sdague> 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 <vishy> i would say write a plan for one area and start implementing it
20:49:29 <dhellmann> vishy: +1, start on something concrete
20:49:31 <sdague> vishy: +1
20:49:43 <anteaya> jcoufal: if people know where to find you they will come to you
20:50:04 <ttx> 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 <anteaya> dhellmann: ha
20:50:43 <flaper87> jcoufal: bring up UX issues to the mailing list
20:50:52 <ttx> jcoufal: a "how to push for better UX in projects" thread.
20:51:06 <flaper87> I'm pretty sure there are common UX issues among several of OS projects
20:51:20 <ttx> 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 <jcoufal> alright, let's move to ML
20:52:19 <ttx> ok, let's skip next topic and cover the governance repo schanges in progress before the end of the meeting
20:52:23 <ttx> #topic Other governance changes in progress
20:52:33 <ttx> 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 <ttx> Amend TC charter language to reflect Gender Parity: https://review.openstack.org/#/c/56150
20:52:50 <lifeless> less bias FTW
20:52:57 <ttx> that one is pretty obvious, yes
20:53:02 <ttx> Change Ceilometer official name to OpenStack Telemetry: https://review.openstack.org/#/c/56402/
20:53:13 <ttx> 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 <ttx> so I'd hold until they bless it
20:53:54 <zaneb> holy mixed metaphor, batman!
20:54:01 <russellb> it's a generic term, so hopefully it won't cause any trouble ...
20:54:04 <jeblair> 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 <sdague> friendly hint to jd__ to update the wiki with all the refs
20:54:22 <lifeless> isn't it a legal question?
20:54:23 <sdague> it's still called the metering meeting, for instance
20:54:26 <lifeless> trademark search etc?
20:54:38 <dhellmann> sdague: I think we're waiting for approval before changing everything
20:54:41 <ttx> lifeless: generally not because it's a function, but yeh
20:54:47 <sdague> dhellmann: ok, fair
20:55:09 <ttx> anyway, it's just a question of waiting a few more days to let Lauren come back from vacation
20:55:16 <annegentle> ttx: was Metering thrown out by the ceilometer team itself?
20:55:22 <annegentle> (by thrown out I mean discarded)
20:55:27 <ttx> annegentle: I think so yes
20:55:34 <russellb> no longer reflected their full scope
20:55:39 <annegentle> rats, I was rooting for not having to change docs
20:55:44 <ttx> so far those names were mostly some form of consensus
20:56:09 <ttx> last one on the board is Update PTLs: https://review.openstack.org/#/c/57079/
20:56:34 <ttx> pretty obvious cleanup too, will APRV it once it gets 7 +2s
20:56:34 <russellb> i'll have another one soon ... adding a mission statement for the compute program
20:56:37 <mordred> ttx: do we need a full TC vote on that one? it seems pretty mechanical
20:56:46 <russellb> 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 <dhellmann> 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 <ttx> 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 <ttx> 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 <mordred> ttx: I think we can trust you
20:58:08 <mordred> and if you abuse, we'll remove you
20:58:11 <russellb> right :)
20:58:14 <russellb> pitchforks and all
20:58:18 * dhellmann cracks knuckles
20:58:19 <annegentle> we really need autopublish to the wiki soon with all these changes, what's the latest on that?
20:58:24 <jeblair> ttx: i think factual updates and typos are ok for the chair to update without votes
20:58:26 <ttx> hahahahaha. my evil plan worked
20:58:27 <mordred> ++
20:58:39 <mordred> jeblair: ++
20:58:51 <lifeless> +1
20:58:56 <ttx> I can now rule the galaxy^W^W^Wpush changes to a repo
20:58:57 <sdague> 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 <dhellmann> it feels weird to publish static documents to a wiki
20:59:23 <jeblair> sdague, annegentle: yeah, i think we wanted more of a docs-publish location and deprecate the wiki...
20:59:26 <sdague> yeh, I think that's a discussion for anotehr day
20:59:27 <russellb> link to cgit from the wiki?
20:59:33 <annegentle> jeblair: sdague: oh, ok
20:59:38 <ttx> dhellmann: one side of the issue is that we have URLs we'd like to preserve
20:59:47 <ttx> some of them bing in the damn BYLAWS.
20:59:47 <dhellmann> edit the pages with links to the new locations
20:59:54 <sdague> annegentle: but I'm with you on using these as the source of truth
21:00:13 <ttx> (well, in bylaws appendixes, but you get the idea)
21:00:17 <jeblair> 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 <ttx> jeblair: hmm, why ?
21:00:43 <dhellmann> that would make it easier to count the votes
21:01:12 <jeblair> 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 <ttx> dhellmann: I kinda liked giving ordinary people the right to express their opinion though
21:01:27 <mordred> jeblair: ++
21:01:30 <jeblair> ttx: definitely not suggesting that people can't or should not express their opinion
21:01:32 <dhellmann> ttx: everyone can comment
21:01:36 <jeblair> ttx: only saying they shouldn't vote.
21:01:36 <russellb> can we just remove -2?
21:01:43 <russellb> and only have +2 (and +/-1)
21:01:46 <ttx> russellb: that's how I count "no"
21:01:54 <ttx> we need to count 'no'
21:02:00 <mordred> russellb: we can, but then why would we vote +1 ever? it seems odd
21:02:09 <russellb> right
21:02:24 <ttx> jeblair: so... ok, better do it now while nobody is actually attached to that
21:02:31 <ttx> and we are way over time
21:02:32 <jeblair> ttx: i believe you have just expressed the most succinct reason this needs to be done
21:02:43 <markwash> 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 <ttx> markwash: yeah, that was my concern
21:03:01 <jeblair> (-2 is not possible, and member -1 is not distinguishable from non-member -1)
21:03:19 <anteaya> unless you refer to the TC member list
21:03:19 <dhellmann> jeblair: you and ttx are interpreting -2 in different ways
21:03:27 <markmcclain> I think a high comment volume would get our attention
21:03:33 <mordred> -2 has a meaning in gerrit that we can't avoid
21:03:40 <jeblair> dhellmann: gerrit is interpreting it differently.  :)
21:03:40 <mordred> it's not about interpretation
21:03:49 <dhellmann> jeblair: fair enough
21:03:52 <ttx> 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 <mordred> once we're on 2.8, we might be able to re-add non-member votes
21:04:05 <ttx> those -2s will prevent us from approving
21:04:12 <ttx> jeblair: so fix it.
21:04:17 <jeblair> ttx: will do.
21:04:17 <ttx> #endmeeting