Under Community Review

Improve Change Tracking (Change Markup) in SDL Tridion Docs

The user group created a "task force" to revisit improving change tracking for SME reviewers. We defined which changes we would like to see marked up, and how we would like them to be formatted. I am attachingChange Tracking Requirements_June29meeting.xlsx the meeting notes for our meeting with SDL from July. We would like SDL to improve the way change tracking in handled in the product (potentially with a 3rd party tool like Delta XML and PS engagement... ). The current OOTB mark-up has been a sort spot for users for quite a while.

Elizabeth Gschwind
Parents

  • yes you got it right. One idea users had was to create some official "SME Review" status similar to "Release Candidate", and to track the review against the original baseline (or something like that). Another idea was to somehow use branching (without releasing) to track all the SME review versions of each official doc release (for example, if version 3 of a pub is for Product User Guide 1.2, version 3 could get created, then branched for the first SME review, branched again for the second SME review, etc., and then all the final comments could be merged back into unbranched version 3 for publication release.) To be honest, we had a lot of ideas on how to avoid version proliferation, but none of them seemed particularly easy to manage or obviously easy to implement. Perhaps Delta XML would have some insights? Thank you for asking!

Comment

  • yes you got it right. One idea users had was to create some official "SME Review" status similar to "Release Candidate", and to track the review against the original baseline (or something like that). Another idea was to somehow use branching (without releasing) to track all the SME review versions of each official doc release (for example, if version 3 of a pub is for Product User Guide 1.2, version 3 could get created, then branched for the first SME review, branched again for the second SME review, etc., and then all the final comments could be merged back into unbranched version 3 for publication release.) To be honest, we had a lot of ideas on how to avoid version proliferation, but none of them seemed particularly easy to manage or obviously easy to implement. Perhaps Delta XML would have some insights? Thank you for asking!

Children
No Data