14:03:31 #startmeeting docteam 14:03:32 Meeting started Thu Feb 26 14:03:31 2015 UTC and is due to finish in 60 minutes. The chair is annegentle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:35 there we go 14:03:36 The meeting name has been set to 'docteam' 14:03:44 #topic Action items from last meeting 14:03:58 oh, its in here. 14:04:00 fancy 14:04:12 cool 14:04:40 welcome nickchase 14:04:45 the last meeting had 14:04:47 asettle to investigate arch guide as a project for a docs swarm 14:04:47 Morning, all. 14:04:56 she emailed me and I think it's a great idea, so sure! 14:05:19 She's also looking for a location for them to meet up informally on the other side of the world 14:05:38 and then someone from RedHat is booking a spot for their swarm Aug 13-14 14:05:58 from 2 weeks ago we had no action items 14:06:18 so, let's talk about review guidelines 14:06:22 #topic Review guidelines 14:06:43 anyone want to start or do you want me to do a recap? 14:06:52 I think a recap is probably in order. 14:07:18 Okay, how far back? We've had difficulties with people being frustrated with doc reviews for a while, going to Tom's ranty rant after the summit :) 14:07:38 Then last week nickchase also expressed frustration on the mailing list -- with nit picks mostly 14:07:55 the review guide on the wiki goes back pre-paris 14:08:14 Merged openstack/openstack-manuals: Fix accidental change in neutron id https://review.openstack.org/159302 14:08:18 ah yes Sam-I-Am 14:08:28 we had a discussion in Atlanta that resulted in the Wiki page at: 14:08:52 #link https://wiki.openstack.org/wiki/Documentation/ReviewGuidelines 14:09:01 it was intended to make the juno install guide go in nice and easy during the rush period 14:09:02 any other context or history 14:09:54 not as an excuse, just to set perspective: Compared to some integrated projects, it's very easy to get patches into the manuals 14:10:06 Both from the setup perspective as well as how we review stuff 14:10:11 yes I agree completely, and was wanting to bring that up as well 14:10:20 That's why we get many new folks - and some that only do a single patch 14:10:23 yeah we're easy :) 14:10:32 So, we help onboarding other contributors into OpenStack. 14:10:44 our timing is good, is our accuracy good? 14:10:52 That's one way of looking at it. :) 14:10:55 If they get scared by us, they wouldn't survive the integrated projects ;) 14:11:02 heh we're the nice ones 14:11:11 Still I would love to have them onboarded 14:11:21 Yes, you know, that's a great way to think about it. 14:11:27 a lot of people get their ATCs with docs 14:11:29 yeah there are definitely people with info in their heads that we need out of their heads 14:11:39 Sam-I-Am: really? I don't think it's statistically significant? 14:11:46 I'm not saying we can rest, I think we're all convinced that we can improve 14:11:55 agreed. 14:11:59 yes 14:12:04 annegentle: i know of a few 14:12:09 so what are some of the solutions? 14:12:34 we also have to balance whatever we do with the work it puts on us. 14:12:35 Maybe we should have a boilerplate email for first time contributors. When we do a review... 14:12:38 Sam-I-Am: it's less than 1% I'm sure of all ATC badges 14:12:42 we're probably the least-encumbered project. you can patch an isolated thing in docs and not go through a whole gating process. 14:12:43 nickchase, we have already 14:12:45 nickchase: we do 14:12:46 of their first patch, we should maybe send them an email that explains.... 14:12:56 what we're doing and why so they don't get freaked out. 14:13:17 I'm not familiar with this initial email. 14:13:18 there is one, but maybe it could use some updates 14:13:29 Everyone knowing it exists would be good. :) 14:13:46 AJaeger: do you know what manages it? 14:13:57 nickchase: I'll find one, we've had a lot of new contributors to api docs lately 14:14:07 Sam-I-Am, some infra magic 14:14:41 #link https://review.openstack.org/#/c/154484/ 14:15:03 nickchase: look at the "Welcome, new contributor!" line for the text 14:15:18 "don't be concerned if requested to make corrections" 14:15:30 "be paitent and be available" 14:15:35 yes, I was just looking. 14:15:46 I'm thinking there are definitely some things that could be added. 14:15:47 The text was written by Tom fifieldt 14:15:56 hola 14:15:59 It'S the same text for all projects 14:16:05 Hey, fifeldt 14:16:06 nickchase: yes, just grep for key phrases in the infra repos 14:16:08 aha. 14:16:10 hey fifieldt 14:16:31 yeah, me summoned fifieldt ;) 14:16:34 * fifieldt tries to catch up with scrollback 14:16:39 ok, so that answers my next question: is this for initial DOCS contributions or for their first contribution period. 14:16:51 nickchase, first contribution to openstack overall 14:16:55 everyone, all projects 14:17:12 OK, so what I was hoping for was something doc-specific. 14:17:24 nickchase: I'll fight you to keep it "just like code" 14:17:25 :) 14:17:35 nickchase: we really don't want to set up "other" or docs ghetto 14:17:38 annegentle: just a heads up, the bus internet is flaky :/ 14:17:47 nickchase: I feel so strongly about it that I can hardly type enough :) 14:18:04 Well, then I'll go back to my first thought: maybe we need an email that "mentors" can send to first time contributors. 14:18:12 Which is what I was thinking in the first place. 14:18:17 nickchase: I really like the mentoring idea 14:18:27 nickchase: it's more personal than a bot 14:18:33 btw, if you want a custom "Welcome, new Contributor" just for docs, we can probably do that 14:18:33 exactly 14:19:03 fifieldt: I'd block it, honestly. I feel very strongly that as we go to team's self service we need to not set apart docs from any other type of contribution. 14:19:13 works for me 14:19:19 do we want to reach out to people, or tell them to reach out to us if they want to contribute more? 14:19:22 I'm with annegentle 14:19:24 teams are going to get less and less support from us in the way of reviews anyway 14:19:34 Sayali Lunkad proposed openstack/training-guides: Modifies osbash files to use osbash ssh keys https://review.openstack.org/158668 14:19:50 but we do have to train reviewers of docs specifically 14:20:09 so I do think we should noodle on what a doc mentoring pairing would be like 14:20:31 I think the specialty teams are one way this is happening already, people are meeting each other due to common knowledge areas 14:20:34 onboarding for both contributions and reviews makes sense 14:20:44 there'Re some people that need mentoring - and some just grab it easily ;) 14:21:20 some of the discussion does have to lead to our own agreement on what we review -- content, conventions, technical accuracy 14:21:21 but even the later ones have questions... 14:21:28 agreed AJaeger 14:21:46 agreed 14:21:47 I also strongly feel that anything that leads to another doc bug being filed is broken. 14:22:00 we have way too many doc bugs and no clear assignees 14:22:02 disagreed :) 14:22:09 nickchase: I know :) 14:22:27 and prioritizing cleanup over content is also problematic for our end goal of providing accurate docs 14:22:58 I'll go back to my original assertion: if people with the skills for the hard stuff could leave the "monkey work" to someone else there would be fewer of the hard bugs you're worried about. 14:23:02 agreed. 14:23:09 what I see in the API docs is that the patch needs to be very clean because NO ONE will clean it up, two case in points that came up this week are the Firewall aaS and VPN aaS docs. 14:23:25 last updated in 2013, warned since last August they were going away, just yesterday noticed that they were gone. 14:23:33 I think WADL is quite a different beast to other docs 14:23:38 fifieldt: true that :) 14:23:47 agreed on that 14:24:03 We NEVER have a surfeit of low-hanging-fruit. 14:24:08 so nickchase I am interested in identifying ways to clean up 14:24:09 I believe most of what we're talking about here is not api site stuff 14:24:09 fifieldt, it's the extreme end but shows the problem 14:24:11 i suspect un-encumbered rst with an easier too chain will reduce some of the overhead for any kind of patch, even fix-ups 14:24:21 and, with the mentoring idea, we WILL need more low hanging fruit 14:24:30 yes. 14:24:35 Merged openstack/api-site: Fix a explain of "Create subnet" Remove following sentence. https://review.openstack.org/158160 14:24:41 yeah, setting up maven and getting docbook right is not that trivial 14:25:06 question is... does non-impactful edits need bugs? 14:25:28 Sam-I-Am, clear no from my perspective 14:25:28 from my perspective: no 14:25:35 at the moment we track quite a lot of these sorts of things with generic bugs 14:25:38 like one per book 14:25:47 yeah, or a bp/spec 14:25:59 Sam-I-Am, I mean: IF you notice something, no need to open a bug. 14:26:05 eg https://bugs.launchpad.net/openstack-manuals/+bug/1217503 14:26:06 Launchpad bug 1217503 in openstack-manuals "Apply document markup conventions to source XML files" [Wishlist,In progress] 14:26:13 is there a way to have low hanging fruit without bugs? 14:26:22 Another problem is if you know something is wrong and cannot fix it directly - how to record that? 14:26:27 the bug thing makes me worried 14:26:41 OK, hang on, I have a very basic question: 14:26:54 annegentle, we can always track it elsewhere - or as part of a single bug. 14:27:15 annegentle: maybe an ongoing low-hanging-fruit bug that keeps a list of particular places that need attention? 14:27:17 Call me crazy -- and I'm not suggesting that tracking as a single bug is a Bad Thing -- but why (aside from statistics) are more bugs so terrible? 14:27:24 "first time contributor bug" heh 14:27:44 nickchase: for a few reasons 14:27:55 1) projects will need to track their own doc bugs in the big tent 14:28:07 will they? 14:28:13 :) 14:28:18 2) bugs for "shared" project docs are already too high with over 500 14:28:42 3) more bugs means less trust of docs 14:28:51 fifieldt: it remains to be seen :) 14:28:57 3 is clearly moot - there are already more bugs in docs than neutron :) 14:29:02 most of our bugs are these docimpacts people throw over the fence 14:29:06 so since #1 is still debatable, that leaves #2 14:29:08 ha 14:29:20 what we need is more of those people contributing 14:29:28 and #2 can be combated by making a separate launchpad project or (laugh here) a special category on storyboard 14:29:33 Sam-I-Am: agreed 14:29:41 Sam-I-Am: right and the current mailing list discussion of rolling releases doesn't give me hope many will contribute :) 14:29:42 we're not here to understand the intricacies of all projects. we're here to make the docs usable. 14:29:58 Sam-I-Am: we can also debate "which docs" usable 14:30:13 Sam-I-Am: if we narrow the scope to only what we have now, what might change about our reviews? 14:30:18 * nickchase is feeling bad because after that whole "template" discussion we had in Atlanta he never got it done. 14:30:33 nickchase: no worries, someone else did it right? 14:30:35 nickchase: we all have our dumpster fires 14:30:44 so another idea 14:30:51 for each deliverable, have smaller review teams 14:30:53 annegentle: not that I know of 14:31:04 get rid of the central docs-core and have cores on individual books. Go. 14:31:25 how does that help, though? 14:31:33 better yet. -- only track bugs against one deliverable 14:31:40 does anyone feel like we're starting to mix issues here? "The Way Forward" Big thinking, with a current issue on review narkyness :) 14:31:42 annegentle, independed of this: let's cleanup docs-core of people that didn't review anything in the last 6 months. We have a few of these AFAIR 14:31:43 then we'll know which ones are the most "in trouble" 14:32:10 fifieldt: timecube :) 14:32:15 AJaeger: sure, and there are lots of people wanting to be core, but it might be easier for them to become core on a single book at a time 14:32:16 fifieldt: I don't think so 14:32:21 annegentle: books core = more formal version of the "specialty team"? 14:32:50 it's not a terrible idea 14:32:52 KLevenstein: right. The Security Guide team does this already, where only security team members can actually publish that book. 14:32:55 annegentle, we can only have cores per repository. 14:33:10 it's a handshake right now, as in, AJaeger and I "know" not to publish their book. 14:33:31 There's also a balancing act between "protection of publish rights" and "speed of change" 14:33:45 I'm not yet completely convinced that all the special teams do work great... 14:33:52 Each needs a driving force behind it 14:33:54 ok, so that I feel is off track. 14:33:57 :) 14:33:58 I think that it's part of what nickchase was struggling with though. 14:34:12 nickchase: you can't override a core's decision 14:34:23 or is it the "anyone's -1 blocking"? 14:34:24 i think each subteam will have their qualms for their specific document 14:34:37 theres general review guidelines, sure 14:34:41 It's the "anyone's -1 blocking". 14:34:50 many of the suggestions revolve around "don't block, fix" 14:35:01 and the only difficuly I had with one of the "fix" suggestions was log a bug. 14:35:04 that's true. 14:35:14 I guess I can relax a bit and know we'll always have more bugs than the team. 14:35:16 annegentle, I find it important that we have a shared team - overlapping - so that knowledge gets exchanged. Not every special team should reinvent their own conventions. 14:35:23 sometimes its easier just to slurp someone's patch and fix it rather than go through a bunch of -1s, especially for new contributors. 14:35:25 AJaeger: very true, that. 14:35:29 AJaeger, agreed 14:35:39 and we'll also still have our beloved common directory ;) 14:35:43 AJaeger: agreed 14:35:50 (know we, docs, will have more bugs than individual project teams) 14:36:00 question is... are the issues bad enough to keep it from being published. 14:36:04 and anybody can take the patch and fix it. So, if I do a -1 and don't have time to fix it, nickchase can fix the patch up properly. 14:36:20 If it's marked so I can FIND it, sure. 14:36:22 might be possible to partial-bug something that needs fixups rather than generating a new bug 14:36:29 then closes-bug once its fixed 14:36:31 one issue with fixing a patch for a newcomer is ensuring education about what they should do if they subsequently need to update it 14:36:37 otherwise it can be confusing as hell 14:36:37 Are we in a hurry to publish patches? 14:36:49 so probably worth getting some generic text in order for that 14:36:54 to explain what we've done and why 14:36:59 and how to update their own repo 14:36:59 OK, so I think fifieldt hits on where we started: communication. 14:37:14 fifieldt, exactly: So, what I do sometimes: Do a proper review and then mark it as WIP with a note "Let me fix this for you...." 14:37:24 fifieldt: are you talking about cherrypicking, or simply pulling in updates to re-edit files? 14:37:35 Right. If you tell someone to update their patch, in general, unless they're really experienced, you will get a blank stare. 14:37:43 sld: review -d 89789078907; git commit -a; git review 14:37:54 ah 14:37:58 I think fifieldt is saying that we should tell them how to fix their patch, we should help them doing the second iteration of it 14:38:06 +1 14:38:07 no 14:38:16 what I'm saying is if we are fixing their patch 14:38:22 we need to explain the process we're taking 14:38:26 Ah... 14:38:29 +1 on that too. :) 14:38:33 lol 14:38:43 explaining is +++ 14:38:45 I think either way it's better than what we have now. 14:38:56 #link https://wiki.openstack.org/wiki/Documentation/HowTo#How_to_amend_a_review-in-progress 14:39:02 just looking for some text that says "hey, there's this stupid thing. I'm going to fix it for you quickly so you don't have to waste your time. This is going to break your local repo, so do this: btw this is what I did" 14:39:06 I've started pasting that into the review when it needs patching 14:39:18 fifieldt: awesome idea 14:39:32 I'll add to it what to do when someone else patches your patch 14:39:38 nickchase, I think you're only seeing a few bad examples, there's a lot of good work already happening 14:39:40 and especially fifieldt'S communication is great 14:39:57 https://etherpad.openstack.org/p/docs-fixed-it-for-you <-- anyone care to edit 14:40:00 AJaeger: I'm glad, but if people don't know that we have a problem. 14:40:34 So ok, let me recap for a moment, if that's OK... 14:41:20 We agree that we need to do something, and communication seems to be the best answer. We are crafting a "standard" message that we can give to newbies when we fix their stuff https://etherpad.openstack.org/p/docs-fixed-it-for-you with the idea that ... 14:41:44 the idea that we communicate "this is how we work, welcome!" 14:41:50 it will get things in quickly, not frustrate people, and not tick them off or make them feel stepped on, while still educating them on what it is that they can do better next time. 14:42:01 yes, education is key 14:42:11 so, when do we fix and when do we just comment? 14:42:24 one of the things we discussed was how docs makes things look pretty after the actual meat is done. so editing other people's patches should be weird. 14:42:28 I think that's a judgement call on the revieiwer. 14:42:35 I think a rule of thumb would be if it'S less than 3 edits, fix yourself, if it's more than 10 - let the author do it... 14:42:39 someone does the hard work of configuring X thing, and we make it pretty. 14:43:01 And there's definite value in that. 14:43:02 Sam-I-Am: WE DO NOT MAKE IT PRETTY NEVER SAY THAT IN MY PRESENSE AGAIN 14:43:14 dead serious 14:43:15 Are you objecting to ... 14:43:18 Sam-I-Am, yes, we can do this as well - but that's something we should *arrange* and communicate before 14:43:24 the notion that we clean things up, or the word "pretty"? 14:43:33 we make things consistent and more readable, therefore more usable 14:43:36 (also dead serious) 14:43:42 Ah, so "pretty". 14:44:00 notion that we know our nitpicky conventions that keep everything presentable and sane 14:44:03 it might be a "girl" thing but that is the fast track to the docs ghetto. 14:44:27 we know how to make the contribution fit with the rest of the docs, which naturally we are more accustomed to and familiar with 14:44:31 * Sam-I-Am transfer to phoneirc 14:44:38 annegentle: fwiw agreed, "pretty" does can an implication of "looks nice, not much there" 14:45:14 right. 14:45:21 *can have an; valkyrie needs coffee 14:45:25 annegentle: maybe I'm the weird one, I just think "pretty" in the context of "pretty-print". But that's probably just me. Connotations acknowledged. 14:45:32 heh 14:45:49 OK, so let me go back for a moment... 14:45:55 text @ https://etherpad.openstack.org/p/docs-fixed-it-for-you is a little less informal now for y'all if desired 14:46:03 to "we make things consistent and more readable, therefore more usable" ... 14:46:10 Are you referring to conventions here? 14:46:19 nickchase: yes 14:46:31 nickchase: also better writing, less meandering is easier to read 14:47:10 So you're saying there that WE handle the conventions. 14:47:19 Which is different from making the author handle the conventions. 14:47:28 Also that we fix the "writing" 14:47:39 which is useful when we are trying to get information out of engineer brains. 14:47:44 Which brings me back to... 14:47:55 in other words, if someone docs a new swift feature, no one here really know the internals of swift, but we can make it conform and presentable like the other docs 14:47:59 nickchase: sometimes. it's a judgement call, which is why I'd like us to train more people on good judgement. 14:48:18 my original assertion: that we should let them focus on the stuff that's only in their brains. 14:48:21 with rst i think well get a lot more "engineer" contribs 14:48:36 I agree, which is why it's REALLY important that... 14:48:37 Sam-I-Am: that's the hope, and swift already does all their docs in rst really 14:48:48 we use this opportunity to encourage those people and not drive them away. 14:48:49 nickchase, we can do this in special cases - but not for each and every patch 14:48:55 but with RST we will still have markup conventions 14:49:09 swift was a bad example 14:49:24 i hope our rst isnt as cumbersome 14:49:25 bottom line: we want every review on every patch to be encouraging that patch submitted to become the #1 docs contributor 14:49:34 rst is designed to be light 14:49:38 s/submitted/submitter/ 14:50:04 fifieldt: i like that ideology / concept. :) 14:50:09 fifieldt: it sounds sappy, but, well, yeah. 14:50:12 the more someone is encouraged, the more they contribute. 14:50:35 the more they dont have to waste time on nits 14:50:38 I have a suggestion: 14:50:43 what about an easy and light step-by-step guide "how to commit to openstack documentation in 10 minutes"? At the moment we link to https://wiki.openstack.org/wiki/Documentation/HowTo on http://docs.openstack.org/. This is a complex and long document and as a first time contributor I do not know if i have to read the whole document, what are the relevant parts, and so on. 14:50:57 berendt: it is long, isn't it? 14:51:00 https://wiki.openstack.org/wiki/Documentation/HowTo/FirstTimers 14:51:04 something like that? 14:51:09 yeah 14:51:10 Unfortunately, there are a LOT of steps that are actually necessary. 14:51:14 but 14:51:14 berendt: our conventions are a mile long too 14:51:23 There's also http://docs.openstack.org/infra/manual/ 14:51:33 random idea: 14:51:42 hmm 14:51:43 maybe not 14:51:44 not doc specific - but the new generic information for OpenStack contribution 14:52:18 OK, I have a potential compromise: 14:52:54 We want people to not be frustrated or bogged down, but we don't want a preponderance of new bugs. One way to do that would be ... 14:53:04 I think there should be a light document for a first time contributor making it really easy to push a first commit. I do not think that any new contributor reads the linked document before the first commit. 14:53:37 If we institute a policy that if you see something simple, it's OK to just fix it with the text in https://etherpad.openstack.org/p/docs-fixed-it-for-you . If it's more complicated.... 14:53:45 During reviews, I often link to special sections of the conventions 14:54:06 AJaeger: +1 - it's been immensely helpful, too. :) 14:54:12 AJaeger: me too 14:54:24 nickchase: yep, I think that's the way. 14:54:36 then we tell the author that this is what it needs, but if they are willing to file a new bug and paste the URL in the comments, then we can close this one. (I'm assuming these are non-impactful) bugs. The hassle of filing a new bug... 14:54:45 and I even got this week a comment: I would have loved to know about the markup conventions before I did my first patch.. 14:55:07 AJaeger: yeah! from Robin I think? 14:55:12 will discourage most people and encourage them to do the right thing and just do the fix, but in extreme cases we will have a smaller number of new bugs that a first-timer can patch. 14:55:26 great summary 14:55:27 Would that be OK? 14:55:31 so, in fact—I wrote a lightweight “how to contribute to openstack” doc for my team at rackspace to try and simplify what’s at the main page. would be happy to share it. 14:55:36 annegentle, don't remember who it was 14:55:44 KLevenstein: cool 14:55:48 KLevenstein: great 14:55:50 KLevenstein: cool 14:55:58 sorry we'd better get to the other topics! 14:56:00 KLevenstein: definitely 14:56:05 I don’t know how much simpler it actually is, but. 14:56:07 OK, so do we agree on this, then? 14:56:17 KLevenstein, let's share and look 14:56:17 Yes. 14:56:18 Merged openstack/openstack-manuals: Update CLI reference for python-openstackclient 1.0.2 https://review.openstack.org/159452 14:56:21 EXCELLENT. 14:56:42 #agreed institute a policy that if you see something simple, it's OK to just fix it with the text in https://etherpad.openstack.org/p/docs-fixed-it-for-you 14:56:45 rst toolchain should make it lighter 14:57:09 KLevenstein: do you want an action item to share that? 14:57:18 annegentle: sure 14:57:34 #action KLevenstein to share a lightweight “how to contribute to openstack” doc 14:57:38 Okay 14:58:04 not sure I need another agreed statement on the more complex policies? 14:58:07 Something like 14:58:24 Merged openstack/openstack-manuals: Update CLI reference for python-cinderclient 1.1.1 https://review.openstack.org/159435 14:58:38 #agreed for balancing a contributor's frustration level with publishing ease, please use good judgement and seek out guidance 14:58:59 Okay better get to User Guides new specialty team 14:59:03 annegentle: sorry to be nitpicky, but I don't see the part about enabling a person to get a bug closed by filing a new one if they're motivated to do that. 14:59:11 #topic User Guides new specialty team 14:59:15 If that's implicit, fine. 14:59:25 nickchase: that was complex to me :) 14:59:46 nickchase: and a judgement call 14:59:59 ok, let's move on. I'll post a proposed statement to the list. 15:00:03 ok thanks 15:00:19 taroth: thanks for joining us, sorry we didn't get to the User Guide for long 15:00:26 annegentle: np 15:00:34 taroth: and I do owe you an email back on your excellent questions about the user guide and admin guide 15:00:40 also 15:00:48 #topic Installation Guides split for Kilo 15:00:54 we no longer publish install guides to /trunk/ 15:01:04 and it is open to kilo now, right Sam-I-Am? 15:01:16 heh no one else has to use this meeting room bwah hah ha 15:01:18 annegentle, did you remove /trunk/install-guides and /trunk/training-guides as well? 15:01:30 :) 15:01:32 we should announce that it's open 15:02:04 AJaeger: remove = .htaccess or actual filesystem file removal .. or both? 15:02:18 err .htaccess redirects 15:02:21 AJaeger: oh I can do that today since I'm home 15:02:33 sld, rm -rf docs.openstack.org/trunk/{install-guide,training-guides} - and add proper redirects 15:02:39 ah 15:02:41 the magical password that only exists on Anne's PC at home :D 15:02:50 fifieldt: actually it's about the network 15:02:53 fifieldt, the one she wanted to share? ;) 15:02:56 oh, right, I see :) 15:03:07 I'm just having vague recollections 15:03:12 fifieldt: I sorted the other by phoning infra :) 15:03:13 of amusement 15:03:22 Who you gonna call :) 15:03:27 ghostbusters! 15:03:36 annegentle: that's my line! lol 15:03:50 sld, that was the password ;) 15:03:51 :) 15:03:53 Okay, I did want to bring up https://review.openstack.org/#/c/157303/ since there's a concern this merged too fast 15:04:06 it wasn't tested, and doesn't tell the user to change the API version 15:04:31 it's fairly safe since it's not published, though, but, this is where "it's a judgement call" comes in -- did anyone log a bug about it? 15:04:43 Sam-I-Am: you noticed it, can you log a bug for investigation? 15:05:01 is trunk still broken for cinderclient, Sam-I-Am? 15:05:21 he's on his phone so might have difficulty, I'll follow up and let us end the meeting! 15:05:34 thanks everyone! 15:05:37 can we talk about the driver docs spec? 15:05:39 https://review.openstack.org/#/c/133372/ 15:05:39 The doc tools update is on the mailing list too, so that's all for now 15:05:48 AJaeger: oh yes. What are your thoughts now? 15:06:01 * AJaeger likes to hand over the spec to somebody else... 15:06:26 Merged openstack/openstack-manuals: Update CLI reference for python-ceilometerclient 1.0.13 https://review.openstack.org/159434 15:06:29 fifieldt raised a point during review that we might have good documentation that won't be that easy to move to vendor docs. 15:06:57 I am frankly surprised at how little vendor doc there is on _their_ sites 15:07:03 it's like we made TOO good a docs site. ha. 15:07:06 I was thinking whether we should make "maintenance" of the doc a requirement 15:07:19