<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/doc-policy.xml,v 1.3 2004/08/26 16:16:04 swift Exp $ -->

<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">

<guide link="/doc/en/doc-policy.xml">

<title>Gentoo Linux Documentation Policy</title>
<author title="Author">
    <mail link="zhen@gentoo.org">John P. Davis</mail>
</author>
<author title="Author">
    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
</author>
<author title="Editor">
    <mail link="spyderous@gentoo.org">Donnie Berkholz</mail>
</author>

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->

<abstract>
This document contains the Gentoo Documentation Policy, which is the
base document which all Gentoo Documentation developers and
Contributers should know and exercise.
</abstract>

<license/>

<version>3.6</version>
<date>August 14, 2004</date>

<chapter>
<title>Introduction</title>
<section>
<title>Introduction</title>
<body>

<p>
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 <e>all</e> documentation must go through before it is 
published on our website, or otherwise.
</p>

</body>
</section>
<section>
<title>Covered Topics</title>
<body>

<p>
This policy will cover these topics: 
</p>

<ul>
<li>Documentation Project Team Organization</li>
<li>Documentation Guidelines</li>
<li>Documentation Team Recruitement</li>
</ul>

</body>
</section>
</chapter>

<chapter>
<title>Documentation Project Team Organization</title>
<section>
<title>Organization</title>
<body>

<p>
The Gentoo Documentation Project Team is split into several smaller teams
that operate in complete cooperation with each other. Each smaller team
represents an active development team of a Gentoo Documentation
Subproject.
</p>

<p>
The Gentoo Documentation Project is strategically lead by a top-level 
manager as required by the 
<uri link="http://www.gentoo.org/doc/en/management-structure.xml">Gentoo 
Management Structure</uri>. This document also describes the responsibilities of
the strategic manager with respect to Gentoo Linux.
</p>

<p>
For day-to-day managerial tasks the Gentoo Documentation Project has an
operational manager. This person keeps track of all
documentation-related tasks that are more short-term. The operational
manager and strategic manager can be one and the same if the strategic
manager wishes so.
</p>

<p>
Currently these positions are taken by the following people:
</p>

<table>
<tr>
  <th>Position</th>
  <th>Developer Name</th>
  <th>Developer Nick</th>
</tr>
<tr>
  <ti>Strategic Manager</ti>
  <ti>Sven Vermeulen</ti>
  <ti><mail link="swift@gentoo.org">swift</mail></ti>
</tr>
<tr>
  <ti>Operational Manager</ti>
  <ti>Xavier Neys</ti>
  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
</tr>
</table>

<p>
Every subproject has a strategic manager of its own. He or she can
have an operational manager if he or she deems appropriate. His
responsibilities to the Gentoo Documentation Project are the same as are
listed on the <uri
link="http://www.gentoo.org/doc/en/management-structure.xml#doc_chap1_sect5">Gentoo 
Management Structure</uri>.
</p>

<p>
The subprojects of the Gentoo Documentation Team together with their
respective strategic managers are listed on the <uri
link="http://www.gentoo.org/proj/en/gdp">GDP Website</uri>. 
</p>

<p>
The decision on adding subprojects is in hands of the strategic manager. 
</p>

</body>
</section>
<section>
<title>Documentation Project Team Members</title>
<body>

<p>
Every member of the Gentoo Documentation Project must be subscribed to
the <mail link="gentoo-doc-subscribe@gentoo.org">gentoo-doc@gentoo.org</mail>
mailing list. This mailing list will be used to discuss all
documentation-related issues. This mailing list is open to all interested
parties, developer or not.
</p>

<p>
Every member of the Gentoo Documentation Project must be subscribed to
the <mail link="docs-team@gentoo.org">docs-team@gentoo.org</mail> alias.
This alias is <e>only</e> used by <uri 
link="http://bugs.gentoo.org">bugs.gentoo.org</uri>
to inform the documentation team about bugs regarding the Gentoo
Documentation.
</p>

<p>
Every member of the Gentoo Documentation Team should be available at
<c>#gentoo-doc</c> on <uri link="http://www.freenode.net">irc.freenode.net</uri>
whenever he or she is online. 
</p>

<p>
Depending on her/his responsibilities, he or she can have limited CVS 
access to <c>cvs.gentoo.org</c>. CVS access can only be given to Gentoo
developers. 
</p>

</body>
</section>
<section>
<title>Documentation Translation Teams</title>
<body>

<p>
Every language should be backed up by an official translation team. This
team is lead by a lead translator and perhaps a follow-up lead translator, who 
both have CVS commit access. If for any reason the lead translator cannot
perform his or her duties, the follow-up lead translator is in charge. If
even this person is unavailable, the mentor(s) is/are in charge of the language.
</p>

<p>
If a translated document is contributed, but the language in itself is
not supported, the Gentoo Documentation Team will not publish it
officially. In this case the document will stay unlinked until an official
translation team of that language is formed.
</p>

<p>
When a language is officially supported, but the team doesn't have any
members or no one wants to take on the responsibilities of the lead
translator, all links to the documents will be removed from the site.
However, the documents will stay available in case the language becomes
officially supported again.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Gentoo Documentation Guidelines</title>
<section>
<title>Legal Issues</title>
<body>

<p>
Every document published by the Gentoo Documentation Project must be
licensed by the <uri 
link="http://creativecommons.org/licenses/by-sa/2.0/">Creative Commons 
Attribution-ShareAlike License</uri>. 
</p>

<p>
Every document must have the following tag inside its GuideXML
sourcecode between the <c>&lt;/abstract&gt;</c> and the <c>&lt;version&gt;</c>
tags:
</p>

