Re: Docs QA procedure
-----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?
-----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-----