14:00:47 <randomuser> #startmeeting Docs Project Meeting - Agenda: https://fedoraproject.org/wiki/Docs_Project_meetings
14:00:47 <zodbot> Meeting started Mon Jul  7 14:00:47 2014 UTC.  The chair is randomuser. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:47 <randomuser> #meetingname Fedora Docs
14:00:47 <zodbot> The meeting name has been set to 'fedora_docs'
14:00:47 <randomuser> #topic Roll Call
14:00:52 * Sparks 
14:00:54 * jjmcd 
14:01:32 * pbokoc 
14:01:47 * pkovar is here
14:02:31 * jhradilek is here.
14:02:41 * yruseva here
14:02:46 * jreznik is around if needed
14:02:48 <pbokoc> you guys ruined it!
14:03:01 <yruseva> next time :)
14:05:06 <randomuser> good showing today, hello everyone
14:05:09 <randomuser> #chair Sparks
14:05:09 <zodbot> Current chairs: Sparks randomuser
14:05:16 <randomuser> #chair pbokoc
14:05:16 <zodbot> Current chairs: Sparks pbokoc randomuser
14:05:28 <pbokoc> *evil laugh*
14:05:31 <randomuser> #topic New Writers
14:05:35 <pkovar> what did we do?
14:05:35 * randomuser snickers
14:06:09 <randomuser> #info New Writers can find help in #fedora-docs or on the mailing list
14:06:45 <randomuser> did any new folks sneak in, and want to say hello?
14:08:43 * randomuser presumes no
14:08:50 <randomuser> #topic Release Notes / Beats
14:08:57 <pbokoc> yeah, I had a thing
14:09:14 <randomuser> pbokoc, yeah/
14:09:32 <pbokoc> almost all tables have a writer assigned at https://fedoraproject.org/wiki/Category:Documentation_beats
14:09:45 <pbokoc> but most of these have been carried over from the previous release (hence the asterisks next to writer names)
14:09:55 * randomuser nods
14:10:17 <jreznik> btw. as we now have only one bug per change - there are some bugs with release notes to be picked up, any idea how to mark it for you?
14:10:34 <pbokoc> we should probably send an e-mail to the list and ask everyone to either remove the asterisk, or remove their names, and give them a week or two to do it
14:10:37 <randomuser> the first thing on the schedule is http://fedorapeople.org/groups/schedule/f-21/f-21-docs-tasks.html validating beat writers, pbokoc
14:10:47 <pbokoc> oh :)
14:11:04 <randomuser> pbokoc, would you care to send the mail?
14:11:09 <Sparks> I believe I saw a message go out to the features that they should be solid or risk being pushed to next release.
14:11:19 <pbokoc> randomuser, sure thing
14:11:31 <randomuser> #action pbokoc to mail list on validating beat assignments
14:12:05 <randomuser> jreznik, i think we're using the "Docs Contact" field in those bugs... if someone has stepped up to cover the Change
14:12:39 <jreznik> randomuser: and if there's text that should be picked up? ready by maintainer?
14:13:33 <randomuser> jreznik, hmm... ideally, we should be checking that copy at every milestone,
14:14:34 <randomuser> jreznik, what do you suggest ?
14:16:06 <jreznik> I'm not sure
14:16:20 <pbokoc> randomuser, you mean, setting the writer assigned to it as docs contact? So, if I'm signed up to the Installer category, I should be set as docs contact on every change Bugzilla related to installer?
14:16:41 <randomuser> let's say that Change owners should expect us to keep up with their work, but we encourage them to communicate with us through normal channels (irc, docs list, mail to their favorite docs person, etc)
14:16:58 <randomuser> pbokoc, we're talking specifically about the Change process
14:17:27 <jreznik> for example this one https://bugzilla.redhat.com/show_bug.cgi?id=1076440#c1
14:17:29 <randomuser> pbokoc, ...but if you wanted to be that thorough :)
14:17:59 <pbokoc> right
14:18:06 * lnovich is here
14:18:43 <pbokoc> ok, why not set needinfo+ on the release notes mailing list? Then everyone would see it, and one of the writers can pick it up
14:19:11 <randomuser> +1
14:19:17 <pbokoc> needinfo? I mean
14:19:28 <pbokoc> jreznik, ^^^
14:19:28 <randomuser> we're all subscribed to relnotes-content@lists.fp.o, right?
14:19:54 <pbokoc> randomuser, when I write the mail I'll mention the list too, just to be sure
14:20:03 <jreznik> pbokoc: I'm just not sure I can watch all bugs just by myself
14:20:05 <randomuser> cool
14:20:18 <randomuser> heh, we don't want that jreznik
14:20:23 <pbokoc> jreznik, yeah, that's a problem
14:20:58 <randomuser> pbokoc, also include "pick up your Change assignments" in the mail?
14:21:12 <pbokoc> randomuser, yeah
14:22:39 <randomuser> I've also been working on revamping the beats layout, mostly to give guidelines on what content to cover for each area
14:22:52 <randomuser> this will at least make it easier for *me*
14:23:02 <randomuser> hopefully for others also, and more people will participate
14:23:06 <randomuser> http://fedoraproject.org/wiki/User:Immanetize/Beats_Redux\
14:23:10 <randomuser> http://fedoraproject.org/wiki/User:Immanetize/Beats_Redux
14:23:13 <randomuser> ...
14:23:47 <randomuser> we don't have to adopt this *now* as our actual beats, since we're already in the process of validating the current list, but it's still helpful imo
14:23:53 <pbokoc> well, anyway, to jreznik's issue - ideally all devs should be aware of the relnotes list and that they should set needinfo on it if they write a release note
14:24:13 <jreznik> pbokoc: that's really an ideal word...
14:24:17 <pbokoc> yeah...
14:24:30 <jreznik> I can do it now, for changes I know it's thre
14:24:30 <randomuser> pbokoc, jreznik there's also a fedora_requires_release_note flag
14:24:55 <jreznik> randomuser: hmm, that could be used
14:25:01 <randomuser> that flag automatically sends stuff to the relnotes-content list
14:25:11 <pbokoc> randomuser, I think we talked about that flag before, but it's still the same problem as with the needinfos - everyone needs to be aware of it and use it
14:25:21 <jreznik> so set it to ? and if acted, you'll set it to +
14:25:29 <pbokoc> yeah
14:25:35 <randomuser> jreznik, I've been trying to encourage *everyone* to do that for whatever bugs they feel appropriate, not just changes
14:25:48 <pbokoc> yes, definitely
14:25:57 <jreznik> randomuser: yeah, it's just hidden and in fedora, we're not much about using flags :(
14:26:00 <randomuser> jreznik, usually, we'd + for "yes this should be noted" and - for "this isn't in scope for RNs"
14:26:23 <jreznik> ok
14:26:28 <jreznik> let's try this
14:26:33 <randomuser> the Changes should *always* be noted - but the flag is still one option for signalling
14:27:00 <jreznik> randomuser: yep, I agree - when someone puts it into bug instead of change page
14:27:05 <jreznik> not to miss it
14:27:51 <randomuser> #proposal if (docs-contact):needinfo docs-contact; else: needinfo docs@lists.fp.o
14:28:18 <randomuser> ...presuming the docs contact has been unresponsive
14:28:39 <pbokoc> yeah, that sounds good. Let's see how it works out
14:28:49 <randomuser> jreznik, and I'd say you don't worry about anything for.. a week? let us try and catch up?
14:29:19 <jreznik> ?
14:29:47 <randomuser> jreznik, don't feel like you have to go through all the changes for us, we should be doing that soon anyway
14:30:24 <jreznik> yeah, I meant just for these clear examples it's in bug and it could be missed
14:30:34 <jreznik> so now I have some way to raise your attention
14:30:34 <randomuser> sure
14:30:39 <jreznik> that's good, thanks!
14:31:55 <randomuser> #accepted docs should keep up on changes, but if needed, if (docs-contact):needinfo docs-contact; else: needinfo docs@lists.fp.o
14:32:24 <pbokoc> randomuser, the Beats Redux page looks good - I wanted to mention that some beats categories aren't all that well defined, but looks like you have it covered :)
14:32:50 <randomuser> pbokoc, thanks
14:33:20 <randomuser> my plan is to make a comprehensive list of categories, then iterate over the list for specific packages or contacts, and so on
14:34:24 <pbokoc> randomuser, you mean you want the page to list specific packages/groups for each category?
14:34:24 <randomuser> assistance welcome :)
14:34:53 <randomuser> pbokoc, as specific as makes sense, anyway
14:35:09 <pbokoc> as in, for example, the anaconda/installer group would list anaconda, blivet, pykickstart, firstboot...? I mean, that would be awesome, but it's a TON of work
14:35:16 <randomuser> maybe it's going to be just "matches for `yum search media player`
14:35:58 <randomuser> we'd at least want to know about anaconda UI changes, feature changes, and new/outdated kickstart options
14:36:33 <randomuser> it might make sense to lump firstboot behavior in there (non-gnome) and bootloaders as well
14:36:52 <pbokoc> yeah, I'm not necessarily talking about specifics right now, I just used it as an example
14:37:04 <randomuser> sure
14:37:09 <pbokoc> well I can help with some of the categories, but it really sounds like a lot of effort
14:37:38 <randomuser> i'm hoping that some SIGs will get involved
14:38:30 <randomuser> it's a lot of effort, but intentionally divided into smaller, more easily digestible bits
14:39:11 <pbokoc> randomuser, all right. We can talk about it later, right now we should probably move to other topics :) I'll help where I can
14:39:20 <randomuser> always appreciated
14:40:17 <randomuser> for now, i'm thinking my time is better spent making things easier for people to help, and recruiting; the redux page is my general SOP for writing RNs once I get started anyway
14:40:23 <randomuser> just written down this time :)
14:40:36 <randomuser> #topic publican/publishing
14:40:48 <randomuser> no rkratky today?
14:41:20 <randomuser> we'll skip this one, then
14:41:30 <randomuser> #topic Guide Status
14:41:42 <randomuser> lnovich, did you catch up with jeast ?
14:42:26 <randomuser> about the storage guide?
14:43:43 <lnovich> yes, she made no promises
14:43:54 <lnovich> but i will get an answer from her
14:44:08 <lnovich> but she has been notified
14:45:36 <randomuser> is there any way for us to get source for the rhel7 storage guide, other than from her?
14:46:06 <randomuser> is this something that we can work out a cooperative arrangement for at an administrative level, maybe?
14:46:09 <randomuser> jhradilek, ?
14:46:35 <randomuser> ( this is maybe a better general question than a guide-specific one )
14:48:28 <pbokoc> randomuser, this is going to vary book from book. Some books' sources can be obtained quite easily, others... not really.
14:48:38 <pbokoc> I think the storage admin guide belongs to the latter category :I
14:48:48 * randomuser nods
14:49:35 <randomuser> #proposal give lnovich another week to reach out to the current storage guide owner; if unresponsive, remove them from default assignment and possibly FAS groups
14:49:58 <lnovich> i will let her know
14:50:25 <randomuser> there's no benefit to us keeping in lockstep with the downstream guide if neither us nor Red Hat are benefitting from it
14:51:10 <pbokoc> yyyyyep
14:51:28 <pkovar> sounds reasonable
14:51:44 <randomuser> Sparks, jjmcd ?
14:51:54 <jjmcd> ?
14:52:28 <jjmcd> Don't think we need to go nuts to keep in sync
14:52:31 <pkovar> i think that in the past,we were periodically checking for unresponsive maintainers / book owners
14:53:11 <pkovar> maybe we should start doing that again?
14:53:37 <randomuser> i could get behind that
14:53:41 <pbokoc> well, that does sound like a good idea... but what do we actually do when we find an unresponsive owner?
14:54:08 <Sparks> beg for a responsive one
14:54:34 <randomuser> what they do for packagers is needinfo on  bugs for a week, try to contact them through other channels, post to the devel list looking for contact info, and if still no response, their privileges and assignments are administratively removed
14:54:51 <randomuser> err.. just the assignments. They can still do stuff if they come back, i think
14:55:11 <pkovar> right, i would just remove the assignments
14:55:16 <pbokoc> definitely
14:55:52 <Sparks> It might be good to remove the privileges.  If they aren't maintaining their account appropriately then we have a hole into our commit system.
14:56:37 <randomuser> Sparks, remove from docs-writers, leave in docs might be a reasonable compromise?
14:56:54 <Sparks> I don't see the need to keep them anywhere.
14:56:56 <randomuser> heh
14:57:02 <Sparks> If you aren't contributing...
14:57:12 <randomuser> it's nice to think that we could leave them in there , just in case they want to throw a commit in
14:57:22 <randomuser> but it's not like it is hard to find a sponsor
14:57:29 <Sparks> and we still accept patches
14:57:50 <randomuser> let's take this one to the list
14:58:01 <randomuser> Sparks, do you want to start it, or should I?
14:58:02 <pkovar> i would only remove the privileges after, say, 12 or 24 months of no activity
14:58:37 <Sparks> randomuser: Go for it
14:58:43 <randomuser> okay
14:58:56 <pkovar> at least that's been the policy for gnome,git accounts, and it has been working well afaics
14:59:06 <randomuser> #action randomuser to start list thread on absentee owners
14:59:20 <randomuser> 12 months sounds reasonable, pkovar
14:59:26 <pkovar> ok
14:59:36 <randomuser> #topic last minute thoughts
14:59:41 <Sparks> wiki
14:59:45 <randomuser> open floor quick
14:59:58 <randomuser> Sparks, doing a bot looks more complex than I thought it would be
15:00:06 <randomuser> i haven't had time to dig into it
15:00:36 <randomuser> on to #fedora-docs !
15:00:40 <randomuser> #endmeeting