15:00:11 #startmeeting StoryBoard 15:00:12 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 o/ 15:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:15 The meeting name has been set to 'storyboard' 15:00:17 o/ 15:00:25 Neat. Anyone else? 15:00:53 I’ll take that as a no. 15:01:05 Agenda! 15:01:07 #link https://wiki.openstack.org/wiki/StoryBoard#Agenda 15:01:21 #topic Discussion: Story Tags 15:01:26 ttx: Take it away! 15:01:33 yay 15:02:08 it's actually story types, not tags 15:02:17 ttx: we ahve AFS now, so you could implement story types with AFS 15:02:29 * mordred runs away 15:02:30 define AFS? 15:02:34 Andrew File System? 15:02:35 We can implement anything with AFS. 15:02:41 krotscheck: yes 15:02:44 that's the beauty of ity 15:02:46 but I'm kidding in this instance 15:02:49 https://review.openstack.org/#/c/129267/ 15:02:52 ttx, and zombo.com 15:02:57 so this is the spec I wrote 15:03:13 I simplified compared to the wiki @ https://wiki.openstack.org/wiki/StoryBoard/Story_Types 15:03:43 If the general idea is acceptable, I would recommend just starting with features and bugs 15:04:00 then tackle the vulnerability case (which requires the privacy aspect) 15:04:09 That seems like a good place to start. 15:04:32 I think types are different enough from tags 15:04:44 especially from the "must have one and only one type" aspect 15:04:55 yah. 15:04:57 that they require their own column 15:05:02 Right, and from a UI perspective making them merged is somewhat confusing. 15:05:29 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 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 If you see: ‘release-icehouse’, ‘bug’, ‘storyboard’, ‘storyboard-webclient”, what exactly is what in that list? 15:05:49 could be color, could be a prominent icon 15:05:59 krotscheck: ++ 15:06:22 so in summary, please review spec 15:06:30 yay, specs! 15:06:39 I dropped the idea to have "inherited" types like "regression" 15:06:51 I think that can be done as Tags over a bug 15:06:54 i would like to help on this story when the spec is agreed 15:07:19 jedimike: sure! Ask in the channel and I’ll point you in the right direction :) 15:07:30 to justify a type, it needs to trigger a specific workflow imho 15:07:45 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 so in theory we could have "wireframe" as a type that would trigger some special tooling in the story 15:08:24 but I don't think we should subtype for regressions or "feature-that-reduces-technical-debt" 15:08:40 jeblair: cool 15:08:54 What’s a workflow? Is that included in this spec? 15:09:00 * krotscheck opens that can of worms. 15:10:35 krotscheck: by workflow I mean, some actions in the UI are restricted based on type 15:11:02 for example, you can't target a feature story task to a stable branch 15:11:02 Alright. For me workflow means that there’s a state machine that gets triggered. 15:11:26 no state machine :) 15:11:39 ….well, validation rules are a certain kind of state machine, no? 15:11:41 it's just that the UI is aware otf types 15:11:52 while it's unaware of tags 15:12:19 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 How about I look at the spec and we go from there :) 15:12:40 yeah, sounds like the right first step 15:12:47 Alrightey, anything else before we move on? 15:12:52 nothing from me 15:12:58 #topic Summit! 15:13:39 Infra is still talking about what goes into the infra track. 15:13:58 I don’t think an official decision on whether SB is in that has been reached yet, is that correct jeblair 15:13:59 ? 15:14:21 correct, i think we'll focus on that this meeting 15:14:25 Cool 15:14:33 what's on the table? 15:15:07 #link https://etherpad.openstack.org/p/kilo-infrastructure-summit-topics 15:15:25 is our brainstorming etherepad and IT HAS GOTTEN BIGGER 15:15:55 Well, storyboard is item #2 on that list. 15:16:06 "Current features, feature roadmap, project migration targets - krotscheck" 15:16:31 what concrete outcomes would we want from that? 15:16:48 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 doing that in the infra track is likely to be preaching to the choir 15:17:47 there might be people in the room that don't already know that, but we shouldn't count on it 15:18:10 yeah, was wondering if we could try to abuse one of the "grwoth issues" cross-project workshops to mention that 15:18:16 err growth 15:18:19 the conference, or potentially the cross-project track would be better for that. 15:18:25 and then talk storyboard at the infra meetup 15:18:34 *shrug*. My conference (not summit) proposal was declined. 15:18:35 yeah. i don't think storyboard is ready for a full cross-project session yet 15:18:35 with people interested to join 15:19:10 ttx: but certainly bringing it up in the context you mentioned would be good 15:19:16 we can try to get that message out :) 15:20:11 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 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 Ok, so it sounds like it’s less of an infra session thing, and more of a meetup thing? 15:21:34 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 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 we're extending storyboard for integration purposes? 15:23:11 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 krotscheck: you're considering the email feature a plugin? 15:24:04 krotscheck: i don't expect to write any plugins for storyboard. 15:24:45 I think plugins are a great idea given the number of downstreams we have that consume things we do 15:24:58 (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 kk 15:25:25 mordred: sure. just trying to figure out what we're talking about :) 15:25:34 Ok, so before we go down the “plugins wat” topic, one more summit topic I want to mention. 15:25:50 o/ 15:25:53 T-Shirts. http://www.customink.com/designs/storyboard/etb0-0014-66bc - 15:25:56 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 If not, I’m just going to get one for myself, because I REALLY need to advocate at the summit. 15:27:15 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 krotscheck: maybe not worth a rush order 15:27:46 I expect being indoors will help. 15:27:57 it's November. It's cold inside too. 15:28:09 i think the biggest advocacy we could do is move infra to storyboard 15:28:18 Although we have a lovely 80�F this weekend 15:28:27 had* 15:29:21 jeblair: That’ll expose storyboard to devs. I want to talk to influencers. 15:29:35 ‘cause, well, they’re the ones who can hire people to help out :) 15:30:13 But it sounds like interest is lukewarm. 15:30:18 So meh. Moving on. 15:30:20 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 #topic MVP 1.1 15:30:51 #topic MVP 1.1: Subscription 15:31:12 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 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 http://puppetboard.openstack.org/node/storyboard.openstack.org 15:32:49 puppet is current on it 15:32:54 krotscheck: may be we shall add a commit id somehow to be displayed on the page 15:33:04 NikitaKonovalov: Good idea. 15:33:05 so we always know what's running 15:33:43 actually it will be better to expose API-side commit also 15:34:34 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 #topic MVP 1.1 Project Groups 15:35:18 krotscheck: we probably want a way to see shas of storyboard and storyboard-webclient, fwiw 15:35:37 krotscheck: but the second probably takes a little bit more work 15:35:40 mordred: https://storyboard.openstack.org/#!/story/318 15:35:54 krotscheck: yes. I agree with that story 15:36:27 Lots of work on project groups, including test coverage and other fun things. 15:36:34 A bunch of them have already landed. 15:36:48 The big outstanding one is the import script. 15:37:05 Anyone feel excited about trying that? 15:37:31 * ttx disappears for a bit while his proxy restarts 15:37:42 krotscheck: what do you mean by 'trying'? 15:37:58 jeblair: “build it" 15:38:18 krotscheck: oh, adding project group support to the import script? 15:38:23 jeblair: Yes. 15:39:01 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 krotscheck: sounds reasonable 15:39:44 ttx: Any thoughts on that? 15:41:13 krotscheck: if "that" is the -groups tag read, makes sense to me 15:41:44 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 But if you’re cool with that we can move forward. 15:42:13 fine by me 15:42:47 Alright. 15:42:51 we have very effective mechanisms in place to propose changes to config files ;) 15:43:09 So, work is ongoing on proejct groups, with only one feature remaining and the other ones either proposed or merged. 15:43:19 #topic MVP 1.1: Tags 15:43:28 NikitaKonovalov: This one’s yours. 15:44:00 Sorry to say but I had no chance to fix that migration 15:44:21 I'll do my best to fix it 15:44:32 Alright. 15:44:51 #topic MVP 1.1 Email 15:44:55 I guess that will be the only change needed for API side 15:45:02 oops. 15:45:06 #topic MVP 1.1: Tags 15:45:21 There’s a bit of UI work needed, no? 15:46:24 Ok, silence. back to email 15:46:29 #topic MVP 1.1 Email 15:47:01 I started working on email. 15:47:19 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 Secondly: Some kind of a cron scheduled worker. 15:47:55 I’ve got patches up for the first, and a WIP for the second. 15:48:19 In both cases, I opted for making them pluggable. 15:48:20 i have some domain expertise here; i should try to review those 15:48:39 Would love your feedback. 15:49:27 jeblair: The review tree starts here (having a pep issue atm) https://review.openstack.org/#/c/128487/ 15:49:43 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 be back in a few 15:50:48 false alarm, back 15:51:43 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 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 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 jeblair: Yep. Same with subscriptions, federation, and hopefully (eventually) auth delegation. 15:53:47 groovy 15:54:04 Also, Stevedore is neat. 15:54:26 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 But I digress. 15:55:12 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 krotscheck: that's the stackalytics plugin ;) 15:55:25 HAH 15:55:26 Nice. 15:55:30 But yeah, exactly. 15:55:46 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 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 so if we want emails to be sent instantly? 15:57:53 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 k, i'll take a look 15:58:23 right, could be different. one is a notification, the other a digest 15:58:29 yep. 15:58:53 The only tricky thing would then be ‘hey do you want that event as a digest or as an instant notification'. 15:59:18 But that, I feel, goes back to allowing a user to list and manage their subscriptions. 15:59:49 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 amusingly, user management of subscriptions was a feature that launchpad added something like 6 years after the service was launched 16:00:05 but i defn see the use case for digests 16:00:16 or for no mail 16:00:24 yep 16:00:30 I, for one, still wish launchpad emailed me less 16:01:07 So that’s it for email. and we’re out of time! 16:01:10 Thanks everyone! 16:01:15 #endmeeting