From Fedora Project Wiki

(added Possible Alternate Work Flow)
No edit summary
Line 1: Line 1:
== Work Flow ==
== Work Flow ==
# Problem is identified
# Problem is identified
# Bug is filed in Bugzilla
# Bug is filed in Bugzilla
# 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
## 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.
# 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
# Owner applies the fix to the master branch.
 
## If there has been no action from the QA
== Possible Alternate Work Flow ==
# Owner publishes the new version, closes bug
This is proposed by [[user:Crantila|crantila]] as a way to deal with the issues of not having enough consistently active contributors.
## 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.


# Problem is identified
== Notes ==
# Bug is filed in Bugzilla
# Docs components with no specified QA contact will be QA'ed by the docs-qa mailing list
# Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
# Patches should not be QA'ed by the component's owners or other regular contributors.
# Filer confirms the patch fixes the problem
# 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.  
# 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:51, 22 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
    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
  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=264141"