15:01:17 <SotK> #startmeeting storyboard
15:01:17 <anteaya> I can be here
15:01:18 <openstack> Meeting started Wed May 18 15:01:17 2016 UTC and is due to finish in 60 minutes.  The chair is SotK. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:21 <shamail> hi everyone
15:01:22 <openstack> The meeting name has been set to 'storyboard'
15:01:35 <Zara> hi shamail! :D
15:01:39 <SotK> #link https://wiki.openstack.org/wiki/Meetings/StoryBoard#Agenda_for_next_meeting Agenda
15:02:02 <shamail> o/ Zara & anteaya!
15:02:12 <SotK> hi shamail :)
15:02:13 <anteaya> hey shamail
15:02:22 <shamail> Hi SotK
15:02:28 <SotK> #topic Announcements
15:02:39 <SotK> We almost have a dev server set up!
15:03:03 <anteaya> yay!
15:03:04 <Zara> \o/
15:03:27 <SotK> I don't think we have any urgent items at the moment, so on to in progress work
15:03:34 <SotK> #topic In Progress Work
15:03:48 <SotK> We discussed complex priorities at length after the meeting last week
15:04:16 <Zara> SotK is finding the logs now
15:04:21 <SotK> #link http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2016-05-11.log.html#t2016-05-11T16:00:31
15:04:25 <Zara> :D
15:04:39 <SotK> I've not actually got round to doing any more work on it since then
15:05:33 <Zara> I think it'd be good if those who want the feature could give more input on the kind of information they'd like to have available at a glance vs after asking for it specifically
15:05:59 <Zara> so anyone interested in visualisation of complex priorities, it's a good time to give thoughts on that over the next few weeks
15:06:15 <anteaya> thank you
15:06:25 <shamail> What is the best format for sharing?
15:06:48 <Zara> discussion in #storyboard, to begin with
15:06:49 <shamail> mailing list or IRC meeting?
15:06:54 <shamail> Thanks
15:07:07 <anteaya> yeah discussing in the channel I think would be fine
15:07:07 <Zara> np :)
15:07:17 <anteaya> I don't think you need to wait for a meeting
15:07:20 <SotK> I agree
15:07:24 <Zara> yeah, the project channel is logged
15:07:37 <Zara> so things won't be lost
15:07:49 <Zara> #link http://eavesdrop.openstack.org/irclogs/%23storyboard/
15:07:58 <shamail> Great
15:08:31 <SotK> I've started looking at Teams, now that the first pass of private stories is merged
15:08:39 <Zara> :D
15:08:51 <SotK> so far I've determined that the GET part of the teams API works
15:09:04 <anteaya> yay private stories is merged
15:09:06 <anteaya> \o/
15:09:12 <Zara> nice
15:09:17 <anteaya> SotK: awesome
15:09:24 <Zara> so that just leaves PUT, POST and DELETE?
15:09:31 <SotK> yeah
15:09:45 <SotK> I'm assuming they work too, we will find out soon
15:09:48 <anteaya> SotK: have you had a chance to test the others yet?
15:09:52 <anteaya> SotK: ah cool
15:10:03 <anteaya> hopefully we will have the dev server up soon
15:10:10 <Zara> cool, thanks for looking into this
15:10:45 <anteaya> Zara: did you want to say anything about the gerrity bits?
15:10:51 <Zara> I started trying to make some operator docs, for quickly spinning up a storyboard instance
15:10:59 <anteaya> yay docs
15:11:07 <Zara> tried with ansible, failed, tried with puppet, failed, journey so far recorded here:
15:11:10 <Zara> #link https://storyboard.openstack.org/#!/story/2000535
15:11:33 <Zara> the puppet errors are similar to the things fungi's finding with trying to set up a dev instance
15:11:44 <Zara> so hopefully as that gets untangled I might be able to revisit it
15:11:51 <Zara> (I have 0 puppet :))
15:11:55 <shamail> Nice
15:11:59 <fungi> i have 0.5 puppet
15:12:07 <Zara> SOUNDS GREAT TO ME
15:12:12 <Zara> :D
15:12:13 <anteaya> Zara: nice work on the investigation
15:12:33 <anteaya> Zara: and I agree it will be nice once docs are in place for folks to spin up their own instance
15:12:52 <Zara> yeah, at the moment they can do it using the developer docs, but it's quite longwinded
15:12:58 * SotK agrees
15:13:18 * anteaya passes on the opportunity to make a British joke
15:14:35 <Zara> #info Zara tried and failed to make some quickstart operator docs, will come back to it pending puppet progress
15:14:53 <anteaya> failed with notes
15:15:02 <Zara> yes :)
15:15:08 <Zara> so in the meantime, I've started looking at integrating StoryBoard with gerrit again
15:15:18 <anteaya> yay storyboard and gerrit
15:15:23 <Zara> mainly just remembering what my old proof of concept did
15:15:27 * SotK seconds the yays
15:15:37 <Zara> #link https://review.openstack.org/#/c/302912/
15:16:05 <Zara> so that still needs to do a few things to work as a proof of concept, even before it can be scaled up
15:16:17 <anteaya> we did talk about this bit at the mid-cycle
15:16:21 <Zara> yup
15:16:26 <SotK> #link https://storyboard.openstack.org/?#!/story/2000584 details how we think gerrit commit messages should work
15:16:29 <anteaya> we even drew things on a whiteboard
15:16:58 <anteaya> fungi: we identified that using task/id is a better way forward than story id
15:17:10 <anteaya> fungi: this will include a commit message syntax change
15:17:39 <anteaya> but it makes more sense as the task is the thing that is tracked and has status updated as well as an assignee
15:18:10 <anteaya> so it made sense to us that the task/id is the thing that starts being used for linking the bits together
15:18:45 <fungi> anteaya: sure. we'll likely still stick with the term "bug" from a commit perspective
15:19:00 <anteaya> yup, that can work
15:19:19 <fungi> but i agree that being able to close out independent tasks in a story for the same project with different commits is an improvement over lp
15:19:23 <anteaya> but right now we use: Story: <story_id> in the commit message
15:19:42 <fungi> that was a transitional thing while we're still also using lp
15:19:45 <anteaya> but that would be very hard to map back to something with a status change in storyboard
15:19:56 <anteaya> ah, I missed that point then
15:19:57 <anteaya> thank you
15:20:04 <anteaya> so glad we are not stuck on that
15:20:34 <anteaya> so use the bug syntax but use the task/id from storyboard instead of the launchpad-id for the bug
15:20:48 <Zara> would we want an interim story-task: <task_id> ? or just jump straight to only using storyboard task ids?
15:20:49 <fungi> the plan has always been to switch to having Closes-Bug et al refer to storyboard (stories? tasks? whatever) once we switch completely
15:21:23 <anteaya> fungi: ah great, that makes it easy
15:21:35 <SotK> that makes sense to me
15:21:38 <anteaya> fungi: was that part of a spec anywhere that I might reference?
15:21:45 <fungi> the main hiccup there will be that our import associates existing lp bug numbers with storyboard story ids, so links for existing bug references might get weird
15:21:59 <anteaya> ah
15:22:07 <fungi> anteaya: i don't think so... did teh spec mention using "story" as a header in commit messages at all?
15:22:25 <anteaya> so the migration testing will need to look out for this case and create some form of way to address it
15:22:30 <fungi> i wonder if there's a way to disambiguate story ids from task ids
15:23:03 <anteaya> fungi: I don't know, I will look it up, but you saying so in the meeting log is good enough as an artifact for my purposes, thank you
15:23:32 <SotK> I don't think there is a way to do that at the moment
15:24:28 <SotK> they're both just numbers and have the potential to overlap
15:24:29 <anteaya> okay so right now story ids and task ids can overlap
15:24:57 <anteaya> in the db schema there is a table for stories and a separate table for tasks
15:25:06 <anteaya> and each table just has a column called id
15:25:32 <anteaya> and it sounds like the ids can be anything
15:25:42 <anteaya> in terms of how many digits they use
15:28:31 <anteaya> fungi: storyboard currently has 5 open specs and I searched for the word commit in them and came up empty in all 5
15:28:46 <anteaya> fungi: so going with there is no spec that talks about commit message syntax
15:28:55 <SotK> yeah, I'm not sure we have a spec about gerrit integration anywhere
15:31:57 <SotK> betherly isn't around this week, and I don't know how far she's got with things, so I guess we'll move onto discussion
15:32:07 <anteaya> sounds good
15:32:12 <SotK> #topic Product WG/Cross-Project Dashboard (shamail)
15:32:27 <shamail> Thanks for this opportunity
15:32:42 <shamail> For reference, I want to share the link to the PWG dashboard again: http://104.239.130.200:9000/
15:32:58 <shamail> We had a meeting last week to discuss evaluating the various platforms available (or scheduled to be available) in the community which includes Storyboard and Phabricator.
15:33:30 <shamail> We decided that a good starting point would be to share our scope/objective and then determine if everyone thinks it aligns with the scope/objective for storyboard as a next step.
15:33:50 <shamail> The dashboard that we prototyped is a read-only page that simply helps us visualize a relationship between artifacts, in the existing dev workflow, that are independent.
15:34:23 <fungi> (btw, changes 318174 and 318180 should _hopefully_ fix the current dev server snakeoil cert puppeting)
15:34:30 <shamail> We don’t intend to enter any new data (even comments) on that page.  Given that objective… do we still feel that there might be potential to add this work to storyboard?
15:34:49 <anteaya> fungi: thank you
15:35:06 <shamail> What are your thoughts?
15:35:32 <anteaya> shamail: thanks for taking the time to evaluate the options
15:36:06 <shamail> np anteaya, FWIW I will be starting a discussion with infra on where should the dashboard live once we ensure we have determined whether it needs its own home
15:36:32 <anteaya> shamail: sure thank you, I think that is a good conversation to have
15:36:37 <shamail> I was worried about whether our objective/scope was clearly provided at the summit
15:36:52 <anteaya> shamail: well Zara is trying to compose a question about that
15:36:59 <Zara> shamail: does the PWG have a summary of what it wants to achieve with the dashboard anywhere? it'd be handy to see why people want this information to be non-interactive, etc...
15:37:07 <shamail> The name needs to change since it is very confusing (it includes both story and tracker in the name, lol.. it is neither)
15:37:08 <anteaya> shamail: she is sitting beside me at the storyboard mid-cycle
15:37:29 <anteaya> shamail: ah naming the bits, so much fun
15:37:29 * shamail goes to check the PWG wiki
15:38:06 * fungi is happy to have the "where and when" discussion on hosting that dashboard at your convenience, if it turns out to be a separate implementation. can just be an ad hoc discussion in #openstack-infra
15:38:33 <shamail> Sounds good fungi…
15:38:37 <shamail> The wiki doesn’t contain much
15:38:41 <shamail> So here is what I found: https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst
15:39:08 <shamail> This gives an overview of the artifacts we are trying to build the contextual relationship for
15:39:40 <shamail> I will take an action item to summarize our requirements and percieved benefits from having a non-interactive view
15:39:47 <anteaya> shamail: here is where we are having difficulty, we don't understand the story of the dashboard
15:40:19 <anteaya> so we can see the artifacts you selected, but so far are a bit thin on the rational for why those were the artifacts selected
15:40:20 <shamail> One of our goals was to not add any additional burden in the development workflow so if we could keep using existing artifacts (rather than create new ones) we felt it would reduce the net burden of our workflow
15:40:26 <anteaya> shamail: if that makes sense
15:40:32 <shamail> anteaya: It totally does
15:40:38 <anteaya> shamail: oh good, thank you
15:40:41 <shamail> I think we have shared what it does but not why we want it
15:41:17 <anteaya> yeah, don't worry about creating additional burden
15:41:26 <sparkycollier> so if I understand correctly the purpose is to get the product working group an easy way at a glance to track progress on development work that's deemed of high interest to the group?
15:41:28 <anteaya> focus on what you want from the tool
15:41:39 <shamail> The main purpose for the dashboard in the PWG is that we will be working on items that might include multiple cross project specs and specs/bps across multiple projects
15:41:56 <anteaya> sparkycollier: that seems to be my understand so far, yes
15:42:25 <shamail> We needed a way to “at a glance” see the status of all the related artifacts for a given user story and the last date of activity so we can ask for more help if progress stalls
15:42:31 <anteaya> sparkycollier: trying to understand a bit of the backstory of why these are the artifacts selected to get a bigger picture on their workflow
15:42:36 <shamail> sparkycollier: +1, that is the main purpose
15:43:04 <Zara> thanks for the link to the repo :) I guess one thing I'm wondering about is how the important fields were decided. eg: there's a description of fields used in the tracker, but I'd be intersted to see the place where those fields were decided upon as the ones to use
15:43:05 <sparkycollier> sounds like a useful thing :)
15:43:12 <Zara> because I think that'd give a lot of context on people's needs
15:43:18 <Zara> *interested
15:43:34 <Zara> and that way, we can identify where things overlap with storyboard
15:43:35 <shamail> anteaya: The reason these artifacts are represented is because they are all a part of the existing development workflow
15:44:12 <anteaya> sparkycollier: yes, I think there is agreement this is useful, I think the storyboard folks are trying to get the bits they need to be able to provide what suits the needs of the group
15:44:22 <fungi> this sounds similar to ttx's idea of an "epic" as an aggregation of multiple stories in storyboard
15:44:24 <shamail> Zara: Can you clarify a bit on the request?  Do you want to know why we included cross project specs, blueprints, etc. or why we chose certain names for the fields?
15:44:26 * SotK suspects our vague not-yet-existing concept of epics maps approximately to these cross-project user stories
15:44:31 <SotK> heh, fungi beat me
15:45:18 <shamail> fungi: That is a good way to look at it… the user stories that PWG generates are epics… We have been writing them and saving them in our repository for about a year.
15:45:23 <sparkycollier> thanks anteaya I'm a little late to the party
15:45:37 <Zara> shamail: it's more general than that, as a first step I'd like to find the place where I can see the PWG choosing the relevant fields. then I can ask questions about the discussions there once I've caught up.
15:45:50 <anteaya> sparkycollier: I saw you join, was trying to catch you up without being obvious, glad you could make it :)
15:45:57 <Zara> otherwise we'll end up asking questions people have already answered :)
15:46:05 <shamail> I think there are two points of intersection between PWG and storyboard… one is the topic we are discussing: the dashboard but the other might be where are actual user stories reside long-term
15:46:08 <SotK> shamail: I expect our eventual implementation of epics would fit the usecase your dashboard solves pretty nicely (though I'd like them to not be readd-only)
15:46:11 <fungi> given that blueprints are more or less superseded by specs now which projects are treating as just more git repos with commits, you could for example have a story which has spec tasks and then additional stories which cover different major implementation aspects, and track their progress and related code review changes as a roll-up into the epic structure
15:46:40 <SotK> fungi: that is how I picture things working without blueprints too
15:47:04 <fungi> the lightweight shim we get from blueprints in launchpad today are easily already covered by just having a "story" in storyboard associated with the spec
15:47:18 <shamail> What are the plans around implementing epics?  Is that something planend to be worked on this cycle?
15:48:22 <fungi> the workflow infra's used so far for its specs actually just sticks with a single story, since tasks in storyboard can be more diverse and granular than lp's bugtasks, but i can see possibly tracking multiple related specs in an epic that way too
15:48:27 <shamail> The relationship that we would prefer is that an epic could be attached to multiple cross project specs (or directly to project level specs) and then we could associate  project-level specs with cross-project specs
15:48:28 <SotK> we don't have any plans for when to work on epics yet afaik
15:49:01 <Zara> shamail: the dashboard source review comments might be helpful to us, if there's a link
15:49:19 <shamail> Let me find it
15:49:24 <fungi> though it sounds like some of the question is would developer involvement be turned away if they showed up willing to write the epic implementation
15:50:44 <SotK> people willing to do the work are welcome, but I think it should be designed first
15:51:11 <anteaya> I think having a design session for epics, either at a mid-cycle or summit would be in order
15:51:20 <SotK> +1
15:51:21 <fungi> agreed, the design work would need to be written up and reviewed by the current sb devs and any other interested parties
15:51:29 <shamail> I will have to find the git repo and share it with you later, I know it’s at https://github.com/OpenStackweb but I can’t find the exact location atm
15:51:34 <anteaya> this mid-cycle we have been focused on items that would put is in line with dev/tc needs
15:51:35 <fungi> wouldn't need to be an inp-erson design session
15:51:41 <fungi> i don't think
15:51:47 <anteaya> like private stories, teams and gerrit integration
15:51:51 <Zara> +2 more contributors always welcome (especially on the js side!)
15:52:08 <anteaya> fungi: okay, but designed
15:52:15 <SotK> I'd be delighted with someone providing a spec for me to review about epics
15:52:23 <shamail> #link https://wiki.openstack.org/wiki/ProductTeam/User_Stories
15:52:38 <anteaya> we mentioned epics at this mid-cycle but had a lot of other task with priority
15:52:46 <fungi> also the other important part of that dashboard seems to be progress tracking. so probably some model for how you figure out what progress on a task/story/epic is (just divide by the number of  identified tasks and increment as each task reaches a closed state?)
15:52:53 <shamail> Here is a wiki page with our workflow and overview of the different activities related to user story implementation
15:53:35 <anteaya> shamail: so we agree that this is not the source code, yes?
15:53:48 <SotK> fungi: I would imagine so, although I have doubts over how "real" those percentages will be
15:53:54 <shamail> We are using user stories which have mandatory fields (such as user story, usage scenario, justification, etc.) and then we are leveraging (after agreement) to help find developers and implement using standard development workflow in the community
15:54:01 <Zara> SotK: right, tasks can vary in complexity
15:54:12 <shamail> yes
15:54:19 <anteaya> shamail: okay thanks
15:54:38 <fungi> SotK: yeah, i think if something like that wasn't positioned as a "percentage" but just tracked number of tasks done/remaining or something, it could be a suitable compromise
15:55:20 <fungi> trying to map actual estimated effort per task onto a timeline gets into all sorts of nasty business logic we'd be better off avoiding
15:55:31 <persia> I would prefer task counts for open, in review, and closed, as three numbers.
15:55:53 <fungi> persia: makes sense. the bar chart is likely what makes it seem like a linear thing
15:56:03 <fungi> which definitely gets misleading
15:56:34 <anteaya> fungi: yes number of tasks done of total is already in line with functionality they completed for persia to be able to see priorities of tasks in subscribed work lists
15:56:47 <shamail> Count is fine (versus %), the main goal there is to see how many items are associated with a given user story and the date of last activity (to be able to quickly gauge if a few specs are blocking the overall user story)
15:57:12 <fungi> anteaya: persia: oh, excellent!
15:57:22 <Zara> it'd be good to fix our 'updated' field to give something relevant
15:57:24 <shamail> The challenge is that we are already in-flight with user stories
15:57:32 <shamail> and need a way to track them relatively soon
15:57:43 <Zara> so improving the 'updated' field is a concrete thing a new contributor could help with
15:57:52 <betherly> hi! update on stuff is that I'm almost ready to push outline of tutorial. sorry didn't come into meeting earlier! shifted my hours and called it a day early today to get ready for holidays
15:58:07 <Zara> betherly: np, I thought you were on holiday already! :D
15:58:12 <shamail> Does it make sense for us to share how we came up with the fields, work on determining a path to epics, but host this prototype somewhere inside infra in the interim to have a tool immediately?
15:58:16 <Zara> betherly: but brilliant!
15:58:26 <shamail> Which could be decommissioned once epics are closer
15:58:27 <anteaya> shamail: well currently storyboard is actively developed by two developers full time with some additional help from other folks
15:58:42 <fungi> shamail: if teh longer term goal is to help get similar functionality into storyboard (e.g. by piggybacking on what the epic concept would provide) then using hosting/using that poc you have in the short term seems perfectly fine to me
15:58:42 <betherly> Zara: nope leave tomorrow but shifted hours so I had time to pack lol :)
15:59:15 <anteaya> shamail: we can understand deadlines but thus far priorities have been for tasks that will put storyboard in line with developer expectations to be selected as the task tracking tool by the tc
15:59:50 <shamail> anteaya: Totally understand.  That is why I suggested hosting the prototype somewhere until epics can be designed and then started.
15:59:50 <SotK> almost out of time folks
15:59:55 <Zara> betherly: really glad the outline's nearly ready, anyway :)
16:00:01 * SotK agrees with fungi in general
16:00:05 <shamail> We have a current need for a solutin as well :(
16:00:23 <anteaya> shamail: yes, the openstack community as a whole has had a need for about a year
16:00:36 <anteaya> shamail: so I totally understand the position
16:00:45 <SotK> our time is up, lets continue in #storyboard if so desired :)
16:00:46 * smcginnis taps foot :D
16:00:49 <SotK> #endmeeting