If you outline the book Campbell, J. P., M. D. Dunnette, et al. (1970).
Managerial Behavior, Performance, and Effectiveness. New York, McGraw-Hill,
you will find that all 19 chapters fit neatly into 4 categories: Selection,
motivation, training and development, and psychology.  The words punishment,
punish, punishing, etc., do not appear in the chapter titles or in the
index.  This is in line with our Greco-Roman-Judeo-Christian-Anglo-American
heritage and is congruent with the distinction between the Old and New
Testaments: In the former God wiped out the population with a flood, visited
people with plagues, and turned people into pillars of salt when they
sinned, whereas in the latter he sends his son(s) to show people how to
solve their problems.
        
If you go through a pending credit list you will probably find several
instances where users have simply abandoned s...@home leaving hundreds if
not thousands of work units unprocessed.  De-select them; if they come back
after a month or two, fine.  If they don't, that is fine too.  The same
treatment should be accorded to the person who day after day returns nothing
but errors.  I don't see any other way to protect the system against people
who intend harm or simply don't care.

As for people who error-out hundreds of work units, they have a problem, and
punishing them is not going to fix it nor earn you any goodwill.  A message
telling them that the problem is almost certainly due to a bad video card,
bad memory, or overclocking and giving a URL to a page describing basic
hardware debugging techniques (e.g., substitute a known-good part, run a
diagnostic such as Memtest86+, reduce the bus frequency, etc.) is far more
helpful and more in line with our culture.

We need to motivate people who do well by, say, giving extra credit for
consistency, rather than punishing them for their mistakes, which they
probably already know are stupid, or for part failure over which they may
have no control.

Charles Elliott


_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to