16:02:29 <cody-somerville> #startmeeting Storyboard Weekly Meeting
16:02:29 <openstack> Meeting started Thu Feb 13 16:02:29 2014 UTC and is due to finish in 60 minutes.  The chair is cody-somerville. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:32 <openstack> The meeting name has been set to 'storyboard_weekly_meeting'
16:02:52 <cody-somerville> #link https://wiki.openstack.org/wiki/StoryBoard#Meeting
16:06:08 <cody-somerville> #topic MVP0 progress
16:06:23 <cody-somerville> gothicmindfood: ^^
16:09:23 <SergeyLukjanov> o/
16:09:48 <gothicmindfood> well, reading backlog in #storyboard at the moment from the overnight work...
16:10:46 <gothicmindfood> SergeyLukjanov + NikitaKonovalov - care to chime in on where we are with auth stuff?
16:11:37 <NikitaKonovalov> those auth protocols are mindblowing, when you hit an "Unknown error"
16:11:38 <SergeyLukjanov> gothicmindfood, IIRC NikitaKonovalov is near to impl openid part
16:11:48 <SergeyLukjanov> :)
16:12:03 <NikitaKonovalov> yes, I finally got the openid part working
16:12:19 <NikitaKonovalov> so the change is comming soon to both client and server
16:12:48 <gothicmindfood> awesome!
16:13:05 <NikitaKonovalov> next thing on the list is to make Oauth part work on client and server sides
16:14:39 <NikitaKonovalov> since I'm new to all that local browser storage stuff, that may take some time to make things work properly
16:14:43 <gothicmindfood> ok - is there anything that's changed from the specs up at https://etherpad.openstack.org/p/StoryboardAuth ?
16:15:16 <gothicmindfood> (just so I can keep tabs on anything that's come up and changed our plan while krotscheck is away)
16:15:18 <cody-somerville> I thought we were going to use OpenID Connect vs. OAuth?
16:16:32 <NikitaKonovalov> OpenId connect is an Oauth implementation which says "what the user can do", but not "who the user is"
16:16:40 <gothicmindfood> I think OpenID connect uses OAuth, right?
16:17:08 <cody-somerville> How confusing.
16:17:19 <NikitaKonovalov> to tell "who the user is" we use OpenId (launchpad provider)
16:17:47 <gothicmindfood> http://openid.net/connect/
16:17:57 <cody-somerville> Wish I could have accessed that while we were at the sprint, lol.
16:18:06 <cody-somerville> Anyhow, anything more on this topic? We're now past 1/4th mark in the meeting. :)
16:18:37 <gothicmindfood> I don't think so - we seem to be moving along, but I know ruhe mentioned a big roadblock has been a lack of reviews
16:18:59 <cody-somerville> I'm going to fix that by hiring some more folks, lol.
16:19:37 <cody-somerville> #topic Single or dual repositories ?
16:20:00 <ttx> did we decide on whether we'd go long term with one or two repos ?
16:20:19 <ttx> because we have requests to add storyboard-webclient to the list of openstack infra projects
16:20:34 <ttx> and I'd rather not accept that if we are going to merge the two repos tomorrow
16:20:55 <gothicmindfood> I think jeblair and mordred probably had the most feedback on that.
16:21:01 <ttx> the main argument for it was, iirc: ability to land client and serverside chanegs in on e go
16:21:10 <mordred> what did I do?
16:21:26 <ttx> the main argument against it was, iirc: mixed core reviewers team
16:21:31 <cody-somerville> I'm in favour of keeping them separate.
16:21:35 <gothicmindfood> mordred: thoughts on 1 vs 2 repos for storyboard.
16:22:01 <mordred> I believe that what we were going to do was explore combined pip/grunt toolchain as a poc in the zuul repo
16:22:15 <NikitaKonovalov> as for me, the only possible proble is to keep everything in sync
16:22:42 <mordred> with teh other things on our plate, I'd rather not rework the tooling that's currently in place and working until we have an actual answer for a next thing
16:23:21 <gothicmindfood> so we're keeping them at 2 for at least a while, ttx (sounds like)
16:23:49 <ttx> ok. thanks! all I needed to know
16:23:53 <ttx> next topic :)
16:24:00 <jeblair> agreed on 2
16:24:33 <jeblair> (i had some arguments in favor of 1, but on futher exploration, i think 2 will be better in the long run, particularly if we treat both as separate python-based deliverables)
16:24:42 <cody-somerville> #agreed on keeping two repositories for now - api server and web client.
16:24:44 <jeblair> (but we should still experiment on zuul)
16:25:10 <cody-somerville> #topic Blocked reviews ?
16:26:13 <ttx> I feel like I've been reviewing consistently recently, but in most cases I only +2d, not +2/APRVd
16:26:23 <ttx> do we have a review bottleneck ?
16:26:40 <ttx> should we attach mordred to the review chair ?
16:27:04 * cody-somerville grins.
16:27:06 <mordred> I need to review - I've been in a 3-day meeting
16:27:08 <mordred> sorry
16:27:37 * gothicmindfood thinks the review chair sounds better than the 3-day meeting chair
16:27:43 <ttx> do we need another +2 ?
16:27:43 <gothicmindfood> :)
16:28:32 <cody-somerville> Let's continue to monitor the situation.
16:28:51 <cody-somerville> #topic Brainstorm on statuses (StoryBoard/Story_Status)
16:29:01 <cody-somerville> #link https://wiki.openstack.org/wiki/StoryBoard/Story_Status
16:29:31 <ttx> So I started brainstorming around the need for story statuses
16:29:38 <gothicmindfood> I dig the workflow up there  from Glance/Drivers
16:29:54 <ttx> mostly due to markwash posting https://wiki.openstack.org/wiki/Glance/Drivers
16:30:14 <ttx> I think his states make sense, but i wish we didn't have any status
16:30:29 <ttx> because if a human needs to set them, they will end up wrong
16:30:43 <ttx> or maybe we should have them only on the features side
16:31:02 <ttx> or maybe we can design priorities in such a way that they encapsulate our needs for status
16:31:24 <ttx> that's step 0 of the discussion, if you have thoughts, please add them to that page
16:31:37 <gothicmindfood> I'm curious - what do we think statuses give us?
16:31:51 <ttx> We have task-level statuses that are linked to the state of the corresponding change in gerrit
16:32:07 <ttx> gothicmindfood: see user stories at the top
16:32:11 <gothicmindfood> ttx: what are the task level statuses?
16:32:28 <ttx> Todo, Under review, Merged
16:32:50 <ttx> that way they are automartically set in 99% of the cases
16:33:13 <ttx> story-level statuses are used for approval of the whole idea, basically.
16:33:14 <gothicmindfood> ttx: so, PTLs etc. need to approve features right now before they can land?
16:33:22 <NikitaKonovalov> well, at least story-level statuses ("New", "Partially done", "Completed") might also be set automatically
16:33:24 <ttx> gothicmindfood: they try to, yes
16:33:39 <ttx> gothicmindfood: except LP makes that tracking a bit miserable
16:33:53 <cody-somerville> I thought the story-level status would be determined automatically based on task-level statuses
16:34:03 <gothicmindfood> ttx: is there a reason they approve at the feature level and not the task level?
16:34:16 <ttx> cody-somerville: they want to automatically block reviews that are not attached to an approved story, basically
16:34:27 <ttx> (at least on the feature side)
16:34:39 <ttx> gothicmindfood: that's a good question
16:34:58 <ttx> gothicmindfood: let me expand on that
16:35:16 <ttx> gothicmindfood: feature stories can have multiple tasks affecting the same project, or multiple projects
16:35:40 <ttx> in the case of multiple tasks affectig the same project, you actually want to approve them in bulk. The story is good for your project or not.
16:36:12 <ttx> in the case of tasks affecting separate projects though... you can't really have story-level approval, because each project PTL might have a different opinion
16:36:22 <gothicmindfood> ttx: but in the case of tasks underneath a feature belonging to different projects.... EXACTLY.
16:36:42 <gothicmindfood> this is what I was getting at over on  priority page
16:36:47 <ttx> which is why I think we actually need to explore alternative ways of expressing that
16:36:50 <gothicmindfood> (I think) (I'm also tired)
16:36:57 <cody-somerville> I'd like to suggest that we don't try to support this use case for now.
16:37:02 <cody-somerville> It's... messy.
16:37:05 <ttx> and we may want to brainstorm on priority first
16:37:26 <gothicmindfood> I am leaning towards the idea that maybe story status doesn't really give us much
16:37:31 <gothicmindfood> in teh way of useful or actionable information
16:37:35 <ttx> cody-somerville: oh it's not URGENT. It's just one of the two big open design areas we need to brainstorm on
16:37:59 <ttx> just wanted to raise the topic to start making you think about it
16:38:09 <ttx> we can move on, we won't solve it today ;)
16:38:44 <gothicmindfood> if OS was the kind of group that enforced story status as a workflow assignment mechanism, I could see it being useful, but... we'll have to continue to hash it out before I think a case is made. :)
16:38:58 <cody-somerville> #topic Brainstorm on priorities (StoryBoard/Priority)
16:39:08 <ttx> so that's the other big open area
16:39:09 <cody-somerville> #link https://wiki.openstack.org/wiki/StoryBoard/Priority
16:39:38 <ttx> I tried to come up with a list of ways priority could be implemented
16:40:42 <ttx> I see some questions in there, i'll try to answer them
16:40:56 <ttx> how does the "official" priority get set when multiple groups have different priorities for the same story?
16:41:06 <gothicmindfood> yeah, that was mine
16:41:17 <ttx> each task is attached to one project. Project has PTL who defines official prio
16:41:32 <ttx> that's task-level priority
16:41:41 <gothicmindfood> so at the story level, how does that play out?
16:42:03 <ttx> there is no story priority.
16:42:07 <gothicmindfood> ok
16:42:11 <gothicmindfood> that was me misunderstanding, then.
16:42:18 <ttx> about kanban-style boards requiring a universal process: i don't think that's the case. You don't have to all have the same columns
16:42:32 <ttx> you shoudl actually pick columns that make sense for your process
16:42:51 <cody-somerville> I'd like to suggest that we go with simple priorities to start with.
16:42:59 <gothicmindfood> cody-somerville: I agree.
16:43:08 <NikitaKonovalov> and what about Launchpad "heat" do we need something like that?
16:43:18 <gothicmindfood> I'm curious about how multi-dimensional would work
16:43:19 <NikitaKonovalov> not a priority
16:43:19 <ttx> NikitaKonovalov: it's pretty useless
16:43:38 <gothicmindfood> but I think it should be introduced based on a need, not because we're playing around with it :)
16:44:15 <persia> Simple priorities quickly devolve to arguments and procedurism if folk have differing opinions about something (maybe PTL can squash this, using procedures from Malone, but ...)
16:44:55 <cody-somerville> persia!
16:45:01 <ttx> gothicmindfood: the need is described in the user stories. We need to express some priority or ranking, and multiple stakeholders have different priorities
16:45:38 <gothicmindfood> ttx: I meant the kanban stuff, not the rest :)
16:45:54 <ttx> the kanban-style view is just saying each stakeholder can have multiple priority views, instead of just one.
16:46:35 <ttx> (it's not a real kanban, basically. it doesn't map to a production process.
16:46:59 <gothicmindfood> so, my inclination is just to wait for the ask from project xyz and until then build the simple priority.
16:47:10 <ttx> anyway, will brainstorm more. Thoese pages were just meant to trigger your interest
16:47:15 <persia> For those planning to implement: what is the difference in effort between parallel and multi-dimensional?
16:47:46 <ttx> persia: paralell would be one priority view per group or person
16:47:51 <persia> ttx: Right.
16:48:07 <ttx> multi-dimensional would allow multiple priority views per group or person.
16:48:29 <persia> My thought is that for MVP, it makes sense to only have parallel, and then move to multi-dimensional when someone is unhappy with parallel, unless switching is expected to be too painful
16:48:37 <ttx> gothicmindfood: interestingly enough, currently we use a mix of milestone targeting and priority to express priority
16:48:48 <ttx> I would also like to fix that.
16:48:52 <persia> That said, if multi-dimensional is easy to implement, no point doing parallel first
16:49:14 <gothicmindfood> ttx: explain how that works, now with milestone targeting and priority.
16:49:39 <ttx> gothicmindfood: we sue milestone targeting to designate a subset of important tasks (bugs and features) to complete for a milestone
16:49:42 <ttx> use*
16:49:54 <ttx> then we use priority to rank them
16:49:59 <gothicmindfood> ttx: and who designates the milestone targeting, the PTL?
16:50:27 <ttx> gothicmindfood: anyone can, which is a problem
16:50:36 <gothicmindfood> ha. yes. I can see that.
16:50:44 <ttx> so we use tricks (like setting a priority on the blueprint) to make it "approved"
16:51:16 <ttx> in a priority-only view, you would just add tasks to a specific list and rank them.
16:51:30 <ttx> things not on the list don't need to be ranked.
16:52:09 <gothicmindfood> right - I'm just wondering who sets the priority here
16:52:10 <ttx> that's useful. setting a priority is not very useful.
16:52:17 <gothicmindfood> and if that's a restricted group of some kind
16:52:36 <ttx> yes, that would be the "drivers", in connection with release management
16:52:56 <ttx> basically the PTLs and their delegates
16:53:12 <ttx> anyway, we are abusing the meeting to brainstorm
16:53:31 <ttx> maybe we should move to open discussion
16:53:33 <gothicmindfood> ha. ttx: I will send you an email TODAY to schedule more time to actually brainstorm
16:53:45 <ttx> ack
16:54:05 <ttx> I need to think more about how that could work.
16:54:35 <ttx> I'd like it to be simple and flexible
16:55:05 <ttx> the drawback of prioritization is that it relies on the fact everything is triaged
16:55:05 <cody-somerville> Any other comments on this topic?
16:55:22 <ttx> whereas the list approach is all about selecting tasks that matter to you
16:55:55 <ttx> so it can be reused for targeting work to a given milestone, and also to follow tasks that matter to you
16:56:41 <cody-somerville> #topic Any Other Business
16:56:46 <ttx> cody-somerville: i'm reluctant to add basic priorities, because I fear we actually don't want priorities at all, basically
16:56:59 <cody-somerville> ttx: I was pondering the same thing.
16:57:22 <ttx> we want worklists
16:57:27 <cody-somerville> I'd like to propose that folks add their IRC nick next to items they add to the agenda.
16:57:31 <persia> Sorted worklists?
16:57:58 <ttx> persia: they would be sorted. But then the oredr might mean something or not mean something
16:58:10 <ttx> depdending on what the list is about :)
16:58:29 <persia> Perfect!
16:58:32 <ttx> damn, typo hour
16:58:55 <ttx> persia: I like it too. It's elegant. Just need to doublecheck it actually makes sense :)
16:59:35 <ttx> cody-somerville: +1 for adding names. Will do next time :)
16:59:37 <persia> Doesn't scale to long lists, but long lists aren't usually interesting in terms of priority
16:59:45 <ttx> persia: right
16:59:52 <cody-somerville> #endmeeting