Skip to content
Roger Sheen edited this page Sep 7, 2017 · 3 revisions

The items below appeared on the “Backlog for the DITA OT documentation” wiki page in the parent dita-ot repository (last edited there on May 12, 2013).

Old Backlog Items

This page originally served as an internal ToDo list for the documentation team. Now that the documentation source files are tracked in a separate docs 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.

  • Topic that discusses the DITA and DITA-OT features that are used in the DITA-OT documentation (keys and key references, filtering, subjectScheme classification for controlling available attributes, etc.) #50
  • Add discussion of chunking to the User Guide #51
  • Add topic that lists books about DITA and the DITA-OT to the DITA and DITA-OT Resources section #52
  • Index the topics #53
  • Redo graphic in Developer Reference #54
  • Add a plug-in that contains style sheets for the DITA-OT PDF

2014 Proposals

During DITA Europe 2014, we discussed several ideas on how to improve the documentation, including:

  • Fix subject scheme map (PR #1796)
  • Split the documentation into a dedicated subrepository to facilitate contributions by less technical users
  • Update build scripts to be independent of main dita-ot repo #3
  • Discuss & agree on coding conventions for authoring
    (120 character line length, IBM Style Guide)
  • Create oXygen project to store project settings like line wrapping, etc. #14
  • Set up transformation scenarios in oXygen to simplify output generation
  • Prune unreferenced topics & resources #15
  • Refactor filenames & folders for consistency (use .dita extension, etc.)
  • Standardize terminology: "transtype" vs. "transform(ation) type"
  • Merge & build on work-in-progress from Kris #21
  • Review links between various sources of project information
    (READMEs, wikis & project website) & other DITA resources per OT #1807
  • Apply new DITA 1.3 spec style guide to docs where relevant
  • Implement Schematron rules to enforce rules we decide on

Ideas are listed above to serve as a basis for discussion.