Goal:

• CCS requirement to move all doc to DITA

Why is this important? 

What is the reason for CCS making this move? (Nelson)

• Current build tool is no longer meeting the documentation needs.
• CCS does not want to develop and maintain its own tool anymore.
• The decision was made to use Adobe tools, which includes storage and possibly version control.
• Enables teams to reuse content across products and delivery methods to better document solutions.
• Simplify doc resource flexibility and reduce the ramp-up time when docs team members need to contribute to and help other teams.
• Easier for writers and doc teams to implement more consistent metadata to customize experiences and gather data.

--Chris, doc manager

Does this change impact engineering, or is this change within CCS only and developers continue as they have been doing when providing input to the Docs Team? (Nelson)

Please see comments below for details from me and Oliver.

We can predict more steps to accessing the doc source. Currently they can fork, create branches instead forking, send PRs, etc... even some TAMs have used the source in the field. We currently have open access to the repo and they use it. The source would move from stolostron.

DITA is for writers, by writers, so they won't know the code and it's not as simple as markdown or ascii. So they likely won't use the source as much. --Brandi

Does this change hinder or impact the company goal to have unified backlogs? (Nelson)
See information in comments. 

I think if we stay in the ACM Jira workspace, that can help. Moving to DITA helps company goal to have CCS teams and doc structured the same way. See more in comments below. (you can also do that with markdown templates–that is how writers work now) Oliver went in to this as well.

Do you anticipate this impacting your ability to deliver continuously on a Train cadence? (Nelson)

We already are behind trains, with the way the team is set up. We expect more process to get doc updated, potentially slower turn around than what we are accustomed to, even reviews that are currently done via a simple PR process would change. They won't be able to send us PRs easily. See more in comments below.

We will of course try to simplify process where we can.

Acceptance Criteria

• ACM team understands the requirement

Dependencies (internal and external)

Previous Work (Optional):

Oliver is the tools focal. Please add info if needed. He will have his own story that I will attach.

PR with notes from Emily (modularization guidance): https://github.com/stolostron/rhacm-docs/pull/7710

Open questions/concerns:

• ACM has been very open and Agile, moving the content from DITA in 2018 to create open practices and collaboration. I am concerned this will cut off that collaboration that has made us successful even through a move where we did not miss a release, with only three writers. I have expressed my concerns to management but putting it here. 
• I am also concerned about the workload/timing and resources we have to do this–we currently have three people for the whole doc project.
• I would like to know from PM what versions have little-to-no customers, as I mentioned to the doc team when asked how far back we are going, to avoid changing what we don't have to change.
  --Brandi (long time architect/project lead for doc, CS, writer for ACM)

Done Checklist

1. Plan for moving content is outlined in this Epic after stakeholder discussion and understanding
2. Predicted internal process is as Agile as possible
   • Removing as many digital walls, cumbersome processes that require developers to spend too much time finding and updating the docs (developer advocacy)
   • Keeping doc team from becoming siloed (doc team advocacy)
3. Managers, PMs, Prgrm Mngr, DE understand and help with work prioritization during the release we plan to do this
4. Engineers/QE/Tech leads understand the requirements
5. This closes and new Epic opens for the actual work