14:00:02 <bcotton> #startmeeting Docs Project Meeting - Agenda: http://fedoraproject.org/wiki/Docs_Project_meetings
14:00:02 <zodbot> Meeting started Mon Jun  4 14:00:02 2012 UTC.  The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:16 <bcotton> #meetingname Fedora Docs
14:00:16 <zodbot> The meeting name has been set to 'fedora_docs'
14:00:22 <bcotton> #topic Roll Call
14:00:28 * zoglesby is here
14:00:33 * pkovar is here
14:00:35 * Sparks is here
14:00:39 * jjmcd 
14:00:51 * randomuser pours coffee
14:00:51 * _logan is here
14:01:44 * sgordon is here
14:02:09 * Sparks would like to talk about koji +publican
14:02:35 <bcotton> Sparks: i believe it's on the agenda
14:02:56 * claneys here
14:04:46 <bcotton> okay, let's get started
14:04:57 <bcotton> #topic Follow up on last week's action items
14:05:11 <bcotton> I did my to-dos. there were no other todos to be todone
14:05:21 <bcotton> #topic Docs Leader elections
14:05:26 * jhradilek is here, just missed the roll call.
14:05:34 <bcotton> welcome, jhradilek
14:05:55 <bcotton> #info Nobody stepped forward to take the Docs Leader crown. bcotton continues by default
14:06:24 <jjmcd> Perhaps we should establish a new position
14:06:29 <sgordon> all hail great leader
14:06:39 <jjmcd> Docs Leader for life
14:06:39 <bcotton> jjmcd: what new position is that?
14:06:45 * bcotton vetoes
14:06:48 <zoglesby> lol
14:06:59 <Sparks> jjmcd: +1
14:07:02 <jhradilek> jjmcd: Consider yourself nominated then. :P
14:07:18 <jjmcd> I gleefully decline
14:07:32 * Sparks is glad he retired from the position before "for life" was added
14:07:34 <jhradilek> bcotton: Can you veto that?
14:07:41 <zoglesby> Sparks: +1
14:07:57 <bcotton> Sparks: zoglesby: this isn't baseball. you can re-enter the lineup
14:08:23 <bcotton> #topic Using koji to publish docs.fp.o
14:08:28 <bcotton> grumble
14:08:34 <bcotton> #topic Using koji to publish docs.fp.o
14:08:47 <bcotton> Sparks: you wanted to talk, you're up first
14:08:52 <Sparks> Awesome
14:09:32 <Sparks> For those that don't know about the power of Publican, there is a build feature that will package our documents into SRPMs and submit them to koji for processing.
14:09:50 <Sparks> This would completely remove the web git repo from the loop.
14:10:10 <Sparks> No more huge repo to sync just to publish a small guide (or any guide)
14:10:16 <jjmcd> How would the SRPM get to docs.fp.o
14:10:20 <Sparks> You just package, push, and forget about it.
14:10:36 <Sparks> the backend process would do a yum update periodically
14:10:50 <jjmcd> Ahhhhh
14:10:57 * jhradilek can't wait to get rid of that 8GB repo he has on his hard drive.
14:11:13 <jjmcd> Where is nb on this?
14:11:28 <Sparks> This is, of course, my understanding of how the magic happens.  I've only peered inside the black box but a few times before going blind.
14:11:48 <jjmcd> Does publican package build all formats?
14:12:10 <Sparks> Rudi had asked for our own instance of koji since using the existing koji would require everyone to become a packager.
14:12:28 <Sparks> When I spoke to Infra about this they came up with a better solution:
14:12:53 <Sparks> We can use the existing koji but with different tags going to a different docs repo.
14:13:04 <jjmcd> Those rascals always do seem to have better ideas
14:13:12 <Sparks> This was all pre-F17... during the freeze.
14:13:17 <Sparks> jjmcd: Absolutely
14:13:43 * jjmcd would be real happy to not have to mess with that monster repo
14:13:53 <Sparks> Nothing has been implemented just yet but we need to file a request with Infra to make this happen.
14:13:59 <Sparks> EOF
14:14:40 <zoglesby> Sparks: so our workflow would be create the publican package, push to koji, sit back and wait?
14:14:52 <Sparks> zoglesby: Pretty much.
14:14:59 * zoglesby LOVES IT!
14:15:03 <Sparks> heh
14:15:10 <jjmcd> No messing with Bodhi?
14:15:19 <Sparks> Not that I'm aware
14:15:23 <jjmcd> cool
14:15:24 <Sparks> I think we'd bypass that
14:16:07 <Sparks> We'd be playing in our own little repo.  If something breaks then it's a bug and it wouldn't affect anyone other than our website.
14:17:03 <randomuser> there was a discussion at some point of providing packaged guides for the repos (maybe just me thinking out loud?)
14:17:04 <jjmcd> Could someone addrepo if they wanted, say, Russian docs on their local box?
14:17:35 <randomuser> is there a benefit to working that in now, while we're laying out procedures for packaging?
14:17:53 <Sparks> I think they would be able to do so, yes
14:18:29 <jjmcd> Of course, they would have to --nogpgcheck since it didn't go through Bodhi
14:18:49 <Sparks> I think we need to get Rudi involved before laying out procedures
14:19:04 <Sparks> jjmcd: The repo could be setup, by default, to not check GPG
14:19:24 <jjmcd> sounds risky
14:19:47 <Sparks> why?
14:19:59 <Sparks> This isn't the Fedora repo
14:20:30 <jjmcd> People could easily forget that it isn't signed.  Better for them to have to specify they are OK with it
14:21:16 <Sparks> Well, we can cross that bridge later.  I don't see much of a risk being that it is only for documentation and not software
14:21:23 <sgordon> <jjmcd> Does publican package build all formats? -> web format rpm is html,html-single,epub,pdf
14:21:31 <sgordon> the desktop rpm is just html-single
14:21:37 <jjmcd> Excellent
14:21:41 <sgordon> (the SRPM generates both)
14:22:35 <jhradilek> s/html-single/html-desktop/ ;)
14:25:02 <bcotton> so are we all agreed that it's worth getting the infrastructure set up?
14:25:23 <bcotton> is it possible to run a "test" site to make sure everything works before going live with docs.fp.o?
14:25:29 <Sparks> _1
14:25:31 <Sparks> +1
14:25:40 <Sparks> bcotton: I would think.
14:26:00 <Sparks> bcotton: Because this would be a change to our existing backend we'd need to setup a testbed.
14:26:54 <bcotton> Sparks: do you want to run point on this then?
14:27:31 <Sparks> bcotton: I can
14:28:23 <bcotton> #agreed We will test using koji to publish docs to the web
14:28:41 <bcotton> #info Sparks will be coordinating the effort
14:28:48 * Sparks will report back to the list on this
14:28:59 <bcotton> #action Sparks to eport back to the list on this
14:29:11 <bcotton> we'll just make this a recurring agenda item until it is settled?
14:29:25 <Sparks> ya
14:30:45 <bcotton> okay, anything else on this topic for now?
14:31:33 <Sparks> not from me
14:31:41 <bcotton> #topic QA recap
14:31:58 <bcotton> for those of you who forgot, we were going to try a more formalized QA procedure this release
14:32:06 <bcotton> #link https://fedoraproject.org/wiki/Docs_QA_Procedure
14:32:50 <bcotton> part of the procedure involved someone (designated to be me) to send weekly pokes to the docs-qa ML about tickets that were languishing in ON_QA status. i did not do this. mea culpa
14:33:22 <bcotton> i feel like the new procedure went rather unnoticed. who else has thoughts on this?
14:35:09 * Sparks had a few things go through QA for the security guide
14:35:36 <bcotton> Sparks: how did that make you feel?
14:36:33 <randomuser> I think that attaching the patch to the bug is an extra, unnecessary step; I haven't seen maintainers for any bugs that I follow do that with their work
14:36:56 <jjmcd> Made my life a lot easier on RNs
14:37:45 <Sparks> bcotton: Made me feel all warm and fuzzy inside
14:38:35 <pkovar> i don't think the new procedure works for every guide and maintainer
14:38:50 <pkovar> people tend to have different workflows, schedules, etc.
14:39:36 <pkovar> that's the same case as with the translation workflow, btw
14:39:52 <pkovar> so maybe it's too formalized?
14:40:07 <pkovar> i don't know, your thoughts?
14:40:57 * pkovar agrees with randomuser :-)
14:41:17 <bcotton> i think a consistent, formalized approach benefits people who work on multiple guides, either as a writer, QAer, or bug reporter
14:41:39 <bcotton> but we do have a problem of one size not fitting all, which is especially challenging on a volunteer project
14:41:58 <pkovar> agreed
14:42:34 <randomuser> my thoughts are the same as when it first came up; my workflow is either 1) checkout git repo -> fix -> push -> comment on bug or 2) checkout -> fix -> commit -> stash -> diff -> comment -> patch -> push
14:42:37 <Southern_Gentlem> pkovar,  if everything is consistant in the long run it makes it easier for people to learn
14:43:27 <pkovar> Southern_Gentlem:  it could be consistent, but maybe not that formal
14:46:05 <bcotton> i guess the next step is for people who have input to patch the procedure :-)
14:47:31 <zoglesby> I understand that this is not an easy thing to iron out, but we have never started the QA process becuase we get this far every time and then the edge case stops us
14:47:55 <bcotton> right. the idea for this release was to get _something_ in place that could serve as a starting point
14:48:15 <zoglesby> I think we need to understand that there are some exceptions, but for the most part X will be the process
14:49:13 <randomuser> I agree with the portion where one person commits a fix, and a qa contact reviews it
14:49:43 <pkovar> i think we need to identify guides for which this procedure actually worked, and then decide
14:49:48 <pkovar> what to do
14:50:34 <pkovar> was there any such guide?
14:51:59 <bcotton> i'm not sure how well the QA procedure was followed in the first place. certainly we don't have any audit to know how many bugs went through the procedure and how many didn't
14:52:09 <lnovich> my internet crashed and burned - now back via my cellphone can someone tell me what topic we are on?
14:52:27 <bcotton> lnovich: QA
14:52:32 <lnovich> thanks
14:53:01 <pkovar> bcotton: then maybe we should make sure that every bug is sent to docs-qa list (via CC)
14:53:23 <lnovich> isn't that automatic?
14:53:25 <bcotton> one idea that's kicking around in my head is having a designated ticket wrangler. someone to generally keep track of the BZ tickets
14:53:34 <pkovar> so that  we have enough data
14:53:45 <lnovich> makes sense
14:53:53 <bcotton> pkovar: i believe most components have been set up that way. that doesn't mean anyone acted on them. we'd still require a manual count to see what got QA'ed and what didn't
14:53:58 <lnovich> that person would have the birds eye view
14:54:27 <lnovich> and once permissions are granted getting statistics from bugzilla is not an issue
14:54:50 <randomuser> bcotton, do you envision that person doing the QA check, or just assignments/observations?
14:54:59 <bcotton> randomuser: maybe a little bit of both
14:55:08 * randomuser nods
14:55:17 <bcotton> randomuser: they wouldn't have to do *all* of QA, but they could at least make sure that someone did
14:55:39 <lnovich> so that person could generate a weekly ticket report so to speak?
14:55:52 <bcotton> sure, that's one option
14:55:53 <randomuser> i might be interested in such a role, bcotton
14:56:29 <bcotton> randomuser: okay, great. i'll start a wiki page to get ideas for what the role should do
14:56:30 <pkovar> bcotton: wasn't that the original QA proposal?
14:56:46 <bcotton> pkovar: kind of, yeah
14:56:52 <pkovar> ok
14:57:21 <bcotton> okay, we've only got about 2 minutes before we get kicked out. Anything else that needs to be discussed (we can continue QA discussion next week)?
14:57:56 <mprpic> I just wanted to note that I'll try and get the SELinux User Guide out for fedora 17 by July 1st
14:58:19 <mprpic> too busy with other stuff to give it a real update :(
14:58:22 <bcotton> mprpic: awesome. please let us know if you need any help moving it along
14:58:38 <bcotton> anything else?
14:58:40 <pkovar> thanks, mprpic :-)
14:58:43 <bcotton> going
14:58:48 <bcotton> going
14:58:54 * bcotton bangs gavel
14:58:56 <bcotton> #endmeeting