15:00:11 <krotscheck> #startmeeting StoryBoard
15:00:12 <openstack> Meeting started Mon Oct 20 15:00:11 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:13 <ttx> o/
15:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:15 <openstack> The meeting name has been set to 'storyboard'
15:00:17 <jeblair> o/
15:00:25 <krotscheck> Neat. Anyone else?
15:00:53 <krotscheck> I’ll take that as a no.
15:01:05 <krotscheck> Agenda!
15:01:07 <krotscheck> #link https://wiki.openstack.org/wiki/StoryBoard#Agenda
15:01:21 <krotscheck> #topic Discussion: Story Tags
15:01:26 <krotscheck> ttx: Take it away!
15:01:33 <ttx> yay
15:02:08 <ttx> it's actually story types, not tags
15:02:17 <mordred> ttx: we ahve AFS now, so you could implement story types with AFS
15:02:29 * mordred runs away
15:02:30 <krotscheck> define AFS?
15:02:34 <krotscheck> Andrew File System?
15:02:35 <ttx> We can implement anything with AFS.
15:02:41 <mordred> krotscheck: yes
15:02:44 <ttx> that's the beauty of ity
15:02:46 <mordred> but I'm kidding in this instance
15:02:49 <ttx> https://review.openstack.org/#/c/129267/
15:02:52 <jedimike> ttx, and zombo.com
15:02:57 <ttx> so this is the spec I wrote
15:03:13 <ttx> I simplified compared to the wiki @ https://wiki.openstack.org/wiki/StoryBoard/Story_Types
15:03:43 <ttx> If the general idea is acceptable, I would recommend just starting with features and bugs
15:04:00 <ttx> then tackle the vulnerability case (which requires the privacy aspect)
15:04:09 <krotscheck> That seems like a good place to start.
15:04:32 <ttx> I think types are different enough from tags
15:04:44 <ttx> especially from the "must have one and only one type" aspect
15:04:55 <mordred> yah.
15:04:57 <ttx> that they require their own column
15:05:02 <krotscheck> Right, and from a UI perspective making them merged is somewhat confusing.
15:05:29 <mordred> not that github is a great example of what to do... but even they have types (bug, pr, etc) and tags - I think largely because of UI sanity
15:05:34 <ttx> ideally you should be able to grasp if you're looking at a feature story, a bug story or a vulnerability story just by loking at the page
15:05:47 <krotscheck> If you see: ‘release-icehouse’, ‘bug’, ‘storyboard’, ‘storyboard-webclient”, what exactly is what in that list?
15:05:49 <ttx> could be color, could be a prominent icon
15:05:59 <ttx> krotscheck: ++
15:06:22 <ttx> so in summary, please review spec
15:06:30 <krotscheck> yay, specs!
15:06:39 <ttx> I dropped the idea to have "inherited" types like "regression"
15:06:51 <ttx> I think that can be done as Tags over a bug
15:06:54 <jedimike> i would like to help on this story when the spec is agreed
15:07:19 <krotscheck> jedimike: sure! Ask in the channel and I’ll point you in the right direction :)
15:07:30 <ttx> to justify a type, it needs to trigger a specific workflow imho
15:07:45 <jeblair> the spec looks good; i can put it on the priority specs list in the infra meeting to let people know it's ready for review
15:07:50 <ttx> so in theory we could have "wireframe" as a type that would trigger some special tooling in the story
15:08:24 <ttx> but I don't think we should subtype for regressions or "feature-that-reduces-technical-debt"
15:08:40 <ttx> jeblair: cool
15:08:54 <krotscheck> What’s a workflow? Is that included in this spec?
15:09:00 * krotscheck opens that can of worms.
15:10:35 <ttx> krotscheck: by workflow I mean, some actions in the UI are restricted based on type
15:11:02 <ttx> for example, you can't target a feature story task to a stable branch
15:11:02 <krotscheck> Alright. For me workflow means that there’s a state machine that gets triggered.
15:11:26 <ttx> no state machine :)
15:11:39 <krotscheck> ….well, validation rules are a certain kind of state machine, no?
15:11:41 <ttx> it's just that the UI is aware otf types
15:11:52 <ttx> while it's unaware of tags
15:12:19 <fungi> definitely a separate concept from the traditional "workflow management" software design you find in large companies
15:12:20 * mordred thinks krotscheck and ttx may be talking at different detail levels
15:12:28 <krotscheck> How about I look at the spec and we go from there :)
15:12:40 <ttx> yeah, sounds like the right first step
15:12:47 <krotscheck> Alrightey, anything else before we move on?
15:12:52 <ttx> nothing from me
15:12:58 <krotscheck> #topic Summit!
15:13:39 <krotscheck> Infra is still talking about what goes into the infra track.
15:13:58 <krotscheck> I don’t think an official decision on whether SB is in that has been reached yet, is that correct jeblair
15:13:59 <krotscheck> ?
15:14:21 <jeblair> correct, i think we'll focus on that this meeting
15:14:25 <krotscheck> Cool
15:14:33 <jeblair> what's on the table?
15:15:07 <jeblair> #link https://etherpad.openstack.org/p/kilo-infrastructure-summit-topics
15:15:25 <jeblair> is our brainstorming etherepad and IT HAS GOTTEN BIGGER
15:15:55 <krotscheck> Well, storyboard is item #2 on that list.
15:16:06 <jeblair> "Current features, feature roadmap, project migration targets - krotscheck"
15:16:31 <jeblair> what concrete outcomes would we want from that?
15:16:48 <krotscheck> Honestly I want to use this summit to impress on people that yes: StoryBoard is coming, and Yes: They will be using it inside of a year, and Yes: If they want to have any say in how their project is managed they need to start contributing.
15:17:30 <jeblair> doing that in the infra track is likely to be preaching to the choir
15:17:47 <jeblair> there might be people in the room that don't already know that, but we shouldn't count on it
15:18:10 <ttx> yeah, was wondering if we could try to abuse one of the "grwoth issues" cross-project workshops to mention that
15:18:16 <ttx> err growth
15:18:19 <jeblair> the conference, or potentially the cross-project track would be better for that.
15:18:25 <ttx> and then talk storyboard at the infra meetup
15:18:34 <krotscheck> *shrug*. My conference (not summit) proposal was declined.
15:18:35 <jeblair> yeah.  i don't think storyboard is ready for a full cross-project session yet
15:18:35 <ttx> with people interested to join
15:19:10 <jeblair> ttx: but certainly bringing it up in the context you mentioned would be good
15:19:16 <jeblair> we can try to get that message out :)
15:20:11 <jeblair> but for the infra session -- probably the best use of time is to get f2f time to discuss tricky new features, or plan our implementation in more detail
15:20:58 <jeblair> i feel like we still have a handle on where we need to get to in the next few months, so i don't want to just repeat what we already know there
15:20:59 <krotscheck> Ok, so it sounds like it’s less of an infra session thing, and more of a meetup thing?
15:21:34 <jeblair> but if there are topics that are a bit further down the road that you think it would be good to discuss, we can target that
15:22:10 <krotscheck> I can’t think of any. The big one that I’ve been noodling over is how to allow infra to extend storyboard for integration purposes, but stevedore solved that rather neatly.
15:22:30 <jeblair> we're extending storyboard for integration purposes?
15:23:11 <krotscheck> jeblair: We’re providing a plugin system by which, if you so desire, you can write a plugin that can talk to things like zuul. And I’m using the email feature as a canary.
15:23:42 <jeblair> krotscheck: you're considering the email feature a plugin?
15:24:04 <jeblair> krotscheck: i don't expect to write any plugins for storyboard.
15:24:45 <mordred> I think plugins are a great idea given the number of downstreams we have that consume things we do
15:24:58 <jeblair> (to close out the summit topic -- if you have something concrete you'd like to get out of the session, please think about that and add it to the etherpad.  i think we'd be happy to have a storyboard session, as long as it's useful.  i don't want to have one just for the sake of form)
15:25:08 <krotscheck> kk
15:25:25 <jeblair> mordred: sure.  just trying to figure out what we're talking about :)
15:25:34 <krotscheck> Ok, so before we go down the “plugins wat” topic, one more summit topic I want to mention.
15:25:50 <NikitaKonovalov> o/
15:25:53 <krotscheck> T-Shirts. http://www.customink.com/designs/storyboard/etb0-0014-66bc -
15:25:56 <NikitaKonovalov> sorry I'm late
15:26:26 * krotscheck was a little late to the game on ordering them, and now only a rush order will do. Do we care enough?
15:27:09 <krotscheck> If not, I’m just going to get one for myself, because I REALLY need to advocate at the summit.
15:27:15 <mordred> I will wear one - but also it's paris and will be cold, so it's possible nobody will know whne I do
15:27:29 <ttx> krotscheck: maybe not worth a rush order
15:27:46 <krotscheck> I expect being indoors will help.
15:27:57 <ttx> it's November. It's cold inside too.
15:28:09 <jeblair> i think the biggest advocacy we could do is move infra to storyboard
15:28:18 <ttx> Although we have a lovely 80�F this weekend
15:28:27 <ttx> had*
15:29:21 <krotscheck> jeblair: That’ll expose storyboard to devs. I want to talk to influencers.
15:29:35 <krotscheck> ‘cause, well, they’re the ones who can hire people to help out :)
15:30:13 <krotscheck> But it sounds like interest is lukewarm.
15:30:18 <krotscheck> So meh. Moving on.
15:30:20 <jeblair> this is kind of going off-topic.  but in our community, quite a number of devs are influencers.  that's kinda one of the things we like about it.  :)
15:30:42 <krotscheck> #topic MVP 1.1
15:30:51 <krotscheck> #topic MVP 1.1: Subscription
15:31:12 <krotscheck> I believe the last UI piece has landed so we can demonstrate that it’s working. The UI is less than ideal (no click through yet), but it’s all up there.
15:32:03 <krotscheck> Looks like either my browser’s cache is still old, or the client hasn’t been updated on s.o.o yet
15:32:43 <jeblair> http://puppetboard.openstack.org/node/storyboard.openstack.org
15:32:49 <jeblair> puppet is current on it
15:32:54 <NikitaKonovalov> krotscheck: may be we shall add a commit id somehow to be displayed on the page
15:33:04 <krotscheck> NikitaKonovalov: Good idea.
15:33:05 <NikitaKonovalov> so we always know what's running
15:33:43 <NikitaKonovalov> actually it will be better to expose API-side commit also
15:34:34 <krotscheck> Ok, added #318
15:34:54 * krotscheck makes a note to keep track of the server to make sure it’s all working.
15:35:07 <krotscheck> #topic MVP 1.1 Project Groups
15:35:18 <mordred> krotscheck: we probably want a way to see shas of storyboard and storyboard-webclient, fwiw
15:35:37 <mordred> krotscheck: but the second probably takes a little bit more work
15:35:40 <krotscheck> mordred: https://storyboard.openstack.org/#!/story/318
15:35:54 <mordred> krotscheck: yes. I agree with that story
15:36:27 <krotscheck> Lots of work on project groups, including test coverage and other fun things.
15:36:34 <krotscheck> A bunch of them have already landed.
15:36:48 <krotscheck> The big outstanding one is the import script.
15:37:05 <krotscheck> Anyone feel excited about trying that?
15:37:31 * ttx disappears for a bit while his proxy restarts
15:37:42 <jeblair> krotscheck: what do you mean by 'trying'?
15:37:58 <krotscheck> jeblair: “build it"
15:38:18 <jeblair> krotscheck: oh, adding project group support to the import script?
15:38:23 <krotscheck> jeblair: Yes.
15:39:01 <krotscheck> jeblair: load projects should also read the -groups tag that we argued about so much a few weeks ago, and should do it in a way that removes groups that don’t exist anymore.
15:39:30 <jeblair> krotscheck: sounds reasonable
15:39:44 <krotscheck> ttx: Any thoughts on that?
15:41:13 <ttx> krotscheck: if "that" is the -groups tag read, makes sense to me
15:41:44 <krotscheck> ttx: Well, the downside of that would be that the Admin Project Groups UI wouldn’t really let you add custom, non-config-file defined groups.
15:41:54 <krotscheck> But if you’re cool with that we can move forward.
15:42:13 <ttx> fine by me
15:42:47 <krotscheck> Alright.
15:42:51 <fungi> we have very effective mechanisms in place to propose changes to config files ;)
15:43:09 <krotscheck> So, work is ongoing on proejct groups, with only one feature remaining and the other ones either proposed or merged.
15:43:19 <krotscheck> #topic MVP 1.1: Tags
15:43:28 <krotscheck> NikitaKonovalov: This one’s yours.
15:44:00 <NikitaKonovalov> Sorry to say but I had no chance to fix that migration
15:44:21 <NikitaKonovalov> I'll do my best to fix it
15:44:32 <krotscheck> Alright.
15:44:51 <krotscheck> #topic MVP 1.1 Email
15:44:55 <NikitaKonovalov> I guess that will be the only change needed for API side
15:45:02 <krotscheck> oops.
15:45:06 <krotscheck> #topic MVP 1.1: Tags
15:45:21 <krotscheck> There’s a bit of UI work needed, no?
15:46:24 <krotscheck> Ok, silence. back to email
15:46:29 <krotscheck> #topic MVP 1.1 Email
15:47:01 <krotscheck> I started working on email.
15:47:19 <krotscheck> Identified a couple of things we needed. Firstly, user preferences that are persisted on the server (Yes I want emails, no I don't).
15:47:27 <krotscheck> Secondly: Some kind of a cron scheduled worker.
15:47:55 <krotscheck> I’ve got patches up for the first, and a WIP for the second.
15:48:19 <krotscheck> In both cases, I opted for making them pluggable.
15:48:20 <jeblair> i have some domain expertise here; i should try to review those
15:48:39 <krotscheck> Would love your feedback.
15:49:27 <krotscheck> jeblair: The review tree starts here (having a pep issue atm) https://review.openstack.org/#/c/128487/
15:49:43 <jeblair> krotscheck: can you elaborate on the decision to make it pluggable?  are you trying to keep the core small and modular and define good interfaces for extending functionality?
15:49:56 * ttx has got to run
15:50:08 <ttx> be back in a few
15:50:48 <ttx> false alarm, back
15:51:43 <krotscheck> jeblair: Basically. Plus, I want to draw a clear line between the web service and other things that get triggered due to the web service.
15:53:03 <jeblair> okay, makes sense.  it sounds like email will be an "in-tree" plugin (i think email support is a batteries-included kind of feature and should be easy to enable)?  that sounds great
15:53:04 <krotscheck> I also feel that mordred’s point is apropos: Consumption of StoryBoard downstream will hopefully become a thing, and it will be an easier thing if downstream can add their own bits.
15:53:37 <krotscheck> jeblair: Yep. Same with subscriptions, federation, and hopefully (eventually) auth delegation.
15:53:47 <jeblair> groovy
15:54:04 <krotscheck> Also, Stevedore is neat.
15:54:26 <krotscheck> The whole “Oh you have this thing installed in your venv? Lemme run that for you!” thing is neat. A little frightening, but neat.
15:54:57 * krotscheck idly wonders if there will eventually be a storyboard-report-everhthing-to-the-man plugin.
15:55:02 <krotscheck> But I digress.
15:55:12 <mordred> yah. I think it fits well with the "it's unlikley you're going to install storyboard plugins and then not want to actually use them"
15:55:13 <jeblair> krotscheck: that's the stackalytics plugin ;)
15:55:25 <krotscheck> HAH
15:55:26 <krotscheck> Nice.
15:55:30 <krotscheck> But yeah, exactly.
15:55:46 <krotscheck> So given user preferences, and a cron hook, and an API event hook, we’ve got the pieces necessary to make emails work.
15:56:16 <krotscheck> My approach is to build an event hook that saves relevant subscription data to a file per user, then use the cron hook to send the emails on a user-defined schedule.
15:56:56 <jeblair> so if we want emails to be sent instantly?
15:57:53 <krotscheck> jeblair: Probably a second event hook. The WIP email patch here includes the configuration options in question: https://review.openstack.org/#/c/129091/1/storyboard/plugin/email/preferences.py
15:58:06 <jeblair> k, i'll take a look
15:58:23 <ttx> right, could be different. one is a notification, the other a digest
15:58:29 <krotscheck> yep.
15:58:53 <krotscheck> The only tricky thing would then be ‘hey do you want that event as a digest or as an instant notification'.
15:59:18 <krotscheck> But that, I feel, goes back to allowing a user to list and manage their subscriptions.
15:59:49 <jeblair> yeah.  i know a lot of folks for whom bug email is instant notification (and in fact, just slots in with their normal email workflow)
15:59:49 <mordred> amusingly, user management of subscriptions was a feature that launchpad added something like 6 years after the service was launched
16:00:05 <jeblair> but i defn see the use case for digests
16:00:16 <mordred> or for no mail
16:00:24 <krotscheck> yep
16:00:30 <mordred> I, for one, still wish launchpad emailed me less
16:01:07 <krotscheck> So that’s it for email. and we’re out of time!
16:01:10 <krotscheck> Thanks everyone!
16:01:15 <krotscheck> #endmeeting