The Gentoo Linux Documentation team aspires to create exceptionally
professional documentation that is immediately clear and concise to the
end user. In order to fulfill this goal, we have very specific rules and
guidelines that
This policy will cover the following topics:
The Gentoo Documentation Project Team is split into several smaller teams that work in tandem with each other. Each smaller team represents an active development team of a Gentoo Documentation Subproject.
The Gentoo Documentation Project is strategically led by a top-level Manager
as required by the
For day-to-day managerial tasks, the Gentoo Documentation Project has an Operational Manager. This person keeps track of all short-term tasks related to documentation. The Operational Manager and Strategic Manager can be one and the same if the Strategic Manager wishes so.
Currently these positions are taken by the following people:
| Position | Developer Name | Developer Nick |
|---|---|---|
Every subproject has a Strategic Manager of its own, and may have an
Operational Manager if deemed appropriate. His responsibilities to the Gentoo
Documentation Project (GDP) are listed in the
Every subproject of the Gentoo Documentation Team is listed on the
The decision on adding a subproject is in the hands of the Strategic Manager.
Every member of the Gentoo Documentation Project must be subscribed to
the
Every member of the Gentoo Documentation Project must be part of the
Members of the Gentoo Documentation Team should be available at
Depending on the assignment or responsibilities, a member may have limited CVS
access to
Every language should be backed up by an official Translation Team. This
team is led by a
If a translated document for an unsupported language is contributed, the Gentoo Documentation Team will not publish it officially. Such documents shall not be linked to the website until an official Translation Team of that language is formed.
When a language is officially supported, but the team does not have any
members willing to take on the responsibilities of the
For more information Gentoo document translations, please consult the
Every document published by the Gentoo Documentation Project must be
licensed by the
Every document must have the following tag inside its GuideXML
source code between the
</abstract> <!-- The content of this document is licensed under the CC-BY-SA license --> <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> <license/> <version>...</version>
Every bug reported on
Whenever a Gentoo Documentation Team member takes care of a bug, he or
she should assign the bug to herself/himself, but make sure that
Every Gentoo Documentation Team may handle documentation development as it sees
fit. However, when the document is finished, it should be transformed into
When a new document is started or a big change is needed, a bug should be filed
at
All changes in contents of the document, except for typo fixes in text itself or in the comments to code listings, should lead to version number (and date) increase. Note that the change of a Code Listings should definitely cause an increase of the version number and date.
All changes in XML formatting should lead to version (and date) bumps only in case the layout of the document changes.
Whether or not to increment the major version number instead of minor version number or other is up to the editor.
Every update of a translation should copy the new version information verbatim from the master English document so fully synchronised translations have the same version information.
To maintain a high-paced documentation development cycle, technical or
intrusive changes to documents can be propagated immediately to the document.
This is allowed only
High-volume, technical or intrusive changes must be accompanied by a bug report
on
If a bugfix includes changes to content as well as internal coding changes, both changes must be committed separately. This allows translators to focus on the relevant changes regarding content and ignore the coding changes.
If the document in question is a translation, the
Malicious conduct by developers has never been an issue. However, it should be noted that documentation developers that misuse their position by
will be reported to the
Everyone interested in contributing documentation, editing existing
documentation, writing new documentation or translating documentation is
welcome to join the team. There are no rules or strings attached to
this. Just make sure you are subscribed to
The Documentation Project has a strict recruitment process outlined below. This process can not be deviated from in any circumstance. We have opted for this recruitment process to assure ourselves that the recruit is well informed about the Gentoo Documentation Policy and the Gentoo Coding Style. It has proven to be quite effective even though many contributors see it as a too large burden to cross.
This recruitment process is meant only for requests to the Gentoo Documentation Repository through CVS. Being listed as the maintainer or Point-Of-Contact for a certain document or range of documents is granted by a simple request to the Operational Manager or Project Lead.
No recruitment process starts without investigating the contributions done already to the Gentoo Documentation Project. The number of contributions must be large to assure a good knowledge of GuideXML, Coding Style and policy. The contribution period must be large as well to inform the contributor about the time-consuming position and pressure the application involves.
The number of contributions and period over which the contributions should be made depends on the position which the contributor solicits for. Although it is difficult to write down these measurements in numbers, the following table should give a general overview. Final decision however lays in the hands of the Operational Manager.
| Position | Minimal Activity | Minimal Period |
|---|---|---|
An update constitutes a non-trivial update to any documentation, translation or otherwise, completely written by the contributor and committed after review by any existing documentation developer. The period is fixed - increasing the contributions does not decrease the period. Also, we don't average the contributions over time to make sure the contributor doesn't give a contribution burst, and then waits until the Phase is over.
Without this phase we can not know if the contributor understands what it takes to be a documentation developer. The validation of this activity happens through bugzilla reports.
Any request for CVS access that does not allow a development activity as written down in the aforementioned table will not be taken into account.
If you feel that you have shown sufficient amount of contributions, contact the Operational Manager of the Gentoo Documentation Project. He will ask you for your coordinates and other information, and then arrange for the next phase to be started.
During phase 2, the recruit is given read-only access to the Gentoo Documentation Repository, allowing him to generate commit-ready patches for the tree. During this period, which is roughly the same as the aforementioned table, his patches are not edited by a documentation developer anymore, but are either committed as-is or refused. The recruit is also assigned to a full-time documentation developer (the mentor) which will guide him through these last phases.
The quality of the contributions are in this phase most important - every patch that does not follow the Documentation Policy, Coding Style or other guideline that affects the document is refused.
During this period, you:
When Phase 2 is finished, the Operational Manager will contact