Eric "Sparks" Christensen
sparks at fedoraproject.org
Wed Nov 24 13:23:53 UTC 2010
-----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 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the docs