-
Notifications
You must be signed in to change notification settings - Fork 97
How we use issues
We use labels and release milestones on the GitHub issues tracker at dita-ot/docs/issues to manage DITA-OT documentation tasks.
This allows us to organize issues by category, prioritize tasks and filter the list of items to show a certain subset.
We assign milestones to issues to indicate the release version in which the issue was (or will be) resolved. Open issues with assigned milestones indicate tasks which are scheduled for implementation in an upcoming release. If no milestone is associated with an issue, the task has not yet been scheduled.
Issues are assigned to a team member to indicate work in progress. When you begin working on an issue, assign it to yourself so others know you're on the job. If an issue is already assigned to someone else, check with them before making related changes to avoid conflicts.
Many of these labels are GitHub defaults, but some are specific to the DITA-OT docs repository.
These issues are items that previously appeared on the “Backlog for the DITA OT documentation” wiki page in the parent dita-ot repository (last edited there on May 12, 2013).
The backlog page moved to the docs wiki on November 20, 2014.
This page originally served as an internal ToDo list for the documentation team. Now that the documentation source files are tracked in a separate submodule, the remaining tasks from this list have been ported to dita-ot/docs/issues on GitHub, so we can keep track of them along with other issues.
The coverage label flags issues related to incomplete information in existing topics, such as missing descriptions of parameters, extension points, properties, etc.
Issues are marked help wanted to indicate areas where contributions would be particularly welcome, or topics that may require additional input from other team members.
This label flags topics that may require updates to reflect changes in recent toolkit versions.
The process label flags issues that are related to the documentation build process, such as changes to build files, continuous integration (CI) routines, generated topics or other aspects of the build infrastructure.
The ready for review label is assigned to pull requests that are considered complete and ready for comments and feedback.
The ready for merge label is assigned to a pull request to indicate that anyone with merge rights can merge it immediately.
These issues typically propose changes to the file structure, DITA markup or other aspects of the underlying project organization that may not be immediately visible to the reader but that would improve code quality, consistency, or align with recent best practices.
Style and terminology issues flag cases where writing style or terms may need to be aligned for consistency.
View the latest DITA Open Toolkit docs at www.dita-ot.org/dev.