16:02:16 <ttx> #startmeeting storyboard
16:02:17 <openstack> Meeting started Thu Feb 27 16:02:16 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:20 <openstack> The meeting name has been set to 'storyboard'
16:02:33 <ttx> Agenda at https://wiki.openstack.org/wiki/StoryBoard -- still time to add stuff to it
16:02:52 <ttx> #topic MVP status
16:03:01 <ttx> krotscheck: how far are we ?
16:03:09 <krotscheck> Non auth MVP seems to have landed. Auth is still outstanding.
16:03:33 <NikitaKonovalov> I've got a bunch of comments from krotscheck
16:03:40 <ttx> once both land, MVP is complete on the webclient side ?
16:03:51 <krotscheck> ttx: I believe so.
16:04:15 <ttx> what about the missing stuff on the server side ?
16:04:24 <krotscheck> ttx: I need to doublecheck, but I think at this point we should be able to start making stories.
16:04:42 <NikitaKonovalov> the code is there, but I was calling the redirects in the wrong order
16:05:24 <NikitaKonovalov> now I'm working to update the change to align it krotscheck's comments
16:05:50 <krotscheck> ttx: Looks like we can file stories
16:05:51 <krotscheck> http://storyboard.openstack.org/#!/story/2/overview
16:05:54 <ttx> So that's on the Auth side. Anything else missing in the server part for MVP ?
16:06:06 <NikitaKonovalov> seems like no
16:06:22 <krotscheck> No.
16:06:54 <ttx> NikitaKonovalov: I was a bit surprised by the amount of code you had to write on the srverside part of Auth. The code that makes you build URL by hand looks scary
16:07:19 <ttx> (wearing my security reviewer hat)
16:07:36 <ttx> NikitaKonovalov: is that expected ? Couldn't we reuse more of library code ?
16:07:57 <NikitaKonovalov> there might be a better way to utilize urrlib
16:08:22 <ttx> NikitaKonovalov: not really blocking on that
16:08:53 <ttx> I was just... surprised that you couldn't implement Auth in 3 lines of code. Django spoiled me I guess
16:09:12 <ttx> NikitaKonovalov: if it works and interacts with Michael's stuff, should be good
16:09:27 <NikitaKonovalov> at some point I was thinking of bringing django plugin back :)
16:09:59 <NikitaKonovalov> the amount of code is huge, because Oauth does not quite fit the open-id-connect protocol
16:10:05 <ttx> krotscheck, NikitaKonovalov: from what you're both telling me, looks like we would reach MVP state by end of this week
16:10:26 <NikitaKonovalov> hopefully
16:10:33 <krotscheck> ttx: Ambitious, but possible.
16:10:43 <ttx> #info MVP status may be reached by end of week
16:10:58 <ttx> OK, anything more on that topic ?
16:11:34 <ruhe> any future MVP customers here?
16:11:42 <gothicmindfood> meeeeee
16:11:46 <ruhe> would be nice to get some feedback from them
16:11:46 * ttx plans to get more familiar with the code and start helping, but it's still a bit too much of a movig target to me
16:11:46 * gothicmindfood raises hand
16:11:52 <ttx> quickly stabilizing though
16:11:57 <ttx> gothicmindfood: go for it
16:12:03 <krotscheck> Actually, the trove team came to me yesterday and asked whether they can start putting an incubation project on storyboard just to see what it's like.
16:12:14 <gothicmindfood> krotscheck: wow, that's cool!
16:12:18 <ttx> argh.
16:12:32 <gothicmindfood> I really want to throw our MVP internally at HP people and make them use it.
16:12:42 <ttx> seriously, it's missing like 99% of the features that will make it usable
16:12:43 * gothicmindfood may be in too many meetings with PMs arguing abou tools this week
16:12:53 <krotscheck> gothicmindfood: You're back from tour?
16:12:59 <gothicmindfood> krotscheck: I'm still out
16:13:12 <ttx> I really fear that initial rejection will cost us down the line
16:13:14 <gothicmindfood> (NYC tonight, DC tomorrow, Chicago Tuesday, then done)
16:13:22 <gothicmindfood> ttx: understood, and agreed
16:13:36 <gothicmindfood> ttx: my fantasy with HP is purely fantasy. Would never actually do that.
16:13:45 <ttx> gothicmindfood: more comments on that topic ?
16:14:25 <gothicmindfood> ttx: I think everyone's psyched about getting to MVP and will remain so until the first group of devs get pissed about having to use it :)
16:14:41 <ttx> that brings us squarely to:
16:14:41 <ttx> #topic What to use to plan the next step
16:14:51 <gothicmindfood> ttx: this is the nature of having a new product that everyone will eventaully be forced to use.
16:15:04 <krotscheck> Oh, I think the next step is pretty clear. MVP didn't include the creation of tasks.
16:15:10 <ttx> I have a number of ideas for the next step, but not sure what is the best tool to organize it
16:15:14 <krotscheck> And, well, that's a pretty big hole in our UI right now.
16:15:18 <ttx> steps*
16:15:24 <ttx> krotscheck: heh
16:15:33 <ruhe> krotscheck: it's possible to create tasks on the API side though
16:15:40 <krotscheck> ruhe: It is?
16:15:56 <ruhe> krotscheck: yes it is :)
16:15:57 <krotscheck> Oh, neat. That solves that then.
16:16:08 <ttx> my question is, we have a backlog of features and need to organize them, order them
16:16:11 <gothicmindfood> krotscheck just needs to make a pretty button, I guess. :)
16:16:22 <ttx> since we are far away from being able to use storyboard for planning work...
16:16:29 <ttx> should we use some trello thing ?
16:16:48 <ttx> I could use some familiarity with it, as I brainstorm over tasklists
16:17:00 <ttx> should we continue to abuse a wiki ?
16:17:00 <ruhe> i'd prefer to use storyboard, even if it has 1% of required features
16:17:10 <krotscheck> I agree with ruhe.
16:17:16 <gothicmindfood> I also like the idea of using storyboard
16:17:19 <gothicmindfood> as clunky as it will be.
16:17:25 <krotscheck> Easier to point and say: ugh this sucks fix it.
16:17:32 <ttx> ruhe: it's really missing the story/task ordering/targeting aspect though
16:17:44 <ttx> and it's a bit tricky to prioritize up
16:18:06 <ttx> as the tasklist thing is still very much only clear in my brain when I'm drunk
16:18:29 <ruhe> ttx: can we workaround it by appending some priority information to story/task title?
16:18:44 <ttx> so to use storyboard for milestone planning, we'd add something we'd remove afterwards, I don't really like that
16:18:57 <ttx> Ah. Abusing title
16:19:01 <ttx> I guess that's an option
16:19:03 <ruhe> i mean - append title manually
16:19:21 <krotscheck> Ok, so the ask is "We want to be able to prioritize stories", yes?
16:19:47 <ttx> krotscheck: I guess alpha order and playing with titles should be enough for that
16:20:13 <ttx> ok, dogfooding ftw
16:20:39 <krotscheck> ttx: I dislike workarounds.
16:20:44 <ttx> should be fun
16:21:34 <ttx> krotscheck: the trick is: prioritization, the way we now plan to do it, is a rather higher-level construct
16:21:37 <ruhe> and simple ordering should be a matter of a couple of lines on the API side
16:22:00 <ttx> at least titles and alpha-ordering don't mean we put in a workaround that we'll remove
16:22:46 <ttx> Any objection to storyboard dogfooding storyboard past-MVP ?
16:23:00 <ttx> I hope we have backups
16:23:42 <krotscheck> I don't hear any objections
16:24:07 <ttx> awesome. Anyone has a topic to discuss, before I waste everyone's remaining meeting time in weird design discussions ?
16:24:41 <ttx> I hear none
16:24:53 <ttx> #topic Sane design
16:24:56 * gothicmindfood is so excited for weird design discussion
16:25:02 <ttx> So that one is mostly sane
16:25:11 <ttx> #link https://wiki.openstack.org/wiki/StoryBoard/Task_Branch
16:25:44 <ttx> There aren't so many ways to do it
16:26:13 <ttx> There are only two subtleties
16:26:38 <ttx> When do we set "release" ?
16:27:12 <ttx> And how do we build final release pages ?
16:27:31 <ttx> But both can be handled at a later time
16:28:05 <ttx> For the first question I'd rather set release at change landing time. But in some cases you really don't know what the "next" milestone will be
16:28:26 <ttx> So collecting them when you tag might actually make more sense
16:28:27 <krotscheck> I need someone to mansplain the differences between all the different openstack branches vis-a-vis releases to me.
16:28:37 <ttx> krotscheck: I'm your man
16:28:53 <krotscheck> ttx: Awesome. How late are you going to be up? I still have to get to the office.
16:29:26 <ttx> Maybe we can go through it now
16:29:29 * gothicmindfood would love to be in on that conversation as a refresher.
16:29:33 <ttx> https://wiki.openstack.org/wiki/BranchModel
16:29:40 <ttx> has some of it
16:29:51 <ttx> We develop on a master branch
16:30:23 <ttx> Around milestones, and during the RC period, we create a milestone-proposed branch, where only milestone-critical or release-critical fixes land
16:30:33 <ttx> master continues unrestricted
16:30:39 <krotscheck> Hrm.
16:30:56 <ttx> At final release time, we turn that milestone-proposed branch into a stable/* branch
16:31:21 <ttx> So by default everything lands in master
16:31:22 <krotscheck> ok, that makes sense.
16:31:38 <ttx> But you may backport STUFF to milestone-propsoed or one of the stable/* branches
16:31:52 <krotscheck> So, it feels to me that "branch" really belongs to a task, while release applies to a story.
16:32:05 <ttx> krotscheck: branch belongs to task yes
16:32:26 <ttx> krotscheck: In an ideal workd, "release" would apply to story
16:32:41 <ttx> but in reality, no
16:32:45 <ttx> for two reasons
16:32:45 <krotscheck> Though I suspect we might not need the "release" field because ultimately that can be derived by figuring out where various patches have landed.
16:32:59 <ttx> Imagine a security issue
16:33:07 <ttx> You fix it in master and in supported stable branches
16:33:24 <ttx> the master task will be "released" in 2014.1 (icehouse)
16:33:38 <ttx> the stable/havana task will be release in some 2013.2.3 or something
16:33:52 <krotscheck> Right - so branch is a tuple, not a single property
16:33:59 <ttx> the release field is there to track where the fix was first published
16:34:34 <ttx> krotscheck: not sure I follow
16:34:49 <ttx> tasks affecting multiple branches would be.. separate tasks
16:35:10 <krotscheck> ttx: Why? Can't a task include releasing code to multiple branches?
16:35:11 <ttx> probably assigned to different people, resulting in different changes being proposed in gerrit, etc
16:35:35 <ttx> krotscheck: I don't think it's worth the added indirection
16:35:44 <ttx> the story is the task group level
16:35:55 <ttx> you fix the story in multiple projects and multiple branches
16:36:10 <ttx> simpler to just have them as a one level list of tasks
16:36:17 <ttx> LP does what you imply
16:36:26 <krotscheck> ttx: Well, tell ya what. We have an immediate path forward on branches, since we know what that's going to look like (one branch per task). Once that goes in, we can see how we end up using it and where release falls into the whole application.
16:36:47 <ttx> example: https://bugs.launchpad.net/ossa/+bug/1260080
16:37:06 <ttx> There are three keystone tasks and one OSSA task there
16:37:52 <ttx> It would be simpler if it showed 4 tasks that you can reorder
16:38:14 <ttx> keystone/master, keystone/havana, keystone/grizzly and ossa/null
16:38:35 <krotscheck> So let's start with branches.
16:38:40 <ttx> anyway, impl detail
16:38:52 <krotscheck> point
16:39:04 <krotscheck> Alright, def something to noodle over.
16:39:19 <ttx> So that was the less insane one
16:39:47 <ttx> because we know we'll want branch and release at task level anyway
16:40:01 <ruhe> question: is branch model - the next big thing we need to implement in storyboard?
16:40:19 <ttx> ruhe: not necessarily, since we don't need it for storyboard dogfooding
16:40:23 <ttx> as we only have master ;)
16:40:45 <ttx> those are just open design questions I go over
16:40:51 * krotscheck personally feels that priority's the next big thing :)
16:41:04 <ttx> hah! nice segway to next topic
16:41:06 <ttx> #topic Crazy design
16:41:13 <ttx> Priorities are for the weak, let's use parallel tasklists for that: StoryBoard/Task_Lists
16:41:39 <ttx> So this is the straw man resulting from some brainstorming with various people
16:42:01 <ttx> basically playing with  concepts of subscription, milestoen targeting, priority...
16:42:23 <ttx> and realizing those are all facets of being able to put a number of stories or tasks in random lists
16:42:34 <ttx> ordered lists
16:43:09 <ttx> so why not oh why not just scrap all those concepts and replacing it with crazy task lists that would look like Kanban boards
16:43:37 <gothicmindfood> I concur with the random thought re: story ordering vs task ordering
16:43:48 * gothicmindfood loves this idea and thinks it's the coolest
16:43:55 <ttx> gothicmindfood: yes, the more I think about it the more I think we need to manipulate stories
16:44:23 <gothicmindfood> ttx: also, because task ordering might have a lot less to do with priority and more to do with dependencies
16:44:49 <gothicmindfood> (which aren't really the same thing, though they often are close to it)
16:44:57 <ttx> anyway, the main drawback of this appraoch is that it will take time to get right
16:45:03 <NikitaKonovalov> and I guess we will need two type of story lists: official and personal
16:45:07 <ttx> and so you can't really USE priorities in the mean time
16:45:16 <ttx> NikitaKonovalov: yes, that's baked in
16:45:18 <gothicmindfood> official project, personal view, and release view.
16:45:39 <ttx> gothicmindfood: got some people asking for projectgroup views as well
16:45:45 <krotscheck> That kindof feels like the leveling system in FFX...
16:45:57 <ttx> krotscheck: EMISSINGCONTEXT
16:46:30 <gothicmindfood> ttx: so infra-group view, for example?
16:46:47 <ttx> gothicmindfood: yes. or oslo
16:47:06 <ttx> there are a few programs wiuth a LOT of projects where the projectgroup will be the main thing they manipulate
16:47:14 <krotscheck> Final Fantasy X. To paraphrase, there's a bunch of stories. All of these stories need to go into the release, and stories are interdependent. Developers start on different parts of the dependency tree, and try to collapse the tree by the time the release goes out.
16:47:26 <ttx> and they want to prioritize across all those projects, not a project-level
16:47:36 <gothicmindfood> ttx: makes sense.
16:47:44 * krotscheck folds up his nerd flag again
16:47:56 <ttx> hah
16:48:00 <ttx> Anyway, I just want to push that idea in some corner of your minds so that you think a bit about it.
16:48:11 <ttx> No need to get to the bottom of it today
16:48:15 <gothicmindfood> I think lists and labels are the way to go
16:48:25 <krotscheck> I think the tricky bit there is how to model it so that the API is performant.
16:48:26 <ttx> that brings us to our next topic
16:48:28 <gothicmindfood> and make storyboard much more powerful as a universal tool, coincidentally.
16:48:36 <ttx> Statuses are for the weak, let's use tags for that: StoryBoard/Story_Tags
16:48:50 <ttx> https://wiki.openstack.org/wiki/StoryBoard/Story_Tags
16:49:13 <ttx> so we all know we'll have tags
16:49:24 <ttx> But but but will we have statuses ?
16:49:56 <ttx> Or can we just discourage status use (manual updates suck anyway) and abuse tags for corner cases
16:50:18 <ttx> gothicmindfood: found a loophole on this one though
16:50:25 <ttx> "If tags are applied to stories, who can set protected tags on a multi-project story ? Drivers are attached to projects ! "
16:50:41 <gothicmindfood> yeah
16:51:03 <gothicmindfood> anyone who is part of a project tagged in a task affiliated with the story?
16:51:18 <gothicmindfood> or a PTL of that project?
16:51:36 <ttx> I guess so
16:51:52 <ttx> since we don't let anyone add a project, that might work
16:52:14 <gothicmindfood> I mean, the task to story relationship is established.
16:52:20 <gothicmindfood> what about where a task hasn't been assigned a project
16:52:22 <gothicmindfood> ?
16:52:43 <ttx> gothicmindfood: I don't think we have such case
16:52:50 <ttx> tasks are always attached to a project
16:53:06 <ttx> You mean a story without tasks ?
16:53:19 <gothicmindfood> I thought a story would always have at least one (auto created) task
16:53:33 <ttx> then problem solved :)
16:53:44 <gothicmindfood> and if someone created a story with no knowledge of the system, it might not have a project affiliated with it
16:53:52 <gothicmindfood> (with its task, I mean)
16:54:00 <ttx> But even in the case of stories without tasks, then you would probably NOT set any protected tags
16:54:31 <ttx> not before you start fractioning the story into specific project tasks
16:55:28 <ttx> The main issue here is... do we really want to abandon workflows in storyboard
16:55:34 <gothicmindfood> yeah. So I think just mandating at least one task affiliatd with one project before tags are possible at the story level
16:55:52 <gothicmindfood> ttx: how does this abandon workflows?
16:56:03 <ttx> i.e. the bug confirmation workflow
16:56:08 <gothicmindfood> ah
16:56:12 <ttx> or the feature "approval" workflow
16:56:22 <ttx> that need multiple states
16:56:45 <ttx> like https://wiki.openstack.org/wiki/File:Glance_Blueprint_Process.svg
16:56:48 <gothicmindfood> well. how much does the community adhere to those workflows, and how strict are they?
16:57:29 <ttx> I'd argue that they are a lot of pain for no gain
16:57:36 <ttx> and I'm a process wonk
16:57:44 <ttx> I may hate the result
16:58:03 <ttx> But thing is.. we spend a lot of time pushing bugs and blueprints through a workflow
16:58:04 <ilyashak_> i recall there was an idea to create special task 'verify me' or 'fix me; and determine state by these tasks
16:58:18 <ttx> and in the end... I'm not sure that helps
16:59:20 <ttx> I want the tool to morph to what we do, rather than force people to go through its way of thinking
16:59:33 <krotscheck> Well, if we're going to have tags on everything, why not just make tags everything? Branches, statuses....
16:59:59 <ttx> krotscheck: because tags are story-level. And branch/release are tasklevel
17:00:13 <ttx> anyway, time is up
17:00:29 <ttx> Thansk everyone
17:00:37 <gothicmindfood> thanks ttx!
17:00:37 <krotscheck> Where a tag can be applied is secondary to using tags to indicate relevance of a task or story.
17:00:38 <ttx> for listening to my rants
17:00:40 <krotscheck> cheers!
17:00:45 <ttx> #endmeeting