# DITA Open Toolkit Development Process

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).

## Revision 1.0

Last updated on February 27, 2005

## Purpose and scope

This document describes the development process of DITA Open Toolkit (DITA-OT) project.

## Roles and Resposibilities

There are several roles in the DITA Open Toolkit open source project. Each has different rights and obligations.

Project Manager (PM)
  An individual responsible for managing this open source project. The PM is expected to ensure that
  - All Projects operate effectively by providing leadership to guide this project's overall direction and by removing obstacles, solving problems, and resolving conflicts.
  - All Project plans, technical documents and reports are publicly available.
  - 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.

  It is anticipated that the PM scope may be enlarged to head of a leadership committee as the project grows.

Committer
  A developer who is expected to influence the Project'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.
Contributor
  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.

## Process life cycle

To ensure transparency and predictability, this project sequences through a series of Phases, with well-defined Phase Transition Reviews:

1. Plan phase

   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.

2. Design phase

   For all the requirements determined to be implemented in the current release, developers will perform high level design and create a prototype if necessary.

3. Implementation phase

   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.

4. Release

   Source and binary code of this release will be put into SourceForge and the next release planning phase begins.

## Procedures

### Manage requirements/features

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).

### Fix bugs

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.

### Contribute code/bug fixes

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 Contribution Policy 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.