<?xml version='1.0' encoding='UTF-8'?>
<!-- This file is part of the DITA Open Toolkit project hosted on 
     Sourceforge.net. See the accompanying license.txt file for 
     applicable licenses.-->
<!-- (C) Copyright IBM Corporation 2005. All Rights Reserved.
 *-->
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="development_process" xml:lang="en-us">
  <title>DITA Open Toolkit Development Process</title>
  <shortdesc>The DITA Open Toolkit development process is modelled after other 
    popular and successful Open Source projects, notably the Eclipse 
    development process (for definitions and process statements).</shortdesc>
  <body>
    <section>
      <title>Revision 1.0</title>
      <p>Last updated on February 27, 2005</p>
    </section>
    <section>
      <title>Purpose and scope</title>
      <p>This document describes the development process of DITA Open Toolkit 
        (DITA-OT) project.</p>
    </section>
  </body>
  <topic id="rolesandresponsibilities">
    <title>Roles and Resposibilities</title>
    <body>
      <p>There are several roles in the DITA Open Toolkit open source project. 
        Each has different rights and obligations.</p>
      <dl>
        <dlentry>
          <dt>Project Manager (PM)</dt>
          <dd>An individual responsible for managing this open source project. 
            The PM is expected to ensure that<ul> <li>All Projects operate 
            effectively by providing leadership to guide this project&apos;s 
            overall direction and by removing obstacles, solving problems, and 
            resolving conflicts. </li> <li>All Project plans, technical 
            documents and reports are publicly available.</li> <li>All Projects 
            operate using open source rules of engagement: meritocracy, 
            transparency, and open participation. These principles work 
            together. Anyone can participate in this project. This open 
            interaction, from answering questions to reporting bugs to making 
            code contributions to creating designs, enables everyone to 
            recognize and utilize the contributions.</li> </ul><p>It is 
            anticipated that the PM scope may be enlarged to head of a 
            leadership committee as the project grows.</p></dd>
        </dlentry>
        <dlentry>
          <dt>Committer</dt>
          <dd>A developer who is expected to influence the Project&apos;s 
            development and has the write access to the source code repository. 
            This position reflects a track record of high quality 
            contributions. At the initiation of this project, the PM nominates 
            one Committer who will oversee the quality and originality of all 
            contributions. </dd>
        </dlentry>
        <dlentry>
          <dt>Contributor</dt>
          <dd>An individual who contributes code, fixes, tests, documentation, 
            or other work that is part of this project. A Contributor does not 
            have write access to the source code repository.</dd>
        </dlentry>
      </dl>
    </body>
  </topic>
  <topic id="processlifecycle">
    <title>Process life cycle</title>
    <body>
      <p>To ensure transparency and predictability, this project sequences 
        through a series of Phases, with well-defined Phase Transition Reviews: 
        </p>
      <ol>
        <li>Plan phase<p>Plan phase is mainly to determine what to implement in 
          each release. The Project Manager will collect requirements and 
          feature requests (enhancements) from all the members at large. Then 
          all the requirements will be prioritized. After discussion with the 
          Committer(s) and other developers, top requirements will be put into.
          The schedule of this release and planned release dates will also 
          be determined. Exit criteria for this release will be set to ensure 
          high quality of all the releases.</p></li>
        <li>Design phase<p>For all the requirements determined to be 
          implemented in the current release, developers will perform high 
          level design and create a prototype if necessary.</p></li>
        <li>Implementation phase<p>Developers will implement the requirements 
          for this release and perform testing before formal release. The 
          Committer(s) will cooperate with contributors to ensure high quality 
          of the code before implementation phase ends.</p></li>
        <li>Release <p>Source and binary code of this release will be put into 
          SourceForge and the next release planning phase begins.</p></li>
      </ol>
    </body>
  </topic>
  <topic id="procedures">
    <title>Procedures</title>
    <body>
      <section>
        <title>Manage requirements/features</title>
        <p>Throughout the project lifecycle, requirements or features will be 
          collected using the SourceForge requirements tracking tool. The PM 
          will have periodic reviews with the Committer(s), Contributors, and 
          interested parties to assess the existing requirements, prioritize 
          them and make decisions. Usually some requirements will be marked as 
          candidates for next release and will be reviewed in the planning 
          phase for next release (or in some cases for interim updates).</p>
      </section>
      <section>
        <title>Fix bugs</title>
        <p>Anyone can submit bug reports in SourceForge bug tracking system. 
          The Committer will determine the owner of the relevant components and 
          assign the bug for validation and disposition. Bugs have different 
          severities. Higher severity bugs will be responded to first, usually 
          worked to closure within one week.</p>
      </section>
      <section>
        <title>Contribute code/bug fixes</title>
        <p>Contributors can submit new code and bug fixes using the SourceForge 
          facilities. The Committer(s) who owns the relevant components will 
          first do due diligence to check code originality and licensing 
          according to the <xref href="ContributionPolicy.xml">Contribution 
          Policy</xref> document. After due diligence, the Committer(s) will 
          use his/her own judgment on whether to accept the code or bug fixes 
          and merge them back to the original code base. Usually within a week 
          after submitting the contribution, contributors will receive a 
          response as to whether the contribution will be accepted or if more 
          time is needed to check the contribution.</p>
      </section>
    </body>
  </topic>
</topic>