20:02:36 <sarob> #startmeeting training-manuals
20:02:36 <openstack> Meeting started Mon Aug 12 20:02:36 2013 UTC and is due to finish in 60 minutes.  The chair is sarob. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:40 <openstack> The meeting name has been set to 'training_manuals'
20:02:56 <colinmcnamara> Colin here
20:03:49 <sarob> hello
20:03:53 <colinmcnamara> hello
20:04:24 <sarob> what do you have for agenda today?
20:04:59 <colinmcnamara> one mine
20:05:03 <colinmcnamara> min
20:05:09 <sarob> sure
20:05:47 <colinmcnamara> back
20:06:00 <sarob> mestery: you online?
20:06:46 <sarob> ill start with mine first...
20:06:56 <sarob> #topic 2 week sprint
20:07:17 <sarob> are we ready to start our first 2 week sprint?
20:07:31 <colinmcnamara> I think so
20:07:34 <sarob> cool
20:07:41 <colinmcnamara> I think we need to be hyper vigalant
20:07:57 <colinmcnamara> and start with a pre-plan figuring out what stories are going to be in
20:08:08 <colinmcnamara> and manage our burn down chart like nazi's
20:08:15 <sarob> ;)
20:08:38 <colinmcnamara> I think an action item is to do resource estimation, and figure out what stories are going to be in this sprint
20:08:44 <sarob> so the user stories in the sprint backlog are assoc user stories
20:09:13 <sarob> can we label them as assoc, so we can start adding oper and dev user stories?
20:09:17 <colinmcnamara> yes, but I don't think all of them will get accomplished in a sprint
20:09:37 <colinmcnamara> we can, but I think we should focus on releasing the associate book first
20:09:43 <colinmcnamara> and then assessment
20:09:45 <sarob> i hear that
20:09:48 <colinmcnamara> and also
20:10:01 <colinmcnamara> start to address preso format (tagging slides, notes, etc)
20:10:08 <colinmcnamara> and get a beta  done
20:10:15 <colinmcnamara> beta delivery
20:10:25 <colinmcnamara> so, one prod dev cycle on associate
20:10:37 <colinmcnamara> then take those lessons learned and apply them to the next level of engineer
20:10:41 <sarob> #ACTION goals for associate training book publish
20:11:14 <colinmcnamara> the big thing is to do an hours estimation, and figure out the true amount of team the team devotes
20:11:16 <sarob> #ACTION add book label for user stories, e.g. assoc, operator, developer, devops
20:11:29 <colinmcnamara> and then mange the sprint to the sprint duration
20:12:05 <sarob> we still need to recruit community committers so i dont know how many hands
20:12:42 <sarob> lets promote that we are open for business to the other user groups and see how many community takers we get
20:12:57 <colinmcnamara> agreed
20:13:03 <colinmcnamara> I talked to shannon mcfarland
20:13:07 <colinmcnamara> he is to busy for core
20:13:12 <colinmcnamara> but wants to participate in community
20:13:54 <sarob> #ACTION publish to user groups that openstack-training project is actively seeking community contributors
20:14:05 <sarob> sounds good
20:14:20 <colinmcnamara> I think an action
20:14:21 <sarob> we need lots of doers, community is it
20:14:29 <colinmcnamara> for getting contribution, is putting together an ignite deck
20:14:40 <colinmcnamara> that goes over the purpouse and mission of openstack-training
20:15:08 <sarob> #ACTION colinmcnamra community contribution ignite deck
20:15:10 <colinmcnamara> I'll take that action
20:15:12 <colinmcnamara> yup
20:15:38 <sarob> i guess i bled into the second agenda item
20:15:41 <sarob> oh well
20:16:00 <sarob> so how many community members is enough?
20:16:15 <colinmcnamara> 20-40
20:16:22 <colinmcnamara> members vs leaders btw is an interesting notion
20:16:47 <sarob> how so?
20:17:11 <colinmcnamara> I personally think that the best way to go after community is to go after the community users group leaders
20:17:36 <colinmcnamara> it may be worth deciding when were are ready to handle a large influx of focus
20:17:48 <colinmcnamara> and get an article published on the OpenStack blog
20:18:24 <sarob> id say now
20:19:07 <sarob> if we can get some people to help take ownership of the different books
20:19:26 <colinmcnamara> I would like to get a consistency in style
20:19:30 <colinmcnamara> and dev process
20:19:35 <sarob> then we can loosely manage the process of getting the material published
20:19:42 <sarob> act more like editors
20:19:42 <colinmcnamara> I think that it would be good to go through and end to end product cycle on associate
20:19:52 <colinmcnamara> then splinter out to each level
20:20:01 <sarob> prob right
20:20:12 <sarob> figure out bugs in process before full bore
20:20:36 <colinmcnamara> thats my recommendation
20:20:43 <sarob> so lets sprint on associate training only, while capturing new
20:20:47 <colinmcnamara> yup
20:20:56 <sarob> users stories for the other books as they come up
20:21:01 <colinmcnamara> focus teams and effort on creating a product that is releasable
20:21:03 <colinmcnamara> yup
20:21:04 <sarob> over the next two weeks
20:21:09 <colinmcnamara> agree
20:21:21 <colinmcnamara> btw, I was thinking that for now
20:21:30 <colinmcnamara> we should probably add each other as reviewers for quick merges
20:21:40 <sarob> #action 2 week sprint starts now focused on associate engineer
20:22:22 <sarob> #action dev, ops, devops user stories captured now, but sidelined until after current sprint has run
20:22:45 <colinmcnamara> question on that action
20:22:57 <colinmcnamara> I think that is something to create, that the user community can create stories
20:23:01 <colinmcnamara> but is  lots of work
20:23:40 <sarob> okay, so we take them as ideas for the next two weeks
20:24:15 <colinmcnamara> yes, it is significant work
20:24:15 <sarob> reassess books and materials post 11sep
20:24:20 <colinmcnamara> agreed
20:24:29 <colinmcnamara> also, that bootcamp may affect our workflow
20:24:30 <sarob> cool
20:24:37 <sarob> i hope so
20:24:50 <sarob> i want new ideas
20:25:20 <sarob> ready for next topic?
20:25:23 <colinmcnamara> yes
20:25:39 <sarob> #topic bug https://review.openstack.org/#/c/41504/
20:26:01 <sarob> i guess that is patch
20:26:07 <sarob> related to bug
20:27:23 <colinmcnamara> that the patch is dependent on the shallow clone
20:27:24 <colinmcnamara> ?
20:29:05 <sarob> lorin and jeremy have asked that we clone remote docs rather than include from raw.github.com
20:29:20 <sarob> im willing to try it out for now
20:29:32 <colinmcnamara> so, how does that affect our workflow
20:29:35 <sarob> see my comment https://bugs.launchpad.net/openstack-manuals/+bug/1211135
20:29:54 <sarob> not really impacts workflow
20:30:31 <sarob> just point to local repo clone rather than raw.github.com
20:30:33 <colinmcnamara> more thinking of the local dev workflow
20:30:44 <sarob> explain?
20:30:49 <colinmcnamara> well, it does affect the fact that we need people pulliing more then openstack-manuals
20:30:54 <colinmcnamara> for the local work
20:30:56 <colinmcnamara> right?
20:31:07 <colinmcnamara> and need to make sure that all are up to date for local mvn builds
20:31:25 <sarob> i created a subdir /openstack-training/sources
20:31:32 <sarob> to house the repo clones
20:32:03 <colinmcnamara> so, everytime there is a merge, gerrit clones into those?
20:32:32 <sarob> i think we should manage the clone timing
20:32:37 <sarob> manually
20:32:45 <colinmcnamara> ok
20:32:47 <sarob> it duplicates content, but
20:32:56 <colinmcnamara> maybe that is something we can automate
20:33:00 <colinmcnamara> so we don't get drift
20:33:00 <sarob> it allows us to control when the source content changes
20:33:07 <sarob> right
20:33:18 <colinmcnamara> you know, we could update the jenkins job to update that sub dire
20:33:36 <sarob> yeah, but im thinking the cloning should be managed
20:33:47 <colinmcnamara> I think dependancies should be managed
20:33:51 <sarob> i prestage the cloning
20:34:04 <sarob> so i know which pages are changing
20:34:04 <colinmcnamara> I think that is effectively branching
20:34:12 <sarob> kinda
20:34:19 <colinmcnamara> I think that we should use maven for dependancy management
20:34:23 <colinmcnamara> or, more accurately
20:34:31 <colinmcnamara> we should manage dependancies programatically
20:34:52 <colinmcnamara> I believe maven is the proper tool to do that
20:34:55 <sarob> if a notice of which pages changed can be sent out to the team
20:34:58 <sarob> im good
20:35:09 <sarob> otherwise id want it to be manual
20:35:11 <colinmcnamara> but, say we get to 600 pages of docs
20:35:19 <colinmcnamara> how are we going to notice an error?
20:35:25 <colinmcnamara> I think this needs to be programatic
20:35:33 <colinmcnamara> especially if an include statement fails
20:35:45 <colinmcnamara> now that I think about it
20:35:50 <colinmcnamara> maven does catch that
20:35:57 <sarob> agreed, but when and how
20:36:04 <colinmcnamara> when an update happens
20:36:14 <colinmcnamara> I am a big fan of keeping as close to trunk as possible
20:36:18 <sarob> back up a sec
20:36:28 <sarob> if we have 600 included pages
20:37:12 <sarob> the choices are auto clone new material, note the source changes and failed includes, somebody will need to pickup
20:37:22 <sarob> maybe auto create bugs
20:37:28 <colinmcnamara> auto create a bug
20:37:35 <colinmcnamara> and that bug would be a priority to address
20:37:36 <sarob> or sprint day one a month to do the same thing
20:37:56 <colinmcnamara> before new material is added
20:37:56 <sarob> or both maybe
20:38:02 <colinmcnamara> core tennant of CI
20:38:09 <colinmcnamara> which is a core tennant of openstack dev
20:39:04 <colinmcnamara> I'd rather fix broken code (before it is merged btw)
20:39:15 <colinmcnamara> vs getting a pile of re-worlk
20:39:43 <sarob> whats new materal
20:39:58 <sarob> new source material or new training materila
20:39:58 <colinmcnamara> so, say an upstream doc changes
20:40:04 <colinmcnamara> introducing a bug
20:40:15 <colinmcnamara> if that upstream is merged say, every 2 weeks
20:40:29 <colinmcnamara> that there can be 2 weeks of new bugs generated from that upstream change
20:40:35 <colinmcnamara> if it is merged imediately
20:40:42 <colinmcnamara> the first bug would trigger a build failure
20:41:00 <colinmcnamara> which would then get addressed as a priority before any new stories are worked on
20:41:39 <sarob> if we are going to hold merges for two active weeks,
20:41:50 <sarob> id better get to be an expert on git
20:42:07 <sarob> smarter than i am now :)
20:42:41 <colinmcnamara> I think we both have that challenge
20:43:08 <colinmcnamara> that and Jenkins / Maven
20:43:52 <sarob> so we build into maven script clone repo, create bugs on failed includes
20:44:13 <colinmcnamara> I think it is a publish step on the merge for the jenkis / zuul system
20:44:21 <colinmcnamara> and then the local dev workflow doesn't change
20:44:26 <sarob> we make policy to solve failed includes as pre-merge priority
20:44:32 <colinmcnamara> yup
20:44:37 <colinmcnamara> always be integrating working clde
20:44:39 <colinmcnamara> code
20:44:47 <colinmcnamara> increases code quality while decreasing lead times
20:45:36 <colinmcnamara> I need to step out pretty soon
20:45:53 <sarob> #action figure out script to clone repos and build failed includes as priority bugs
20:46:09 <sarob> im done
20:46:16 <colinmcnamara> cool
20:46:20 <sarob> aob?
20:46:23 <colinmcnamara> none
20:46:24 <colinmcnamara> you?
20:46:29 <sarob> thats a wrap
20:46:33 <colinmcnamara> ttyl
20:46:44 <sarob> #endmeeting