[Mailman-Developers] On allowing any list member to be an email moderator

[Brad Knowles]

At 5:32 PM +0900 2006-01-03, Stephen J. Turnbull wrote:

>  1.  All the ban-author options should go, they take up _way_ too much
>      space.  In all the lists I've ever subscribed to, I've only seen one
>      case where they would have been appropriate, and that guy quickly
>      learned not only how to change from, sender, and envelope, but
>      also his IP addresses.  I've never seen a case on XEmacs lists
>      (ie, in long but limited-scope experience as a moderator).

	I find that I use those functions pretty frequently on the 
various lists that I help administer at ntp.isc.org.  I don't think 
I've used them yet in helping to moderate lists at python.org, 
however.

>      There are lists where identifiable senders _are_ a problem, so
>      this should be optional.  I think everybody has a spam problem,
>      though---I'd vote for the spam-oriented layout as the default.

	I could support that view.  For myself, I would turn those 
options back on, but that would be more of a personal thing.


	For me, the problem is not one of screen space.  The problem is 
one of server performance.  I can hit "page down" pretty frequently 
and get through a list of messages reasonably fast.  But when I've 
got a thousand messages queued up for moderation, my entire machine 
grinds to a halt as it tries to render that page -- very, very, very, 
very, very slowly.

	This is why I want those command-line server-side tools.

>  2.  I would sort/group on (prefix-scrubbed) subject rather than
>      sender;

	Agreed.

>  3.  Where possible, the information _and the controls_ for a single
>      entry should be on a single line.  I think it's reasonable to
>      assume as a default that the moderator has at least a 1024px width
>      screen

	Now there, I disagree.  My machine is a few years old, but there 
are still plenty of laptops being built and shipped today that have 
relatively small screens, and laptops are quickly becoming the 
default computer instead of desktops.

	Morever, we can't know the typeface/font size choices that the 
moderator has made in their web browser, so what may fit on your one 
line may wind up being effectively three poorly formatted lines for 
someone who is visually impaired.

>      The Defer/Approve/Reject/Discard options can be enormously
>      compressed by getting rid of the tags.

	Based on my other disagreements above, I think it's pretty 
obvious that anything built on top of those premises would get 
further and further into the "bad idea" category.

>  4.  It would be very nice if it could be arranged that each column was
>      of a fixed width but with a horizontal scrollbar every twenty rows
>      or so.

	IMO, this violates the concept of getting everything onto one 
line, so that you can compress things as much as physically possible. 
Either go with an idea or don't, but don't go with an idea and then 
muck it up at the last moment.


	From everything you've said, I think you would like Skip's 
mmfold.py script.  I think you should check it out.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.