Fedora Documentation Steering Committee (FDSC) Charter
Revision History
29-MAR-2005 - Karsten Wade <kwade@redhat.com> First draft
03-APR-2005 - Karsten Wade <kwade@redhat.com>
Release draft, incorporates guidance from gdk, tfox, mjohnson
Moved process pieces to separate process doc
Clean-up
05-APR-2005 - Karsten Wade <kwade@redhat.com>
Final clean-up prior to Wiki posting at:
http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Charter
Release 1.0 of the FDSC charter
19-APR-2005 - Karsten Wade <kwade@redhat.com> Minor changes to make document acceptable to FDSCo Approval and acceptance of the charter by the FDSCo
I. Name
The Fedora Documentation Steering Committee, also known as FDSC or FDSCo. Convention suggests latter be pronounced "eff-disco". This committee oversees the Fedora Documentation Project (FDP).
II. Statement of Purpose
This section addresses the goals of the FDSC.
At its core, the purpose of the FDSC is to make the Fedora Documentation Project successful.
To accomplish this, the FDSC has several key functions:
- A. Make operational decisions for the project.
- B. Maintain a list of active tasks.
- C. Practice open and accountable leadership.
- D. Consider the long-term strategy of the project.
- E. Act within the goals and beliefs of the overall Fedora Project.
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:
http://fedoraproject.org/wiki/Extras/CvsAccess
The committee is actively discussing the process for adding new CVS committers. Our philosophy is to avoid a Cathedral CVS. We'll see how good of a job we do.
B. Maintain a list of active tasks on the project Wiki
A Wiki is chosen because of the ease-of-updating and ability to share maintenance tasks. It is also similar to what other Fedora project teams are doing.
To start, this is a bulleted list with some structure/order. It is a first meeting agenda item to create and maintain this list.
http://fedoraproject.org/wiki/DocsProject/MasterTasks
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
Another no-brainer. To be a Fedora project, act like one.
Here is the canonical document for these goals and beliefs:
http://fedora.redhat.com/about/objectives.html
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:
DocsProject/SteeringCommittee/ProcessDocs