[RFC] dumping the CED in favor of local variables
by Karsten Wade
I'd like to recommend we dump the usage of CED files in favor of the
local variables designation. The CED file is a pre-compiled DTD subset.
http://fedora.redhat.com/participate/documentation-guide/s1-emacs-cedfile...
The only noticeable change that matters is that indenting is different
by two characters overall. It's really no big thing to reindent entire
files, or sections of them to avoid <screen> blocks.
The CED files technically need to be recompiled with the introduction of
each new tag. They are a hassle to load everytime you load the
document.
The local variables will load the parent file in the buffer, which is
convenient, and does all this automatically when you open the file.
You put one of these at the bottom of each XML file:
<!-- Keep this comment at the end of the file
Local variables:
mode: xml
xml-parent-document:("parent-file.xml" "book" "chapter")
End:
-->
The small pain of converting our docs will be more than made up for in
the not-so-long run.
- 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, 12 months
Comments on Documentation Idea
by Thomas Jones
Hello all,
I have been reviewing the progress of the Fedora project for over a year
now. Honestly, I was a little reluctant to transition to another
distribution. I had been a mainstay of SuSE since release 7.0; mainly
because of the security oriented nature of the product(s).
Now that I've made the plunge and am loving it; I want to provide my
services to the community where I can. Here goes my idea:
What about a documentation suite entitled --- Fedora Security Series?
Here's a brief vision statement.
The purpose of the series is to provide a security-related orientation
of a great multitude of topics and how they relate to the Fedora
distribution and its role in a network infrastructure.
For instance, the first couple topics that I would like to write would be:
- Risk Assessment of a Fedora Core Installation Scheme
- Risk Analysis of an Desktop Installation
- Risk Analysis of an Server Installation
- Policy Development in a Multiuser System
- etc......
As you can see, the topics are sequential in structure. Which alleviates
any issues due to end-user initiated problems.
i.e. in order to develop a complete operating system risk analysis and
determine a control solution(s); you must first perform the risk
assessment to determine probable threat agents, and safeguards
The intended audience would be Power-Users, and individuals with
Information Technology experience. However, with a good content model it
should be easily understood by the general user.
This series should be authored by individuals with relevant security
experience. They don't need to be CISSP certified; just have first hand
knowledge of the topic.
I am inclined to get the series started in the right direction; so I
would like to write the first few topics for a good base. Then it's up
to the community!
These should all be included in a series of related themes.
I can start the first topic as soon as the community accepts the idea. I
personally think this is great idea (of source I would!); but don't want
to work on this idea; if it undermines the ideas of other team members.
Thank you for your time.
Thomas Jones
19 years
CVS now open
by Karsten Wade
Hi fellow writers and editors:
We are mighty pleased to announce the opening of CVS for the Docs
Project.
Our intention is to have the lowest barrier to entry possible. After
getting our grubby little hands, uh, I mean, fine Elven fists on the
keys a few weeks ago, we have been formulating some philosophy and
guidelines to help make our experience nicer.
## Quick Version of How To Get CVS Access:
* Read the CVSAccess guidelines Wiki page[1]
* Do a proper self-introduction to the list
* Show that you have something to put in CVS: as an editor by picking
something to edit, as a writer through producing a draft or working
outline
* Use the proper process[2] to get an account on cvs.fedora.redhat.com
[3]. Put yourself in the 'cvsdocs' group and wait for approval.
[1] http://www.fedoraproject.org/wiki/DocsProject/CvsUsage
[2] http://www.fedoraproject.org/wiki/Extras/CvsAccess
[3] https://admin.fedora.redhat.com/accounts/
This all presumes you have read the Documentation Quick Start[4] and are
familiar with the Fedora Project Documentation Guide[5]. Don't worry
about the DocBook/XML stuff right now. :)
[4] http://fedora.redhat.com/participate/documentation-quick-start/
[5] http://fedora.redhat.com/participate/documentation-guide/
## What Philosophy?
Golden Rule in effect. Treat others and their directories in CVS as you
would have them treat you and your files.
Only truly vital resources will have CVS ACLs. You are on your best
behavior as a community member to Do The Right Thing.
Don't put any illegal stuff in CVS. That would be BAD.
Don't attempt (or succeed) in cracking the CVS host systems, or use it
as a launchpad for crack attempts. That would be VERY BAD.
## Who Gets to Go Where?
Read the CVSAccess[1] page for details. The quick version is that
assigned writer(s), editor(s), and a doc manager are the only ones who
should be messing around in a particular directory.
The doc manager is the single person accountable for what goes on in the
directory. It can be one of the writers, editors, or third person
otherwise not involved. To start, it's likely to be one of the FDSCo
members, lending a wise and guiding hand where needed. *cues ethereal
music*
Each doc has one or more writers who must collaborate together within
the same repository. Thank ye gods for revision control!
An editor can edit for technical and grammatical/wordsmith details. The
editor must know and enforce the style guidelines from the Doc Guide[6].
There may be more than one editor to fill all the roles.
[6] Forthcoming URL _will_be_:
http://fedora.redhat.com/participate/documentation-guide/ch-style.html
NOTE: URL does not work. We're, uh, editing it for style. Long story.
Coming Real Soon Now, with a shiny announcement.
--
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/
19 years
docs CVS commits - new list
by Karsten Wade
Until it was recently changed, our CVS commit messages were being copied
to a list for Fedora Extras. To highlight our own signal, I changed the
commit messages to come to fedora-docs-commits. Currently our commit
level is low, but as it ramps up, we are going to be glad that this is
not coming to f-docs-l. :)
https://www.redhat.com/mailman/listinfo/fedora-docs-commits
This is an important part of having an open CVS, seeing what everyone is
doing. Mistakes will be caught more quickly, and it will be easier to
learn how and why writers and editors do as they do.
For example, in the past I've collaborated with other writers on the
same XML files, and I could watch the changelog messages to see what
people did and why they did it (presuming their log was useful). I
would know right away if I needed to fix anything.
If you are writing or editing for the project, it is truly necessary to
be on the commits list.
cheers - 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/
19 years
[Fwd: [LINK] Open source projects for those on the dole (fwd)]
by Karsten Wade
Anyone in Australia want to see if there are potential doc writers in
this program? DocBook/XML is much easier to learn than most
programming, is a real world skill, and we sure could use docs from
regular users for regular users.
Open source projects for those on the dole
Angus Kidman
APRIL 26, 2005
The Australian
http://australianit.news.com.au/articles/0,7204,15083420%5E15317%5E%5Enbv...
A NEW "hack for the dole" scheme will allow unemployed people to meet
their mutual obligation requirements by working on open-source software
projects.
Linux Australia has gained approval for the scheme being launched as
part of its CommunityCode.org project to encourage software development.
It is trying to attract skilled enthusiasts to work as mentors.
Project developer Matthew Palmer said he had begun working with a mother
who was developing educational software for children.
He said early interest in the project, launched last week at
Linux.conf.au 2005 in Canberra, had been strong. "I've talked to heaps
of people and they've all been really keen on it," he said.
As well as coding, other tasks under the scheme could include
documenting and art.
As a community organisation, Linux Australia meets government
requirements for organising mutual-obligation projects for the long-term
unemployed.
Mr Palmer said, although Linux was easy to use as a desktop operating
system, one goal for the Community Code.org project was to make
contributing software modifications an equally straightforward task for
everybody.
--
We have yet to see the full impact of the open, global marketplace. By
1997 all raw materials and technology will be available everywhere in
the world. The only differences between countries and markets will be
skill levels, education, and the level of empowerment of the workplace.
-- Sydney Smith
Regards
brd
Bernard Robertson-Dunn
Sydney Australia
brd(a)iimetro.com.au
_______________________________________________
Link mailing list
Link(a)mailman.anu.edu.au
http://mailman.anu.edu.au/mailman/listinfo/link
_______________________________________________
Memo-list mailing list
Memo-list(a)redhat.com
http://post-office.corp.redhat.com/mailman/listinfo/memo-list
--
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/
19 years
Self Introduction: Just because it wasn't a practice when I joined! ;-)
by tuxxer
1. Full legal name
Charles C Heselton
2. City, Country
San Diego, CA, USA
3. Profession or Student status
Security Engineer
4. Company or School
Raytheon
5. Your goals in the Fedora Project
* What do you want to write about?
Security pertinent topics.
* What other documentation do you want to see published?
Security related documentation. ;-)
* Do you want to edit for grammar/writing and/or technical accuracy?
Sure.
* Anything else special?
I believe in the open source community and I want to contribute
wherever, and however, I can. Plus, I like to drink beer. ;-)
6. Historical qualifications
* What other projects or writing have you worked on in the past?
Mainly proprietary stuff, SOP's etc.
* What level and type of computer skills do you have?
Gimme a scale. ;-) I can script (perl, shell, etc.), write web pages,
etc. I've been in the industry for about 8 years, security specifically
for about 3 years.... I've been working with Linux since Caldera
OpenLinux 3.2?? (circa 1999-ish)
* What other skills do you have that might be applicable?
Not sure.....don't know fully what the requirements are yet.
* What makes you an excellent match for the project?
I'm interested, I want to contribute, and I have time to spare.
(well.....some. ;-)
7. GPG KEYID and fingerprint
pub 1024D/F1E11EA1 2004-05-02
Key fingerprint = 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1
1EA1
uid Tuxxer (Tuxxer) <tuxxer(a)cox.net>
sub 1024g/A168232E 2004-05-02
19 years