Using a Blog to Track Documentation Issues

Bug tracking tools intended for developers are too “heavyweight” for documentation. They don’t help at all with workflow, and invariably have categories and status options that make no sense whatever for documentation.

Well, here’s a tool in the “featherweight” division that does a pretty darn nice job:
http://knownissues.blogspot.com/search/label/outstanding

Assuming you can see that page (I hope you can), you can see that it is simply blog in which issues are recorded, where comments can  added for additional information, workarounds, and fix info.

This particular version use’s Google’s blog, which has several features that make it ideally suited to the task:

·         The ability to label a blog.
This blog labels things as “Outstanding” or “Fixed”. Since everything
is available from the main blog page, they added a pseudo “category”
in the navigation pane called “All Issues”. So while “Outstanding” and
“Fixed” links go the appropriate search-URL for those labels, the
“All Issues” link simply goes to the main blog page.

·         The ability to put multiple labels on a blog.
For documentation, it would be easy to create categories for particular
documents (PX UG for product X user guide, PY DG for product Y
deployment guide, PZ CG for product Z configuration guide, for
example). Of course, then you would really want the ability to search
on label combinations, so you could find all entries tagged as “open”
and “UG”, for example.

You could always simulate that behavior, though, by creating a different
blog for each document. It’s not quite as nice, but it would work. Either
way, you can easily see everything that applies to a single document at
one time—something that’s can’t be said for the typical defact tracking
tool that was originally set up for development.

·         The ability to add multiple writers to a blog.
All writers could put new entries into the blog, and change labels from
Outstanding to Fixed. They might even be able to edit comments.
(Haven’t yet found out what the site is capable of, in that regard.)

·         The ability to limit the audience for a blog
So even though the blog is “public”, its readership could be limited
to internal reviewers.

All that’s left really, is to come with a good way to let the audience enter
issues on their own. That could be done by adding them as “writers”, as
well as “readers”.


All in all, it looks like something worth experimenting with.