Identifying Topics with Changes

should add that I do one more thing, that end-users can actually see. Any change or addition in help topics is labeled as such, for at least one or two versions from its insertion. In other words, let's say I add a new topic for a new report form. At the top of the topic, under the title, I add

New in Build 2.3.22

or if this information is early,

Coming in Build 2.3.22

I also add this in the body of an existing topic to identify changes or new content in the topic.

I can search on this phrase, and delete it after a few versions (our support and field staff like to see these labels in there too, so they can explain the history of changes in a process to clients, so they prefer that I don't remove them for a while).

and finally, yes, I do maintain a spreadsheet, on which each topic is listed with its map ID, last revision date and version, Topic Name, form name, File Name, and Notes. I share this with the programmer who updates the program with my help links from time to time, so he can use it to verify my map ID changes and additions. Yes, it is tedious, but for both of us it's a good sanity check / backup.

If you are just trying to cover your butt - meaning, that you want a way to know when changes were made and why in case anyone comes to you disputing the content, here's what I do.

I created a small revisions table template, and put it in a DHTM drop-down, with the link (called Topic History) at the bottom of each topic. The table contains three columns: Revision Date, New Version Number, and Notes.

Then, as changes are made, I update the version and detail the changes in the table. Because clients don't need to see this, I use a build tag to exclude it from the final build.

Hi Mary.
To add to Imarden's post, I've never saw the need to track changed topics and as the topic status tags available in RH7 and before were so limiting I just didn't bother when I did have to. RH8 however gives you the opportunity to define your own statuses. I've covered this on my blog.

You can assign a build tag to new / edited content to make it stand out from other topics and content. For example, I often insert content that is a version or two ahead of our current production build, so I want to be able to find that information easily and possibly hide it from clients. I give that content a build tag, named something like NewInVersion2. Then if I choose, I can get RH reports that list topics that contain build tags, or, I can exclude this new content from the build.

HI Mary. My suggestions sorta depend on what your goal is - why you need to know which topics have been changed, and what do you do with that information?