Docs QA procedure

[Christopher Antila]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi:

My thanks go out to those who participated in the Bug Squashing Party as well. 
Some of the bugs for my guide were solved, leaving my time for the strange and 
obscure bugs that I filed myself.

I like the process that Eric recommended, as represented by the wiki page 
linked in the original email. It seems to me like a "bare minimum" that we 
should strive for, so that at least three people think a bug has been 
adequately fixed.

But Ben brings up a good point. I'm assigned as the QA contact for the ex-
Deployment Guide (now the System Administrator Guide, I think), and there are 
several bugs marked as On_QA that I have yet to have the time to review. There 
are several more bugs that have been fixed and published without my approval. 
If I wanted to point fingers, saying "this shouldn't happen," I would've done 
that on the list long ago... but I don't think it's the case. As Ben said, 
there don't seem to be enough consistently-active members of the Docs Project 
to pull off this method convincingly.

So here's an alternative QA procedure that allows for QA contacts, like 
myself, who aren't responsive. Steps 1 to 5 are the same as the current wiki 
page.

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.
6.a) 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.
6.b) 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.

This seems like it might be very complicated to understand, but the basic idea 
is this. If the bug needs to be fixed urgently, we request urgent QA. If the 
bug can wait for the next release, we wait for the QA contact to have spare 
time. If we have to branch a Guide and a patch isn't "VERIFIED," we can still 
use the patch, but we should also still make sure the QA contact reviews the 
patch eventually. I updated the wiki to adde my "possible alternate work flow."

Will it work? I don't know. The biggest problem right now is that most of the 
Guides don't appear to have QA contacts.


Christopher.


On 16 December 2011 20:59:03 Ben Cotton wrote:
> Thanks to everyone who participated in the Bug Squashing Party earlier
> this week. Since it's in the past, we've promised ourselves we'd
> settle the QA process. Please take some time to read the proposal that
> Sparks put together[0] and offer comments on list.
> 
> I have concerns about the manpower required, although it might be a
> good opportunity to get inexperienced contributors involved.
> Certainly, it should reduce the number of bugs we have to go back and
> fix.
> 
> Any other thoughts?
> 
> [0] https://fedoraproject.org/wiki/Docs_QA_Procedure
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQEcBAEBAgAGBQJO7BBhAAoJEInCktGVqZ8V0RAH/2e0IfyWtYaNnc/eF7079j17
Yo50OpubYDwC3j4kw0VJOfzPE1yRGt8Rw4LVW4IBSqJWwRGJeliSa6bicHqSbN4A
JGw4l8072OHmrZ+caArxIA4xghGukWcZ9T9Sdo0jpf5m/z2U5VYSY6Ddktm+dMd2
cytEoD6r4Jv5dPqLgMlU9eHgV7fITpp+E2xOoyu8bT13QZLNRb89qSdiXK3UUwjg
06QCrmGp54WWNwSwVnf87iS4v+x8k7aQYF9yrQ+yYmqG04NwqMHjdYfXfZlTn2LE
qpxoiHQ9XWzQfE1At5iM5AxfFpO62uMNuuu096w8UOj/NyyEBPwFDl+0uEEIaI0=
=4k+d
-----END PGP SIGNATURE-----