Keeping track of review status

[ChoccieMuffin]

Hi all.

I know this topic has been batted around a few times on the forums, but I'm seeking your advice.

I have 42 Flare projects containing 16,444 htm files and 441 snippets, generating 39 CHM targets and 46 PDFs, and it would be useful to track when the topics have been reviewed. I know I could use tags, but our work (as for most Tech Authors) comes in peaks and troughs and I would have to go about adding and editing tags to topics at peak times, which is considerably less than ideal.

One suggestion that has been raised by my colleague is to maintain a spreadsheet that lists all the different chapters in the PDFs (most of the PDFs and CHMs use very similar TOCs) to give the date reviewed and name of reviewer, and I'm heading in that direction, but I wonder if you have any other suggestions that I could put forward.

[doc_guy]

How do you plan to use the information? If it is for reporting, I don't know of any solution that won't cause you troubles in terms of keeping it updated.

First, the spreadsheet. The information in the spreadsheet is only as useful as it is current. Somehow, you need to track all topics in your project in the spreadsheet while continuing to add new topics, and keep track of moved topics. It means anytime you are doing any kinds of changes in Flare, you need to have the spreadsheet open so you can update what topics you've reviewed, update any new topics, etc. This is going to be a problem if you have multiple people who need to access the spreadsheet at the same time.

Second, File Tags. Again, it's only useful as it is current, but in this scenario, anytime you review a topic, you need to open the topic properties and update the file tags. However, this is probably easier to maintain in the long run, because you don't need to worry about forgetting to add new topics, or keep track of renamed/moved topics, etc. Using the File List in Flare, you can easily sort on data in the file tags, so you can see what files haven't been edited for a while. You can also export the File List to Excel so you can do pivot tables or advanced filtering to see what content needs attention. I think this is a better option than the spreadsheet.

If you don't need the information for reporting, but you just want to be able to see it in a topic (and have the reminder to update it when you review a topic in Flare), you can always create content in the topic that is conditioned OUT of all targets with review information. I do this in some projects. There is a DIV at the end of the topic that has the following paragraphs:

• Author
• Date created
• SME
• Reviewer
• Date Reviewed

The information is safely stored in each topic, and if I want to see the status of any given topic, I can open the topic to see it. However, this has the big disadvantage of not being reportable on a large scale, since you have to open each topic to see the information. On the other hand, you see it EVERY TIME you edit the topic, so it is easier to remember to update it.

I don't know what solution is right for you, but these are some things to think about as you are considering your options.

[trent the thief]

Paul, if you create a target that only contains your conditioned DIV, that could be the report. It's not as handy as a homebrew online DB app online for an entire team to use, but it would work to report all statuses.

[dogsma]

Choccie Muffin,

Have you come up with a solution? I would like a report of just those topics with a custom last reviewed date or completed status. Reviewing even a few hundreds of topics in a list is even too onerous

[ChoccieMuffin]

TBH, I just gave up on the idea of trying to identify topics that haven't been reviewed recently or keep a live log of topics that have changed.

Instead, I add a paragraph at the bottom of the topic or snippet when I've done something significant to it. I format the paragraph as p.COMMENT, a style I added to my stylesheet that applies the COMMENT condition from my condition tag set and sets the background as yellow (so really obvious) and I set ALL my targets to EXCLUDE the COMMENT condition when they go live.

A typical paragraph might say:
"Last edited: May 2020, Release XX.YY [actual release version number]. Removed the row in the table about the xxx check box because it's been removed from the GUI." or "Last edited: Reviewed Apr 2019, no changes needed for [[feature name]] in Release XX.YY." or "Last edited: Jan 2020. Removed note about xxx after review by AAA [name of someone in the company]. Feb 2020. Reinstated note about xxx after review by BBB [name of another person in the company]."

I always start that paragraph with "Last edited" so I can at least do a search on what topics have a review comment in them, and while trying to keep the comments brief, that last one ("AAA said remove it, BBB said put it back again") has got me out of hot water several times when people complain that I've deleted something or added something - with so many massive projects and so many changes people ask for, there's no way I can remember why I did something!