-----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----- -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
