23:01:18 <sarob> #startmeeting product-team
23:01:18 <openstack> Meeting started Wed Mar 18 23:01:18 2015 UTC and is due to finish in 60 minutes.  The chair is sarob. Information about MeetBot at http://wiki.debian.org/MeetBot.
23:01:19 <barrett1> Anyone here for the Product Work Group meeting?
23:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
23:01:22 <openstack> The meeting name has been set to 'product_team'
23:01:29 <sarob> roll call
23:01:37 <Rockyg> o/
23:01:40 <barrett1> Carol Barrett
23:01:48 <rolandchan> Roland Chan
23:01:48 * sgordon here
23:02:08 <Shamail> Hi
23:02:17 * sarob \o/
23:02:28 <gothicmindfood> o/
23:02:44 <sarob> excellent
23:02:50 <sarob> agenda
23:02:53 <sarob> #link https://wiki.openstack.org/wiki/Meetings/product-team
23:03:27 <sarob> barrett1: want to kick off what happenned at the ops midcycle?
23:04:02 <Rockyg> go for it!
23:04:19 <sarob> or anyone that was there...
23:04:22 <barrett1> Sure - I sent several emails to the group with info along the way
23:04:31 <sarob> #topic ops midcycle
23:04:32 <barrett1> I also posted info in our etherpad
23:05:02 <barrett1> We were able to talk with Operators, PTLs/Developers and Foundation folks
23:05:02 <sarob> which one?
23:05:08 <sarob> etherpad
23:05:23 <barrett1> Checking
23:06:13 <barrett1> https://etherpad.openstack.org/p/kilo-product-management-socialization
23:06:49 <sgordon> line 639 onwards
23:06:50 <barrett1> There was a placeholder at the end for feedback from Ops Meetup so I added the email info there
23:07:23 <sarob> im with you
23:07:42 <barrett1> I also edited the wiki page to add a link to the roadmap that includes the PTL interview info and PTL comments about what the PWG could do for them
23:08:17 <barrett1> We still are missing info on some key projects on intentions for K, L and M
23:08:19 <sarob> better color, thx
23:09:09 <sarob> i like the ttx feedback
23:10:03 <sarob> im confused to the not meeting with TC part
23:10:21 <sarob> since the TC is a cross section of the PTLs mostly
23:10:22 <rolandchan> yes, I think their buy in as a group is needed.
23:10:27 <sgordon> mostly
23:10:37 <sgordon> but i think what he is getting at is that is more coincidence than anything
23:10:37 <barrett1> Thierry didn't see a reason why we would need to meet with the TC, they don't approve this
23:10:44 <sgordon> as the PTL = TC link is long gone
23:10:59 <Rockyg> the xcpoject meeting, right after the TC meeting is where all the PTLs are supposed to gather and work together
23:11:06 <sgordon> so there are PTLs, of projects which are likely important to us, who arent on the TC
23:11:14 <sgordon> (plenty of them in fact)
23:11:15 <sgordon> right
23:11:16 <barrett1> Thierry suggested the xproject team because all PTLs are there and it's their meeting.
23:11:20 <sgordon> Rockyg +1
23:11:26 <sarob> rockyg: good point
23:11:39 <rolandchan> support != approval
23:11:42 <sarob> im fine starting with the xproject team
23:11:51 <sarob> the same peoples
23:11:54 <sarob> similar
23:12:17 <sarob> rolandchan: meaning?
23:13:05 <rolandchan> meaning there is value in having the TC say they support something even if they aren't in an approval chain for that thing.
23:13:33 <sarob> got it
23:13:49 <sarob> like being responsible rather than accountable
23:14:13 <sarob> maybe consulted or informed is better example
23:14:25 <barrett1> What we could take into the xproject meeting is goals, process, sample roadmap (from interviews), sample use case (which would be based upon Operators feedback and be the basis for populating the roadmap).
23:14:26 <Shamail> Wouldn't the TC want to be involved when a long-term roadmap is being proposed (based on PTL feedback) or since the roadmap is built using PTL feedback it doesn't require approval?
23:14:32 <rolandchan> yep. I think "consulted" is perfect.
23:14:55 <Rockyg> I believe that Thierry thinks if the PTLs all agree, he can feed the info back to th TC without issue (optimistically)
23:15:02 <barrett1> Does the TC "approve" the goals for each release for each project?
23:15:13 <sarob> barrett1: nope
23:15:19 <sarob> PTLs job
23:15:25 <sarob> PTLs rule
23:15:29 <sarob> dude
23:15:31 <Rockyg> sarob ++
23:15:37 <barrett1> I don't understand why the TC would be involved with the Roadmap either
23:15:42 <Shamail> Makes sense if we don't encounter disagreements.  I guess the bigger question is do we think it will be instances where this agreement may arise?
23:16:03 <Shamail> blah auto correct
23:16:12 <sarob> i wanted to socialize with the TC what we are doing
23:16:17 <sarob> rather than get approval
23:16:19 <Shamail> This agreement = disagreements
23:16:22 <Rockyg> There will be priority issues on getting mulitple PTLs on the same page
23:16:34 <barrett1> Rocky ++
23:17:03 <jogo> why not socialize on the openstack-dev ML?
23:17:07 <barrett1> The other thing the PTLs talked about was the need to balance new features with bug fixing - they struggle with this
23:17:11 <sarob> there 2
23:17:15 <Shamail> sarob: I agree, we don't have to include them in the actual process but socialization would be great
23:18:33 <sarob> okay, lets follow ttx advice and start talking to the xproject group as we get the rough roadmap, use cases, workflow ready
23:18:57 <sarob> while also publishing to openstack-dev ML
23:19:07 <barrett1> sarob ++
23:19:08 <Rockyg> ++
23:19:20 <sgordon> wfm
23:19:23 <sarob> \o/
23:20:23 <Shamail> sarob: +1
23:20:45 <sarob> #action team: once rough roadmap, use cases, workflow ready, we join the xproject meeting and publish URL to openstack-dev ML
23:21:22 <sarob> what deadline
23:21:29 <Rockyg> might want to introduce the product team to the PTLs before that.  In case some are up on our group
23:21:31 <sarob> do we want to give ourselves?
23:22:14 <sgordon> so i think we are making a lot of progress on rough roadmap
23:22:22 <Rockyg> Just a hi, we're here, this is what we're working on.  the next time you see us here on the agenda will be with the drafts...
23:22:24 <sgordon> not as clear on where we are at on use cases / workflow
23:22:31 <sarob> rockyg: we should at least have the rough workflow ready for review
23:22:34 <barrett1> for deadline how about intersecting the xprojec team meeting the week of 4/13 or 4/20?
23:22:54 <sgordon> rough roadmap being = documenting existing priorities
23:23:02 <sarob> def before liberty summit
23:23:03 <sgordon> (for now)
23:23:06 <Shamail> Yep
23:23:18 <sarob> sgordon: yes
23:23:44 <barrett1> Can we take work flow and rough roadmap (per Steve) to xproject meeting the week of 4/13?
23:23:47 <Shamail> Agreed on both topics (sgordon and barrett1)
23:23:57 <Rockyg> 4/20 might be hard, depending on how the RCs are going.  4/13 or about 3 weeks before summit would be good
23:24:03 <sarob> we dont start thinking about new priorities and goal until the PTLs feel we are a responsible group
23:24:21 <Shamail> sarob: +1
23:24:30 <sarob> 4/13 is a month from now
23:24:37 <Shamail> 4/13 sounds good
23:24:41 <sarob> do we need that much time?
23:24:42 <barrett1> It seems like we could help the PTLs by bringing them Operators feedback in a consistent form and create Use Cases that utilize that feedback
23:25:07 <sarob> i was thinking like next week or the one after
23:25:28 <barrett1> Sooner the better works for me
23:25:45 <Shamail> The challenge is also how much progress we want to make on the coordination piece by liberty.  I'd like xproj feedback for sure on that portion of the workflow.
23:25:58 <sarob> we can loop back to xproject with summit ready stuff for 13apr maybe
23:26:20 <sarob> shamail: +1
23:26:23 <barrett1> +1
23:26:37 <Rockyg> +1
23:27:12 <barrett1> Should we get a repository setup and post our docs there ahead of that meeting?
23:27:19 <Shamail> The one after is good... It gives people time to leverage one full week to try and fill out as much of the rough roadmap as possible but still leaves time for work before summit
23:27:41 <Shamail> barrett1: +1, happy to draft some use-cases as well
23:27:56 <sarob> barrett1: we are planning on using the xproject repo right?
23:28:15 <barrett1> I'm hoping to have some we can use from WTE too
23:28:41 <barrett1> Does anyone have a format for Use Cases that they have used and like?
23:28:58 <sgordon> well now...
23:28:59 <Rockyg> We cod do a directory called product or product-wg under the xproject repo
23:29:08 <sgordon> http://git.openstack.org/cgit/stackforge/telcowg-usecases/tree/template.rst
23:29:09 <barrett1> sarob: OK, will we create a sub dir there?
23:29:11 <Rockyg> go, sgordon!
23:29:21 <barrett1> rocky ++
23:29:38 <sgordon> the main thing i had an AI to add to it (from a telco wg perspective) was personas/user story section
23:29:48 <sarob> barrett1: yup
23:29:56 <Shamail> sgordon: +1 on the format
23:30:23 <Shamail> Would we have core reviewers in xproj?
23:30:34 <barrett1> steve ++ think the narative is helpful
23:30:44 <sarob> shamail: ugh, good point
23:30:58 <sarob> shamail: yeah, we would need to
23:31:04 <sarob> workflow details
23:31:13 <sarob> #link https://docs.google.com/document/d/13JPDDiBGGXf5dtP0u8C-1So2Mjb3yEmGhv_ijVqyEf0/edit#
23:32:28 <sarob> soo,
23:32:30 <Shamail> If we need core in xproj then we probably can't commit before reviewing with them.
23:32:42 <sarob> shamail: yup
23:33:25 <sarob> so lets get the rough draft of what the workflow looks like ready for xproject review
23:33:26 <barrett1> On the process, what is the "community voting" in  1.ij?
23:33:31 <sarob> within one to two weeks
23:33:42 <barrett1> sarob ++
23:33:50 <sarob> every pass
23:33:58 <sarob> the technical community reviews
23:34:03 <barrett1> OK
23:34:09 <barrett1> why the DefCore check?
23:34:20 <sarob> random thought
23:34:43 <sarob> that defcore state should be a quick double check
23:34:46 <Shamail> That was teased out through doc comments... Probably no real relation to DefCore arm.
23:34:48 <Shamail> Atm*
23:35:11 <barrett1> Given that DefCore applies to "adopted" capabilities, it's not always likely that these new features will be already included
23:35:12 <sarob> defcore is going to spit out money
23:35:13 <sarob> nice
23:35:37 <Shamail> Sarob: 😄
23:36:12 <barrett1> I suggest we take that box out
23:36:14 <Shamail> barrett1: true... at best we might want to scan failed tests from DefCore to maybe find new items
23:36:16 <sarob> barrett1: defcore and product work are on the opposite ends of the innovation cycle
23:36:34 <barrett1> sarob: Agree
23:36:54 <sarob> i was keeping defcore in our thoughts as we work through the rough draft
23:36:55 <Rockyg> The other check would be to see if defcore thinks it wants to deprecate something we have plans for in the future roadmap
23:36:57 <sarob> was all
23:37:18 <sarob> i dont think we should ask defcore for a review
23:37:32 <sarob> just that the product team check to see the state of defcore
23:37:44 <barrett1> I think we'd need to create a matrix for each use case showing which projects are likely to be impacted
23:37:57 <Shamail> barrett1: +1
23:38:13 <sarob> barrett1: interesting, id like to see how that would look
23:38:24 <Shamail> We could include it at the end of each use-case or commit message?
23:38:39 <sarob> use case heatmaps?
23:38:40 <barrett1> sarob - I am working on one for Rolling Upgrades with Zero downtime. I can share it
23:38:53 <sarob> barrett1: okay
23:39:10 <sarob> more data good
23:39:17 <Rockyg> kewl.  I wanna see that one, too
23:39:21 <barrett1> Once we have the Use Case and the Matrix with appropriate core-reviewer approval, would that be the 1st milestone?
23:39:22 * sarob say more data good
23:39:23 <Shamail> Ditto
23:40:07 <sarob> barrett1: umm, let me noodle that
23:40:41 <sarob> lets continue this on the ML
23:40:43 <barrett1> My thought is, with that in hand, we could start the process of evaluating existing BPs for changes and creating new ones needed to implement the use case
23:40:50 <sarob> so we can finish the agenda
23:41:13 <sarob> sounds good
23:41:49 <sarob> #topic state of tags, our purpose/focus
23:42:10 <sarob> #link http://lists.openstack.org/pipermail/product-wg/2015-March/000198.html
23:42:42 <sarob> who wants to take this up for the group discussion?
23:43:14 <sgordon> well, tl;dr we have a big tent and people coming into it to see what's what want some guidance via tags
23:43:15 <Shamail> I can start but Rockyg and sgordon plz chime in
23:43:26 <sgordon> what tags, who defines them, etc.
23:43:31 <sgordon> is pretty much a blank slate
23:43:41 <sgordon> in particular there does not seem to be a rush of people to be the who
23:43:59 <Shamail> There was a discussion on a specific tag "production ready" that Rocky sent over... I think we all agreed on the cons associated with such a tag.
23:44:01 <Rockyg> My thoughts are that we have a unique perspective in that we are some of the most experienced in delivering product as opposed to code
23:44:13 <barrett1> From the Ops Meetup - it seems like there is a desire from Operators for a small form of an integrated release. And tags that describe the interoperability of other projects with that core.
23:44:26 <Shamail> * apologizes for cell phone lag... Listening to others now.
23:44:41 <barrett1> I wonder if there needs to be 2 (or more) classes of tags - One for developers and One for Operators?
23:44:48 <sgordon> the other variation of this discussion which was raised on the -dev thread
23:45:08 <sgordon> was whether each of the "old" criteria the TC evaluated should be considered to see if it should be a possible tag
23:45:13 <Rockyg> Shamail, and we also know the pitfalls of assigning the wrong words to a collection of code ;-)
23:45:29 <Shamail> :-)
23:45:43 <sgordon> barrett1, i see it as different groups defining tags rather than classes of tags
23:45:56 <sgordon> so the user group would be a good example of a body that likely should set some
23:45:58 <barrett1> sgordon: what's an example of a group?
23:46:06 <sgordon> similarly i think this body is well placed to provide a different perspective
23:46:37 <barrett1> If the Operators defined an OpenStack-Core tag, how would they cause it to be used by the developers?
23:46:49 <Rockyg> sgordon:  I think the TC have an idea of something like foundational, then other tags that can be applied to other projects that meet the old TC criteria but don't sound like check boxes
23:46:54 <sgordon> what does used mean here barrett1
23:47:11 <sgordon> i mean really, to me, "using" them means going to the list of projects
23:47:19 <sgordon> and see ooh this has tag-1, tag-2, and tag-3
23:47:30 <barrett1> Having the tag associated with portions of code
23:47:48 <sgordon> but we're not talking about tagging portions of code no?
23:47:53 <sgordon> we're talking about tagging projects?
23:48:16 <barrett1> entire projects?
23:48:17 <sgordon> if we have to have the tags set in code then i think we have a problem
23:48:18 <Rockyg> Please let's not use "core".  It's overloaded already.  and if it were used, it would be nova, glance, keystone and either nova-network or neutron and cinder or swift
23:48:31 <Shamail> Current scope is project... :)
23:48:36 <sgordon> yeah
23:48:51 <barrett1> rockyg: Based upon the the Ops feedback Horizon would be in that set too
23:49:09 <Shamail> I think everyone has good points on tags and possible organization of tags... I would like to add another question: what's product WG's role (if any)?
23:49:37 <sgordon> well i was thinking about this earlier
23:49:55 <barrett1> Would our role be in using Tags to help Operators find implemented Use Cases?
23:49:55 <sgordon> primarily i think we need to determine what we care about
23:49:56 <Shamail> We can always participate as individuals or parts of other teams... But do we need a WG stance?
23:50:06 <sgordon> e.g. stable api (i can use n-1 client against this project)
23:50:15 <sgordon> just as an example
23:50:42 <sgordon> we also dont necessarily have to decide right now, we may come up with common things we care about exposing via tags later
23:51:04 <sgordon> my only concern (more generally) is again that in the absence of *anyone* stepping up and defining the tags it's kind of the wild west
23:51:12 <barrett1> sgordon: I like the idea of using tags to communicate what's important to Operators.
23:51:12 <sgordon> and that is what the operators seemed to be concerned about as well
23:51:27 <barrett1> +1
23:51:34 <Shamail> Devils Advocate:  that is moving us from a group sharing PTLs thoughts as use-cases to a group actually suggesting roadmap items (and how to tag them)
23:51:41 <Shamail> sgordon: +1
23:52:03 <sgordon> Shamail, debatable - one of the tags from our pov might be "has roadmap" ;p
23:52:24 <Shamail> Nice :)
23:52:36 <rolandchan> shamail: I'm fine with that in any case.
23:52:37 <barrett1> shamail: If we're not suggesting roadmap items then I don't think we're helping the PTLs and the OpenStack
23:52:55 <sgordon> there's a balance to be struck here but i see it actually as within what we discussed as our remit
23:53:13 <Shamail> barrett1: agreed in the long-run but crawl, walk, run
23:53:19 <sgordon> because it's ultimately about assisting consumers of openstack to interpret what's going on
23:53:30 <sgordon> the roadmap activity obviously strikes at that
23:53:34 <sgordon> i think tagging does too
23:53:44 <sgordon> but like i said that doesnt mean we need a definitive list of tags today
23:53:58 <barrett1> I thought tagging was more intended for people who want to build a version from the trunk...no?
23:54:01 <sgordon> i would imagine the list of tags, more generally, will grow over time anyway
23:54:21 <barrett1> And that they tags could somehow also help out with documentation...
23:54:27 <sgordon> i believe it to be much more general than that
23:54:36 <jogo> sgordon: for examples of what make good tags, I think the former gradation list, http://governance.openstack.org/reference/incubation-integration-requirements.html, could be turned into tags
23:54:57 <Shamail> So if we decide we want to help with the tagging system... (E.g. Help tame or document the Wild West)... Any ideas on how to proceed?
23:54:57 <sgordon> i mean put it this way
23:55:07 <sgordon> was the integrated release only to help those building from trunk?
23:55:36 <Shamail> sgordon: don't think so... It was also supposed to help consumers know that this code runs in production somewhere
23:55:38 <sgordon> jogo, agreed - just as Rockyg said though that seems to be something actively being looked at in the -dev community already
23:55:45 <Shamail> And follows the OpenStack way
23:55:45 <sgordon> Shamail, right - if even that
23:56:13 <sgordon> depending on which version of the integration requirements was used at a point in time :)
23:56:19 <sarob> so can i bring it back
23:56:27 <sarob> to what we are doing
23:56:49 <Rockyg> I also think that we may be able to help provide a clearer path between the conversion to big tent and how the tags are used to define and the tent
23:57:01 <sarob> i dont think tagging has much to do with our group right now
23:57:02 <jogo> sgordon: yup, but tags along those lines could be useful. I as a dev am interested in the answer to: As an operator I will only look at projects that have the following tags
23:57:28 <sarob> we are creating a multirelease roadmap
23:57:54 <barrett1> I guess the question is how do we create a link from the roadmap to the projects?
23:58:06 <sarob> maybe theme based tags could be one of the outputs
23:58:16 <sarob> but other than that
23:58:21 <barrett1> so someone could actually get the roadmapped capabilities in their deployment
23:58:24 <sarob> tagging is out of scope for us i believe
23:58:30 <Rockyg> The devs know that the one big integration approach is starting to collapse under its own weight and they think tags will help when the tests are more directed to limited collections of projects.  They just don't haven't been able to connect the tent with the tags tightly yet.
23:58:41 <Shamail> sarob: that's a good starting point at an intersection
23:59:02 <sarob> we are in the last minutes
23:59:08 <barrett1> sarob: what's an example of a theme?
23:59:24 <Rockyg> telco
23:59:26 <sarob> CBP
23:59:33 <Rockyg> storage cloud
23:59:35 <barrett1> sarob: CBP?
23:59:47 <Shamail> barrett1: the "ilities"... Availability, Scalability, etc.
23:59:50 <Rockyg> private cloud
23:59:50 <sarob> oops, i mean thats a vertical using our
00:00:01 <sarob> shamail: +1
00:00:17 <Rockyg> OOoh, the ilities are good tags to consider
00:00:20 <sarob> theme is a feature that many verticals have in common
00:00:23 <barrett1> I'll take a pass at editing the work flow per the discussion here and sending out the project matrix
00:00:37 <sarob> cool
00:00:43 <sarob> good place to stop
00:00:53 <sarob> be active on the ML my friends
00:00:56 <barrett1> I have updated a slideware version of the roadmap too - could use comments/edits on that
00:01:04 <Rockyg> ++
00:01:15 <sarob> #endmeeting