<pre caption = "Licensing notice for the Gentoo Documentation">
&lt;/abstract&gt;
<i>
&lt;!-- The content of this document is licensed under the CC-BY-SA license --&gt;
&lt;!-- See http://creativecommons.org/licenses/by-sa/2.0 --&gt;
&lt;license/&gt;
</i>
&lt;version&gt;...&lt;/version&gt;
</pre>

</body>
</section>
<section>
<title>Bugs and Updates</title>
<body>

<p>
Every bug reported on <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>
should be handled as fast as possible. If a bug cannot be handled 
in a timely fashion, the reporter of that bug should be informed about
this using a comment on the bug. The tactical or operational manager can 
decide that a bug has a higher priority and should be handled first before any 
other task the assingee is responsible of.
</p>

<p>
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
<c>docs-team@gentoo.org</c> is on the Cc-list. Unless with the consent
of the operational manager, a bug may not be taken away from another
Gentoo Documentation Team member without their approval.
</p>

</body>
</section>
<section>
<title>Document Development</title>
<body>

<p>
Every document the Gentoo Documentation Team develops can be developed
as the related parties see fit. However, when the document is finished,
it should be transformed into <uri 
link="http://www.gentoo.org/doc/en/xml-guide.xml">GuideXML</uri>.
</p>

<p>
When a new document is started or a big change is needed, a bug should be filed 
at <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>
concerning the development of this document. If there is already a bug
in the database that requests a change to the documentation, a new bug
does not have to be filed. Grammatical, syntactical or small changes
do not require a bug to be filed on <uri 
link="http://bugs.gentoo.org">bugs.gentoo.org</uri> as well.
</p>

<p>
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.
</p>

<p>
When updating a handbook-related file (such as the various
<path>hb-*</path> files) you must bump the parental
<path>handbook-&lt;arch&gt;.xml</path> file as well and commit all files at
once (which also means an identical commit message).
</p>

<p>
All changes in XML formatting should lead to version (and date) bumps only in 
case the layout of the document changes.
</p>

<p>
Whether or not to increment the major version number instead of minor version
number or other is up to the editor.
</p>

<p>
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.
</p>

</body>
</section>
<section>
<title>Reviewing and Committing</title>
<body>

<p>
To keep a high-pace development cycle of the documentation, technical or
intrusive changes to documents can be propagated immediately to the document
<e>if</e> the editor is 100% confident his changes are correct and working. If
you are not 100% confident (for instance because a user has told you how to fix
it but you cannot verify yourself), have the change reviewed by a Gentoo
Developer that can verify the change.
</p>

<p>
High volume, technical or intrusive changes must be accompanied by a bugreport 
on <uri>http://bugs.gentoo.org</uri>. This bugnumber <e>must</e> be mentioned in
the CVS log to allow backtracing of changes.
</p>

<p>
If a bugfix consists out of both content as internal coding changes,
both changes must be committed seperately so that translators can easily
view the important changes (content) and ignore the coding changes.
</p>

<p>
In case of a translation, the lead translator of the language is
responsible for the document. Only he or she may commit the document to CVS
unless he or she is currently "in training", in which case his or her
mentor should commit it.
</p>

</body>
</section>
<section>
<title>Sanctions</title>
<body>

<p>
Although this has never been necessary, it is still important to list this in
the policy - even though it is hateful. Anyway, documentation developers that
misuse their position by
</p>

<ul>
  <li>deliberately providing wrong information to users or developers</li>
  <li>deliberately writing flawed documentation</li>
  <li>deliberately corrupting documents</li>
  <li>
    deliberately go against the decisions made policy-wise or through a
    consensus-model on the Gentoo Documentation mailinglist
  </li>
  <li>
    not performing at all for a long time without informing the GDP and without
    replying to the operational manager's request for a status update
  </li>
</ul>

<p>
will be reported to the <uri link="/proj/en/devrel">Gentoo Developer
Relations</uri> project.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Documentation Team Recruitement</title>
<section>
<title>Contributors, Authors, Translators</title>
<body>

<p>
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 <c>gentoo-doc@gentoo.org</c>
and you have fully read this policy and understand it.
</p>

</body>
</section>
<section>
<title>Gentoo Documentation Developer</title>
<body>

<p>
As a Gentoo documentation developer should know everything in the <uri 
link="http://www.gentoo.org/doc/en/policy.xml">Gentoo Policy</uri>
even though you're not submitting ebuilds. You should also have read the
<uri link="http://www.gentoo.org/doc/en/gentoo-release-policy.xml">Gentoo 
Release Policy</uri> and <uri 
link="http://www.gentoo.org/doc/en/management-structure.xml">Gentoo Management 
Structure</uri>. This is all needed to ensure our userbase that no Gentoo 
developer gives wrong information about critical things.
</p>

<p>
Contact the operational manager of the Gentoo Documentation Project. He
will ask you for your coordinates and other information and then arrange 
a mentor for you who will guide you through the first days or weeks as
developer.
</p>

<p>
You will be given a Gentoo e-mail address and be appointed to one or
more subprojects. During the initial days or weeks, you should ask your
mentor as much as possible, preferably have him/her double-check everything
you do. If your function requires CVS access, you will only receive it
when your mentor deems it appropriate. Until then, your mentor is in
charge of the CVS commits.
</p>

</body>
</section>
<section>
<title>(Follow-Up) Lead Translator</title>
<body>

<p>
Becoming a (follow-up) lead translator shouldn't be held lightly. You are
responsible for every translated document and final reviewing. The lead
translator will make certain that the translated documents are
grammatically and syntactically perfect. 
</p>

<p>
In order to become a Gentoo (follow-up) lead translator you must be a Gentoo
developer.
</p>

<p>
During your "training" period you are a (follow-up) lead translator and 
should act upon it. All guidelines regarding (follow-up) lead translators 
apply.
</p>

</body>
</section>
</chapter>
</guide>
