----- Original Message -----
Sent:
Friday, July 05,
2002 6:57
PM
Subject: Sunday
night bug summary
One of the main motivations for
moving from the bugtrack
majordomo mailing list to the Bugzilla defect tracking
system was that the volume of traffic on bugtrack could no longer be managed
by election services associates.
Bugzilla succeeds in this goal, however we are now faced with the
opposite problem. Associates
are not notified of new bugs as they are found and fixed like they used to
be. From the looks of things,
not everyone is rushing onto staff site to take a look at the latest
bugs.
Starting at
Midnight this
Sunday, each of you will receive a weekly bug activity summary report. You can get the report for any
period at any time from the new Period Activity
Report page on the staff site.
Here is this
Sunday’s report1.
You will receive this email from a new majordomo mailing list called
bugreport@dieboldes.com. You’ll probably want to set up a
folder and sort rule in your mailer for this
address.
The report summarizes all bugs
that were fixed during the week, and all bugs that were assigned to
engineers but have not yet been fixed during the week. The core idea behind the report is
to show you the information you need to know, while omitting that which you
don’t. You can of course still
get full disclosure from bugzilla directly. The Period Activity Report does not
show:
·
Bugs that are not yet
assigned.
·
Bugs that have a severity of
Minor or Trivial.
·
Bugs that were resolved as
DUPLICATE, INVALID, WONTFIX, WORSFORME, or LATER.
Bugs that are not yet assigned
will normally appear in the next week’s report. You can find out which bugs are
currently unassigned at any time by going to the Users Page and
selecting Not
Assigned.
This results in a very short
weekly report, which is the whole idea. With this convenience comes an
important responsibility however.
You must make sure you have read and understood all bugs in the
report, and their impact on your users. The bugs are in the report because
they can have a real effect on your election. Take them seriously. Major and Critical bugs will appear
in red on the report.
We are assigning severities to
all bugs moving forward, and will try to get some assigned retroactively as
well. Here is the
key:
Critical
If the bug is ignored, affected
jurisdictions will either violate a major electoral statute, will have the
real possibility of reporting incorrect election results, or will fail to
report results at all. There is
no solution to the problem other than a software
upgrade.
Major
The bug will disrupt the
election process in a visible way.
Steps will need to be taken by election services and/or election
officials to work around or mitigate the problem. It is however possible to conduct an
election with the software as it is.
Normal
The bug represents a serious
malfunction of the software.
The problem may require steps to be taken by election services and/or
election officials to work around or mitigate the problem, but failing to do
so will not have major repercussions.
Minor
The problem is technically a
bug, but can be trivially ignored or has an obvious workaround. At worst, the bug may cause
confusion to users.
Trivial
The problem is technically a
bug, but one would have to take deliberate steps to reproduce the problem
that would not occur in normal election operations. The problem is not even confusing,
just pedantic.
(Blocker
is not used)
If you feel that your bug has
been assigned the incorrect severity, get with Ravina and she will get it sorted
out.
As always, questions and
suggestions are welcome.
Ken
1The
report may change a bit between when you read this email and Sunday as work
continues.