-----BEGIN PGP SIGNED MESSAGE-----
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
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
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
1.) Problem is identified
2.) Bug is filed in Bugzilla
3.) Someone fixes the bug and submits a patch to Bugzilla (same ticket) for
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
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.
On 16 December 2011 20:59:03 Ben Cotton wrote:
Thanks to everyone who participated in the Bug Squashing Party
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 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
Any other thoughts?
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----