How to identify doc issues to technical writers

The following describes the mechanisms developers can use to identify doc issues to the technical writers. The process to follow depends on why the issue requires or implies an update to the documentation:

• If the issue is an engineering issue that ideally should be fixed and is serious enough to warrant a warning to users in the Release Notes:
  • Add the the 3_1-release-notes tag to the issue.
  • Add a comment to the issue that either describes a workaround for the issue or states that no workaround is available.
  • For internal issues (e.g. bugster), this situation would be handled by setting the Documentation in Release Notes Program Management option.
• If the issue is an engineering issue that, when fixed, changes the UI or product behavior in some way that must be documented:
  • File a separate doc issue that depends on the engineering issue.
  • Do not wait until the engineering issue is fixed and then change it to a doc issue. By then, it might be too late.
  • For internal issues, this situation would be handled by setting the Fix Affects Documentation option.
• If the issue is incorrectly filed as an engineering issue, for example, because the reported behavior is the intended behavior but is not documented:
  • Change the issue to a doc issue.
  • For internal issues, this situation would be handled in a similar way: by changing the bug to a doc bug.