Docs QA Procedure

Work Flow

1. Problem is identified
2. Bug is filed in Bugzilla
3. Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
4. Filer confirms the patch fixes the problem
5. Bug goes to Docs QA (Bug set to "ON QA")
6. Docs QA checks the items documented in the Docs QA Review Guidelines in the patch
7. Docs QA sets ticket as "VERIFIED"
8. Author patches guide, publishes the new version, closes bug

Possible Alternate Work Flow

This is proposed by crantila as a way to deal with the issues of not having enough consistently active contributors.

1. Problem is identified
2. Bug is filed in Bugzilla
3. Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
4. Filer confirms the patch fixes the problem
5. Bug goes to Docs QA (Bug set to "ON_QA")
6. Guide owner patches guide.
   1. If a fix is needed for the current release, owner says so and requests immediate QA action. Patch is applied to current release and master.
   2. Otherwise, the fix is applied to the master branch.
7. Docs QA checks the items documented in the Docs QA Review Guidelines in the patch, on the timeline requested by the guide owner. If a Guide's dedicated QA contact does not respond within a week, or says they cannot fulfill their duties in the timeline requested, somebody else can jump in.
8. Docs QA sets the bug to "VERIFIED"
9. When a Guide is branched for release, all patches can be included, even if they are still "ON_QA," but the bug remains ON_QA so the QA contact can verify the fix eventually.