Docs QA Procedure

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Added proposed work flow)
 
(added Possible Alternate Work Flow)
Line 4: Line 4:
 
# Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
 
# Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
 
# Filer confirms the patch fixes the problem
 
# Filer confirms the patch fixes the problem
# Bug goes to Docs QA (Bug set to "ON QA"
+
# Bug goes to Docs QA (Bug set to "ON QA")
 
# Docs QA checks the items documented in the [[Docs QA Review Guidelines]] in the patch
 
# Docs QA checks the items documented in the [[Docs QA Review Guidelines]] in the patch
 
# Docs QA sets ticket as "VERIFIED"
 
# Docs QA sets ticket as "VERIFIED"
 
# Author patches guide, publishes the new version, closes bug
 
# Author patches guide, publishes the new version, closes bug
 +
 +
== Possible Alternate Work Flow ==
 +
This is proposed by [[user:Crantila|crantila]] as a way to deal with the issues of not having enough consistently active contributors.
 +
 +
# Problem is identified
 +
# Bug is filed in Bugzilla
 +
# Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
 +
# Filer confirms the patch fixes the problem
 +
# Bug goes to Docs QA (Bug set to "ON_QA")
 +
# Guide owner patches guide.
 +
## 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.
 +
## Otherwise, the fix is applied to the master branch.
 +
# 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.
 +
# Docs QA sets the bug to "VERIFIED"
 +
# 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.
  
 
[[Category:Docs QA]]
 
[[Category:Docs QA]]

Revision as of 03:45, 17 December 2011

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.