14:00:22 <bcotton> #startmeeting Docs Project Meeting - Agenda: http://fedoraproject.org/wiki/Docs_Project_meetings
14:00:22 <zodbot> Meeting started Mon Dec 19 14:00:22 2011 UTC.  The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:27 <bcotton> #meetingname Fedora Docs
14:00:27 <zodbot> The meeting name has been set to 'fedora_docs'
14:00:33 <bcotton> #topic Roll Call
14:00:59 <pkovar> I'm here
14:01:00 * jsmith is fairly busy this morning, but will try to lurk
14:01:04 * Sparks 
14:01:09 * randomuser .
14:01:37 * jjmcd 
14:02:21 <suehle> here
14:02:27 <Sparks> WOOT!
14:02:36 <bcotton> suehle: with food?
14:02:57 <suehle> I worked from home today, but I can make you some toast. Perhaps a waffle.
14:03:16 <bcotton> acceptable
14:03:24 <bcotton> any one else wandering into the room?
14:03:47 * Sparks is making cheese biscuits
14:05:02 <bcotton> okay, let's do our thing
14:05:04 <bcotton> #topic Follow up on last week's action items
14:05:35 <bcotton> my items are all checked off. i don't see a jhradilek so i guess we'll just carry that one forward
14:05:56 <bcotton> actually, let's push that off to later down the meeting
14:06:02 <bcotton> #topic FUDcon Blacksburg
14:06:02 * LoKoMurdoK here
14:06:09 <bcotton> #link http://fedoraproject.org/wiki/FUDCon:Blacksburg_2012
14:06:20 <bcotton> #info Docs is sponsoring two classes at FUDCon Blacksburg: Introduction to Docs and DocBookXML/Publican
14:06:24 <bcotton> (welcome LoKoMurdoK)
14:06:53 <bcotton> anyone have things to say about Blacksburg?
14:07:09 <Sparks> .
14:07:18 <bcotton> Sparks: go
14:07:18 <Sparks> Be there or be square.
14:07:24 <Sparks> That is all... carry on.
14:07:26 <jsmith> And come prepared to work!
14:07:49 <Sparks> Well, those aren't for the classes.
14:08:00 <Sparks> I guess we *are* going to have a hacker-thon?
14:08:00 <jsmith> Can I get a volunteer to blog about the Docs events at FUDCon?
14:08:08 <jsmith> Sparks: I hope so, yes :-)
14:08:09 <Sparks> jsmith: I can do that.
14:08:30 <bcotton> #agreed Sparks will blog about Docs events at FUDCon Blacksburg
14:08:59 <Sparks> That's not to say that others *shouldn't* blog about the events.
14:10:50 <bcotton> anything else re: FUDCon?
14:11:38 <bcotton> #topic Docs QA
14:11:50 <bcotton> #link https://fedoraproject.org/wiki/Docs_QA_Procedure
14:12:02 <bcotton> i've seen precious little commentary on the mailing list
14:12:13 <bcotton> who has thoughts to add?
14:12:53 <pkovar> will try to add some thoughts to that
14:13:09 <randomuser> is 'Docs QA' a specific role/person, or is the idea just to get the fix confirmed by any second party?
14:13:37 <Sparks> I believe someone added an *alternative* path on the wiki page
14:13:39 <bcotton> randomuser: it's a procedure for us to apply collectively for all bugs
14:14:06 <bcotton> ah yes, crantila added an alternate, let me read that
14:14:32 <randomuser> bcotton, i mean as quoted from the procedure 'Docs QA sets ticket as "VERIFIED" '
14:14:59 <bcotton> randomuser: ah okay. it means the QA person for that particular component. we'll have to tidy the language a bit
14:15:25 <randomuser> so, an assigned role specific to the component
14:15:27 <randomuser> ok
14:16:36 <pkovar> looking at the QA contacts list at bugzilla...
14:16:58 <pkovar> it seems like the majority of contacts are merely outdated
14:17:30 <bcotton> yeah, we'll have to update both guide owners and QAs before we get too far along into the Beefy Miracle process
14:17:40 <Sparks> We can change those QA contacts to the Docs-QA list and then let someone go up and take the ticket when they have a chance.
14:17:45 <pkovar> maybe we should first focus on getting the qa people together and then move to a new workflow?
14:18:00 <bcotton> Sparks: that might work better than having a single person
14:18:17 <Sparks> pkovar: I think we have people.  But they've been standing around for so long waiting for a procedure that they may have gone elsewhere.
14:18:29 <Sparks> bcotton: Want me to take that for action?
14:18:47 <bcotton> Sparks: what's the action, specifically?
14:18:49 <bcotton> #chair sparks
14:18:49 <zodbot> Current chairs: bcotton sparks
14:19:05 <pkovar> maybe, but if we don't have them, the bugs will rot in the bugzilla forever with the proposed workflow
14:19:10 <Sparks> To change the QA assignee in BZ from an individual to the docs-qa list.
14:19:17 <pkovar> that's my concern, anyway
14:19:19 <Sparks> pkovar: Too late...
14:19:24 * sgordon rubs his eyes
14:19:26 <bcotton> #action Sparks To change the QA assignee in BZ from an individual to the docs-qa list.
14:19:40 <bcotton> pkovar: i'd argue that's the current state anyway
14:20:11 <pkovar> with the current situation, owners don't have to wait for QA to confirm and go ahead
14:20:15 <Sparks> I think it would be nice to have the nag feature turned on in BZ...
14:20:24 <jjmcd> Is it really good to have NO responsibility?
14:20:53 <bcotton> pkovar: we can include a timeout for QA
14:20:59 <bcotton> Sparks: is that an option?
14:21:03 <Sparks> bcotton: I was just going to say that.
14:21:06 <bcotton> jjmcd: what do you mean?
14:21:27 <jjmcd> Asigning the qa contact to a ML means nobody has responsibility to review the bug
14:21:40 <jjmcd> eventually it will quit working
14:21:45 <bcotton> #action bcotton to add timeouts and definitions to qa procedure
14:21:46 <Sparks> That only means EVERYONE has responsibility.
14:22:00 <jjmcd> Yeah - a committee - and we know how well that works
14:22:03 <bcotton> i see what jjmcd says though.  if everyone has responsibility, no one does :-)
14:22:04 <Sparks> It's a visability issue, IMO.  If we set the QA to a single person then others don't know about the need.
14:22:25 <pkovar> not sure if the timeouts are technically possible in bugzilla though
14:22:30 <jjmcd> Don't we all see all the bugs?
14:22:38 <Sparks> No
14:22:47 <Sparks> They don't get delivered to our inboxes.
14:23:16 <Sparks> pkovar: These aren't hard and fast timeouts but rather workflow timeouts.
14:23:27 <suehle|afk> nick suehle
14:23:38 <bcotton> no, ruth suehle
14:23:44 <jjmcd> Almost seems like we need a bug shepherd
14:23:51 <Sparks> You'd think she'd know her name by now.
14:23:57 <bcotton> jjmcd: yeah, a nagbot
14:24:00 <Sparks> jjmcd: I agree.
14:24:13 <bcotton> jjmcd: i propose the docs leader take that role
14:24:16 <bcotton> crap
14:24:25 <Sparks> BZ has the ability to nag people of open tickets on a weekly basis but it's not activated in this instance.
14:24:27 <jjmcd> sounds good to me
14:24:53 <suehle> is the middle ground 2-3 people with responsibility?
14:25:12 <bcotton> suehle: it is, but that's more difficult to manage and rebalance as people come and go
14:25:53 <suehle> could it work as a rotating job? where those 3 ppl each go a week at a time?
14:26:34 <bcotton> that sounds like a lot of manual effort
14:27:09 <Sparks> Sending the messages to the QA list means that anyone can grab the ring and run with it.
14:27:10 <pkovar> just to make sure i'm not missing people, are we talking about 3 qa people in total for all our guides, or 3 people  for each of the guide?
14:27:46 <pkovar> *missing anything
14:27:48 <bcotton> as a first step, how about we use the QA ML with me as a nagbot. we can revisit in a few months to see if we need to change things?
14:28:57 <randomuser> would it be valid to file a bug against a component to fix an unresponsive qa contact?
14:29:14 <pkovar> you mean like periodically nagging people around?
14:30:11 <bcotton> pkovar: yeah, since we don't have BZ's nag feature turned on, i'll be a wetware implementation of it
14:30:36 <pkovar> uhm, that looks like a lot of work though
14:31:29 <bcotton> pkovar: possibly. some of it can be done through automated BZ queries
14:31:33 <pkovar> thing of number of bugs for our fast developing, large guides, like SAG
14:31:34 <Sparks> You can probably script most of it.
14:31:42 <pkovar> *think, sorry
14:31:58 <Sparks> I'd guess you could replace bcotton with several cron job scripts with similar effectiveness.
14:32:01 * Sparks ducks
14:33:01 <bcotton> so in the interests of iterative development, can we start out this way and fix whatever we find broken?
14:33:16 <pkovar> so do we know the number of our current QA volunteers?
14:33:22 <Sparks> bcotton: Doing something is better than doing nothing.
14:33:30 <pkovar> 3, 5, 8 people?
14:34:04 <Sparks> pkovar: Like I said earlier, we had people but they probably went away as we never got the workflow in place.  We might need to go find new/more people now.
14:34:16 <fnadge> I'd volunteer, who else?
14:34:44 <bcotton> #action Sparks to add bcotton to the docs-qa admin list, send password
14:35:05 <bcotton> #action bcotton to advertise docs-qa list to docs list
14:35:28 <bcotton> #action bcotton to tidy language of QA process and add timeouts
14:35:56 <bcotton> is it safe to move on to the next topic?
14:36:07 <Sparks> .
14:36:15 <bcotton> go ahead Sparks
14:36:46 <Sparks> I've added docs-qa@lists.fp.o to most guides.  These guides were the ones where there wasn't a QA assignee.  The guides with an assignee I left in place for now.
14:36:51 <sgordon> scrolling up a bit here
14:36:56 <sgordon> but as far as a nagbot
14:37:07 <sgordon> internally for our bugs/tickets we do a weekly report
14:37:24 <sgordon> listing bug owner and number of new/assigned tickets
14:37:39 <Sparks> #info I've added docs-qa@lists.fp.o to most guides.  These guides were the ones where there wasn't a QA assignee.  The guides with an assignee I left in place for now.
14:38:10 <Sparks> sgordon: My problem is that I just plain forget about the bugs I have assigned to me since this isn't my primary job...
14:38:16 <sgordon> yeah
14:38:29 <sgordon> well likewise, i mean i am in BZ all day for $DAYJOB but that doesnt mean im looking at these
14:39:51 <Sparks> EOF
14:40:06 <bcotton> okay, let's move on, because the next topic might be discussiontastic, too
14:40:18 <bcotton> #topic Guide Status
14:40:35 <bcotton> subtopic: do we want to retire the Installation Quick Start Guide (IQSG)?
14:40:56 <Sparks> -1
14:41:14 <bcotton> Sparks: why?
14:42:11 <Sparks> We moved documentation like this *from* the wiki so people could download it for offline viewing.  If there are updates that need to happen they can be worked on the wiki and then fixed in the formal guide.
14:42:21 <Sparks> IMO, we really shouldn't have formal documentation on the wiki.
14:42:39 <randomuser> +1
14:42:40 <sgordon> i will +1 that
14:42:53 <sgordon> wiki is a good way for people to have a low barrier to entry for providing snippets of content
14:43:02 <sgordon> but we need to marshal that into the books for formal use
14:43:28 <bcotton> so would it be reasonable to consider the quick install wiki page an upstream for the IQSG?
14:43:42 <Sparks> I would say so.
14:43:59 <Sparks> Label the page as draft and hack on it.
14:44:27 <sgordon> have we got a link for that to throw in the minutes?
14:44:31 <bcotton> my main concern is that the gent who wrote that page insists on keeping it and thus we have the possibility of conflicting or confusing information between the two
14:44:36 <bcotton> #link https://fedoraproject.org/wiki/Fedora_Quick_Install_Guide
14:44:50 <Sparks> I'll happily update snippets or, better yet, help the hacker learn how to update the formal documenation.  I'd bet that jsmith would as well (as time allows).
14:45:18 <sgordon> i see bcotton, really i think we should be cleaning the page out as we move bits into the guide
14:45:26 <Sparks> bcotton: It's not really up to him.  He can keep it in his namespace or on his own website but we have a workflow.
14:45:50 * Sparks doesn't mean to sound like a hard nose here.
14:45:58 <bcotton> Sparks: true, but we can't just lock him out of the wiki, so it behooves us to play as nicely as we can
14:46:16 <bcotton> or we can let jsmith wield his FPL club, but that's above my pay grade
14:46:27 <Sparks> Oh, I don't mean to do that.  I just mean we can take his text and move it into the guide.
14:46:41 <jjmcd> So, why arent we training him in publican?
14:46:54 <pkovar> if you step in, that's great
14:46:59 <pkovar> :-)
14:47:06 <Sparks> Once he has contributed his text to the wiki he has licensed it to us to do things like move it into DocBook and publish.
14:47:14 <Sparks> jjmcd: +1
14:48:09 <Sparks> It comes down to one basic principle: People need a one stop shopping experience when looking for documentation.  We've said that the place to go is docs.fp.o.
14:48:36 <jjmcd> Not like we shouldn't use content from folks who aren't comfortable with the whole docs process, but lets not make it look like the "elite" vet stuff.  Looks like us-tnem
14:48:47 <pkovar> unfortunately, it's not the case with many fedora docs
14:49:02 <pkovar> and we can't do much about that either
14:49:15 <Sparks> pkovar: Can't do much about what?
14:49:16 <pkovar> unless we have tens of contributors
14:49:25 <pkovar> manpower
14:49:45 <pkovar> look at packaging guidelines, or licensing
14:49:51 <Sparks> We've had manpower.  We just need to rally the troops, IMO.
14:49:55 <pkovar> it's all kept on the wiki
14:50:30 <Sparks> Hardly anything is on the wiki now
14:50:55 <pkovar> i see many people with a strong wiki preference in the community
14:50:55 <Sparks> We spent hundreds of man hours collecting stuff off of the wiki and turning it into DocBook for just the purpose I mentioned before.
14:50:57 <jjmcd> pkovar, on the wiki it may as well be buried under the ocean - you just can't find it
14:51:38 <pkovar> as i said, look at the guidelines for packagers or licensing...
14:51:53 <sgordon> i would argue there is an obvious difference in audience there
14:51:57 <pkovar> they are not going to convert it to docbook
14:52:02 <sgordon> documentation for contributors vs documentation for users
14:52:15 <Sparks> pkovar: Those aren't for end-users.  Big difference.
14:52:39 <pkovar> sgordon: but we try to satisfy both audiences on docs.fp.org
14:52:51 <Sparks> pkovar: We're specifically talking about end-user documentation that comes from the Docs project.  We are not talking about documentation that comes from other projects.
14:53:06 <sgordon> personally i would also argue it would ultimately be good if the packaging guidelines actually were in docbook, but thats not a battle i would be going into with them in their current state on the wiki
14:53:23 <pkovar> me neither :-)
14:53:49 <pkovar> we have fedora contributors docs on docs.fp.o...
14:53:53 <bcotton> so it seems to me that using the wiki as upstream for the IQSG keeps everyone happy-ish?
14:54:00 * Sparks notes we've started putting other guides on docs.fp.o that aren't specifically end-user (elections guide, CSI, etc)
14:54:15 <pkovar> right... ;-)
14:54:22 <Sparks> bcotton: That's the way it was designed to work.
14:54:45 <bcotton> #agreed we will use the "Fedora Quick Install Guide" as upstream for the IQSG
14:54:49 <jjmcd> Perhaps
14:55:08 <jjmcd> What if we had some naming convention for the upstream for every guide
14:55:15 <jjmcd> the release notes beats works well
14:55:33 <jjmcd> We collect content on the wiki then clean it out when converted to docbook
14:55:44 <Sparks> jjmcd: Perfect example
14:55:53 <jjmcd> But we have defined names so people can find it
14:55:55 <bcotton> i think that's the way to go then
14:56:02 <pkovar> good idea, but i guess you need to discuss it with the wiki author first
14:56:16 <jjmcd> pkovar, yes, of course
14:56:40 <jjmcd> But if we had some sort of convention, or even an index page
14:56:43 <sgordon> certainly it would be nice to have some idea of a naming standard/convention
14:56:47 <sgordon> that authors could opt into
14:56:47 <bcotton> jjmcd: i think we should wait until after the next release to pursue that. actually getting the IQSG would give us some leverage
14:57:07 <jjmcd> Yes, a model we could start with
14:57:13 <bcotton> part of the reason the wiki page was made was the fact that we've failed to get the IQSG out the door the past two releases
14:57:14 <sgordon> :)
14:57:35 <Sparks> Category:Draft Documentation
14:58:00 <randomuser> Sparks, +1
14:58:07 <pkovar> yes, that's what i added so it is categorized
14:58:08 <jjmcd> That currently has a lot of cruft, doesn't it?
14:58:16 <jjmcd> Not that it couldn't be cleaned up
14:58:37 <bcotton> maybe that should be our next party
14:59:02 * pkovar agrees
14:59:07 <bcotton> but we're at the end of the hour, so i'd like to open the floor up quickly
14:59:15 <Sparks> jjmcd: I'm sure it's full of *stuff* and in desperate need of being cleaned.
14:59:28 <Sparks> .
14:59:38 <bcotton> #topic Open Floor Discussion
14:59:46 <bcotton> sparks, did you have something?
14:59:50 <Sparks> #idea We clean out Category:Draft Documentation at FUDcon Blacksburg
15:00:02 <bcotton> +1
15:01:48 <bcotton> okay, so the next meeting is the day after Christmas. I'll be around, will there be people to meet with?
15:02:32 <Sparks> bcotton: I may be driving...
15:03:07 * Sparks notes that RH will be closed and we might get some help from those usually busy folks.  Virtual hack-a-thon?
15:03:28 <bcotton> that might be fun
15:03:35 <pkovar> unfortunately no
15:03:38 <Sparks> We did it a couple years ago.
15:03:56 <pkovar> vacation :-)
15:04:23 <bcotton> pkovar: vacation denied
15:04:28 <pkovar> heh
15:04:58 <bcotton> okay, well i guess i'd better start doing things for $dayjob before people get sad
15:05:43 <bcotton> thanks everyone, and joyous $seasonal_celebration to all
15:05:46 <bcotton> #endmeeting