CAPI-SNAP-Doc/doc_dev_guide/sec_template_policies.xml

<!--
  Copyright (c) 2016 OpenPOWER Foundation
  
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
  
-->
<section version="5.0" xml:lang="en" xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="section_template_policies">

    <title xml:id="section_template_policies_title">Policies and conventions</title>
    <para>Most document style policies are established simply by using the provided documentation framework.  However, 
    by applying some conventions to the document source structure, community members will be able to work across more d
    ocumentation projects.</para>
    <para>The recommended documentation structure guidelines are as follows:
        <orderedlist>
            <listitem>
                <para>The head book file should be named with the prefix "bk_".</para>
            </listitem>
            <listitem  xml:id="section_template_vrm_policy">
                <para>The document versioning as defined by the <literal>&lt;releaseinfo&gt;</literal> tag in the main book
                file <literal>bk_xxx</literal> should be named "Revision V.R.M", not "Version V.R.M" or simply "V.R.M" where:</para>
                <itemizedlist>
                  <listitem>
                    <para>Significant updates increment the <literal>V</literal> (Version) value while reseting the <literal>R</literal> and 
                    <literal>M</literal> values to <literal>0</literal>,</para>  
                  </listitem>
                  <listitem>
                    <para>Material, but small, updates increment the <literal>R</literal> (Release) value and reset the <literal>M</literal> 
                    to <literal>0</literal>, and</para>
                  </listitem>
                  <listitem>
                    <para>Trivial updates (such as typos and grammatical changes) only need to increment the <literal>M</literal> (Modifier) 
                    value.</para>
                  </listitem>
                </itemizedlist>
                <note><para>Numbering of "pre-release" versions or draft versions of a document may be handled in multiple ways such as
                incrementing the previous modifier level until publication and then updating appropriately, setting the releases to 
                the anticipated level and then appending a "_preN" suffix where "N" can be incremented during drafting.  Each Work Group
                may set their own policy here.</para></note>
            </listitem>
            <listitem>
                <para>Chapters files should be named with the prefix "ch_".</para>
            </listitem>
            <listitem>
                <para>Section and sub-section files should be named with the prefix "sec_".</para>
            </listitem>
            <listitem>
                <para>Appendix files should be named with the prefix "app_".</para>
            </listitem>
            <listitem>
                <para>Figures source and images should be placed in the <literal>figures</literal> sub-directory for the document.</para>
            </listitem>
            <listitem>
                <para>Releases of the same document sound be contained in the same tree, but tagged at levels of interest using
                the <literal>git tag</literal> command.  See the <xref linkend="section_template_git_commands"/> for more specifics
                on <literal>git</literal> commands.</para>
            </listitem>
        </orderedlist>
    </para>
    <para>In addition to documentation structure, general community/project guidelines are as follows:
        <orderedlist>
            <listitem>
                <para>Contributions to the documentation projects should conform to the <citetitle>Developer Certificate
                Of Origin</citetitle> as defined at <link xlink:href="http://elinux.org/Developer_Certificate_Of_Origin">
                http://elinux.org/Developer_Certificate_Of_Origin</link>. Commits to the GitHub project need
                to contain the following line to indicate the submitter accepts the 
                DCO:<screen>Signed-off-by: Your name &lt;your_email@domain.com></screen></para>
            </listitem>
        </orderedlist>
    </para>

</section>