From Fedora Project Wiki

Revision as of 16:56, 24 December 2011 by Bcotton (talk | contribs)

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
    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.
  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. Owner applies the fix to the master branch.
    1. If there has been no action from the QA after two weeks, the Owner applies the fix without QA approval.
  9. Owner publishes the new version, closes bug
    1. 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.

Notes

  1. Docs components with no specified QA contact will be QA'ed by the docs-qa mailing list
  2. Patches should not be QA'ed by the component's owners or other regular contributors.
  3. The Docs lead is in charge of nagging the docs-qa mailing list about open QA tasks since the nag feature of BZ isn't enabled.
Retrieved from "https://fedoraproject.org/w/index.php?title=Docs_QA_Procedure&oldid=264392"