Post History

Source: https://writers.stackexchange.com/q/12948
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

My team uses MadCap Flare for documentation and we have an editor on the team. When a writer is ready, we assemble a review package in Flare and send it to the editor, and she makes changes and sends it back to the writer for resolution. (The writer has the final say, and responsibility for making sure edits don't change the technical accuracy of the documentation.) The review bundle sent back to the writer contains marked-up changes similar to those in Word's "track changes" mode -- cross-outs for deletions, a different color for insertions, and annotations (call-outs) for other editor-to-writer communication.

That's all fine, but Flare requires that each change be individually accepted or rejected, and the problem we're having is that an edit for a single paragraph might produce a dozen individual changes, each of which needs to be handled. If you were to accidentally accept 11 of them and decline one, you'd have messed-up text because the changes are all related. We want _atomic change groups_ -- accept all or none of these -- in this situation. (Flare does support "accept all" or "reject all" at the file level, but that's too coarse-grained.)

We've tried Google and we've got some pretty experienced Flare users on the team, and the best we've come up with, when a block of text requires many small edits, is to have the editor cut/paste the text into a new block, edit _that_, and then delete the original. But that's tedious if done all the time and hard to anticipate if making changes while editing. The editor shouldn't have to make two passes, one to read and then a second to go back and make changes either "inline" (if just a few) or by this more-elaborate cut/paste routine (if more extensive).

Is there a way to cause Flare to group a selected set of changes together to support atomicity? I envision the editor being able to mark all changes in a paragraph as being part of the same group, and the writer then being able to say "yes" or "no" to that group.

We are using a mix of version 9 and 10. If upgrading everybody to version 10 would help we can do that.

Original score: 4