[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Fedora Docs Steering Committee



As part of the evolution of the Fedora Project, we have formed a
steering committee to oversee documentation activity.  

http://fedoraproject.org/wiki/DocsProject/SteeringCommittee

The Fedora Documentation Steering Committee (FDSC) is:

* Gavin Henry 
* Karsten Wade (chair/project lead) 
* Mark Johnson 
* Paul Frields 
* Stuart Ellis 
* Tammy Fox 
* Tommy Reynolds 

## More information below than you want to read, unless you want to:

In essence, the overall Fedora Steering Committee empowers the Fedora
Documentation Steering Committee (FDSC) to run the documentation project
according the guidelines of the overall project.  The chair of the
committee (that's me) is then accountable for the entirety of the
documentation process.  The chair can delegate any of those tasks, from
writing and editing to managing CVS and Web publication.  In fact, the
structure is such that the chair -must- delegate or drown in the
workload.

All committee work is done in the open.  Read the charter and process
docs linked from the Wiki page above for more information.

It is a stated goal of Fedora steering committees to be balanced with
members of the Fedora community.  This translates as, "People who don't
work for Red Hat."

For this reason, we have formed the first round of the committee with
four members of the community-at-large and three of us from Red Hat.
      
If you want all the gory details of what the committee does and how it
works, read the charter and process docs.  These people were picked for
the committee because of merit.  In the future, when there is more room
on the committee and/or sub-committees are created, we will be looking
around for other project members who merit inclusion.

My objective, in chairing the committee and running the project, is to
get relevant Fedora documentation written.  My emphasis is on quality
over quantity.  You will see the FDSC active on the list, working out
processes, and working within and without process to get stuff done.

There are advantages to having a minimal amount of order.  Many here
would agree with this approach.  It is easier to get stuff done.  Even
grassroots organizing is organized.

There are also advantages of process.  Without enough good process, the
project will not survive.  A company can enforce process on their
management of a distro, but for a community to buy into the process, it
must arise from the community.  There will be necessary process created
and followed for this project.

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/

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]