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).
Last updated on February 27, 2005
This document describes the development process of DITA Open Toolkit (DITA-OT) project.
There are several roles in the DITA Open Toolkit open source project. Each has different rights and obligations.
It is anticipated that the PM scope may be enlarged to head of a leadership committee as the project grows.
To ensure transparency and predictability, this project sequences through a series of Phases, with well-defined Phase Transition Reviews:
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.
For all the requirements determined to be implemented in the current release, developers will perform high level design and create a prototype if necessary.
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.
Source and binary code of this release will be put into SourceForge and the next release planning phase begins.
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).
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.
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.