16:01:33 <krotscheck> #startmeeting Storyboard
16:01:34 <openstack> Meeting started Mon Dec  8 16:01:33 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:37 <openstack> The meeting name has been set to 'storyboard'
16:01:52 <krotscheck> Agenda: https://wiki.openstack.org/wiki/StoryBoard#Agenda
16:02:03 <krotscheck> #topic Actions from Last week
16:02:14 <krotscheck> Most of these things are mine, so I’ll go through them.
16:02:29 <krotscheck> Pester Fungi: Not yet done.
16:02:38 <krotscheck> File stories: Should all be in there now.
16:02:51 <yolanda> hi there
16:02:56 <fungi> yeah, pester me
16:02:56 <ttx> o/
16:03:02 <gothicmindfood> o/
16:03:09 <fungi> success
16:03:09 <krotscheck> Oh look, people!
16:03:39 <krotscheck> rcarrilocruz isn’t here, we’ll assume he’s off doing awesome things.
16:03:41 <jeblair> hiya
16:03:50 <yolanda> krotscheck, is national holiday in Spain
16:03:54 <krotscheck> Oh!
16:04:00 <krotscheck> Well then, that explains it.
16:04:05 <krotscheck> Do we have a bank holiday in Britain?
16:04:08 <jeblair> we should all take the day off! ;)
16:04:11 <krotscheck> (Because of jedimike)
16:04:16 <CTtpollard> not today krotscheck
16:04:24 <ttx> It's not even a hholiday in France.
16:04:24 <krotscheck> Gotcha.
16:04:30 <krotscheck> ttx: That’s rare.
16:04:31 <krotscheck> :D
16:04:39 <ttx> Indeed, I thought we had all holidays
16:04:52 * ttx goes on strike to protest
16:05:00 <jedimike> o/
16:05:07 <krotscheck> jedimike: How’s that paging spec?
16:05:50 <jedimike> krotscheck, submitted at https://review.openstack.org/#/c/139638/ , yolanda left a comment and there's some typos to fix, going to wait for more feedback before i submit an updated version though
16:06:28 <krotscheck> Awesome!
16:06:51 <krotscheck> Ok, so we’ve got stories filed, a new spec, and a holiday. Moving on!
16:06:56 <krotscheck> #topic User Feedback
16:06:58 <jeblair> #link paging spec https://review.openstack.org/#/c/139638/
16:07:09 <krotscheck> Has anyone received direct user feedback over the last week?
16:07:45 <jeblair> i think clarkb mentioned that having 'merged' ~= 'resolved' was feeling weird in some cases
16:08:40 <krotscheck> That kindof starts to work into the workflow discussion, no?
16:08:48 * krotscheck agrees.
16:09:04 <ttx> we could have non-code-backed projects use a different word.
16:09:10 <jeblair> i think i may have been logged out unexpectedly, but i haven't really collected enough data on that
16:09:32 <jeblair> ttx: i'm assuming this is related to a code-backend project; i didn't have a chance to follow up with him though so i don't know the full details
16:09:32 <CTtpollard> ttx: I like that idea
16:09:36 <krotscheck> Well, the refresh token fix went in mid last week, so I hope that’ll be a less frequent occurrence.
16:09:39 <jeblair> code-backed
16:10:15 <jeblair> krotscheck: okay, good to know -- what is the expectation?  like: if a user is active at least every N minutes, they will not be logged out?
16:10:19 <krotscheck> This suggests that we have different project types that trigger different status groups.
16:10:53 <krotscheck> jeblair: The expectation is that as long as your client has both an access token and a refresh token, you will never be logged out.
16:10:54 <ttx> krotscheck: not necessarily.
16:11:03 <jeblair> krotscheck: ack, thx
16:11:15 <ttx> krotscheck: one of my specs proposes to add a "code repo" field to projects
16:11:40 <ttx> so you can recognize that without having to introduce project types
16:12:17 <ttx> frankly, different status groups would rseult in a bit of a mess for data analysis across openstack projects
16:12:39 <krotscheck> ttx: Yeah, but the tradeoff is that we have to special case things based on a complex state machine in the frontend.
16:12:43 <ttx> but if it's just about translating "merged" into somethign that makes more sense...
16:13:02 <jeblair> why don't i follow up with clarkb and find out what circumstance made him feel it was inappropriate
16:13:11 <krotscheck> If A and B but not C show merged, else show resolved, etc etc.
16:13:56 <krotscheck> Works for me.
16:14:06 <krotscheck> jeblair: Can you capture that conversation in a story?
16:15:00 <krotscheck> CTtpollard: Anything from your end of things?
16:15:44 <jeblair> krotscheck: ack
16:16:33 <krotscheck> Ok, let’s move on.
16:16:40 <krotscheck> #topic Urgent Items
16:16:46 <krotscheck> Nothing on the agenda, anything new?
16:17:10 <yolanda> nothing from my side
16:17:22 <CTtpollard> nothing urgent no from me
16:17:25 <yolanda> tried to ping mbitard several times for the login issue, but no answer
16:17:34 <yolanda> any other known way of contact?
16:17:58 <krotscheck> I got nothing, sorry :/
16:18:13 <jedimike> nope
16:18:18 <krotscheck> Ok, moving on!
16:18:26 <krotscheck> #topic Discussion: Documentation (persia)
16:18:32 <krotscheck> persia: You around?
16:19:15 <krotscheck> Ok, nothing there.
16:19:48 <krotscheck> I’m going to skip rainya’s piece as well, it’s been a month since the summit and neither of them have shown up to meetings.
16:20:21 <krotscheck> #action krotscheck Contact persia and rainya about their agenda items being dropped.
16:20:33 <krotscheck> #topic Discussion: Branch Support (ttx)
16:21:04 <ttx> o/
16:21:11 <ttx> So I pushed two spec drafts
16:21:26 <ttx> First one about task branch: https://review.openstack.org/#/c/139613/
16:21:37 <krotscheck> #link https://review.openstack.org/#/c/139626/
16:21:42 <ttx> It actually introdices a "project area" concept that can also be used on non-code projects
16:21:45 <krotscheck> #link https://review.openstack.org/#/c/139613/
16:22:00 <ttx> but we can rename it branch if everyone finds that confusing
16:22:29 <krotscheck> What does “project area” mean to you? Is there a nuance you want to highlight?
16:22:30 <ttx> One idea is to optimize UI in case a single area is defined
16:23:33 <ttx> krotscheck: the idea is to let non-code-backed projects also have something like branches to separate their work into multiple categories
16:24:07 <ttx> But if there is no real use case for it, we can just rename everything "branch"
16:24:19 <ttx> anyway, the rationale is decribed in the spec draft
16:24:23 <ttx> +s
16:24:36 <ttx> The second draft is about milestones
16:24:38 <krotscheck> So, much like the different task groups that the Win The Enterprise group is using?
16:24:56 <ttx> krotscheck: probably yes, haven't dived into their use case yet
16:25:05 <ttx> https://review.openstack.org/#/c/139626/
16:25:32 <ttx> describes how we can track which milestone a given task was completed in
16:25:47 <ttx> for feature parity with some of the Launchpad "milestone" concept
16:26:05 <ttx> So please have a look and give me early feedback, I can iterate on that
16:26:25 <ttx> Then once we made progress, I'll rewrite the storytypes stuff on top of that
16:26:59 <ttx> area/milestone map to branch and tags in a code-backed repo
16:27:03 <krotscheck> Alright, so that’s pretty high priority.
16:28:04 <krotscheck> I’d like everyone to take a look at those two specs this week so we can get that work moving forward and ready for dev.
16:28:39 <yolanda> sure, i'll take a look at that tomorrow
16:28:51 <jedimike> will do
16:28:57 <ttx> krotscheck: there is a bit about setting all the tasks "milestone" column when you push a tag that will probably brush your REST hair in the wrong direction
16:28:59 <CTtpollard> sure
16:29:14 <krotscheck> ttx: That’s ok, I got a haircut on saturday
16:29:20 * krotscheck feels that’s relate.d
16:29:26 <krotscheck> Anwyay, next:
16:29:34 <krotscheck> #topic Discussion: API Paging.
16:29:48 <krotscheck> jedimike: You pushed a spec, any comments on that?
16:30:01 <jedimike> so https://review.openstack.org/#/c/139638/ is the Ultimate Pagination Solution (tm) spec
16:30:10 <jedimike> it's pretty long, goes through UI interaction too
16:30:25 <jedimike> all comments, questions, feedback welcome
16:30:50 <krotscheck> Cool, anything you want to highlight?
16:31:09 <jedimike> well the snapshot system is how i've implemented it before, backed by a database
16:31:26 <jedimike> if anyone has other suggestions that might work and aren't db backed, i'd be interested in that
16:31:53 <jedimike> but really for now I want to know that it makes sense
16:31:56 <krotscheck> I’ve seen redis-based implementation.
16:32:11 <jedimike> because I've implemented this a few times and you know what it's like, writing docs for a system you're familiar with :)
16:33:19 <krotscheck> Righto. So let’s push discussion to the spec from this point forward and check in next week.
16:33:36 <krotscheck> #topic InProgress: Email
16:33:43 <krotscheck> New patch on the cron workers.
16:33:56 <krotscheck> I still need to write some tests for it.
16:34:11 <krotscheck> But this iteration actually allows us to have the cron plugin declare its own schedule.
16:34:51 <krotscheck> #topic InProgress: User Auth Token
16:34:59 <krotscheck> No progress. Endpoint landed, UI still coming.
16:35:05 <krotscheck> #topic Caching Update
16:35:09 <krotscheck> Done. Merged.
16:35:19 <krotscheck> #topic Tags (NikitaKonovalov )
16:35:22 <krotscheck> You here?
16:36:09 <krotscheck> Nope, ok.
16:36:26 <krotscheck> #topic InProgress: Dashboard Updates.
16:36:32 <krotscheck> yolanda: Looks like that one merged?
16:36:36 <yolanda> krotscheck, yes
16:36:45 <krotscheck> Awesome.
16:36:49 <krotscheck> Also, OMG Dashboard is useufl.
16:36:52 <krotscheck> *useful
16:37:10 <yolanda> i'd like that to have configurable widgets
16:37:40 <krotscheck> Yeah, I feel like we’d all like that.
16:37:49 <krotscheck> Also, the ability to replace it with a kanban board?
16:38:03 <yolanda> krotscheck that will be awesome but tons of work
16:38:07 <krotscheck> The possibilities are endless.
16:38:18 * ttx would like to be able to clear all "recent events"
16:38:30 * ttx files story
16:38:39 * krotscheck actually has been adapting the kanban code drop to fit into storyboard...
16:38:57 <krotscheck> That came from CTtpollard’s team… I _think_.
16:39:04 <yolanda> krotscheck that will be awesome
16:39:08 <krotscheck> indeed.
16:39:46 <jeblair> i actually don't think that will be awesome
16:40:14 <jeblair> there's a lot of more awesome things that i'm looking forward to first :)
16:40:23 <krotscheck> jeblair: Like email? :)
16:40:45 <ttx> like tags
16:41:11 * krotscheck sighs.
16:41:14 <krotscheck> Apologies on all of those. I’ve been doing a few internal HP things that are thankfully over now.
16:42:11 <krotscheck> jedimike: Next thing is paging. I feel like we’ve already covered that so I’m goign to skip it.
16:42:17 * ttx hadn't really noticed a drop in krotscheck's activity
16:42:20 <krotscheck> Unless you’ve got something?
16:42:20 <jedimike> okeydokey
16:42:28 <jedimike> nope, all in the spec :)
16:42:33 <krotscheck> #topic InProgress: Anything new?
16:42:43 <krotscheck> Anything new out there?
16:43:04 <krotscheck> Oh yeah, configurable statuses!
16:43:17 <krotscheck> #topic InProgress: Configurable Task Status (yolanda)
16:43:33 <yolanda> krotscheck, working on the grouping of tasks dynamically now
16:43:41 <krotscheck> Awesome.
16:43:55 <yolanda> there are comments from ttx about the fixed signature / variable signature on the api
16:44:09 <yolanda> so i grouped all the counts on one field, because i prefer the idea of the API signature being fixed
16:44:14 <yolanda> any opinions?
16:44:26 <krotscheck> I agree with the way you did that.
16:44:31 <krotscheck> It also greatly simplifies that query.
16:44:32 <jedimike> i agree with keeping the sig fixed
16:44:57 <ttx> link ?
16:45:09 * ttx doesn't remember such comment, but then...
16:45:23 <krotscheck> That change is going to break downstream third party UI’s, but it’s a simple enough update for them to dig into the subobject.
16:45:34 <yolanda> looking
16:45:50 <krotscheck> ttx: https://review.openstack.org/#/c/139100/1/storyboard/db/models.py
16:46:28 <krotscheck> Basically, instead of a story_summary having explicit fields for its task statuses, it’s now going to have a task_statuses field that’s a map of counts by status.
16:46:29 <yolanda> ttx, i may be confused with your comment then... https://review.openstack.org/#/c/139100/
16:46:54 <ttx> yolanda: I don't think I commented there :)
16:47:07 <yolanda> yes, it's another review, sorry
16:47:21 <krotscheck> So instead of { todo: 4, merged:10…} It’s now going to be { tasks_statuses: { ‘custom_status_1’:10, ‘custom_status_2’: 22}}
16:47:43 <jeblair> i don't think we need to worry about breaking downstreams yet; we should retain our flexibility until we're much further along
16:47:51 <ttx> oh, you mean my earlier comment about analysis across projects
16:48:29 <yolanda> ttx, was confused with comment on that https://review.openstack.org/#/c/138389/2/src/app/services/resource/task_statuses.js ...my fault as i read all reviews in my email quite fast today
16:48:34 <jedimike> jeblair, agreed
16:49:00 <yolanda> krotscheck, so yes, it will be breaking downstream for a while, and i need to update code in the frontend to properly consume it
16:49:05 <ttx> yolanda: ok
16:50:09 <yolanda> krotscheck so i'll add some tests there
16:50:40 <krotscheck> Well, we can just coordinate the merges. That way the client impact will be minimal.
16:51:02 <jeblair> ++
16:51:22 <yolanda> i'll grab some time this week to work on both sides
16:51:41 <krotscheck> cool.
16:51:52 <krotscheck> Anyone else working on something in secret?
16:52:14 <yolanda> krotscheck, working on the backend preferences
16:52:18 <krotscheck> Right!
16:52:28 <krotscheck> #topic InProgress: Backend Preferences (yolanda)
16:52:42 <yolanda> so problem is that double async, you first need to asynchronously grab the client, then grab the preferences
16:53:15 <krotscheck> We can chain promises for that though, can’t we?
16:53:48 <yolanda> the way i did they are chained, first it resolves the client then it resolves the preferences
16:55:54 <yolanda> so according with your comments you think that the approach is fine for pagination, events... only comment is with the way to retrieve that in the user preferences section, right?
16:56:42 <yolanda> and you also commented that the preferences should be cached, maybe we can try angular-data or some similar approach?
16:56:49 <krotscheck> Urm… well, no. User preferences is one of those things I feel that the application needs at initialization, becuase it’s something that can drive pretty much anything at any level.
16:56:58 <krotscheck> Dashboard initialization, etc.
16:57:08 <krotscheck> Well, we’ve already put angular-cache in place :)
16:57:53 <yolanda> then this should be loaded either when the user logins, or when the user starts the app and he/she is already logged in
16:58:18 <krotscheck> The way we’re doing logins right now, the app is refreshed once a new auth token shows up.
16:58:22 <krotscheck> So on init should be fine.
16:58:34 <krotscheck> (Low on time)
16:58:46 <yolanda> ok, i'll update the approach to use angular-cache
16:58:51 <krotscheck> kk
16:58:57 <yolanda> this could be applied also to task statusse
16:58:59 <yolanda> statuses
16:59:00 <krotscheck> Yep.
16:59:18 <yolanda> ok, tons of work for this week
16:59:24 <krotscheck> Yep.
16:59:45 <krotscheck> Alright, we’re out of time. Thanks everyone!
16:59:57 * krotscheck needs to make more time for open discussion :/
17:00:06 <krotscheck> #endmeeting