17:00:11 #startmeeting training-guides 17:00:11 Meeting started Mon Nov 17 17:00:11 2014 UTC and is due to finish in 60 minutes. The chair is sarob. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:14 The meeting name has been set to 'training_guides' 17:00:35 hello 17:00:37 hy 17:00:41 hi 17:00:42 evening 17:00:54 ggreet ;) 17:01:09 rluethi, if you are interested in this, the cluster does not work something with the Compute Node 17:01:12 VMs do not launch 17:01:29 dbite: you are telling me this now? 17:01:38 I found this out like 2 hours ago 17:01:41 but you were not on IRC 17:01:56 dbite: let's talk about that after the meeting. 17:02:01 yes, sure 17:02:10 dbite: or is it on the agenda? :) 17:02:27 rluethi: now it is ;) 17:02:38 rluethi, I think I agree with matjazp :) 17:02:57 we need a way to test changes to the cluster 17:02:57 id like to start with #topic specs and blueprints for kilo milestones 17:03:14 #topic specs and blueprints for kilo milestones 17:03:27 hello 17:03:34 hi sayali 17:04:18 #link https://review.openstack.org/#/q/status:open+project:openstack/docs-specs,n,z 17:04:45 sarob, who has the commit rights for this? 17:05:23 I mean reviewer rights? 17:05:27 from training manuals team 17:05:31 *training guides 17:05:42 #link https://review.openstack.org/#/admin/groups/384,members 17:05:49 looks like just me 17:06:05 kool 17:06:12 hello 17:06:22 hey sam-i-am 17:06:28 hi Sam-I-Am 17:06:32 hey 17:06:38 hello 17:06:47 so our design session ideas from #link https://etherpad.openstack.org/p/training-guides-kilo-summit 17:07:18 need to be voted on in the review queue for #link https://review.openstack.org/#/q/status:open+project:openstack/docs-specs,n,z 17:07:29 by the team 17:07:32 Sam-I-Am, will you be there on docs IRC channel after the meeting? 17:07:42 dbite: should be 17:07:48 Sam-I-Am, Kool 17:08:45 we need to turn our actions and other ideas from the design session into specs and bp 17:08:49 sarob: I am afraid I lost the plot, what is it that you want to vote on, and how/when will that happen? 17:09:02 so i can assign them to kilo m1 and m2 17:09:45 sarob: so you want us to take stuff that we talked about at the summit and fill in proper specs and bps? 17:09:51 rluethi: for the training team to be all grown up like other projects, we need to follow the kilo release schedule more or less 17:09:57 matjazp: yup 17:10:18 sarob: oh, ok. 17:10:21 we have a bunch of actions 17:10:35 if we just started with those, we 17:10:49 will have a bunch of good work for this cycle 17:10:51 sarob: so we'll write up a blueprint for maybe changing the name of a sub-group? for real? 17:11:06 sarob: but not all of them... some are internal... 17:11:14 rluethi: exactly 17:11:15 rluethi: no not that, but bigger changes 17:11:37 sarob: like introduction af Moodle for online quizzes 17:11:43 sarob: let's mark the big ones and what kind of spec/blueprint they need, then. 17:11:48 matjazp: exactily 17:11:58 rluethi: you got it 17:12:11 we could have one blueprint per sub pproject to begin with 17:12:19 let do it on the etherpad, below the exiting text 17:12:28 our body of work for the kilo release should be described in launchpad 17:12:50 I think we need one blueprint per sub-project at least to state the major purpose of the project 17:12:56 I agree with sayali 17:13:02 the tc is our technical governing body and they need to 17:13:15 know what we are planning, have completed, 17:13:19 and pushed on 17:13:31 dbite: at least one 17:13:37 dbite: but yes 17:13:55 sarob, yeah, something that gives the general structure for sub-projects and what they do 17:13:59 we can have a spec that links to other specs too 17:14:06 I am not sure if the TC is interested in reading our Wiki pages that seriously 17:14:10 dbite: indeedly 17:14:24 dbite: um, prob not 17:14:42 dbite: but when we ask for incubation, some will for sure 17:14:56 dbite: all will look to launchpad 17:15:29 sooo, how to start 17:15:55 i like dbite idea of each sub-team lead coming up with specs 17:16:13 well, to be fair it was sayalis idea 17:16:15 otherwise, you are just planning on the status-quo 17:16:24 listing down all the things that need to be done and distinguishing the big ones as bp and the rest as bugs? 17:16:32 sayalis: right ;) 17:16:52 sayali: certainly, as bugs are generally 17:17:14 sayali: small fixes, but also assigned the milestones 17:17:36 yep we could have it all organized 17:17:52 we can kinda ignore m3 / feature freeze and assign some of our work to then 17:18:05 as the docs program does that too 17:18:23 but we should avoid big changes late in the release 17:18:40 i guess we need to decide on our team workflow as a whole :) 17:18:48 are we at the point of deciding the release cycle? 17:18:55 dbite: can you riff on a few spec ideas now? 17:18:57 I thought we need to wait till we decide on XML content 17:18:59 for docs team 17:19:11 sarob, that is why I am doing crazy 5k loc patches 17:19:28 I need to show the working concept to annegentle before I can comment or proceed 17:19:37 as discussed and concluded in the summit meeting 17:19:51 dbite: right 17:20:05 dbite: thats a spec 17:20:22 only after the doc team agrees 17:20:32 dbite: perhaps an easy win, but big work that you should get credit for 17:20:33 and also it may be a spec for both training uides and docs team 17:20:44 dbite: i think it is 17:20:50 sarob, yes 17:20:57 there was one question that Roger came up with 17:21:02 rluethi, want to shoot? 17:21:31 dbite: not sure what you are referring to now. 17:21:32 dbite: not all the docs program team was there for our design session, so specs will communicate our plans 17:21:41 rluethi, about the content management 17:21:46 for slides 17:21:59 dbite: get the broader team buyin for our release cycle work 17:22:22 dbite: you mean how we get feedback? 17:22:35 ahh, no for creation and maintaining the slides content 17:22:41 if we replace it with XML content 17:22:47 I did not want to step on your question 17:22:53 *XML with slides 17:23:00 dbite: just go ahead :) 17:23:18 sarob, We need to have someone maintain and create Slides 17:23:20 dbite: like some xml if we use the right tools? 17:23:32 which will possibly replace most or all of the XML content 17:23:45 I will be a bit pre-occupied with basic-install guides and infra part of the project 17:23:51 and I am not good at creating slides 17:23:58 dbite: since we plan on most of our content being rst 17:24:19 slides can be just a deliverable like the guides 17:24:45 dbite: i think we decided that the slides are the main deliverable, right 17:24:47 ? 17:25:04 why separate maintainer? 17:25:15 dbite: integration work with install guides remains 17:25:25 we just use the same process we used for Upstream Uni 17:25:40 dbite: but rst to html slides are what majority of our customers will use 17:26:02 matjazp: thats my understanding 17:26:14 sarob: actually... most will use only html (or PDF ;) 17:26:45 matjazp: or pdf, right on 17:26:49 whatever you do, try to avoid just copying the install guide 17:27:00 Sam-I-Am, that is the plan 17:27:03 tracking changes isnt easy 17:27:07 to point links to the manuals content 17:27:12 Sam-I-Am, I feel the pain 17:27:41 docbook inter-book references suck, so maybe regular http links work better... i dunno. 17:27:46 sarob, matjazp I am not sure if we just use upstream content 17:27:50 or work on it, modify it 17:28:00 or we need the same structure and convert books to slides 17:28:00 dbite: your spec on the install guide integration plans would help explain the plan 17:28:08 sarob, it will not do so 17:28:16 it will only push the basic install guides to manuals 17:28:19 if it works that is 17:28:24 if theres any way i can make the install guide more friendly to the training stuff, let me know. 17:28:41 Sam-I-Am, I think you will love the idea I am working on 17:28:41 sam-i-am: there def is. 17:28:50 lets discuss this after the meeting on docs IRC channel 17:28:58 Sam-I-Am: we devised a path forward at the summit 17:29:30 dbite: please please write up your plan as a spec 17:29:30 sure. i missed the summit. :/ 17:29:46 dbite: and work with sam-i-am on that 17:30:05 dbite: so the rest of the docs team can comment on 17:30:17 sarob, matjazp are you sure we do not need someone to take responsibility for maintaining the Slides? And by slides I mean the slides which will be in place of Associate, Operator, Architect and Developer guides 17:30:26 ok, creation of slides is a big change -> we should do a spec and BP on it 17:30:39 sarob, yes, I will I just need to follow our planning from the summit 17:30:48 dbite: what are you proposing? another subproject 17:30:51 before pushing anything else and also need to know wher eto push the specss :) 17:30:56 dbite: our team will maintain the rst just like we have the xml 17:31:05 matjazp, no, I will not be able to work on slides content 17:31:15 the same subproject, but I need someone to work on the content 17:31:19 sarob: exactly.. some contributors will focus on slides, some on the guides 17:31:21 how to create and maintain the slides 17:31:36 guys, it's not so much about whose project it's on, it's about who is going to do the work. 17:31:44 dbite: understood, we need more people on the project 17:31:49 dbite: i agree 17:32:00 dbite: oh.. now I understand what are you saying 17:32:01 sarob: yes 17:32:01 dbite: i can find you those people 17:32:03 sarob, I would be a bad idea for me to create slides, speaking from experience 17:32:10 sarob, thanks :) 17:32:23 dbite: no need for you to do it 17:32:27 be aware my friends that i have spun up 17:32:38 with reed and a few others 17:32:51 the product management team within openstack 17:33:00 we had our first meet over the summit 17:33:10 Product Management? 17:33:17 this is really a great opportunity for all of us 17:33:31 to get our companies more involved with our projects 17:34:27 the pm team is asking the PMs at large to commit resources to the projects they want to succeed 17:34:36 like this one 17:34:49 we need more people to be successful 17:35:11 the rest of the openstack projects need more trained openstack contributors and operators 17:35:31 sarob: so any concrete names yet? 17:35:58 yes 17:36:12 but i dont see them popping up here yet 17:36:30 thats is a very common summit problem 17:36:41 interest but hard to follow through 17:36:55 i can start to do that now 17:36:59 +1 on that heh 17:37:02 especially with docs :/ 17:37:09 with specs, blueprints and the product management team 17:37:14 i wish i could put more time into the training stuff 17:37:57 sam-i-am: i aim to get commitments from our respective companies to our cause 17:38:13 sam-i-am: for each cycle 17:38:44 i guess in a way i'm helping with the install guide 17:38:47 we will have a pm team midcycle like the operators midcycle to discuss release cycle progress 17:39:05 but i wish we could get more phil_h :) 17:39:13 and what the PMs are doing and/or could be doing to meet the project goals 17:39:40 back to our agenda 17:39:59 if we list out the work we want/need to get done for the kilo cycle 17:40:09 i can shop for help 17:40:37 if we get incubated, 17:40:47 i think we can give that responsibility to each sub-team lead to begin with? 17:40:53 sarob, I think we first need a contributor who will be working with us for more than a release cycle 17:40:54 it will help us get more help too 17:40:57 for the slides content 17:41:12 dbite: i agree 17:41:16 and then we can get more people volunteer in and not worry if they stick around for longer time 17:41:40 so, specs my friends 17:41:49 are our friends 17:42:01 it describes our plans 17:42:15 so we can claim success and 17:42:28 get more people aligned with our cause 17:43:09 can each of the sub-team leads write out at least two specs by the end of the week? 17:43:41 they need to be pushed up so we can read and comment 17:43:49 sarob: I don't think so. we have not yet decided on the things that are spec-worthy. 17:44:01 sarob, we need to burn down the list 17:44:10 which we did not finish at the last meeting 17:44:17 on the etherpad 17:45:16 dbite: you dont think the install guide integration is worthy of a spec? 17:45:33 sarob, I need a go forward from annegentle first 17:45:50 then I know where to push the basic install guide 17:46:04 and it is clear where and how exactly to write the spec 17:46:04 dbite: how are you planning on doing the integration? 17:46:20 first is the POC, which is in the reivew system as of now 17:46:34 https://review.openstack.org/#/c/134538/ 17:46:37 #link https://review.openstack.org/#/c/134538/ 17:46:58 once this is in and builds basic install guides, I show it to Anne and get her consent 17:47:02 then I push the spec 17:47:08 and integration starts :) 17:47:11 dude, its backwards 17:47:21 first spec for big changes 17:47:25 then patch 17:47:30 sarob, this is before the spec 17:47:33 or changes 17:47:44 if annegentle says no, then there is no integration 17:47:52 then we continue with our old ways 17:47:57 spec/bp is for discussing big changes 17:48:08 rluethi: dbite: but anne can block that in the spec/bp, can't she? 17:48:33 dbite: you need to discuss the change with annegentle and the rest of the docs team 17:48:35 matjazp: I suppose. spec in that case is just a proposal. 17:48:40 sarob, matjazp, I agree but this is what we agreed in the summit during the meeting with annegentle and ajaeger 17:48:44 dbite: the spec/bp is where you do that 17:49:06 sarob, the point is that I need to prove if the integration idea is even valid for a proposal 17:49:39 need some feedback and then know for sure what the proposal it is! 17:49:46 feedback from the manuals team 17:50:07 dbite: ugh, i guess proceed if annegentle asked for it this way 17:50:36 dbite: its going to be difficult for the rest of the docs team to understand what is happenning 17:50:53 dbite: and why 17:51:10 sarob, we already have a spec for basic install guides 17:51:18 this change is not a push for integration 17:51:48 sarob: I thought the idea was to have a POC first and if it proves to be doable, then ask for feedback. 17:51:52 since annegentle did not understand how it will work, she asked me to do a basic mockup and get more feed back 17:52:20 sarob, I am not against writing spec for it but the problem right now is if we need to spec 17:52:31 dbite: yeah, i remember 17:52:34 and where to put it, manuals, or training guides etc. 17:52:42 dbite: now 17:53:19 dbite: so will discuss the merits of the change in gerrit 17:53:46 yeah 17:54:39 rluethi: can you write up getting the build scripts to work with public infra? 17:55:12 matjazp: write up the moodle work as one or more specs 17:55:31 sarob:will do 17:55:34 sarob: can you elaborate what you mean? 17:55:46 sayali: specs on AV scripts, etc 17:56:16 rluethi: we need to get trainees using a cluster to learn 17:56:31 rluethi: either local laptop or remote public infra 17:56:32 sarob:cool, but without prior discussion with the team? 17:56:43 rluethi: dbite: I will give scripts to my students 17:56:53 matjazp, in that case we will fix it asap 17:56:58 matjazp, its a minor issue 17:57:03 sarob: you mean make the scripts work hosted on openstack? 17:57:07 sayali: we will discuss and debate over the specs themselves 17:57:09 not a major one, probably ubuntu updated something 17:57:19 sayali, discussion can happen over the review process 17:57:23 i think in that case i should make the video on how to use osbash soon too :) 17:57:25 sarob, we need to agree when to push the specs 17:57:28 dbite: ok 17:57:34 rluethi: i dont think so, 17:57:35 I suggest getting +1 from all the core team 17:57:39 cool sarob dbite 17:57:59 * rluethi is dense and will need some further explanation 17:58:09 rluethi: i think we need to build the images for use in public clouds 17:58:21 * dbite is more stupid for sure 17:58:31 rluethi: and figure out how the best way the trainers can prep for a class 17:59:00 rluethi: by either prepping the students to build the cluster on their laptop prior to class 17:59:19 rluethi: or by getting the public infra ready 17:59:23 times up 17:59:23 sarob: okay, I can think about that. do we have a template for training-guide specs? 17:59:26 rluethi: or both 17:59:43 matjazp: yup 17:59:46 rluethi: id use the docs one 17:59:53 sarob: k 18:00:40 #link https://github.com/openstack/docs-specs/blob/master/specs/template.rst 18:00:45 out of time 18:00:47 friends 18:00:53 see you on the ML 18:01:00 #endmeeting