QA Process

[David Nalley]

On Wed, Nov 24, 2010 at 9:35 AM, John J. McDonough <wb8rcr at arrl.net> wrote:
> On Wed, 2010-11-24 at 08:23 -0500, Eric "Sparks" Christensen wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 11/24/2010 02:52 AM, Zach Oglesby wrote:
>
>> > The first possibility is to require all changes to be entered as
>> > patches in bugzilla, each patch would then have to be verified by a QA
>> > person prior to being included in the guide. I don't particularly like
>> > this idea as a content writer, I don't really want to have to submit
>> > tickets to bugzilla every time I make changes to a guide that I am the
>> > POC on.
>
>> While this may be a cumbersome solution, it may also be the easiest to
>> manage.  If I make a change in the third paragraph on the second page of
>> X guide then I have to convey that in some way to the QA person and we
>> need to track it to make sure that it gets done.
>
> No kidding cumbersome.  Probably triples the work, and why, just to get
> it into BZ?  There is a commit message automatically generated with
> every change, we can easily roll back the change in git, and it doesn't
> affect anything but the repo until we publish, so adding a huge amount
> of manual work just to make the commit message show up in BZ sounds
> incredibly dumb beyond all belief.
>
> That being said, I do like the idea of tracking everything in BZ, but
> this is just horrible.
>

I snipped a lot.

After seeing the problems with lack of QA/testing in the current
update process for packages, I have to agree. I think we are likely
struggling to keep up. (I know my own participation has been limited
to a few patches to IG/IQSG this cycle.) That means that adding
additional QA layer onto things will mean 1) things either don't get
pushed because they haven't been QA'ed or worse, we'll go to all the
trouble, they won't get QA'ed because people don't have the time, and
we'll end up pushing the changes anyway.

I don't disagree with the need for additional QA, but I'd offer
several suggestions.
1. apply to a small group first - a single guide - see if it scales.
2. simple is better.......sadly I don't have any suggestion for simple
here - and of necessity, writing/editing/publishing the guides is
already relatively complicated (though far simpler than in years past)