> I tend to agree with you. However, it is not realistic. I would suggest
> instead of a point system, a nonimation system. Like, "Mozilla.org
> Volunteer of the month/week."
I never suggested a point system. I don't see the value of
"awarding" anything. I merely suggested reporting statistics
out of the bug database and leaving it at that. A bit of
SQL can report simple counts and averages per-person, for a
given period, illustrating best practice.
I disagree with the idea of a judging system. That is just another
kind of game, and your concept of votes is not workable.
Here are my objections to a voting system:
1. It is labour-intensive, when people could be testing and
fixing bugs. Each vote caster needs to be informed of the
whole range of activity within the mozilla project in order
to cast a knowledgeable vote. That is not practical when
one is seeking best practice. It only identifies preferred
or known practice.
2. It is over-managing. There is no need for a non-automated system
in this case. There is no need to have someone 'running' it. All
that is required is a Web page and a CGI script. It is
set-and-forget.
3. It creates a political environment that distracts from the job,
which is bug testing and fixing. If you want to execute a power
grab, then there are far better ways than appointing a judging
panel (although that's a good start).
The reason your 'ice skating' problem exists is because the
ice-skating fraternity is a tight community where all the
visible members know each other. Mozilla is the same and your
voting system does nothing to rectify that. Only members of
the community with a political investment will bother to
vote. Also your statistical arguments about 1 in 20 are (ahem)
totally wrong (bad mathematics).
Finally, the first argument that was made in this thread was
that the bug resolution system shouldn't be "polluted" with
announcements or other feedback messages. Your proposed
voting system is exactly that, except that the feedback
messages are "feedforward" messages running the other way
(from reader to system, rather than from system to reader).
So it is equally disruptive.
Sorry for the criticism, but I think Keep It Simple, Stupid
applies here. All that is needed is a web report.
If there's some soul out there who wants to spend a day a week
or more developing a fanzine for bugs, possibly including a voting
system, or other political, journalistic or marketing activities,
then let him/her put his hand up. That separate goal can be
achieved by implementing a script in bugzilla that provides a
newsfeed (by Web) of changes every 24 hours. Anyone can then
pickup that feed and use it on their website for their pet
project. That project might be the larger goal of showering
praise on the better bug fixers, or gaining self-notoriety.
But even then, any praise should be based on _facts_ not
on _votes_. In order to get the facts, you first need
a summary report. You can distort the facts later, if
you think there's a real need to do so ... sigh.
In overview, the engineering goal of:
1. reducing the labour of fixing bugs by encouraging best
practice in the submission of bugs.
shouldn't be confused with the social goal of:
2. handing out trophies, favours and notoriety to members and
others for some politically or socially-motivated reason.
Fixing 1 means reporting the objective facts of best practice.
Fixing 2 means setting up a system for people to play with.
Both can be done. Just don't pretend that 2. achieves 1. It doesn't.
The bugzilla system itself doesn't need any of that complexity.
It just needs one more summary report.
- Nigel.
--
---------------------------------------------------------------------
Nigel McFarlane Melbourne, Australia
Software, Telecommunications, Internet, Physics UTC +10 or +11 hours
Analysis, Programming, Writing, Education Phone +61.3.9415.7080
