15:02:38 <krotscheck> #startmeeting storyboard
15:02:40 <openstack> Meeting started Mon Jun 30 15:02:38 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:43 <openstack> The meeting name has been set to 'storyboard'
15:02:43 <NikitaKo_> o/
15:02:49 <ttx> o/
15:02:51 <krotscheck> Good morning, everyone!
15:03:01 * krotscheck failed at updating the agenda in time.
15:03:44 <krotscheck> So in the interests of keeping things up to date, I’m going to edit it during the meeting.
15:03:51 <krotscheck> #topic Specifications
15:04:26 <krotscheck> ttx, you’ve got another comment on tags, anything interesting?
15:05:15 <ttx> I did a new version of it, just got a review asking for adependency to be added
15:05:48 <ttx> If that's the only feedback i'll run a new version with that rolled in
15:06:02 <ttx> krotscheck: made progress on your alternate proposal ?
15:06:26 <krotscheck> ttx: I think that’s the only thing. I had some time to consider the alternate proposal last week, and I ran a quick performance test, and it’s pretty much the worst idea in the world.
15:06:41 <krotscheck> So I’m going to pass on my alternate proposal.
15:06:54 <ttx> it's technically attractive, but yeah, i can see how it can quickly get out of control
15:07:11 <krotscheck> Yeah, a single table for all indexes is a bit harsh.
15:07:28 <ttx> OK, then I'll push a new patchset to address Nikit'as concern
15:07:33 <krotscheck> Alrightey.
15:08:01 <krotscheck> NikitaKo_: Did you see my updates to the use cases in search?
15:08:15 <NikitaKo_> I've seen that
15:08:37 <NikitaKo_> The spec is more clear about browse vs search now
15:08:39 <NikitaKo_> and that's great
15:08:58 <krotscheck> Yeah. Which brings us back to the question of ‘is search global or resource-specific’?
15:09:38 <krotscheck> Because ultimately, that UI I put together I’d like to eventually pull aside into a ‘Query builder” with which people can design their own dashboards.
15:09:50 <krotscheck> And leave search to be true search, more freeform.
15:10:13 <krotscheck> And that can either be global or resource specific.
15:10:44 <NikitaKo_> I think it's more natural when one endpoint returns one type of resource
15:11:01 <NikitaKo_> so I'd prefer to keep them separately
15:11:17 <krotscheck> NikitaKo_: I agree. ttx?
15:11:21 <NikitaKo_> The UI however should query all of them by default
15:11:53 <ttx> krotscheck: +1
15:12:01 <krotscheck> Alright, that settles it.
15:12:05 <ttx> I think that UI will shine in advanced searchg
15:12:20 <NikitaKo_> one more question here is what are those resources?
15:12:25 <krotscheck> To be honest, writing up the use cases for search really let me focus in on what the UI should be doing.
15:12:28 <NikitaKo_> Now we have stories tasks and users
15:12:48 <krotscheck> NikitaKo_: And projects?
15:12:54 <NikitaKo_> yep and projects
15:13:28 <NikitaKo_> do we need search for events or comments?
15:13:31 <krotscheck> Right. So that’s an interesting question. Let’s say we search for something which is semantically a subresource: Example, comments on a story. Should we be searching stories? Or should we be searching on comments?
15:14:45 <krotscheck> Actually, better question: What should the API do vs. what should the client do?
15:14:45 <mordred> o/
15:15:34 <ttx> krotscheck: I'd say if you search stories, you'd query subresources
15:15:37 <krotscheck> I feel that the API contract should be consistent across all primary resources. It’s subresources I’m not certain of.
15:15:47 <mordred> krotscheck: hrm. excellent question - my old zope background would say "comments are owned by stories, so you should search stories"
15:15:50 <ttx> but if you eoecifically search comments, you should not search stories as well ?
15:15:55 <ttx> specifically*
15:16:02 <mordred> krotscheck: but my non-zope present says "that means I have to know too much about the data model to use the API"
15:16:09 * ttx needs a new keyboard
15:16:47 * jeblair boxes up a model-m for ttx
15:17:19 <krotscheck> …oh man, those things are indestructible.
15:17:45 <krotscheck> Ok, so any disagreement with all primary resources having the same API contract (barring differences in filter fields)?
15:18:37 <ttx> jeblair: i could certainly use one :)
15:18:58 <ttx> krotscheck: no
15:19:02 <krotscheck> I feel that the use case here would be: “I am searching for a thing, and that thing may be in a comment somewhere”. From  a UI perspective I’m going to take the user straight to the story on which that comment is, preferably with an autoscroll to that same comment.
15:19:20 <ttx> krotscheck: +1
15:19:25 <NikitaKo_> krotscheck: +!
15:19:26 <mordred> ++
15:20:27 <krotscheck> Righto.
15:21:01 <krotscheck> So given that from a UI perspective, I don’t know what story I’m searching on when I issue the search, I need either one of two things:
15:21:16 <krotscheck> 1- comments as a primary resource that I can search on, and extract the story ID from the comment
15:21:34 <krotscheck> 2- Story search index includes comments.
15:21:37 <krotscheck> But even then....
15:21:51 <krotscheck> How important is it to indicate that a search hit was on a comment rather than on a story?
15:22:07 <krotscheck> Consider the UI: “Hey we found our search on a comment”
15:23:13 <krotscheck> Also there’s the whole “What’s easy to do right now”, because comments might end up on more than one resource type.
15:23:24 <ttx> krotscheck: I think it's hinier if you autoscroll, but it's also OK if you don't
15:23:29 <NikitaKo_> My vote is for 1 here
15:23:30 <ttx> shinier
15:24:25 <mordred> I think ultimately 1 sounds richer - because as you said, there may be more things that have comments
15:24:33 <NikitaKo_> the comments endpoint is pretty similar to any other, and since there is going to be a SqlAlchemy implementation it should be pretty easy
15:25:19 <krotscheck> I have no disagreements with 1.
15:25:37 <krotscheck> Yeah, actually, the more I think about it the more I prefer it.
15:26:12 <krotscheck> So, it sounds like search is a feature of all primary resources, and ‘subresource’ implementations end up more as convenience filters?
15:26:21 <krotscheck> (which makes everything a primary resource)
15:27:04 <jeblair> krotscheck: i think the presentation of the results can help with that
15:27:29 <jeblair> krotscheck: before displaying the story and autoscrolling to the comment
15:27:46 <jeblair> krotscheck: you're probably going to display a list of results, and in that, i'm bettinng you can make it clear the hit was on a story or comment or ...
15:28:30 <jeblair> krotscheck: (i'm slightly laggy and responding to several minutes old text)
15:28:46 <krotscheck> I think everyone should go look at the new search/browse UI :)
15:28:58 <krotscheck> This one: https://review.openstack.org/#/c/99975/
15:29:38 <ttx> krotscheck: ok, added to todo
15:29:43 <NikitaKo_> krotscheck: I've already did, and it looks great
15:30:04 <krotscheck> NikitaKo_: Yeah, and after the discussion this morning I’m way happier with having comments.
15:30:33 <krotscheck> (Fair warning for everyone, I’ve since built on that UI to add things like auto-tab-focus)
15:31:24 <krotscheck> jeblair: No worries. Honestly, we’ll test the autoscroll and see how people respond before approving that.
15:31:41 <krotscheck> jeblair: Autoscroll to me is one of those ‘It could be awesomely bad if built incorrectly’ features.
15:31:59 <krotscheck> jeblair: The new search UI actually clearly separates the resources on which you got a hit.
15:32:21 <krotscheck> Anyway: Any more comments on search? I think we know where we’re going at the moment.
15:33:04 <krotscheck> NikitaKo_: Do you still want me to add comments as a blank resource, given that the UI won’t ever show that section if the results are hardcoded to []?
15:33:18 <NikitaKo_> krotscheck: I guess no
15:33:20 <jeblair> that's a very big change
15:33:33 <krotscheck> jeblair: Believe me, I tried to break it up.
15:34:13 <NikitaKo_> the browse.js means it does browsing through resources, we will need something like search.js to handle them
15:34:48 <NikitaKo_> and actually to query search endpoints when they are ready
15:35:03 <NikitaKo_> The WIP change is here btw https://review.openstack.org/#/c/101476/
15:37:10 <krotscheck> Ok....
15:37:20 <krotscheck> Oh good, he’s back
15:37:43 <NikitaKo_> something strange is going on with my irc client
15:38:01 <krotscheck> It’s probably MI-6
15:38:26 <krotscheck> Any more comments on specifications?
15:38:36 <krotscheck> Else we can move on to ongoing work.
15:38:41 <NikitaKo_> There is a new one
15:39:00 <NikitaKo_> https://review.openstack.org/#/c/103106/
15:39:07 * krotscheck makes a note to look at that.
15:39:31 <NikitaKo_> This is for teams API
15:39:53 <NikitaKo_> The main idea there is that user teams could be synced from Gerrit
15:40:23 <krotscheck> Hrm...
15:40:36 <krotscheck> Does this include some of the original permissions spec?
15:41:50 <NikitaKo_> krotscheck: are you referring to the etherpad with permissions?
15:41:55 <krotscheck> Yeah
15:42:28 <NikitaKo_> It does not right now, but it's a good idea to add that stuuff
15:43:12 <jeblair> we used to sync launchpad and gerrit teams, and then we stopped
15:43:23 <NikitaKo_> jeblair: why?
15:43:28 <jeblair> it was extremely difficult to do correctly
15:43:57 <jeblair> and as it turns out we needed different teams in the different tools
15:45:04 <jeblair> the closest thing to an overlap where the tools might use the same teams are using gerrit core reviewers when dealing with security bugs
15:45:23 <jeblair> ttx: what's the current thinking on that? ^
15:45:49 <jeblair> (but in generaly, bug triagers are not necessarily core reviewers, and vice-versa)
15:46:01 <NikitaKo_> is there any other source to get core members except Gerrit group?
15:46:15 <ttx> jeblair: the only thing we use launchpad groups for is now for subscription to private bugs and permissions granting
15:46:19 <jeblair> and drivers (people who can set milestone targets on bugs or blueprints [stories]) don't have much to do in gerrit
15:46:36 * krotscheck makes a note to transfer permissions specification to infra-specs
15:46:37 <ttx> and those are largely disjoint from gerrit groups
15:46:53 <ttx> so the pain of syncing was no longer worth the benefit
15:47:06 <ttx> err... the other way around
15:47:25 <jeblair> my inclination would be that we should make sure that we have a good api so that people (maybe us in the future, even) can sync mebership automatically with external tools...
15:47:53 <jeblair> but not to depend on them directly, and not expect us to do any automated syncing in the near future
15:48:00 <NikitaKo_> then we need to decide which kind of groups StoryBoard should have
15:48:10 <NikitaKo_> more Gerrit-like, or Launchpad-like
15:48:26 <krotscheck> So, what is a group?
15:49:18 <NikitaKo_> A group of users with a set of permissions
15:49:25 <ttx> krotscheck: I'd say, an entity permissions can be granted to
15:49:39 <ttx> AND a set of people you'd like to add to a private bug ACL
15:49:50 <ttx> but that's not the immediate use case
15:50:05 <NikitaKo_> possibly assign a task to a group?
15:50:05 <ttx> and that can be considered a "permission" too
15:50:31 <ttx> NikitaKo_: I'm not sure we want to encourage that
15:50:41 <ttx> NikitaKo_: but yes, that was possible in LP
15:50:42 <krotscheck> Sounds like we need to do some requirements gathering on this. Can I ask everyone to write up their concept of what a “team” and/or “group” is and send it to NikitaKo_ ?
15:50:53 <ttx> I can take that
15:50:56 <krotscheck> Alright
15:51:00 <krotscheck> Send it to ttx then :)
15:51:01 <ttx> unless you need it for tomorrow
15:51:12 <krotscheck> I dunno, NikitaKo_: When do you need it by?
15:51:22 <ttx> TC handling bogged me down last week
15:51:58 <NikitaKo_> By the moment we start protected tags or something like that
15:52:07 <ttx> NikitaKo_: ok
15:52:28 <ttx> should that be a specs, or more a wiki page ?
15:53:00 <krotscheck> ttx: Eeehhh,… I’m leaning more wiki right now? Spec is more detailed and implementation specific.
15:53:09 <ttx> krotscheck: ++
15:53:23 <krotscheck> I want the eventual output to be sortof like the use case section I added to NikitaKo_ ’s search spec.
15:53:34 <ttx> let's call it a brainstorming wikipage
15:53:39 <krotscheck> Awesome.
15:54:33 <krotscheck> Any other specs thoughts?
15:55:06 <krotscheck> #topic Ongoing work!
15:55:10 <krotscheck> Everyone gets a minute!
15:55:14 <krotscheck> Reverse alphabetical order!
15:55:27 <ttx> hmm, that may mean me
15:55:27 <krotscheck> Yolanda got her momentjs things merged, awesome!
15:55:38 <krotscheck> ttx is next!
15:56:10 * ttx managed to do some reviews, and pushed a new version of the Tag spec, but that's about it
15:56:17 <ttx> blame Defcore
15:56:32 <ttx> next
15:56:53 <NikitaKo_> I've started that Teams spec
15:57:16 <NikitaKo_> And there is a change setting up oslo.messaging for notifications
15:57:17 <NikitaKo_> https://review.openstack.org/#/c/102842/
15:57:26 <krotscheck> Awesome.
15:57:32 <NikitaKo_> It is based on TimeLine events we already have
15:57:50 <NikitaKo_> Work on my local rabbit pretty nicely
15:57:58 <krotscheck> Noce.
15:57:59 <krotscheck> Nice
15:58:00 <krotscheck> Nice nice
15:58:36 <NikitaKo_> So that's all from me
15:58:47 <krotscheck> I wrote out use cases for search, which I then promptly incorporated into my UI work. Did an ad-hoc UX test with a random person I met at a coffeeshop which also helped me refine the UI on the search page.
15:59:09 <krotscheck> Also a bit of work on the storyboard puppet module after a bunch of good comments from reviewers.
15:59:17 * krotscheck is trying to get rabbit onto storyboard.openstack.org
15:59:45 <krotscheck> MaxV disconnected right when we were about to get to him.
16:00:06 <krotscheck> Aishwarya is stuck in HP background checks, but I’m meeting up with her in an hour.
16:00:27 <krotscheck> And that’s it!
16:00:30 <ttx> yay
16:00:30 <krotscheck> #endmeeting