To do this, the FDSC oversees all aspects of the docs project,
including writing, editing, CVS, publication (Web, etc.), and project
membership details.

Committee membership is expected to take one to two hours per week.
This time is in addition to any commitments as a project member.

III. Scope of Work

The following sections describe the work engaged in by the FDSC, as
drawn from the groups purpose.

A. Making operational decisions

The committee meets once per week on IRC (#fedora-docs on
irc.freenode.net at TBD). The purpose of this meeting is to assign
tasks, check on the status of work, help unblock activities or resolve
issues, and anything else necessary to keep the project on track.

Committee discussions occur on the fedora-docs-list@redhat.com mailing
list (f-docs-l). Meeting notes are posted copies of the IRC log
mailed to f-docs-l. A list of links to the archives of the mailed
notes may be posted on the Wiki.

An operational decision is anything that needs deciding, such as
assigning or requesting an editor or writer to a work on a specific
task, or implementing a part of a project strategy.

In their position, committee members are empowered to act as final
editors, committers, and Web publishers. As such, the first-round
committee members shall also be the first to be able to commit to
CVS. As per the rules of the Fedora Project, all committers need to
follow the procedure to get CVS access, although Red Hat contributors
do not need to sign the Contributor License Agreement (CLA), as
described in the process on this page:

C. Practice open and accountable leadership

This one seems like a no-brainer. Still, conversations are taken
off-list, or are never on-list in the first place.

Meetings are open on IRC, with minutes posted to the mailing list.
Discussions are had on f-docs-l. Any discussions that occur off-list
or via IRC are brought on ASAP.

For the docs project in particular, this is a chance to lead by
example. Open content is even more contentious than open source
software. There is a large quantity of opposition to keeping
information free. Persecution and prosecution of people who work to
keep informed content free continues. Because of the danger of
self-censorship in a closed or partially open format, it is safer to
work entirely in the open.

This is a best practice. If something needs to be discussed on the
side to keep the on list flow going, so be it. Consensus reaching is
always done on list, and that requires completely open information.
Any content (ideas) and work generated off-list should be brought into
the sunshine as soon as feasibly possible.

This document is a self-referential example. It was written by one
person, vetted by three other people, then posted to the Wiki. It is
not a way of setting something in stone through secret dealings, it's
just an efficient way to trust modular project teams to do their jobs.

D. Consider the long-term strategy of the project.

It is an important part of the leadership of the steering committee
brings to the FDP to study and act upon long-term strategic
objectives.

E. Act within the goals and beliefs of the overall Fedora Project

IV. Audience

The work of the FDSC is intended to benefit the members and
deliverables of the FDP. Other audiences include Fedora developers
and the Fedora Steering Committee.

V. Committee Requirements and Terms of Service

Note: This content may be moved to a process document.

Following the first round, potential committee members have to be a
committer for at least one full Fedora release cycle. Their actions as an editor,
writer, and committer form a part of the recognition required to do
committee service. For the first round, some active participants in
the Fedora community received an offer to join the steering committee.
This first-round list of persons was decided upon by the Red Hat
members of the committee in consultation with other Red Hat members of
the Fedora Project.

The committee consists of a roughly even mix of Red Hat employees and
Fedora community members. To be effective, the committee needs to represent the community as a whole.

Each member commits to a minimum of one or two full release cycles of active
duty on the committee. This is decided upon by the member, based on their own
requirements. At the end of their term, they may be asked to extend,
or may opt to request to extend, subject to the consensus of the
committee. It is expected that many people will continue to hold the
position they have attained through merit. There is no limit to the
size of the lurking committee, although there is a natural limit of how many
people will be active and effective. If a committee member becomes
inactive, they should move themselves to the inactive or sabbatical
list. It is considered good to have many archived committee members
available to help new members keep from making mistakes of the past.

Active members need to attend meetings to remain active. A member who
has moved to the inactive list can be made active again by requesting
reactivation from the current actitve members of the committee.

The committee chair is the de facto project leader, and serves that
role within the Fedora Project. The chair must be a Red Hat employee,
as per the rules of the Fedora Project.

The committee chair agrees to a two or three release cycle of duty. The new
chair arises from the committee, and has the consensus of the entire
committee for the position. Refer to 2. Committee Consensus Process
for more on how to do this. A chair may request to extend the duty
another release cycle or two, subject to the vote of the full
committee. Similarly, the committee can request the chair to extend
service, but the chair has the option of refusing.

The committee and the chair are subject to any rulings that come from
the overarching Fedora Steering Committee. It is the duty of the chair to
represent the FDP within the overall project, meaning such decisions
will have followed a similar open consensus process and should not be
a surprise to project or committee members.

As part of their service, the committee should attempt to meet
face-to-face at least once per year. This can be at a convention such
as FUDCon, LWCE, or similar. Such meetings are essential to keeping
the human factor intact in what is essentially a human endeavor - free
and open information. Whereas this is an official request of the
Fedora Documentation Steering Committee, use this as leverage
wherever you can to get permission and funds to get together with the
committee. This is a request, not a requirement, but a strong
request. This is an ongoing effort to make happen.

VI. Committee Consensus Process

For information about the consensus process, refer to the FDSC
process documentation at: