15:00:13 <krotscheck> #startmeeting StoryBoard
15:00:13 <openstack> Meeting started Mon Jul  7 15:00:13 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:18 <openstack> The meeting name has been set to 'storyboard'
15:00:21 <NikitaKo_> Hi
15:00:21 <krotscheck> Good morning, beautiful people!
15:00:29 <ttx> o/
15:00:38 <krotscheck> Ok, so looking at the agenda I see two major things which I think are going to take the majority of the discussion time.
15:00:52 <krotscheck> So I’m going to rearrange the meeting a bit and get the quick stuff out of the way.
15:01:00 <krotscheck> (Those two items being Vision and Search)
15:01:05 <jeblair> o/
15:01:12 <jeblair> krotscheck: link to agenda?
15:01:22 <krotscheck> Agenda: https://wiki.openstack.org/wiki/StoryBoard
15:01:37 * krotscheck makes a note to self to make someone else update meetingbot with agenda pages.
15:01:56 <krotscheck> #topic Ongoing Work.
15:02:13 <krotscheck> Ish is still in HP background check hell.
15:02:22 * krotscheck is super annoyed at HR processes.
15:03:10 <krotscheck> I spent last week with a bunch of rebases, specification docs, and getting annoyed at font encoding engines. Ultimately, little actual progress, though we did manage to land Quicknav.
15:03:34 <krotscheck> MaxV: You around?
15:03:52 <krotscheck> Guess not. NikitaKo_ ?
15:03:58 <NikitaKo_> I'm here
15:04:18 <NikitaKo_> So, I've been working on Teams API
15:04:26 * krotscheck saw that, and likes where it’s going.
15:04:27 <NikitaKo_> The DB part is on review
15:04:43 <NikitaKo_> The superusers migration is also there
15:04:56 <NikitaKo_> and the REST part is comming
15:05:12 <krotscheck> Excellent.
15:05:23 <NikitaKo_> I've also started looking at oslo.db
15:05:47 <krotscheck> NikitaKo_: Oh? Is that new and/or somethign we should really use?
15:05:50 <NikitaKo_> and I guess we will be able to migrate soon
15:06:16 <NikitaKo_> Nothing new there, but now it will be installed through requirements.txt
15:06:27 <NikitaKo_> which means no code syncs
15:07:01 <krotscheck> That’s nice.
15:07:11 <NikitaKo_> that's all from my side
15:07:16 <krotscheck> ttx: You wrote a pretty spiffy vision doc, which we’ll talk about in a bit. Anything else?
15:07:28 <ttx> I iterated on Tags specs. Haven't worked on team/groups although I think the use cases I contributed to https://review.openstack.org/#/c/103667/ is probably most of it
15:07:52 <ttx> so not sure a separate doc is still needed on that?
15:08:18 <krotscheck> Fair point. NikitaKo_? Thoughts?
15:09:14 <MaxV> krotscheck: hello
15:09:44 <ttx> krotscheck: I can give it another thought and if I have more, propose it in a comment on that spec
15:09:53 <krotscheck> ttx: That’ll work.
15:09:54 <ttx> if we think it belongs to another doc we can still wiki it
15:10:02 <krotscheck> MaxV: Hey there! Any updates from last week?
15:10:46 <NikitaKo_> krotscheck: re separate spec, I need to have a look
15:10:51 <MaxV> krotscheck: No, I didn't had the time due to scss introduction in Horizon, but I think I will be able to make some patches and reviews during this week
15:11:09 <krotscheck> MaxV: Wow, sounds like y’all are doing good work over there :)
15:11:16 <MaxV> krotscheck: I have started a script to avoid to download node again on each run
15:11:20 <krotscheck> Alright, Let’s see if teams and permissions can be merged.
15:11:32 <krotscheck> MaxV: That would greatly speed up our builds.
15:12:20 <krotscheck> MaxV: It might be intersting to look at Trusty as a build node, since the version of node on that is way more recent. I’m a few months removed from that code though...
15:12:27 <jeblair> MaxV: ++
15:12:48 <krotscheck> Alright, on to specs...
15:12:51 <krotscheck> #topic Specs
15:13:14 <krotscheck> So, from previous comments it sounds like Teams/Permissions are still under discussion.
15:13:41 <krotscheck> FYI - I just added the permissions spec because it was on Etherpad and I didn’t want to lose my thoguhts there, if it becomes superfluous then we can get rid of it.
15:14:25 <krotscheck> Most of the specs discussion (from past history) will likely focus on search, so I’d like to mention the others first.
15:15:20 <krotscheck> First question for jeblair: At what point is a spec “approved”? For example, we’ve got the subscriptions spec, and it seems to have settled, and we’re already putting some of the pieces into place for that, but it’s not “Approved” yet.
15:15:46 <krotscheck> jeblair: So what’s the expectation there?
15:17:27 <krotscheck> Ok, so teams & permissions are still up for discussion.
15:17:29 <jeblair> krotscheck: i'll take a look at that again soon then
15:17:30 <krotscheck> Other than that we still have search.
15:17:47 <krotscheck> ttx, you added a comment to the search spec that I thought was interesting.
15:18:01 <krotscheck> Quote: “The client-side implementation looks good. However game is not over yet on the server side final implementation. Maybe we could split this into initial search and scalable search, since it looks like we are implementing the first now ?”
15:18:07 <jeblair> krotscheck: approved is, well, approved -- so when an infra-core leaves an approval vote
15:18:14 <jeblair> krotscheck: and the patch lands to the repo
15:18:22 <krotscheck> jeblair: Does it seem strange to you that storyboard-core can’t approve its own specs?
15:19:00 <jeblair> krotscheck: not at all.  storyboard is a constituent project of the infrastructure program, and the overall direction of that program is set by the ptl and core team
15:19:26 <jeblair> krotscheck: i plan on seeing that you, ttx, and other important players are in agreement before approving storyboard related specs
15:19:54 <krotscheck> Got it.
15:20:04 <krotscheck> I disagree, but now’s not the time to talk about that.
15:20:14 <krotscheck> On to ttx’s comment.
15:20:22 <jeblair> krotscheck: if i do something you don't like there, feel free to discuss it with me.  you can always run for ptl or take it up with the tc.
15:20:45 <krotscheck> I thought his comment was intersting in the split between “initial search” and “scaleable search"
15:20:52 <jeblair> krotscheck: and as a last resort, you're welcome to work on whatever projects you want outside of the context of the openstack project.
15:21:04 <krotscheck> See, the client implementation is purely a browse UI.
15:21:30 <NikitaKo_> There is a change for the server side
15:21:31 <jeblair> krotscheck: but as long as you're trying to work within it, please do attempt to follow our processes.
15:21:50 <krotscheck> jeblair: Have I not?
15:22:19 <jeblair> krotscheck: you said you disagreed with them.
15:22:21 <krotscheck> jeblair: As I said: A bit out of context for the scope of this meeting, so I’ll drop you a private email later. Honestly, I feel like most of the things will end up on the disucssion for the vision doc.
15:22:46 <NikitaKo_> which can be called "initial"
15:22:50 <NikitaKo_> here it is https://review.openstack.org/#/c/101476/
15:22:59 <krotscheck> Right!
15:23:01 <krotscheck> Soryr
15:23:07 * krotscheck is getting split between two conversations.
15:23:16 <jeblair> krotscheck: i didn't start the conversation, but i am prepared to finish it.  i look forward to your email.
15:23:31 <ttx> krotscheck: my point there is that I expect the discussion on the final server-side solution to take a bit of time -- and it shouldn't block the client-side implementation (which uses the primitive server-side SQL-backed search)
15:23:38 <krotscheck> jeblair: Yes please, I’ll drop you a line (I don’t disagree with process, just with underlying assumptions)
15:24:01 <krotscheck> I totally agree with you ttx.
15:24:18 <ttx> we can "improve" the server-side afterwards
15:24:24 <NikitaKo_> I also agree
15:24:31 <ttx> (inserts something about bridges being crossed)
15:24:47 <NikitaKo_> Action item for me to split it
15:25:09 <krotscheck> #action NikitaKo_ Split search specification into “inital” and “scaleable"
15:25:56 <krotscheck> I like the initial abstraction on that.
15:26:23 <krotscheck> So it sounds like initial search has consensus, do we want to talk about scaleable search?
15:26:38 * krotscheck may be wrong in assuming consensus.
15:26:56 <ttx> it's fine by me (initial)
15:27:33 <ttx> I don't have strong opinions on scaleable, i'll defer to those who will implement/maintain the beast
15:28:08 * krotscheck has been familiarizing himself with the guts of Lucene/ES recently, so that he knows what he’s talking about :)
15:28:23 <NikitaKo_> Anyway the scalable solution will require messaging and a a lot of changes to puppet modules
15:28:50 <krotscheck> Messaging would be driving index rebuilds, yes?
15:29:01 <NikitaKo_> krotscheck: yes
15:29:23 <krotscheck> Righto
15:29:48 <NikitaKo_> I think it makes sense to use messaging for both notifications and indexing
15:30:05 <krotscheck> NikitaKo_: I agree.
15:30:44 <krotscheck> I’m a little worried that my own self-investment in that spec (due to my authorship) is making me blind to other potential solutions though, so if anyone has different thoughts...
15:31:00 * krotscheck doesn’t want messaging to be the hammer and everything else to be a nail.
15:31:42 <krotscheck> Anything else on specs before we switch over to Vision?
15:32:23 <krotscheck> #topic Vision Document (ttx)
15:32:25 <krotscheck> https://wiki.openstack.org/wiki/StoryBoard/Vision
15:32:28 <ttx> OK, so I drafted a basic vision while you were celebrating independence, trying to stay high-level and hopefully implementation-agnostic
15:32:47 <ttx> I wrote remarks at the bottom
15:33:01 <ttx> about things that were not as self-evident as the rest
15:33:23 <ttx> which may trigger more discussions imho
15:33:34 <krotscheck> As it should :)
15:33:46 <ttx> Not sure if the rest of the "vision" is fully consensual though
15:34:00 <ttx> it's just that it flowed consistently when I wrote it
15:34:20 <ttx> while the two sticky points felt more artificially attached
15:34:47 <ttx> I still stand by those, because I still think it's the easiest way to solve that hole in our tooling
15:34:54 <ttx> but I welcome discussion on them
15:35:35 <krotscheck> Honestly, I love that doc because I can pull actual features out of it very quickly.
15:35:37 <ttx> it's a first draft, comments welcome
15:35:56 <krotscheck> Case and point: The first paragraph tells me that tasks do not necessarily have to be attached to code.
15:36:04 <ttx> krotscheck: did I manage to stay implementation-agnostic enough ?
15:36:18 <ttx> The only thing that's pretty hardcoded in there is the task/story relationship
15:36:30 <krotscheck> ttx: Yes. I see no python.
15:36:32 <krotscheck> :)
15:36:58 <krotscheck> The third paragraph also tells me that personal goals are a separate way of organizing tasks.
15:37:22 <krotscheck> I have one question: Does the spec meaningfully change if we replace “gerrit” with “code review system”?
15:37:43 <krotscheck> (similar with git vs. source control)(
15:38:01 <ttx> krotscheck: no. we could say code review system and VCS
15:38:06 <ttx> +1
15:38:11 * ttx fixes
15:38:59 <krotscheck> Which of the notes do you want to talk about?
15:39:06 <krotscheck> The bug vs task tracker is interesting.
15:39:22 <krotscheck> We have the “is_bug” flag in the db righ tnow.
15:39:55 <ttx> so, another thing that emerged from this is that we could have 3 types
15:40:02 <ttx> feature, bug and vulnerability
15:40:14 <ttx> which are the key components of changelogs/release notes
15:40:26 <krotscheck> Interesting distinction
15:40:27 <ttx> taking a step back allowed me to see the 3rd type
15:40:58 <ttx> since I suddenly no longer saw it as a bug, but as a piece of release information to convey
15:41:22 <krotscheck> Hrm.
15:41:25 <ttx> that said, if we drop the changelog task and let the VCS build it for us, it's a non-issue
15:41:28 <krotscheck> Iiiiiinteresting.
15:41:44 <ttx> back to bugtracker/tasktracker
15:42:09 <ttx> the problem with bug tracking is that it's almost a workflow that happens before the main use case (task tracking) happens
15:42:26 <ttx> we can make the task tracker bug-submission friendly (which is the way we started to do that)
15:42:46 <ttx> or we can try to have a separate tool / separate panels for bug submission/triaging
15:43:12 <ttx> I still think the first option is the simplest, but i'm ready to have a long thought about it
15:43:39 <ttx> I know that particular bit was bothering gothicmindfood as well
15:43:49 <krotscheck> That kindof jives with some of the UX feedback I got around the workflow for a feature. Design discussion is something that happens well before any tasks are assigned, right?
15:44:28 <ttx> krotscheck: that's one way of seeing it yes... You could also consider it's just one of the tasks
15:44:33 <krotscheck> True
15:44:37 <ttx> task 0
15:44:47 <ttx> especially now that it lands in a code repo
15:44:48 * krotscheck wonders if a bug is simply a story with the Bug system tag
15:44:51 <ttx> and we can track the status of that
15:45:02 <krotscheck> Hi there, ish_!
15:45:18 <ish_> Hi Michael..
15:45:43 <ttx> krotscheck: the trick there is... developers create stories and tasks for themselves in most cases. They may look at bugs and triage them, but it's almost a separate workflow
15:46:08 <krotscheck> ttx: Workflow-by-tag?
15:46:19 * krotscheck is just throwing concepts up against the wall here.
15:46:21 <ttx> krotscheck: yeah, probably the simplest
15:46:38 <ttx> krotscheck: alternative is to have an incident response component in parallel of the task tracking component
15:46:53 <ttx> but I fear that the former would get ignored
15:47:08 <krotscheck> ttx: Not if we surface it.
15:47:12 <ttx> given that our devs are all cats
15:47:14 * gothicmindfood might be tired, but often thinks bugs are just a tag
15:47:16 <krotscheck> I like cats
15:47:31 <krotscheck> I have two of them. As long as you have a little shiny red dot they will go wherever you want them to.
15:47:47 <ttx> krotscheck: anyway, I just wanted to single out that those two parts of the "vision" were probably the ones were discussion should still happen
15:48:10 * gothicmindfood also requests a joke 'feature' tag to put with bugs if someone wants
15:48:10 <ttx> do you see anything questionable in the rest of the vision ?
15:48:26 <krotscheck> Nope.
15:49:13 <ttx> doesn't mean it's done or designed -- the whole "organize their work" thing is pretty nebulous at this point
15:50:18 <krotscheck> ttx: Well, given that we can (soon) describe a search via a fixed set of criteria, saving those criteria into your own customized dashboard isn’t hard :)
15:51:44 <krotscheck> ttx: Ok, so what part in particular do you want more focus on?
15:52:12 <NikitaKo_> krotscheck: do you mean we need something like gmail has, when you do a search and then say "create me a filter by that search" ?
15:53:19 <krotscheck> NikitaKo_: That’s what I’m thinking. Rather than try to proscribe what goes on someone’s dashboard, let people design it themselves.
15:53:33 <krotscheck> (and then go in and figure out what people have actually built, and inform our use cases from that)
15:54:00 <krotscheck> But that’s pie-in-the-sky right now.
15:54:16 <krotscheck> #topic Open Discussion
15:54:17 <ttx> krotscheck: I think the focus should still be on the milestones we defined on the roadmap
15:54:23 <NikitaKo_> users could build their subscriptions with the same mechanizm then
15:54:23 <krotscheck> ttx: I agree
15:54:48 <ttx> krotscheck: defining them after user adoption requirements is a pretty fgood way of doing it
15:55:07 <krotscheck> NikitaKo_: Yup.
15:55:27 <krotscheck> Ok, so we have 5 minutes, are there any major roadmap blockers that we’re running into?
15:56:03 <krotscheck> One thing I noticed is that we have lots of admin-related tasks but we don’t have any place to really put them into the UI.
15:56:29 <krotscheck> Oh, also, ttx: Are project groups an admin thing or a anyone thing right now?
15:57:06 <ttx> krotscheck: I think it can be an admin thing
15:57:17 <ttx> coupled with personal project subscription
15:57:33 <ttx> should cover most cases...
15:57:57 <krotscheck> ttx: Admin it is then.
15:58:07 <krotscheck> Nobody has any roadmap blockers/
15:58:08 <krotscheck> ?
15:58:14 <krotscheck> (Other than code reviews? :) )
15:58:45 <NikitaKo_> nothing that I can see
15:59:00 <ttx> nop
15:59:36 <krotscheck> Awesome.
15:59:40 <krotscheck> #endmeeting