Self-Introduction: Kara Pritchard
by kara＠kspei.com
Full legal name: Kara J. Pritchard
City, Country: Fairview Heights, IL USA (suburb of St Louis)
Profession: Own a computer consulting, service, and retail shop.
Company: K&S Pritchard Enterprises, Inc. (www.kspei.com)
Goals: My goals are simple... to contribute. Since moving on from LPI and
not having the extended time for publishing projects anymore, the itch to
contribute somewhere has been strong. My husband is a maintainer for a
few Extras packages and suggested I take a look at this project. I must
admit that my available free time is erratic, however.
What do you want to write about?
KJP: I'm best with instructional documentation such as HOWTOs,
Step-By-Step, or Training guides. Therefore, I think topics geared toward
the user audience would be the most interesting.
Do you want to edit for grammar/writing and/or technical accuracy?
KJP: I've done technical editing for several book and magazine publishers.
I'm quite opinionated when it comes to the clarity and feel a reader gets
from a writing sample. I'm very good at giving that opinion, so don't ask
me to do it if you don't want any complaints :)
What other projects or writing have you worked on in the past?
KJP: I authored two editions of the RHCE Exam Cram in '99 and '00. I
contributed to a guide to DocBook, been a project reviewer for New
Riders, an editor for O'Reilly, IDG, and Linux User/Format/Magazine. I
was also responsible for all the content development for the LPI exams
from Dec '99 through this spring.
What level and type of computer skills do you have?
KJP: I'm becoming quite the hardware geek. I build a lot of Linux-based
workstations and high-end servers. I do more admin work when it comes to
Linux than consulting, installation, etc. I'm not a programmer, though
have been known to read through a perl or shell script on occasion.
What other skills do you have that might be applicable?
KJP: Good people skills, project management background
What makes you an excellent match for the project?
KJP: Long history in the Linux community, prior Linux-related technical
content development, editing, and management experience. Very
short-winded.
GPG KEYID and fingerprint
[kara@frell gpgfiles]$ gpg --fingerprint 6DEC5002
pub 1024D/6DEC5002 2002-01-22 Kara Pritchard <kara(a)kspei.com>
Key fingerprint = 42AC 471F 6E98 8134 C39E 81F4 9F2E 1DEE 6DEC 5002
uid Kara Pritchard <kara(a)luci.org>
uid Kara Pritchard <kara(a)lpi.org>
sub 1024g/27194020 2002-01-22
Kara Pritchard Phone: 618-398-3000
President, KS Computer Room Inc. kara(a)kspei.com
Southern Illinois Linux Users Group www.silug.org
--
18 years, 9 months
f.r.c organization
by Paul W. Frields
Karsten mentioned to me offhand last night, after the meeting, that we
may need some standards in place for publication directories on
fedora.redhat.com. At least some of our publications will (hopefully)
eventually be translated, and some may branch for different versions of
Fedora Core. The locations on the Web site should reflect this. Here's
some initial thoughts, any of which might be wrong: :-)
1. No directory should include the name "fedora," simply because it's
redundant.
2. I'm not an Apache expert, but I'm pretty sure there is functionality
for redirecting client requests based on the browser's reported language
settings. In other words, if a client asks for "index.html," and it
reports language "en," the server can deliver "index.en.html," or some
such. Same for "ru," "ko," etc. We should try to take advantage of
this with our current directory build names of "document-name-en,"
"document-name-ru," etc., and not separate this off into a folder
hierarchy of its own.
I could see this as a good way to organize:
docs/
selinux-faq/
fc2/
index.php ...
fc3/
fc4/
jargon-buster/
release-notes/
fc3/
fc4/
...
The only glitch I see is that moving directory names around is a CVS
nightmare, so the initial conversion will be ugly on the commits list.
Does anyone see other problems with this standard?
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 9 months
web publishing
by Karsten Wade
Here's a helpful (beta) methodology with pointers for updating the
fedora.redhat.com/docs site:
http://fedoraproject.org/wiki/EditingFedoraRedhatCom
Let us know any problems you have with it, or just fix the page
yourself. :)
Why do you want to know about this?
One of the important roles in the publishing chain is the Web Publisher.
These persons convert documents to post on fedora.redhat.com/docs, QA
the work before making it live, and are responsible for making the
changes go live.
During the Push to Publish Week (P2PW), having more people trained on
this important final step is a key to successful publishing.
Once you have this setup, you are free to provide patches and bug
reports for other parts of f.r.c, such as project pages, the Developer
Guide, various participation pages, and so forth.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
18 years, 9 months
Push to Publish Week 18 - 22 July
by Karsten Wade
Writers and editors, grab your red pens, correction fluid, and XML
skills.
The week of 18 to 22 July is the first FDP Push to Publish week.
Everyone is encouraged to participate. We're trying to get as many
documents edited and published as possible.
Do you have a document that has been languishing in CVS?
A tutorial almost completed that just needs $SOMETHING more to get it
published?
A final barrier we can help you break through?
All challenges considered!
Meet here on this mailing list next week. We'll see what this
documentation community has to say.
- Karsten
PS: This is a pre-announcement that we're likely to follow up with the
week of 25 - 29 July as a second P2PW. If some of the excitement of the
first week rubs off on you, maybe you'll be ready by the second
week. ;-)
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
18 years, 9 months
new bugzilla status for FDP
by Karsten Wade
Because we are getting so many individual guides and projects to track,
it made sense to move our bugzilla work into a separate Product category
in bugzilla.
Now, when you are entering a new bug report[1] or from within an
existing bug, you can choose Fedora Documentation as the Product. This
is a dropdown menu within the bug report. Then, each guide has an
individual Component.
Bug reports are automatically filled with initial owner and QA contact,
as well as Cc: list. This helps us receive, sort, and manage bug
reports more easily. It also raises the visibility of the Documentation
Project as a peer within the Fedora Project community.
Enjoy,
Karsten
[1] https://bugzilla.redhat.com/bugzilla/enter_bug.cgi
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
18 years, 9 months
minutes FDSCo meeting 12 July 2005
by Karsten Wade
/me sings
~\o ... in a blaze of glory ./~
Fedora Documentation Steering Committee (FDSCo)
12 July 2005
#fedora-docs, irc.freenode.net, 2000 UTC
Attending:
==========
Karsten Wade
Stuart Elliss
Tammy Fox
Tommy Reynolds
Gavin Henry
Mark Johnson
Paul Frields
Updates:
========
The file in /cvs/docs/owners/owners.list is where we edit to define
all bugzilla components in the new Fedora Documentation product.
FDP now has a top-level in bugzilla. See announcement to f-docs-l.
Actions:
========
Karsten - announce Push to Publish week for 18 - 22 July, preannounce
a repeat the following week
Karsten - update http://fedoraproject.org/wiki/DocsProject/Tasks with
new product-level bz info, use fewer words
Karsten - start posting IRC log to f-dsco-l again
Karsten - announce new product-level status in bugzilla
Paul - update doc-guide outline to include new task process
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
18 years, 9 months
tidy-bowl - BETA invitation!
by Paul W. Frields
Greetings FDPers,
Tommy and I have been collaborating on a method to mitigate our problems
with multiple editors. When FDP started, we envisioned a beautiful,
pristine world in which everyone used Emacs+psgml -- pipe down,
Tommy ;-D -- and collaborating writers and editors would not end up
reformatting each other's work, since they were using the same tools.
However, that expectation has proved somewhat unreasonable, especially
in light of (1) our goal to lower barriers for entry as far as possible,
and (2) the proliferation of XML editors out there. As a result, the
FDP canon will, in all likelihood, no longer require people to use
specific tools, although a preference for Emacs+PSGML is likely to
linger, since the majority of the editors are using those tools.
An XML normalization engine (xmlformat) will reformat docs when they are
imported or committed to CVS. It uses a configuration file which should
not complicate life for writers or editors using most tools of which
we're aware. Because the normalization does not change the actual copy
of the file on your disk, you don't have to worry about how the
committed version might have different whitespace, margins, blocking,
etc. from your copy on disk. You simply keep editing as usual. Any
person checking out a file from CVS will get the normalized version,
which they can feel free to *reformat* locally. Any such changes will
be "stripped" when commits are made. Only the content matters.
CAVEAT: Once you make a change to a .xml document where your local copy
is NOT normalized, when you use the "cvs diff" command, the diff will be
very long because of the normalization differences. Sorry, folks, that
part's out of our hands; it was the price we paid to allow more tools
out there, and it seems worth it. The diff that actually ends up going
to the fedora-docs-commits list from the CVS server *will* be sane.
If you must have a sane local diff, you can run "cvs up -C <file>" to
replace your non-normalized file with the normalized version from the
repository. If you have uncommitted work in the file, commit it before
you run that command, or it will be lost. The only drawback is that
your editor may want to reformat the file again when you next load it.
This will not affect CVS.
So now, THE INVITATION:
For now, the only module that is normalized is the xml-normalize/
module. Please feel free to add files there and observe the results...
i.e. beat on the script. If something breaks, please report problems to
the list, Tommy, or me. Please check the log for a file before you
diddle with it, so as not to inconvenience another tester. Thanks and
have fun!
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 9 months
