In Flare, how can we make atomic change groups in review?

Question

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.

Answer 1

This has nothing to do with the source control, so the GIT support in V11 and 12 is a red herring.

There is no better way of doing this, as of version 12 (April 2016). What you are doing and your work around are the only two ways I know of doing what you want.

In our group, we use Track Changes for the changes that we want the author to review. We don't use Track Changes for the changes that we have the authority to make without having the original writer re-review it. But this has the undesirable effect of requiring the editor to keep clicking the on/off button.

Your other option would be to only allow the reviewer to annotate the doc, rather than edit the doc, but that has other painful repercussions.

Finally, I will point out that in Flare 12, when you generate a PDF, Flare now has the option to print the track changes content and the comment bubbles in the PDF, so people can review the PDF file itself and see the tracked changes. I know this still doesn't directly answer the need in your question, but it is a cool new feature related to what we are talking about.

The best thing to do at this point is to submit a feature request on MadCap's website giving them an example and use case. They are pretty receptive to feedback.