14:00:58 <randomuser> #startmeeting Docs Project Meeting - Agenda: https://fedoraproject.org/wiki/Docs_Project_meetings
14:00:58 <zodbot> Meeting started Mon Apr 13 14:00:58 2015 UTC.  The chair is randomuser. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:58 <randomuser> #meetingname Fedora Docs
14:00:58 <zodbot> The meeting name has been set to 'fedora_docs'
14:00:58 <randomuser> #topic Roll Call
14:01:14 * pbokoc 
14:01:24 * lnovich1 is here
14:01:29 * bexelbie is here
14:02:06 <lnovich1> need to run to another meeting sorry I can't stay at the moment
14:03:01 <randomuser> #chair bexelbie pbokoc
14:03:02 <zodbot> Current chairs: bexelbie pbokoc randomuser
14:03:59 * bexelbie takes a seat :)
14:04:07 <grundblom> hello
14:04:17 <grundblom> #here
14:04:22 <grundblom> dangit
14:04:36 <randomuser> morning, grundblom
14:04:43 * smcann is here
14:04:44 <grundblom> Good Morning!
14:06:16 <randomuser> #topic follow up on action items
14:06:40 <randomuser> out last meeting was canceled because it was empty
14:07:17 <randomuser> in the previous meeting, I was going to .. do stuff for the release notes
14:07:53 <randomuser> and I think that's getting done
14:08:09 <randomuser> #topic New Writers
14:08:32 <randomuser> hrm
14:08:38 <pkovar> /me is latše
14:08:43 <pkovar> late , rather
14:08:53 <randomuser> I have to step away for a few minutes, if someone could carry on?
14:09:49 <smcann> on the new writer front - I put in my last commits to the virt-manager chapter of the virt-getting started guide (private branch)
14:09:56 <pbokoc> bexelbie, it's on you
14:10:16 * bexelbie will try
14:10:26 <bexelbie> Are there any new writers present?
14:10:31 <grundblom> new writer: I think I am done with the boxes chapter on my repo under rundblom_boxes chapter
14:10:33 <bexelbie> as opposed to most recent committers :)
14:10:41 <smcann> I'll be offline mostly for the next coupel of weeks, but y'all can email if there is more comments/ fixes needed to that chapter
14:10:45 <grundblom> I also made an attempt to write for the entertainment beat
14:10:51 <bexelbie> +1 smcann and grundblom
14:11:11 <pbokoc> grundblom, in the wiki?
14:11:11 <bexelbie> smcann, and grundblom  do you have a plan for finalizing your commits and getting them to master?
14:11:43 <smcann> last I heard, either lnovich or randomuser was going to take both and merge/recreate the getting started guide
14:12:02 <grundblom> pbokoc, yes,
14:12:35 <bexelbie> lnovich stepped away, so hopefully randomuser can confirm where he is with that plan when he returns - or if we need to find some additional help
14:13:18 <grundblom> bexelbie, I think I need some more time and training with git before I commit them to someplace real / serious
14:13:45 <grundblom> right now I have been only in my own personal repo and had to recover a couple times from being new
14:13:51 <bexelbie> grundblom, I respect.  It sounds like randomuser is going to do the merge for you - one thing that would be nice from a helping other new contributors perspective is if you could spell out some of your questions
14:13:53 <smcann> I'm probably in the same boat - not to be trusted w/ the sharp knives yet
14:14:01 <bexelbie> answering them would help us improve the guide for new writers
14:14:04 <bexelbie> ditto to smcann
14:14:11 <pbokoc> grundblom, right. Well, the issue is that none of the other beats have similar info - which version of what is shipped in the release... we mostly only cover changes, new and deprecated functionality
14:15:19 <grundblom> pbokoc, oh that makes sense, So I need to find out what the new version of rhythmbox does different, if anything
14:15:43 <pbokoc> grundblom, yeah, that would work better
14:16:18 <pbokoc> and if there aren't any significant changes, we usually just ignore it. The relnotes are never totally comprehensive, only high-level user-facing stuff
14:16:36 <pbokoc> documenting every change in everything... that way lies madness :)
14:16:55 <smcann> fwiw on entertainment, I read somewhere that f22 will have an updated libimobiledevice package which will allow me to sync iphone IOS 8
14:17:48 <grundblom> thanks smcann, that sounds cool! I will go investigate that
14:18:13 <pbokoc> cool
14:18:40 <smcann> http://www.libimobiledevice.org/
14:19:24 <pbokoc> alright, anyone else have anything? I think the stuff you folks have in private branches would be better discussed after the meeting with randomuser
14:19:30 <smcann> and this is what made me think int's coming in f22 https://apps.fedoraproject.org/packages/libimobiledevice
14:20:41 * randomuser pops back in
14:21:02 <pbokoc> let's continue with the next topic then
14:21:04 <randomuser> yes, the plan is for me to merge grundblom and smcann's branches into master when they are ready
14:21:27 <pbokoc> #topic Release Notes Beats
14:21:42 <pbokoc> now, where was that query again
14:22:08 <pbokoc> #link http://red.ht/1IOcNdu - query showing all Change bugs accepted for f22
14:22:23 <randomuser> #info Beats are getting closed on wiki
14:22:28 <pbokoc> we still have 9 bugs unclaimed (not counting the ones on NEW)
14:22:57 <pbokoc> there's like 3 in there about GNOME (GNOME 3.16, something about Nautilus and new notifications)
14:23:10 <pbokoc> we really should cover that
14:23:23 <pbokoc> any volunteers? :)
14:23:42 <randomuser> I heard pkovar likes writing gnome stuff
14:23:54 <pbokoc> yeah, now that you mention it...
14:24:38 <pbokoc> wink wink
14:24:42 <pbokoc> there's also one for KDE (Plasma 5), but rkratky isn't here
14:24:55 <randomuser> the Workstation beat needs to be [re]written still as well
14:24:58 <pkovar> randomuser: i will see what i can do
14:25:09 <randomuser> pkovar, thanks :)
14:25:30 <pbokoc> pkovar, set yourself as docs contact on the bugs you cover, please
14:25:57 <randomuser> #info Edition overviews were left intact, because we want to give an overview of them and not simply describe changes
14:26:13 <pkovar> pbokoc: will do when i get to it
14:26:22 <pbokoc> cool, thanks
14:27:49 <pbokoc> also I asked some others to write a few beats - yruseva for preupgrade-assistant and bara said she'll do some of the python-related stuff, that's like 2 bugs
14:28:18 <pbokoc> so I guess we're mostly good, I'll just need to talk to the installer team and get them to tell me what changed there
14:28:39 <pbokoc> anything else?
14:29:03 <randomuser> #action randomuser to close beats on wiki
14:29:04 <lnovich> sorry I had to step out but now I am back - and on the beat note - still waiting for Cole to tell me what's included
14:29:38 <pbokoc> lnovich, included where?
14:29:46 <randomuser> lnovich, you could always research it yourself, if all else fails :P
14:29:53 <lnovich> what features
14:30:29 <lnovich> i know i can do it myself - but at last I spoke to him, he wasn't sure himself what would go in and what wouldn't
14:31:09 <randomuser> we're in a package freeze at the moment, nothing new is going in
14:31:47 <lnovich> ok so he should know at this point
14:31:52 <pbokoc> yep
14:31:52 <randomuser> anyway, he's a good source, we don't need to dwell on it
14:33:05 <pbokoc> so anyway
14:33:28 <pbokoc> #topic Publican/Publishing
14:33:39 <pbokoc> randomuser, you wanted to talk about old guides?
14:33:48 <randomuser> I do, yes
14:34:07 <randomuser> when we migrate to..  whatever, we will have to republish everything
14:34:31 <bexelbie> that could be interesting ...
14:34:43 <randomuser> and there are diminishing returns in publishing older guides, as the work involved to get them republished goes up, and the efficacy of the content goes down
14:35:13 <randomuser> so I'm proposing that we don't keep publishing guides more than one release past EOL
14:35:19 <lnovich> if we can do it  way after or way before a release it would have the least amount of impact
14:35:45 <bexelbie> randomuser, taht is very reasonable … would we want to run them out to pdf (if we can) and use that as the “archive” format?
14:36:09 <pbokoc> hey, I was just about to suggest that!
14:36:23 <randomuser> yeah, I like that idea
14:36:34 <lnovich> way better to do it that way than to remove....
14:36:37 * bexelbie read pbokoc’s mind and typed faster than him
14:36:56 <lnovich> some kind of vulcan mind meld?
14:37:13 <pbokoc> I knew you americans were in my head! Friggin HAARP and alien technology...
14:37:19 <randomuser> bexelbie, although, do keep in mind that I'm not intending to go forward with an only-publican-guide content set
14:37:37 <lnovich> you forgot to wear your aluminum foil hat again, didn't you?
14:37:43 <randomuser> let me provide some context, I guess
14:37:45 <pbokoc> https://imgflip.com/s/meme/Ancient-Aliens.jpg
14:37:47 <bexelbie> randomuser, meaning what exactly to make sure we are on the same page
14:38:19 <randomuser> the automated tooling I'm working on will watch branches fN ... f19, f20, f21, f22, etc
14:38:34 <bexelbie> right
14:38:51 <randomuser> I've set it up to watch specifically those branches, because that's the naming convention used everywhere else
14:39:10 <bexelbie> makes sense - so you want version level branches that can be republished easily …
14:39:15 <randomuser> so we don't have to manually maintain that list, I set it up to query pkgdb and get the branch names
14:39:26 <lnovich> makes sense
14:39:38 <bexelbie> that works well
14:39:51 * bexelbie doesn’t think of that as a publican-only process
14:40:08 <lnovich> sounds more like a version control process
14:40:17 <randomuser> so the question is, do we want to watch and publish branches for all possible fedora releases, or do we want to do a subset of them?
14:40:30 * bexelbie votes for a subset
14:40:41 <lnovich> active only - archive the rest
14:40:44 <bexelbie> with output to PDF on frozen non-published branches
14:40:54 <bexelbie> to keep those who stick around post-EOL happy
14:41:11 <randomuser> well, we could do N EOL releases for that
14:41:22 <lnovich> as there are those still using F9 - I actually had to help support someone on it ...don't ask!
14:41:41 <randomuser> I've got exactly one mode of support for F9 users...
14:42:01 <pbokoc> yeah, clue-by-four
14:42:24 <randomuser> besides the extra overhead, the project as a whole does not support EOL releases and the cultural norm is to be very discouraging about using them
14:43:03 <pbokoc> yeah, but at the same time, we don't really update and republish all content for each new release
14:43:04 <lnovich> i say we keep older EOL releases available - but with all appropriate warnings and labels and PDF only and only update those that matter
14:43:37 <pbokoc> some guides are outdated, and I wouldn't want to just slap a new release version on the old content and republish it as "better than nothing"
14:43:45 <lnovich> +1
14:44:08 <lnovich> I would like to think we have higher value standard than that
14:44:13 <randomuser> pbokoc, ideally, we could destroy the publishing infrastructure at any time and recreate it by firing the builder instance again
14:44:14 <pbokoc> if it stays on the site, but it's marked as e.g. F18 and there's no newer one, it tells users that they shouldn't expect everything to work the same
14:44:53 <randomuser> I like the idea of what you're saying, lnovich, but it means a whole lot more work than simply publishing those branches as-is, without comment
14:45:41 <lnovich> we once thought about putting cobwebs on the doc with a tagline that said something like - This content is rather dusty, if you want to clean it up, click here to become a docs contributor
14:46:03 <randomuser> adding labels takes work, setting up the frontend to display EOL stuff or only PDFs takes more work, generating different build sequences takes work...
14:46:08 <lnovich> or something like that
14:46:52 * randomuser nods
14:47:41 <randomuser> it's a neat idea
14:47:42 <lnovich> im just thinking out loud, but if we remove the content entirely, will anyone notice?
14:48:05 <randomuser> lnovich, to be clear, I'm not planning on removing anything from web.git
14:48:11 <lnovich> and if they don't should we worry about it?
14:48:26 <lnovich> i mean from the web server
14:48:31 <randomuser> I think people will probably notice, and I'm ok with that
14:49:01 <pbokoc> well, another thing is that... currently, if someone sees e.g. the Accessibility guide on the website, and they see the last release was for F14, it might prompt them to join and help. If the guide isn't there, most people would probably think we just don't have any guide like that, and we're not interested in it
14:49:12 <randomuser> you can't get F12 packages on your F21 instance, it doesn't align with that to provide F12 docs
14:49:31 <randomuser> pbokoc, it would be pretty easy to create a list of not-published guides, fwiw
14:50:04 <lnovich> maybe just remove the doc from the webserver, make a 404 splash page and see how many are looking for it before we provide a PDF
14:50:07 <bexelbie> I agree that we should call out when something was last updated - but I don’t like the current display - but that is window dressing
14:50:10 <randomuser> although, that would come from a deprecated publican guide list, and some repos would potentially be a whole collection of articles, so it doesn't completely translate
14:50:39 <pbokoc> randomuser, well, I'm afraid less people would see a list somewhere - because they won't be specifically looking for it
14:50:50 <bexelbie> do we just archive the old site as a whole and put it on a server and let it sit and rot? and not worry about going to far past EOL
14:51:07 <pbokoc> instead, I think people google something like "Fedora accessibility", get the ancient guide, see that there's no newer one... you know
14:51:35 <randomuser> bexelbie, I think we probably would do that... but if we have a policy about maintaning a given number of guides, it would catch up after a few releases
14:51:48 <randomuser> also, someone is working on the accessibility guide right now :)
14:52:37 <lnovich> do we know  / care how other projects handle this issue?
14:52:43 <bexelbie> perhaps we can find a way to pull the guides forward without rebranding in the branching scheme … alal the f20 docs included this f14 historical beauty
14:52:48 <pbokoc> yeah, I know
14:53:48 <lnovich> of course what will happen once the design team goes through with their plans? all of this talk may be for nothing
14:53:52 <randomuser> it sounds like there's a lot to discuss here, perhaps we should continue on the list
14:54:18 * bexelbie wonders if we could find people who want to go through the old guides and test/scope the changes to make getting contributors/updates happier (I don’t know who would do this …)
14:54:24 <bexelbie> +1 on list
14:55:21 <randomuser> bexelbie, I'm hoping that if we give people a platform where they can write simple articles without buying into maintaining and integrating an entire guide, contributions will go up
14:55:52 <bexelbie> randomuser, I agree - but I also think that will mean a greater need for content strategy
14:55:58 <randomuser> indeed
14:56:01 <lnovich> content policy as well
14:56:23 <randomuser> I keep picturing us ending up with a process similar to the package review process
14:56:40 <randomuser> with guidelines and per-article review
14:56:46 <lnovich> we may and it may not be a bad thing - if done correctly
14:56:55 <randomuser> there seems to be a lot of packages in the repo, so it must work :P
14:57:12 <lnovich> especially if one can get badges for packages!
14:57:15 <bexelbie> it is a question of manpower too
14:57:20 <randomuser> yes, you get badges for packages
14:57:26 <bexelbie> but yes, that process could well work
14:57:26 <lnovich> i mean patches
14:57:31 <randomuser> bexelbie, definitely bootstrapping involved :P
14:57:35 <smcann> in the area of what do other folks do - I can't find docs in openstack other than for the most recent release.. .at least not the operating guide
14:57:40 * bexelbie just looks strapping in boots
14:57:55 <randomuser> I'd also like some comment on the metadata proposal I sent to the list
14:57:57 <lnovich> TMI Bex
14:58:02 <valebes> Hi
14:58:02 <randomuser> because this thing is going to need it
14:58:14 <bexelbie> I think a lot of projects are moving to “step 1 is run the current code” model
14:58:14 <lnovich> hi valebes!
14:58:23 <bexelbie> not very enterprise friendly, but helps with these answers
14:58:23 <valebes> How are you?
14:58:26 <randomuser> and if you don't comment, I'm just going to start adding those metada files to your guides
14:59:14 <randomuser> metada! metadata!madata!
14:59:53 <randomuser> bexelbie, yeah, and the first step in any troubleshooting process is "do you have the latest packages for your supported release"
15:00:09 <lnovich> metadata - for what purpose
15:00:17 * randomuser notes there was a proposal to cancel the QA meeting
15:00:26 <bexelbie> randomuser, with the same challenges - this kind of loops back to our personas conversation
15:00:48 <bexelbie> for some variants, like perhaps workstation (with fedup) it may be reasonable to say your not in X revisions - upgrade
15:00:56 <bexelbie> with others like server we may need to make things available longer
15:01:11 <randomuser> Okay, I have another meeting, gtg
15:01:17 * bexelbie needs to read the meta data email as he is behind
15:01:32 <randomuser> yes, please do
15:01:37 * randomuser &
15:02:19 <lnovich> ok will do
15:03:39 <lnovich> ok - are we ending the meeting?
15:04:27 * bexelbie thinks we should and continue on list
15:04:51 <lnovich> yes but someone - the chair needs to end the meeting so that it is official
15:04:59 <pbokoc> alright then
15:05:05 <pbokoc> #endmeeting