14:00:11 <bcotton> #startmeeting Docs Project Meeting - Agenda: http://fedoraproject.org/wiki/Docs_Project_meetings
14:00:11 <zodbot> Meeting started Mon Jul  9 14:00:11 2012 UTC.  The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:20 <bcotton> #meetingname Fedora Docs
14:00:20 <zodbot> The meeting name has been set to 'fedora_docs'
14:00:26 <bcotton> #topic Roll Call
14:01:10 * steveg_afk 
14:02:15 * jjmcd 
14:02:16 * randomuser pours coffee
14:02:34 <bcotton> randomuser: i hope you brought enough for everyone. or at least your dear leader
14:03:07 <randomuser> of course I'll share, as best I can
14:03:30 * randomuser splashes coffee in an easterly direction
14:03:45 <bcotton> TCP: Transmission of Caffeine Protocol
14:05:07 <randomuser> i'm honestly considering an implementation of RFC2324 using a raspberry pi
14:06:04 <bcotton> hokay, let's get started
14:06:07 <bcotton> #topic Follow up on last week's action items
14:06:30 <bcotton> so, as best as i can tell, there was no last week. so we'll call it two weeks ago's action items
14:06:36 <bcotton> i finally did mine, we'll get to it
14:06:42 * shaiton say hello
14:06:46 <bcotton> Sparks: ping
14:07:18 * Sparks is here!
14:08:02 <bcotton> Sparks: you were supposed to send a note to the mailing list about a man page website. did that happen?
14:08:12 <Sparks> it did not
14:08:32 <bcotton> do you still plan on doing htat?
14:08:36 <Sparks> yes
14:08:56 <bcotton> #action Sparks to take man page website to mailing list
14:09:07 <Sparks> tu
14:09:24 <bcotton> #topic Using koji to publish docs.fp.o - Sparks
14:09:33 <bcotton> #info List discussion https://lists.fedoraproject.org/pipermail/docs/2012-May/014324.html
14:09:40 <bcotton> #link https://fedoraproject.org/wiki/Automating_publishing
14:10:25 <Sparks> This is still in progress.
14:10:32 <Sparks> Work is being done.
14:10:46 <bcotton> hooray! is it basially in infra's hands for now?
14:11:51 <Sparks> No...  I think it's in someone else's hands but I don't remember.  Rudi is working this.
14:12:31 <bcotton> okie dokie. any looming decisions for us to consider or are we on cruise control?
14:12:48 <Sparks> cruise control
14:13:35 <Sparks> I can answer some questions if anyone has any
14:15:39 <bcotton> sounds like a no
14:15:50 <bcotton> should we skip the man page topic?
14:15:57 <Sparks> we could
14:16:51 <bcotton> is there anything new to disucss?
14:16:55 <randomuser> I thought debian's solution wasn't really our style, fwiw
14:17:09 <bcotton> #topic Publish man pages - Sparks
14:17:18 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=828669
14:17:21 <Sparks> randomuser: What is debian's solution?
14:17:49 <randomuser> packages installed, and a perl script grabbing manpage text and formatting it
14:18:11 <randomuser> it seemed to require a lot of shepherding the data around
14:18:38 <bcotton> randomuser: not to mention a server with every single package installed
14:18:45 <randomuser> exactly
14:19:16 <randomuser> something that would hook into our infrastructure and grab the relevant files as needed, and parse them, would be ideal
14:19:27 <Sparks> Yeah, it seems like not a great idea but I'm hoping that maybe we can just pull down all the source RPMs and have a script go through them.
14:19:56 <bcotton> so an easier (for us) solution would be for FESCo to change packaging standards so that man pages are a separate RPM ($package-man) that the main package RPM depends on. i doubt we'll ever talk anyone in to that idea though
14:20:03 <randomuser> heh
14:20:54 <shaiton> or have koiji copying the manpage somewhere else for us
14:21:00 <randomuser> i bumbled around in koji for a while, but didn't discover a way to easily/problematically grab a specific file
14:21:07 <bcotton> Sparks: do you know if there's already somewhere that has all SRPMs readable programmatically?
14:21:14 <ianweller> can we get the packages app to do it?
14:21:20 <ianweller> it already has lists of files
14:21:24 <Sparks> bcotton: I do not
14:21:29 <ianweller> that may be coming from repodata, though. i think it has local package caches though
14:22:18 <randomuser> i like the idea of doing it through koji, because there is a possibility of pushing updates instead of pulling
14:23:21 <bcotton> doing it through koji would make it a much simpler process on our end. then we'd just need a web server and maybe a few scripts to glue it all together
14:23:53 <shaiton> so we need a koji master?
14:23:58 <ianweller> if you guys like, i can ask the guys behind the packages app if man pages is a thing they can do
14:24:05 <bcotton> ianweller: sounds good
14:24:30 <bcotton> #action ianweller to ask the guys behind the packages app if man pages is a thing they can do
14:24:33 <jjmcd> I don't think koji changes the game much
14:24:43 <jjmcd> Just pushes the problem to someone else
14:25:29 * bcotton wonders what the websites team thinks about this
14:25:32 <jjmcd> The main issue is identifying the man page in the SRPM.  Whether Koji or someone else does it is no real difference.
14:25:47 <jjmcd> Koji has less reason to worry than most
14:27:13 <shaiton> bcotton: websites is not responsible about apps
14:27:24 <shaiton> We can of course provide man pages
14:27:34 <bcotton> shaiton: ah okay
14:27:38 <shaiton> but I am +1 for having them though packages apps
14:27:48 <shaiton> (that would be more consistent)
14:27:54 * jsmith leans that direction as well, if it's not too much work
14:28:16 <skvidal> hi docs people - question about the manpages thing
14:28:26 <bcotton> skvidal: go ahead
14:28:42 <skvidal> why does having another index/display of man pages help?
14:28:53 <skvidal> what is it that we get out of it?
14:29:11 <daumas> google search presence (joke)
14:29:20 <skvidal> right....
14:29:34 <ianweller> bcotton, jjmcd, Sparks: ^^
14:29:49 <bcotton> skvidal: that was my question initially, too. i think some of it is that other man page sites sometimes lag teh version in fedora (first!), and so options are undocumented or incorrect
14:29:54 <randomuser> somebody's manpage index is going to come up when fedora users are searching for docs; it may as well be something they can trust
14:30:17 <skvidal> but ours are less likely to come up - if only b/c the links are going to churn faster
14:30:49 <skvidal> and if the links are saddled with versions/releases - they will expire faster, too
14:30:57 <Sparks> skvidal: But only in searches.  If people know it exists...  they go directly there.
14:30:59 <sgordon> debatable, in most cases the churn will be within existing man pages, no?
14:31:23 <randomuser> skvidal, i haven't seen any discussions on versions/releases
14:31:25 <skvidal> Sparks: why would they go to a seven-layer deep url?
14:31:35 <skvidal> randomuser: so the plan is for the man pages to be referred to by what?
14:31:37 <randomuser> I'm assuming we want to just have an up to date archinve?
14:31:46 <Sparks> skvidal: They wouldn't.  man.fp.o
14:31:55 <skvidal> domain.fp.o/manpages/pkgname/bin/man.1
14:32:02 <daydrim> it specialist often use man pages from popular ant trusted web sites. And man pages on the web sites not actually is up to date. But man pages from fedora would be a relible resource
14:32:10 <skvidal> so then that's going to be confusing to anyone not using F-current
14:32:15 <skvidal> but using F-current -1
14:32:27 <Sparks> skvidal: Nah....  man.fp.o  Select release and package.
14:32:36 <skvidal> Sparks: so if you're selecting release AND package
14:32:40 <skvidal> then we'll see churn
14:32:42 <skvidal> every 6 months
14:32:49 <Sparks> and?
14:32:55 <bcotton> skvidal: the versioning point is valid. we'd want to keep the supported versions at a minimum
14:33:22 <skvidal> Sparks: so - from a search perspective - we won't get as many connections from google
14:33:24 <sgordon> the page that sparked this query off goes back to F12
14:34:00 <sgordon> and it seems to do ok (first hit for "fedora man pages")
14:34:04 <Sparks> skvidal: I'm not concentrating on the search aspect.  Are you only concerned with Google?
14:34:13 <skvidal> I'm concerned w/what users DO
14:34:29 <skvidal> and what they do is go to google (or maybe bing HAHAHAA)
14:34:37 <skvidal> and search for help on the problem they are having
14:34:44 <randomuser> skvidal, crappy blog posts FAR outrank docs.fp.o - but we aren't giving over to bloggers there either
14:34:59 <Sparks> skvidal: i'm saying that if people know about the solution then they won't use Google
14:35:04 <skvidal> randomuser: I give over to blog posts all the time over docs
14:35:17 <bcotton> Sparks: i'm not sure that's true. i google for sites i know about more than i care to admit
14:35:25 <Sparks> heh
14:35:28 <skvidal> Sparks: it's faster to type it into google
14:35:36 <skvidal> Sparks: I don't have to screw with finding the url or even care
14:35:43 * randomuser uses site:docs.fp.o <topic>
14:35:44 <Sparks> skvidal: Maybe but then you don't know what you're going to get
14:35:55 <skvidal> I know I'm going to get answers
14:36:08 <randomuser> maybe we need an SEO SIG?
14:36:13 <skvidal> which is all I care about
14:36:14 <skvidal> answers
14:36:28 <ianweller> randomuser: oh please no
14:36:32 <skvidal> Sparks: also - if the person is capable enough to know that they want to look at the man page
14:36:33 <ianweller> randomuser: :)
14:36:40 <Sparks> skvidal: Right... might be old and out dated answers but you'll get answers
14:36:40 <skvidal> they seem capable enough to just type 'man bin'
14:37:19 <bcotton> skvidal: i often read man pages in a browser instead of a console. easier to skim, imo
14:37:48 <randomuser> skvidal, respectfully, i think we're only establishing that you don't feel the manpages effort is worthy of your participation
14:38:04 <skvidal> randomuser: no - I think I'm trying to keep us from housing a lot of stuff that will bitrot
14:38:26 <skvidal> like all the other man page indexes out there
14:38:31 <skvidal> I'd suggest the following
14:38:37 <skvidal> you want man.fp.o - great - put a metric on it
14:38:48 <skvidal> if it gets fewer than N hits that ARE NOT search crawlers
14:38:50 <skvidal> then shut it down
14:39:18 <bcotton> skvidal: any suggestions on a reasonable value of N?
14:39:29 <daydrim> heh , and the next step will be publication of translated man pages to variety of native languages? )))
14:39:49 <pingou> daydrim: s/publication of translated/translation/
14:39:54 <pingou> first things first
14:40:05 <skvidal> bcotton: nothing right off - maybe do it by percentages
14:40:13 <skvidal> bcotton: if you have 10000 hits in a 6month period
14:40:18 <skvidal> and 90% are crawlers
14:40:21 <skvidal> it's time to call it a day
14:40:37 <bcotton> that seems reasonable
14:40:51 <bcotton> i'd like to go ahead and table this discussion for now
14:41:00 * skvidal goes away again
14:41:03 <skvidal> thanks for letting me chime in
14:41:10 <bcotton> skvidal: thanks for your input!
14:41:22 <bcotton> i think the next step is to figure out how much effort this will require
14:41:54 <bcotton> from there, we can make some kind of determination as to whether or not the expected benefit justifies the work
14:42:12 <bcotton> so let's continue figuring this out on the mailing list and in next week's meeting
14:43:17 <bcotton> #topic QA recap
14:43:27 <bcotton> #link https://fedoraproject.org/wiki/Docs_QA_Procedure
14:43:44 <bcotton> so I finally got aroudn to writing up a proposed list of duties for a QA wrangler
14:43:50 <bcotton> it's at the bottom of the page linked above
14:44:44 <randomuser> while we're designating a qa role, i had an idea
14:44:57 <bcotton> if i recall correctly, we're still not sure we like this procedure, at least as far as our ability to implement it given our resources
14:45:01 <bcotton> go ahead, randomuser
14:45:41 <randomuser> I suggest that we open a QA bug for each Feature put forward in each Release, possibly per Doc
14:46:35 <randomuser> a further, and probably wholly unneeded step, could be blocker bugs as the QA guys do
14:46:44 <bcotton> the idea being this way there's some trackable assignment to make sure features get included in docs?
14:47:30 <randomuser> but we should see changes coming so that there arent bugs filed like "this should be 'systemctl status <service>' not 'service <service> status'
14:47:43 <randomuser> bcotton, that's the idea
14:48:20 <bcotton> randomuser: who would be responsible for opening these tickets?
14:48:49 <randomuser> bcotton, the QA wrangler
14:49:05 <randomuser> as i see it as a QA related cause
14:50:25 <bcotton> that makes sense. can you add that to the wranger duties, please?
14:50:43 <randomuser> sure
14:51:59 <bcotton> do we have any other QA related thoughts this week? i'm taking a QA in IT class this fall, so i'm sure i'll have plenty ideas for us in December :-)
14:53:18 <bcotton> #topic Open Help Conference
14:53:25 <bcotton> #link http://openhelpconference.com
14:53:31 <bcotton> #info Open Help Conference is Aug 11-15 in Cincinnati, OH
14:53:37 <bcotton> just a friendly reminder that this is coming up
14:54:07 <bcotton> #topic Open floor discussion
14:54:15 <bcotton> anything else in the last few minutes before we have to leave?
14:54:37 <randomuser> bcotton, QA page updated
14:54:44 <bcotton> randomuser: thanks
14:54:49 * randomuser nods
14:54:51 <shaiton> no news about the IQSG and Zanata?
14:55:09 <shaiton> that was on the mailing list
14:55:27 <bcotton> shaiton: i've heard nothing further
14:55:45 <shaiton> ok, will wait for the guide writter
14:56:11 <bcotton> last call!
14:56:53 <bcotton> thanks everyone, great meeting!
14:56:57 <bcotton> #endmeeting