Alright, so we don't stop at just talks, let's 'just do it'. I would
like to create a newsletter for QA contributors and others involved in
developer support. I'll need an editor or, at the very minimum, a
co-editor. I'll also need one or more coordinators who help manage the
Hall of Fames activities. For the actual contents, I'll need some
column writers. If you have an area of special interest and can write
articles on a regular basis, please contact me (or the editor, if
someone volunteers for that position.)
The newsletter will be named Mozilla Quality Updates. I took the word
"assurance" out because I think we should expand our scope of quality
activities to cover quality control (QC) & quality improvement (QI).
The purpose of the newsletter shall be:
educate QA contributors and developer supports so that they can
carry out their activities more effectively and efficiently
The newsletter shall be published weekly. A summary report or, if
possible, feature edition shall be published every 35 days.
The newsletter shall feature the following contents regularly:
_Weekly Hall of Fame_: a list of most frequent contributors of
that week
_Bugzilla Tips_: just to get started, here are my 'two cents':
[1] *Answer your own question, then ask*: you may discover in
Mozilla what you believe to be misbehavior or a lack of
feature. Rather than proceeding to file a bug report or
search for one, ask yourself why:
Is the behavior/feature by design?: would there be
any negative effect if the current behavior is
changed? what are the advantages of the current
behavior?
Does the behavior you want exist already?: could
there be some other ways to do the samething
but you have not discovered?
Does the behavior you want conflict with other design
requirements?: does the behavior you want
conflict with standards (e.g. W3C HTML
specificatons)? does the behavior make Mozilla
less accessible?
When you try to answer these questions, you may find out
that the current behavior is indeed not a bug. You may
even learn from your answers and able to think of ways
to improve the current behavior!
[2] *Create the bug report first, search for duplicates later*:
'But wait a minut,' you might ask, 'don't we have enough
duplicates already?' Well, perhaps I should rephrase it
as 'Create the bug report first, then search for
duplicates, and file the report last.' The reason why
you should compose your report first is because
verbalization of your problem helps you understand it
better, thus allowing you to create a better Bugzilla
query (search). You can determine from your own report
what text pattern and keywords might exist in a
duplicate, if it exists, thus allowing to locate it
quicker.
_Bugzilla Updates_: how many bugs filed in the previous weeks? How many
of them are duplicates? How many are new? what bugs were fixed?
_Test Case of the Week_: feature a good test case that demonstrates the
problem of a bug. The creator of the test case could discuss the
processes s/he took to zero in on the bug. This should be helpful
to the Tech Evangelism persons too.
That's it for now. Feedbacks welcome.
(anyone notice the latest nightly build is not friendly on copy & paste?)
