Minutes from Docs meeting on 7 August
by Brian Exelbierd
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
6 years, 8 months
Self-Introduction
by Nathan Hicks
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
6 years, 8 months
A suggestion for automatic categories for wiki pages...
by Mark Aitchison
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
6 years, 8 months
