-----BEGIN PGP SIGNED MESSAGE-----
On 11/24/2010 02:52 AM, Zach Oglesby wrote:
This email may be a little late, but at tonight's meeting I would
to talk about possible ways to preform QA for docs, I have two
possible suggestions, and any others would be welcome.
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
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.
In my opinion, using BZ to track the issue from start to patch to QA to
inclusion is rather simple compared to doing this on the wiki or email or...
The second idea is to write to the proposed docs-qa list to inform the
QA team that a doc has been changed and need to be looked over. We may
be able to semi-automate this process by emailing the list when
commits are pushed a repo.
You'd still need to know what changed and be able to approve or
disapprove that change. Once it is in the repo it is often too late to
pull back out and make more changes or know if something has already
been through QA. I'd prefer to not have anything go into the repo until
it has been approved.
It may also be possible make use of both of these ideas depending on
the circumstance (patches from outside sources are checked via
bugzilla when a bug is submitted and internal work is done on the
It would also be good if everyone on the QA team was fluent in DocBook
XML so tags could be checked or could be added where needed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----