Docs QA Procedure
From FedoraProject
(Difference between revisions)
(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
- 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")
- Docs QA checks the items documented in the Docs QA Review Guidelines in the patch
- Docs QA sets ticket as "VERIFIED"
- 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.
- 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.
