-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/24/2010 02:52 AM, Zach Oglesby wrote:
This email may be a little late, but at tonight's meeting I would like 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 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.
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 docs-qa list).
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.
Zach Oglesby
- --Eric