docs August 2017

docs@lists.fedoraproject.org

19 participants
25 discussions

[Fedocal] Reminder meeting : Fedora Docs Weekly Meeting
by immanetize＠fedoraproject.org 13 Aug '17

13 Aug '17

Dear all, You are kindly invited to the meeting: Fedora Docs Weekly Meeting on 2017-08-14 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: An hour of docs folks talking about what they are working on and what they'd like to work on. More information available at: [https://fedoraproject.org/wiki/Docs_Project_meetings](https://fedoraproject… Source: https://apps.fedoraproject.org/calendar/meeting/371/

1 0

Minutes from Docs meeting on 7 August
by Brian Exelbierd 07 Aug '17

07 Aug '17

There are no minutes today due to no attendance. If you wanted to be at the meeting and couldn't, please reply to this email. It may be time to look for a new meeting time. We have a blocker bug (xrefs) for the new docs site. Robert Kratky has written some code to resolve it. Unfortunately we found a bug in the handling of include files and that is now being worked. regards, bex

2 1

Self-Introduction
by Nathan Hicks 07 Aug '17

07 Aug '17

Hello all - I'm Nathan Hicks. I'm brand new to the Fedora Project as a contributor, but I’ve been an active user since Fedora 21 (before that I was using other distributions). Most of my experience has been either academic or hobby - I am always trying to learn new things. I’m hoping I can do just that by contributing and learning from all of you. I live in the United States on Eastern Standard Time. Most recently I’ve been exploring docker containers and ansible playbooks more from a hobby and volunteer use case. As far as programming, I’ve had varied exposure with Ada95, C++, C, PHP, but most frequently use shell scripts, Python2.7 and vanilla markdown with github.io <http://github.io/> Jekyll. Lately, I’ve been mostly messing around with building virtualized home servers via oVirt and proxmox. I also like to use qemu-kvm and am getting more familiar with virt-install and virsh as I’m weening myself from virt-manager. I think I’d be an excellent match for the project because I’m rather obsessive in my own work about documenting things that I do so that other people that come after me can have references to go on (otherwise a lot of work goes to nil). I’d love to help out wherever you think I’m needed the most. Currently I’m estimating my time will be limited to about 4 hours a week - but I should have a better idea in another month or so if I can put more time in. FAS: nmhicks pub 4096R/EEEB4370 2017-08-02 [expires: 2018-08-02] Key fingerprint = E5F3 B6B7 E97F 6199 B0DD 2709 EB85 B1E3 EEEB 4370 uid [ultimate] Nathan Hicks <nathan.m.hicks(a)gmail.com <mailto:nathan.m.hicks@gmail.com>> sub 4096R/7BD2CF44 2017-08-02 [expires: 2018-08-02] Sincerely, Nathan Hicks

3 2

[Fedocal] Reminder meeting : Fedora Docs Weekly Meeting
by immanetize＠fedoraproject.org 06 Aug '17

06 Aug '17

Dear all, You are kindly invited to the meeting: Fedora Docs Weekly Meeting on 2017-08-07 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: An hour of docs folks talking about what they are working on and what they'd like to work on. More information available at: [https://fedoraproject.org/wiki/Docs_Project_meetings](https://fedoraproject… Source: https://apps.fedoraproject.org/calendar/meeting/371/

1 0

A suggestion for automatic categories for wiki pages...
by Mark Aitchison 01 Aug '17

01 Aug '17

Taking a random page like https://fedoraproject.org/wiki/Administration_Guide_Draft/NFS I notice there are several obvious (and some not-so-obvious) indications that the page is out of date. I think it would be a good idea, and probably can be done automatically for the most part, to have a clear indication of the state (score?) of each wiki page to indicate how valid and up to date it probably is. That indication should be a clear box at the top, and (if the page is so out of date that it may be unusable) it could change the background to (say) some shade of pink. These are the things that could be checked automatically: 1. uses a command or suggests installing a package that doesn't exist in the latest release (other than in a section clearly headed for "Older Versions") 2. uses a command (like yum) that is deprecated/out-dated (that might include any system-config-xyz options since they seem to be disappearing?) 3. does not have a section on testing the changes that have been made (if the advice had included "edit" or "install" anywhere). 4. the latest release of Fedora mentioned anywhere on the page is over 2 years old. There should also be a clear feedback method on each page (like "This answered my question"/"This didn't tell me everything I needed to know"/"This did not work for my system"/"I think it could be done or said more simply"/"The page misses some important (e.g. security) issue" plus an option to be contacted for more details. That should also (after human checking) make it's way into the page's "usefulness score". And there should be a ranked list of pages needing "some love" with an indication of just how in need of attention they are, so pages don't remain out of date too long. Related to that, and something that could (like Wikipedia, etc) be automatically checked and made obvious to editors), there should be some sections on most pages in a standard format, e.g.: * a subsection "Documentation checked up to release nnn" * a subsection "Older versions" describing differences for users of earlier releases. * instructions on what firewall changes are needed (if none say so for any page mentioning installing anything or changing any system option/file) * a "For example" section * a "Checking your changes" section * a "Security implications" section * a "Why you might not want to do this" section(!!), for example saying there are other ways to do the same thing, or how much performance hit you might get, or how things may freeze for a while if another system is down, or security worries, etc. And it shouldn't just list options (e.g. no_subtree_check) it should either say why to choose/disable the important ones, and perhaps link to some page with a discussion - perhaps forum-linked. and ways to link to the pages that we can be pretty sure will stay valid for a long time... e.g. if the page has a quick explanation of how to allow SELinux or a firewall to allow the changes to work, but you want to link to more detailed instructions on another page, then that link should stay valid for a long time. Maybe a way, even, for editors to say "this page depends on this link", although it should be possible to work this out automatically and warn any person editing editing the linked page if it will break links from other pages. Thoughts? Mark Aitchison

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs August 2017