From Fedora Project Wiki
- Problem is identified
- Bug is filed in Bugzilla
- Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
- Create a new local branch for you to work: git checkout -b patch_for_BZ_<bug #>
- Make your changes in your new branch.
- Once you have committed your changes create your patch: git format-patch master --stdout > BZ<bz number>.patch
- 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"
- Owner applies the fix to the master branch.
- Check for errors before applying: git apply --check BZ<bz number>.patch
- If no errors, apply the patch: git am --signoff < BZ<bz number>.patch
- Push the changes to the remote repo.
- If there has been no action from the QA after 10 days, the Owner contacts QA Wrangler (see below).
- If there has been no action from the QA after two weeks, the Owner applies the fix without QA approval.
- Owner publishes the new version, closes bug
- 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.
- Docs components with no specified QA contact will be QA'ed by the docs-qa mailing list
- Patches should not be QA'ed by the component's owners or other regular contributors.
- 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.
The Docs QA Wrangler will be a quasi-official position within Fedora Docs. The person who volunteers for this task will be responsible for:
- Prodding assignees about stale tickets
- Reporting regularly to the Docs groups about the ticket state (aggregate data on count, severity, status, etc)
- ensuring QA contacts are assigned for bugzilla components
- Performing spot checks on tickets to see if they follow the QA process and make determinations about the process' effectiveness.
- Opening tickets for new Features to ensure major changes to Fedora are reflected in each guide.
- Wrangling external review of their own commits