: Re: Should the documentation of a known issue change dependent on the stability of a product release? I am writing the release documentation for a software product and a design flaw has been discovered

@Cugini967

Vote Up Vote Down

Although in most cases the choice rests with business decision makers and those in charge of message tone, it's reasonable for the writer to have some proposed solutions. Choices may vary based on:

Potential liability/negative publicity.
Schedule of product releases vs documentation releases, that is, how much time after code freeze/flaw finding do you have before doc freeze, does doc really "freeze" or can it be updated easily, how does the doc staff availability affect the ability to be responsive, etc.

A few suggestions around your scenarios:

If the flaw appears in beta for a limited audience and will be fixed by GA:

A release note and workaround (if applicable) should be sufficient. If the workaround is too complex/lengthy for release notes, it can be standalone as a knowledge base article (available to just the beta participants as appropriate).
But proceed with the core documentation as if the fix will be in GA as anticipated. If you're publishing the core doc for the beta users, make sure it's tagged as beta -- use it as an opportunity to elicit feedback as well as to notify users that it's not quite ready for prime time.

If the flaw is exposed to the public and does not have a scheduled fix, then it's part of the product and needs to be documented as such.
If the flaw is discovered too late for the core documentation release, release notes plus KB article and maybe more direct outreach to the customer base.
If the flaw is really crippling, the doc staff can speak up for the users and say we can't release like this, and see if there are other options to get a fix happening or a software-based workaround (like disabling part of the interface so the customer can't get into trouble with the flaw).

(0)

Login to post a comment!