15:01:17 #startmeeting storyboard 15:01:17 I can be here 15:01:18 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:21 hi everyone 15:01:22 The meeting name has been set to 'storyboard' 15:01:35 hi shamail! :D 15:01:39 #link https://wiki.openstack.org/wiki/Meetings/StoryBoard#Agenda_for_next_meeting Agenda 15:02:02 o/ Zara & anteaya! 15:02:12 hi shamail :) 15:02:13 hey shamail 15:02:22 Hi SotK 15:02:28 #topic Announcements 15:02:39 We almost have a dev server set up! 15:03:03 yay! 15:03:04 \o/ 15:03:27 I don't think we have any urgent items at the moment, so on to in progress work 15:03:34 #topic In Progress Work 15:03:48 We discussed complex priorities at length after the meeting last week 15:04:16 SotK is finding the logs now 15:04:21 #link http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2016-05-11.log.html#t2016-05-11T16:00:31 15:04:25 :D 15:04:39 I've not actually got round to doing any more work on it since then 15:05:33 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 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 thank you 15:06:25 What is the best format for sharing? 15:06:48 discussion in #storyboard, to begin with 15:06:49 mailing list or IRC meeting? 15:06:54 Thanks 15:07:07 yeah discussing in the channel I think would be fine 15:07:07 np :) 15:07:17 I don't think you need to wait for a meeting 15:07:20 I agree 15:07:24 yeah, the project channel is logged 15:07:37 so things won't be lost 15:07:49 #link http://eavesdrop.openstack.org/irclogs/%23storyboard/ 15:07:58 Great 15:08:31 I've started looking at Teams, now that the first pass of private stories is merged 15:08:39 :D 15:08:51 so far I've determined that the GET part of the teams API works 15:09:04 yay private stories is merged 15:09:06 \o/ 15:09:12 nice 15:09:17 SotK: awesome 15:09:24 so that just leaves PUT, POST and DELETE? 15:09:31 yeah 15:09:45 I'm assuming they work too, we will find out soon 15:09:48 SotK: have you had a chance to test the others yet? 15:09:52 SotK: ah cool 15:10:03 hopefully we will have the dev server up soon 15:10:10 cool, thanks for looking into this 15:10:45 Zara: did you want to say anything about the gerrity bits? 15:10:51 I started trying to make some operator docs, for quickly spinning up a storyboard instance 15:10:59 yay docs 15:11:07 tried with ansible, failed, tried with puppet, failed, journey so far recorded here: 15:11:10 #link https://storyboard.openstack.org/#!/story/2000535 15:11:33 the puppet errors are similar to the things fungi's finding with trying to set up a dev instance 15:11:44 so hopefully as that gets untangled I might be able to revisit it 15:11:51 (I have 0 puppet :)) 15:11:55 Nice 15:11:59 i have 0.5 puppet 15:12:07 SOUNDS GREAT TO ME 15:12:12 :D 15:12:13 Zara: nice work on the investigation 15:12:33 Zara: and I agree it will be nice once docs are in place for folks to spin up their own instance 15:12:52 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 #info Zara tried and failed to make some quickstart operator docs, will come back to it pending puppet progress 15:14:53 failed with notes 15:15:02 yes :) 15:15:08 so in the meantime, I've started looking at integrating StoryBoard with gerrit again 15:15:18 yay storyboard and gerrit 15:15:23 mainly just remembering what my old proof of concept did 15:15:27 * SotK seconds the yays 15:15:37 #link https://review.openstack.org/#/c/302912/ 15:16:05 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 we did talk about this bit at the mid-cycle 15:16:21 yup 15:16:26 #link https://storyboard.openstack.org/?#!/story/2000584 details how we think gerrit commit messages should work 15:16:29 we even drew things on a whiteboard 15:16:58 fungi: we identified that using task/id is a better way forward than story id 15:17:10 fungi: this will include a commit message syntax change 15:17:39 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 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 anteaya: sure. we'll likely still stick with the term "bug" from a commit perspective 15:19:00 yup, that can work 15:19:19 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 but right now we use: Story: in the commit message 15:19:42 that was a transitional thing while we're still also using lp 15:19:45 but that would be very hard to map back to something with a status change in storyboard 15:19:56 ah, I missed that point then 15:19:57 thank you 15:20:04 so glad we are not stuck on that 15:20:34 so use the bug syntax but use the task/id from storyboard instead of the launchpad-id for the bug 15:20:48 would we want an interim story-task: ? or just jump straight to only using storyboard task ids? 15:20:49 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 fungi: ah great, that makes it easy 15:21:35 that makes sense to me 15:21:38 fungi: was that part of a spec anywhere that I might reference? 15:21:45 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 ah 15:22:07 anteaya: i don't think so... did teh spec mention using "story" as a header in commit messages at all? 15:22:25 so the migration testing will need to look out for this case and create some form of way to address it 15:22:30 i wonder if there's a way to disambiguate story ids from task ids 15:23:03 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 I don't think there is a way to do that at the moment 15:24:28 they're both just numbers and have the potential to overlap 15:24:29 okay so right now story ids and task ids can overlap 15:24:57 in the db schema there is a table for stories and a separate table for tasks 15:25:06 and each table just has a column called id 15:25:32 and it sounds like the ids can be anything 15:25:42 in terms of how many digits they use 15:28:31 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 fungi: so going with there is no spec that talks about commit message syntax 15:28:55 yeah, I'm not sure we have a spec about gerrit integration anywhere 15:31:57 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 sounds good 15:32:12 #topic Product WG/Cross-Project Dashboard (shamail) 15:32:27 Thanks for this opportunity 15:32:42 For reference, I want to share the link to the PWG dashboard again: http://104.239.130.200:9000/ 15:32:58 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 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 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 (btw, changes 318174 and 318180 should _hopefully_ fix the current dev server snakeoil cert puppeting) 15:34:30 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 fungi: thank you 15:35:06 What are your thoughts? 15:35:32 shamail: thanks for taking the time to evaluate the options 15:36:06 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 shamail: sure thank you, I think that is a good conversation to have 15:36:37 I was worried about whether our objective/scope was clearly provided at the summit 15:36:52 shamail: well Zara is trying to compose a question about that 15:36:59 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 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 shamail: she is sitting beside me at the storyboard mid-cycle 15:37:29 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 Sounds good fungi… 15:38:37 The wiki doesn’t contain much 15:38:41 So here is what I found: https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst 15:39:08 This gives an overview of the artifacts we are trying to build the contextual relationship for 15:39:40 I will take an action item to summarize our requirements and percieved benefits from having a non-interactive view 15:39:47 shamail: here is where we are having difficulty, we don't understand the story of the dashboard 15:40:19 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 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 shamail: if that makes sense 15:40:32 anteaya: It totally does 15:40:38 shamail: oh good, thank you 15:40:41 I think we have shared what it does but not why we want it 15:41:17 yeah, don't worry about creating additional burden 15:41:26 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 focus on what you want from the tool 15:41:39 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 sparkycollier: that seems to be my understand so far, yes 15:42:25 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 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 sparkycollier: +1, that is the main purpose 15:43:04 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 sounds like a useful thing :) 15:43:12 because I think that'd give a lot of context on people's needs 15:43:18 *interested 15:43:34 and that way, we can identify where things overlap with storyboard 15:43:35 anteaya: The reason these artifacts are represented is because they are all a part of the existing development workflow 15:44:12 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 this sounds similar to ttx's idea of an "epic" as an aggregation of multiple stories in storyboard 15:44:24 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 heh, fungi beat me 15:45:18 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 thanks anteaya I'm a little late to the party 15:45:37 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 sparkycollier: I saw you join, was trying to catch you up without being obvious, glad you could make it :) 15:45:57 otherwise we'll end up asking questions people have already answered :) 15:46:05 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 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 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 fungi: that is how I picture things working without blueprints too 15:47:04 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 What are the plans around implementing epics? Is that something planend to be worked on this cycle? 15:48:22 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 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 we don't have any plans for when to work on epics yet afaik 15:49:01 shamail: the dashboard source review comments might be helpful to us, if there's a link 15:49:19 Let me find it 15:49:24 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 people willing to do the work are welcome, but I think it should be designed first 15:51:11 I think having a design session for epics, either at a mid-cycle or summit would be in order 15:51:20 +1 15:51:21 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 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 this mid-cycle we have been focused on items that would put is in line with dev/tc needs 15:51:35 wouldn't need to be an inp-erson design session 15:51:41 i don't think 15:51:47 like private stories, teams and gerrit integration 15:51:51 +2 more contributors always welcome (especially on the js side!) 15:52:08 fungi: okay, but designed 15:52:15 I'd be delighted with someone providing a spec for me to review about epics 15:52:23 #link https://wiki.openstack.org/wiki/ProductTeam/User_Stories 15:52:38 we mentioned epics at this mid-cycle but had a lot of other task with priority 15:52:46 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 Here is a wiki page with our workflow and overview of the different activities related to user story implementation 15:53:35 shamail: so we agree that this is not the source code, yes? 15:53:48 fungi: I would imagine so, although I have doubts over how "real" those percentages will be 15:53:54 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 SotK: right, tasks can vary in complexity 15:54:12 yes 15:54:19 shamail: okay thanks 15:54:38 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 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 I would prefer task counts for open, in review, and closed, as three numbers. 15:55:53 persia: makes sense. the bar chart is likely what makes it seem like a linear thing 15:56:03 which definitely gets misleading 15:56:34 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 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 anteaya: persia: oh, excellent! 15:57:22 it'd be good to fix our 'updated' field to give something relevant 15:57:24 The challenge is that we are already in-flight with user stories 15:57:32 and need a way to track them relatively soon 15:57:43 so improving the 'updated' field is a concrete thing a new contributor could help with 15:57:52 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 betherly: np, I thought you were on holiday already! :D 15:58:12 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 betherly: but brilliant! 15:58:26 Which could be decommissioned once epics are closer 15:58:27 shamail: well currently storyboard is actively developed by two developers full time with some additional help from other folks 15:58:42 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 Zara: nope leave tomorrow but shifted hours so I had time to pack lol :) 15:59:15 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 anteaya: Totally understand. That is why I suggested hosting the prototype somewhere until epics can be designed and then started. 15:59:50 almost out of time folks 15:59:55 betherly: really glad the outline's nearly ready, anyway :) 16:00:01 * SotK agrees with fungi in general 16:00:05 We have a current need for a solutin as well :( 16:00:23 shamail: yes, the openstack community as a whole has had a need for about a year 16:00:36 shamail: so I totally understand the position 16:00:45 our time is up, lets continue in #storyboard if so desired :) 16:00:46 * smcginnis taps foot :D 16:00:49 #endmeeting