15:00:51 <SotK> #startmeeting storyboard
15:00:52 <openstack> Meeting started Wed Mar  2 15:00:51 2016 UTC and is due to finish in 60 minutes.  The chair is SotK. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:56 <openstack> The meeting name has been set to 'storyboard'
15:01:19 <SotK> #link https://wiki.openstack.org/wiki/Meetings/StoryBoard Agenda
15:01:26 <Zara> (oh, in the time it took me to correct my typo in #startmeeting storyborad...)
15:01:35 <SotK> sorry :)
15:01:54 <Zara> :) I don't *think* we have any announcements
15:01:59 <SotK> I can make you chair if you like :)
15:02:12 <Zara> nah, I'm fine
15:02:24 <SotK> heh, ok
15:02:35 <SotK> I don't think we have announcements either
15:02:40 <SotK> any urgent things?
15:02:57 <Zara> nothing new
15:04:15 <Zara> we still have no dev instance, I'm tempted to artificially bump the urgency so something happens
15:04:25 <Zara> but that'd be mean
15:04:31 <SotK> oops
15:04:42 <SotK> #action SotK to sort out a dev instance soon
15:05:11 <SotK> #topic In Progress Work
15:05:30 <SotK> #info Worklists and Boards is still ongoing
15:05:46 <Zara> (re: dev instance, if it's still 'soon' next weds, I'll request specifics.)
15:06:13 <SotK> #link https://review.openstack.org/#/q/status:open+topic:due-dates Due Dates patches
15:06:18 <SotK> (fair enough)
15:06:20 <Zara> \o/
15:06:22 <Zara> there are lots!
15:06:44 <betherly> definiton due-dates patches?
15:07:08 <betherly> ie is that things that have urgency to them?
15:07:26 <persia> Rather, it is a set of patches to allow people to indicate that a given task has a date.
15:07:37 <persia> It might be a near date (urgent) or a far date (e.g. release goal)
15:07:39 <betherly> ahhh yes. my bad
15:07:43 <Zara> heh, yeah, there's some context here: https://storyboard.openstack.org/#!/story/2000476
15:07:49 <betherly> i did know that. having a brain malfunction
15:07:59 <Zara> np, I can see how the sentence was ambiguous xD
15:08:09 <betherly> awesome thanks for the link Zara
15:08:20 <Zara> hm, I should link it for the logs
15:08:23 <Zara> #link https://storyboard.openstack.org/#!/story/2000476
15:09:14 <Zara> the api patches are merged (except the archiving cards patch, iirc), so the above are the UI patches
15:09:42 <SotK> I'm looking at automatic worklists today, with success so far :D
15:09:49 <persia> \o/
15:10:04 <Zara> yes, \o/ \o/ \o/!
15:12:21 <SotK> anything else in progress?
15:13:00 <Zara> I've mainly been reviewing this week.
15:13:05 <Zara> boolean search has been merged, though!
15:13:27 <Zara> oh, this is still in review: https://review.openstack.org/#/c/278987/
15:13:34 <Zara> #link https://review.openstack.org/#/c/278987/
15:14:14 <Zara> that's the patch which changes header 'search' to 'jump to...' and removes the magnifying glass, in an attempt to limit search confusion
15:14:31 <betherly> oh awesome ill review that now
15:14:38 <SotK> \o/ thanks betherly
15:15:14 <betherly> that was an easy review lol! 2 lines of code and html at that :D
15:15:29 <Zara> and then current plan is to make header 'search' work more like the tags search does currently, with the titles as criteria
15:15:33 <Zara> \o/
15:15:46 <Zara> so that's what I'll be looking at either late this week or early next week
15:15:52 <Zara> depending on how due dates review goes, I think
15:16:15 <betherly> is the plan then to remove the search navigation from the left?
15:16:47 <Zara> yes, I'd like to remove it now; I need to rework the other search patch
15:16:54 <betherly> ok cool
15:16:55 <Zara> because otherwise mobile users have no nice way to search
15:17:05 <betherly> ++
15:17:26 <Zara> #link https://review.openstack.org/#/c/279204/
15:17:43 <Zara> we talked in the comments there, another thing to do at the end of this week/start of next week, thanks for reminding me
15:19:36 <Zara> but yeah, mainly reviewing. some of the earlier due-date patches need some reviews, btw
15:20:00 <Zara> #link https://review.openstack.org/#/c/278508/6
15:20:15 <Zara> #link https://review.openstack.org/#/c/284275/4
15:20:29 <Zara> all others depend on those so I'm just making sure they don't get forgotten about
15:20:42 <Zara> (sorry to go back to earlier topic)
15:21:43 <Zara> that's what I'm up to at the moment, anyway.
15:22:24 <SotK> anything else?
15:23:35 <Zara> I don't think so. there are other vague things on the horizon but I don't think I'll be doing much beyond review, and search patches, before next meeting
15:24:07 <Zara> anyone else?
15:24:42 <betherly> ill try and make a start on the flow diagram for the about page and keep looking into solutions for how to go about it
15:25:47 <Zara> cool, thanks :D
15:25:49 * SotK is excited for that
15:26:56 <betherly> yay
15:28:29 <SotK> #topic Email Config
15:29:25 * SotK doesn't know what to do about this
15:29:47 <Zara> neither do I. :/ I'm acting as a human notifications service in the meantime
15:30:03 <SotK> we could poke some more, or ask to take over the patch if any of us had time to test it/figure out whats wrong
15:31:24 <Zara> yeah, I think I'll poke in infra; I don't think I have time to learn puppet and test and work out what's going on. :(
15:31:40 <Zara> especially since last time I tried to take over a patch, everything went up in flames
15:32:45 <SotK> sounds good to me
15:35:25 <SotK> #topic UX Meetup
15:35:41 <SotK> #link https://etherpad.openstack.org/p/storyboard-ux-meetup
15:35:49 <SotK> thanks for coming betherly :)
15:35:51 <persia> Hurrah: the topic for which I've been waiting.  It seems folk discussed "bugs" vs. "tasks".  This seems to come up a lot.  What is the difference?
15:37:02 * persia has seen lots of arguments over "bug" vs. "feature" in the past, and doesn't want any metadata to express this without *very* clear semantic distinctions and consensus on the utility of the information to some consumer.
15:37:51 <betherly> was a great day yesterday thanks for having me SotK Zara
15:38:28 <betherly> persia: so tasks are requests and things to do
15:38:36 * SotK personally thinks they are both mostly the same thing: "a thing that requires work to be done to achieve a goal"
15:38:51 <betherly> bugs are issues that are blockers or just things that need fixing
15:39:07 <qwebirc93330> Hello, is there a cutoff upto when the code from master will be included in mitaka/stable?
15:39:12 <persia> betherly: So, if something "needs fixing", isn't this a representation of a request to do something?
15:39:18 <betherly> so for example, with the ironic-ui, a task might be to 'add a node' functionality
15:39:26 <persia> If something is "blocking", doesn't that mean someone should do something, and so be requested?
15:39:37 <betherly> but a bug might be that the 'add a node' functionality exists but isnt working correctly
15:39:57 <persia> Ah, so perhaps you are differentiating between "regression" and "non-regression"?
15:40:17 <persia> As in, something that used to do something doesn't is a "bug" and something that has never done it would be a "feature"?
15:40:31 <betherly> yes exactly. or an addition to something that already exists
15:40:41 <persia> WHich is the "addition"?
15:40:44 <betherly> but a bug is an issue with something that exists that isnt working correctly
15:40:44 <Zara> (to me, bug vs feature is a distinction to make at the story level, and tasks are 'things to do' in both features and bugs. so I don't think of it in terms of tasks vs bugs, and the discussion didn't change my mind on that.)
15:41:08 * SotK agrees that if we distinguish, it should be at the story level
15:41:18 <persia> To me, a story should be written to describe desired behaviour, and it doesn't much matter whether someone tried to implement it before or not, as long as it isn't working today.
15:41:35 <persia> Or rather, as long as we can tell whether it works as described today.
15:43:24 <persia> Now, I'm arguing against any "bug" vs. "feature" vs. "task", etc. distinction, but to be clear, some of the arguments I've seen in the past include needing to differentiate on whether something is a regression, needing to differentiate on whether something is planned/unplanned, needing to differentiate whether a request comes from users vs. product management, etc.
15:43:47 <Zara> qwebirc93330: storyboard follows the independent release model; it's continuous delivery. does that help?
15:44:12 <persia> I'd be happy to hear other potential discriminators, and perhaps we could reflect some or all of them, but let's be careful to be clear, so different consumers don't interpret things differently, and argue about whether a given flag should be set.
15:45:08 * SotK thinks tags could provide a bunch of that if used properly
15:45:26 <SotK> i.e. if you are product management making a request, add a tag which signifies that
15:45:28 <Zara> yeah, I personally am fine with people just using tags.
15:45:53 <Zara> if enough people want to use the same ones, we look at making a special bit of metadata for them, but only then
15:45:59 <persia> Are there parts of the "bugs vs. tasks" discussion from yesterday that can7t be implemented with tags?
15:47:03 <SotK> I think there was a desire to be able to show dependencies somehow
15:47:11 <betherly> im just thinking of going back to launchpad in particular where we submit bugs and blueprints seperately
15:47:14 <SotK> "we can't do B whilst bug A exists"
15:47:24 <Zara> yeah, tasks that block other tasks.
15:47:27 <betherly> but ye i guess could be done with tags
15:47:36 <betherly> yep dependencies is a good idea to have for sure
15:47:46 <betherly> how to display that though is a hard one
15:48:04 <persia> LP doesn't support dependencies: it's something that was argued extensively for years, and actively blocked by some of the LP product folk.
15:48:25 <persia> I'm not entirely opposed to them, but it is important to understand precisely what is being expressed.
15:48:37 <Zara> I think it can get very complicated fast, where most of the time people just end up remembering what their blockers are anyway, or reading a comment in the description.
15:49:18 <Zara> theoretically you could use the 'link' field in a task to link to a blocking task and not bother modelling it any deeper than that.
15:49:48 <persia> Do "links" have a text field where someone can describe the relation?  If so, that provides flexibility.
15:50:03 <persia> Although it makes it hard to search for tasks that are blocked, or are not blocked.
15:52:36 <Zara> I'm not sure that's a problem. people generally want to know 'is this specific task I'm interested in blocked?'. the exception is maybe a manager, who'd want to know if people on their team were blocked, but I think they'd have other primary channels for that.
15:53:46 <persia> To me, unblocked is the more interesting seach, from the perspective of "how can I (realisitically) help?"
15:54:56 <SotK> perhaps allowing a story/task (idk where we want to model dependency) to have an arbitrary list of other tasks/stories they depend on, and if that list has contents that aren't "merged", the story/task is blocked
15:55:11 <Zara> links don't currently allow a user to add extra text information, but we could extend them easily enough (technically a user can put whatever text they like in a link, but extra text would then stop the link from functioning as a link, because it's just wrapped in <a> tags).
15:55:12 * SotK can see a task needing a link and also being blocked
15:56:01 <Zara> I'd really rather not model dependency at all
15:56:56 <Zara> it seems like a lot of hassle for very little gain, since I think most cases would be solved by a 'btw we're blocked by x' next to the task
15:57:19 <Zara> worst case scenario, you end up chasing a load of links in a circle, which will probably be a problem with modelling it too
15:58:04 * SotK would be equally happy with saying "put links in the description if you want them", but that doesn't allow searching
15:58:39 <Zara> similarly, I think asking 'where can I help' on irc is always going to be better.
15:59:20 <Zara> nearly out of time
15:59:22 <SotK> we can continue in #storyboard if people want, our time is up
15:59:28 <Zara> snappish
15:59:39 <SotK> #endmeeting