14:04:00 <ttx> #startmeeting storyboard
14:04:01 <openstack> Meeting started Thu Dec 12 14:04:00 2013 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:04:05 <openstack> The meeting name has been set to 'storyboard'
14:04:09 <ttx> yay, a meeting bot
14:04:35 <ttx> Since i didn't expect I would chair this, we don't have a meeting agenda
14:04:41 <ttx> so it should be quick
14:04:51 <SergeyLukjanov> cool, we have an own meeting channel :)
14:04:54 <ttx> #topic gothicmindfood introductions
14:05:13 <ttx> gothicmindfood: care to introduce yourself to our Russian friends ?
14:05:30 <gothicmindfood> ha. Ok. Hi to everyone!
14:05:42 <gothicmindfood> I'm Colette and I'm a new hire at HP on mordred's team.
14:06:14 <gothicmindfood> he brought me on (and we've got a couple others joining in the next week or so) to work on Storyboard.
14:06:45 <gothicmindfood> I'm not really a coder - I'm more of a process person, though I have a big interest in learning python and getting up to speed.
14:06:55 <ttx> SergeyLukjanov, NikitaKonovalov: quick reverse intro ?
14:07:23 <mordred> hey
14:07:25 <mordred> sorry I'm late
14:07:27 <SergeyLukjanov> ttx, sure
14:07:30 <SergeyLukjanov> mordred o/
14:07:33 <ttx> mordred: howdy
14:07:36 <NikitaKonovalov> hi
14:07:48 <ttx> mordred: you don't have cody around, do you ?
14:08:02 <mordred> nope. we may have gone drinking last night. he might be dead in a ditch in barcelona
14:08:15 <SergeyLukjanov> I'm Sergey, PTL of Savanna, working in Mirantis and very interested in Storyboard
14:08:20 <SergeyLukjanov> :)
14:08:31 <gothicmindfood> Oh cool. Nice to meet you Sergey - were you in Hong Kong?
14:08:54 <SergeyLukjanov> gothicmindfood, yep
14:09:06 <NikitaKonovalov> I'm Nikita, I also work in Mirantis and contributed to Savanna project
14:09:06 <mordred> I'm Monty, former PTL of Infra, I hire people to work on things - and I'm going to get storyboard stood up and working if it kills all of you :)
14:09:12 <NikitaKonovalov> mostly to it's UI part
14:09:31 <gothicmindfood> I was too! Came to a couple of the Savanna sessions. Loved what I saw.
14:09:40 <ttx> ok, moving on
14:09:43 <ttx> #topic Winter Storyboard sprint/meetup
14:09:49 <SergeyLukjanov> gothicmindfood, glad to here that ;)
14:09:53 <ttx> I have absolutely no news about that.
14:10:10 <ttx> except that I proposed limited options
14:10:20 <mordred> oh - you did? to dev list?
14:10:23 <mordred> I may have missed that
14:10:30 <ttx> one being to organize something around FOSDEM (Brussels, Feb 1-2)
14:10:38 <ttx> mordred: private email to cody as requested
14:10:41 <mordred> ah. ok
14:10:52 <ttx> the other is to do something mid-February (week of 10 or 17)
14:11:09 <SergeyLukjanov> ttx, I really like the meetup in Europe :)
14:11:10 <ttx> My January filled up
14:11:16 <mordred> I believe gothicmindfood is on tour in february
14:11:22 <gothicmindfood> My February post February 3rd is no good
14:11:32 <gothicmindfood> but if I got back to NYC on the 3rd, I could be okay
14:11:41 <mordred> gothicmindfood: how about Feb 1/2 in brussels? perhaps meet the day before?
14:12:00 <mordred> like, Jan 31 ish
14:12:22 <ttx> yes, we could do a 2-day before the weekend, then you can leave on Sunday (2nd)
14:12:23 <gothicmindfood> That would  be good. I'd have to figure out how to get my cello to NYC without me, or just do a fly back to SFO to pick it up before going back to NYC.
14:12:44 <gothicmindfood> the 29th/30th could be better just to give me cello-pick-up time.
14:12:53 <ttx> also, beers++ and FOSDEM++
14:12:58 <gothicmindfood> and I go home on the 2nd early, go to NYC on the 3rd
14:13:14 <gothicmindfood> beers++ and mussels++++
14:13:33 <ttx> later options are scarce, as I enter what's known as the reelase-summit spiral of doom
14:13:53 <ttx> only to be out of it in... late May
14:14:02 <gothicmindfood> ttx: can we get you some medication to help alleviate the symptoms of that? ;-)
14:14:18 <mordred> hehe
14:14:21 <mordred> we call that wine
14:14:27 <ttx> it would probably interact with all the drugs I already have to take to duplicate myself in two places
14:14:39 <mordred> I need to check on budgets at HP to see if we can all commit to being there
14:14:39 <ttx> wine is part of it
14:14:47 <gothicmindfood> mordred and I should go splitsies on a case of burgundy for you.
14:14:50 <mordred> but I think functionally it seems doable
14:15:19 <ttx> gothicmindfood: one interesting thing with Brussels is I travel by train, which makes bringing wine a much more realistic option
14:15:39 <ttx> although wine in brussels is like having beer in spain. Wrong.
14:16:05 <ttx> mordred: I expect cody has details on everyone's availability by now
14:16:10 <gothicmindfood> ttx: I will trade you any weird american thing I can get on a plane for some decent Morgon. Always, fwiw.
14:16:11 <SergeyLukjanov> mordred, I need to check budget too
14:16:58 <ttx> ok, moving on then
14:17:15 <ttx> #topic Early objectives
14:17:42 <ttx> So, the trick at this point is to make progress that will still be useful once we make drastic changes
14:18:05 <ttx> I wouldn't invest too much in UI polish (like those error messages you proposed, NikitaKonovalov)
14:18:26 <ttx> because they might just get completely removed if/when we switch to SemanticUI
14:18:48 <ttx> search is still very useful because it's so much missing from the prototype it's not even funny
14:18:57 <mordred> ++
14:19:01 <mordred> search  - thank you
14:19:13 <SergeyLukjanov> the very simple improvements could be useful for using storyboard to track storyboard work
14:19:20 <ttx> but I think the decoupling of the backend / RESTification is what we should be focusing on right now
14:19:20 <mordred> that's a good point
14:19:38 <SergeyLukjanov> ttx, agreed, that's what I'd like to see :)
14:19:38 <mordred> CD is my number one goal - I want to get one up and running soon
14:19:40 <mordred> but
14:19:52 <mordred> I did this: https://github.com/emonty/stories
14:20:03 <mordred> which is a split out of the DB into sqlalchemy/alembic
14:20:12 <mordred> so it's set up for migrations, whcih means CD is possible
14:20:32 <mordred> I think actually what I should do is take that and make it a patch to storyboard
14:20:42 <ttx> mordred: could you explain how it works a bit more ?
14:20:53 <ttx> it's just the DB being split ?
14:20:55 <mordred> it's just the db models
14:20:57 <mordred> yes
14:21:03 <SergeyLukjanov> is it possible to use sqla in django?
14:21:12 <ttx> mordred: does it need to stand alone ?
14:21:12 <NikitaKonovalov> it is
14:21:24 * SergeyLukjanov not really aware about how django works
14:21:27 <NikitaKonovalov> but do we really need to stick sqlalchemy?
14:21:33 <mordred> it does not need to stand alone - I think it should just go back into our main tree
14:21:55 <mordred> and be used as model library
14:22:27 <gothicmindfood> Do we have a free-standing non-code version of the data-model floating around anywhere?
14:22:30 <ttx> mordred: so that means we don't use django model anymore -- do we also lose the automagic admin/ stuff ?
14:22:33 <mordred> I do not want to marry ourselves too much to django way of thinking, because we don't have good openstack integration that way
14:22:35 <mordred> hoirizon is an outlier
14:22:46 <ttx> or does django just falls back onto its 4 feets ?
14:22:52 <mordred> I'd rather we have sqlalchemy and alembic and pecan/wsme like the other projects
14:23:19 <mordred> ttx: we do lose admin that way - but I don't care, because I don't want to use that
14:23:21 <mordred> we want to get projects into storyboard with manage-projects/projects.yaml anyway
14:23:23 <mordred> so before we ahve a rest api for that
14:23:34 <ttx> mordred: so.. if we build the UI on top of a REST client, we'll need two components anyway
14:23:42 <NikitaKonovalov> still I have seen a kind of Django-sqlalchemy binding library which may be helpful before moving to wsme
14:23:44 <mordred> just having an import thing that can read projects.yaml and insert it into the db is all we need
14:24:02 <mordred> ttx: sure - but we can do that piece meal
14:24:18 <mordred> if we have the model in the repo using sqlalchemy, but the rest of the app is consuming it via python classes
14:24:20 <mordred> we can ADD a pecan rest api
14:24:26 <ttx> should we make that split (Db+REST server / REST client / UI) earlier rather than later ?
14:24:27 <mordred> and then start replacing the python db calls with rest calls
14:24:37 <mordred> I think we can do it gradually.
14:24:43 <mordred> I don't tihnk it's essential for us to make a big switch
14:24:44 <ttx> should it live all in same repo ?
14:24:53 <ttx> s/should/can
14:24:59 <mordred> for now, yes
14:25:01 <mordred> becaus SANITY
14:25:17 <mordred> we'll go crazy if we try to do a 3 repo split at this point
14:25:41 <mordred> NikitaKonovalov: neat! that might be a good middle step!
14:25:50 <ttx> so we would start the backend/pecan server on one side and start the django app on the other, but they could just live in same repo. OK
14:26:15 <mordred> yup. and the django app might not even talk to the wsme server at first :)
14:26:17 <NikitaKonovalov> there is no client now, so it may start from scratch in a separate repo
14:26:35 <mordred> that is a great point
14:26:47 <ttx> so one thing we could start working on is a API
14:27:11 <ttx> because so far this has been mostly model-driven
14:27:16 <ttx> and then UI-driven
14:27:30 <ttx> whereas the important piece in the final architecture is actually the API
14:27:41 <mordred> yah. agree
14:27:44 <NikitaKonovalov> +1
14:27:48 <mordred> I have an 8 hour plane flight tomorrow - I may take a first stab at one
14:27:50 <mordred> and see what you guys thinmk
14:27:52 <mordred> ":)
14:28:17 <ttx> and that's probably where process people like gothicmindfood can bring value without being too caught in technical implementation details
14:28:41 <ttx> gothicmindfood: fwiw see work areas @ https://wiki.openstack.org/wiki/StoryBoard
14:28:59 <ttx> Api would belong in "main concepts"
14:29:23 <ttx> mordred's pilot work would rather be "Technical Architecture"
14:29:30 <gothicmindfood> thanks for that, ttx.
14:30:29 <ttx> mordred: would be good to see what API we need for the current state
14:30:45 <ttx> mordred: so yes, if you like to work in planes. Or are in a business seat
14:30:48 <mordred> ttx: I was thnking that would make for a great v1 api - purely functional, no 'good' design
14:31:05 <ttx> I'll think about it too in my spare time
14:31:06 <mordred> ttx: then we can add a v2 api that is well designed, and then start rewriting the UI to consume it
14:31:33 <mordred> you have spare time?
14:31:45 <ttx> the danger, I think, is to start so high-level we can never make fast progress in evolving the current version
14:32:17 <ttx> this is, in essence, a Launchpad replacement. Not something that will revolutionize task/bug tracking
14:32:29 <ttx> I mean, it may revolutionize, but that's for version 3.0
14:32:49 <ttx> We need this thing now
14:33:58 <ttx> and even if we do it "simple" it will be so much better than what we use now it's not even funny
14:34:36 <ttx> that doesn't mean we can't be smart while doing it. just means the smartness shouldn't delay us too much.
14:34:42 <gothicmindfood> out of curiosity, ttx: what's your timetable on having something useful to use with OS looking like?
14:35:12 <ttx> I think we need to have openstack-ci and a few other guinea pigs up and running by the icehouse release
14:35:41 <ttx> then a significant subset of integrated/incubated projects by J release
14:36:08 <mordred> I'd lie to be more aggressive
14:36:24 <mordred> I'd like to do a forklift migratoin of everyone who isn't migrated already as the very first thing afer the J summit
14:36:38 <ttx> by "need" I mean so that everyone retains its sanity. I expect LP usability to not go any better now that HP recruited one of the 2 last LP devs
14:36:58 <ttx> the last one is probably already looking for a job
14:37:16 <mordred> I think that, other than infra and guinea pig projects, if we have parallel trackers per project, people will go insane
14:37:47 <ttx> mordred: i want us to have a good story to sell to ALL projects by I so that we can get them moved over the J cycle
14:37:56 <mordred> yes
14:38:18 <ttx> nobody tells me "I like Launchpad and would like to keep it"
14:38:39 <gothicmindfood> ttx: but some people do say it's the best bug tracker that they've used (despite its faults)
14:38:43 <ttx> so if we do something not too bad, they will gladly switch
14:38:49 <gothicmindfood> no one likes their bug trackers
14:38:54 <gothicmindfood> ever.
14:38:57 <mordred> gothicmindfood: I've met that guy ... thierry I think is his name
14:39:01 <gothicmindfood> HA
14:39:09 <ttx> gothicmindfood: it's the best, but mostly due to its model, I think. Not its UI
14:39:29 <ttx> the part of the model that made people like it, we already copied
14:39:36 <SergeyLukjanov> :)
14:39:42 <mordred> ++
14:39:47 <mordred> ttx: btw - good work on the model
14:39:50 <ttx> and extended where they failed to apply it (features)
14:40:02 <mordred> I did not feel the need to make large changes when I was doing the sqla work
14:40:07 <ttx> and then completed it (project groups just make sense)
14:40:12 <mordred> and questions I had were answered by the model itself
14:40:28 <ttx> mordred: the POC was just a Db model originally
14:40:39 <ttx> then without UI people would not have loved it
14:40:49 <mordred> the one thing it was missing was user/groups
14:40:54 <gothicmindfood> ttx: understood, II just still think least-hated means it's valued. ;-)
14:41:16 <gothicmindfood> ttx: dyou have a non-code data model map somewhere?
14:41:20 <mordred> but I believe that was just because you were using django auth stuff
14:41:23 <ttx> gothicmindfood: certainly. people will realize it wasn't that bad once presented with an laternative
14:41:32 <mordred> gothicmindfood: heh.
14:41:32 <gothicmindfood> ttx: (2nd question: or can I make one??) ;-)
14:41:50 <ttx> Our work is to make it "not suck" enough
14:41:50 <mordred> gothicmindfood: make one all you want! I'll even look at it and tell you waht I think
14:41:54 <mordred> ttx: ++
14:42:22 <ttx> gothicmindfood: I think NikitaKonovalov posted one
14:42:24 <NikitaKonovalov> I made a wiki page a bit earlier https://wiki.openstack.org/wiki/StoryBoard/ObjectModel about the object
14:42:43 <ttx> Also there was one (now outdated) at https://wiki.openstack.org/wiki/Task_Tracker_Requirements
14:43:43 <mordred> oh - neat. I hadn't seen that
14:43:47 <ttx> gothicmindfood: that said we already have UX questions. Like "do we need to be able to mark tasks invalid/wontfix/opinion"
14:43:58 <mordred> I should go and make sure that the new db code still maps to that
14:44:02 <ttx> vs. just delete the invalid tasks
14:44:19 <ttx> gothicmindfood: or Should priority be set for the whole story or per-task ?
14:44:38 <ttx> those are not critical, but still affect the model
14:44:48 * mordred votes for task at the data model layer
14:45:19 <mordred> but - it's possible that we have a more somple ui that only shows it on the story for now, and that code sets the priority on every task on the story
14:45:25 <ttx> sometimes they are simplicity vs. customizability decisions, and I don't care that much about them
14:45:30 <mordred> yes
14:45:42 <mordred> I think also - invalid vs. delete could also be a UI thing
14:45:53 <mordred> we could have an invalid status in the db
14:46:05 <mordred> and have the UI 'delete' operation set that status and then never show invalid things
14:46:32 <mordred> that way we have complete data in the db for historical reasons should we want to analyze it - but don't have to do complex user workflows
14:46:39 <ttx> basically, there are a few things i'm very attached to (like obviously the task/story layer), but a lot of others I'm very open about (UI framework, RESt decoupling, priority per task or per-story, etc.)
14:46:41 <gothicmindfood> ttx: any reason we can't have story priorities *and* task priorities as different types of priorities?
14:47:22 <gothicmindfood> mordred: maybe admin module can see invalid, but not basic user?
14:47:22 <ttx> gothicmindfood: no, I think mordred is right. Store prio at task table, and by default assign the first task prio to every task. Then allow people to change them
14:47:36 <mordred> gothicmindfood: maybe so
14:47:50 <ttx> probably the right tradeoff between usability and finesse
14:48:01 <mordred> also - I think there wants to be a concept at some point of user priorities
14:48:15 <mordred> like, there is the global priority of a task for the project
14:48:17 <ttx> mordred: that's an interesting concept to explore yes
14:48:19 <mordred> but on my personal todo list
14:48:26 <gothicmindfood> ttx: certainly more in line with how a SCRUM team views stories - each story has a priority in the list that's unique and ordered.
14:48:37 <mordred> you know - pbr bugs are WAY more important for me to look at than jim
14:49:11 <ttx> mordred: Ithink there are two difefrent concepts there. Importance (impact) and Priority (for me)
14:49:23 <gothicmindfood> ttx: ++
14:49:25 <mordred> ttx: yah.
14:49:25 <gothicmindfood> exactly
14:49:32 <mordred> also - there is an interesting thought from gothicmindfood there
14:49:34 <ttx> but then bugtrackers who have both are generally confusing
14:49:35 <gothicmindfood> mordred: not that we don't love your priorities, but they are, in fact, yours
14:49:44 <gothicmindfood> ;-)
14:50:03 <mordred> which is unique ordered priorities - rather than arbitrary categories
14:50:06 <NikitaKonovalov> may be just add a "favorites" for each user
14:50:11 <ttx> mordred: so haveing story/task importance on one side and PERSONAL priority on the other would work
14:50:12 <mordred> NikitaKonovalov: ++
14:50:23 <gothicmindfood> mordred: I don't see why we shouldn't be able to have both.
14:50:26 * SergeyLukjanov likes favorites too
14:50:44 <ttx> Oh. and that personal priority could also be used in two dimensions. Kanban style
14:50:48 <mordred> ttx: right - I mean, a task-priority-user mapping table shoudl allow any user to set private priorities on tasks for themselves
14:51:03 <ttx> user or groups.
14:51:05 <mordred> ttx: can you explain that last thought?
14:51:07 <mordred> ah
14:51:13 <ttx> this is getting better by the minute
14:51:15 <gothicmindfood> mordred: I'm thinking about an ordered list vs labeled priorities and not thinking they're mutually exclusive.
14:51:23 <mordred> yup
14:51:27 <mordred> I'm grokking now
14:51:45 <mordred> a user can have a prior list - a group can have a prior list - and the task can have an importance
14:52:08 <gothicmindfood> also, projects probably have their story priorities set by their tech lead, right?
14:52:12 <ttx> mordred: trello-style kanbans have things in different columns, but you can still order them. So that lets you express complex priorities
14:52:20 <gothicmindfood> (just checking)
14:53:01 <ttx> gothicmindfood: that would be a group priority yes
14:53:07 <mordred> gothicmindfood: yeah. I expect jeblair to say which things are the most important for infra to care about
14:53:28 <ttx> you could combine priority AND subscription to build a "things I care about" view
14:53:43 <ttx> anyway, that doesn't affect the base model
14:53:53 <ttx> that's interestig tricks we can play on top of it
14:54:06 <ttx> to make the result more suable in dev work planning
14:54:09 <ttx> usable*
14:54:20 <gothicmindfood> ttx: it's also a little bit about modeling users, but it  may impact workflow decisions *with* the model
14:54:23 <ttx> and not just a relmgt tracking tool
14:54:54 <gothicmindfood> so - admin, tech lead, heavy user, light user
14:54:58 <gothicmindfood> are things I'm thinking about
14:54:59 <ttx> #topic open discussion
14:55:03 <ttx> 5 minutes left
14:55:13 <ttx> anything else, or should we continue to brainstorm out loud ?
14:55:28 <mordred> ttx: so - stories are global and not owned by a project, yeah? and tasks have projects
14:55:37 <ttx> yes
14:55:49 <mordred> who owns importance on a story if it doesn't have a project associated
14:55:49 <gothicmindfood> or stories can be owned by more than one project?
14:56:03 <gothicmindfood> I feel like a story should have at least one project, right?
14:56:05 <mordred> like, who reviews/accepts?
14:56:07 <gothicmindfood> no orphan stories?
14:56:29 <ttx> mordred: we need a corner case for stories with no tasks
14:56:46 <mordred> I mean, there are qualities that teh story owns
14:56:46 <ttx> either automatically craete a "orphan" task, or some other smart workflow
14:56:47 <NikitaKonovalov> can we say that the story belongs to project if all of it's task are in the same project?
14:56:49 <mordred> like the description
14:57:10 <mordred> I want to know which users get to change those - or do we just go with a wiki-like "anyone can"?
14:57:14 <gothicmindfood> but what if the story is in development - like a feature on a waitlist?
14:57:24 <mordred> I'm fine with wiki-like 'anyone can' btw
14:57:30 <ttx> mordred: cody said he has an idea araound that
14:57:35 <mordred> awesome
14:57:40 <ttx> (how to treat stories with no tasks)
14:57:56 <mordred> question is still valid for stories with tasks
14:58:02 <ttx> I suggested a hack that would make them fall into a "no-project-associated" view for further triaging
14:58:06 <mordred> what about a story that has a task for nova and a task for cinder
14:58:17 <mordred> who owns the top-level story data
14:58:25 <mordred> I'm just going to assert 'nobody'
14:58:25 <gothicmindfood> both should, right?
14:58:35 <gothicmindfood> with the ability to see that others know it as well?
14:58:43 <ttx> mordred: I'd say it's undefined prio until a task is added
14:58:52 <mordred> what about the story description
14:58:56 <ttx> undefined meaning "to triage"
14:59:04 <ttx> mordred: free-for-all
14:59:08 <mordred> great
14:59:11 <mordred> I love it
14:59:19 <gothicmindfood> whoever gets it first ;-)
14:59:29 <ttx> I don't think restricting bugtracker access has done anything good anywhere
14:59:50 <gothicmindfood> can we have project teams be able to 'poke' each other to do stuff? ;-) (half-joking)
14:59:51 <ttx> we just need to tighten milestone planning stuff, targeting etc
15:00:14 <ttx> but who can change status / edit desc / titles ? Probably not
15:00:21 <ttx> (as long as they are authenticated)
15:00:46 <ttx> ok time is up
15:00:57 <ttx> famous last words ?
15:01:21 <ttx> gothicmindfood: that would be "add a task for another project"
15:01:33 <ttx> gothicmindfood: (we already do that a lot in LP)
15:02:17 <ttx> gothicmindfood: so yes, it's something we need to preserve
15:02:31 <ttx> #endmeeting