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

[Stephen J. Turnbull]

>>>>> "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:

    Brad> 	I can't speak for Barry or anyone else, but when I use
    Brad> Mailman to handle mailing lists for webmaster, postmaster,
    Brad> etc..., there is a 99% chance that any one particular
    Brad> message is spam, and I have to take a look at the remaining
    Brad> 1% to see if they've managed to forge a plausible subject
    Brad> line on something that we would rather not be allowed
    Brad> through to the list.

If it's really necessary to look so that you can get from 99% to 100%,
then there needs to be some improvement in the UI.

Suggestion: provide a spam-oriented (rather than netiquette-oriented)
moderator screen option.

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).

    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.

2.  I would sort/group on (prefix-scrubbed) subject rather than
    sender; non-whitelisted senders rarely send more than one topic in
    a short period, although they often get frustrated by moderation
    and mail system delays and repost.  And spammers often use
    multiple fake authors for multiple tries of a given subject.  Both
    would be conveniently trapped by this sort.

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 and can read small enough type to put 100 characters on a
    line, and provide an alternative format for people who moderate
    from their cellphones or need inch-high fonts.  (Obviously with
    >80 characters per line you need the vertical rules to separate
    fields.)  I'd try arranging as | Sender | CCs | controls | Subject |
    to optimize eye and mouse movement.

    The Defer/Approve/Reject/Discard options can be enormously
    compressed by getting rid of the tags.  For graphical browsers, use
    rotated text (SVG or prerotated PNGs) in column headers, repeated
    every 20 rows (#rows should be configurable).  For non-graphical
    browsers, use initials (D/A/R/X).

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.  This would allow most froms to be identified in 15-20
    characters, but convenient scrolling if you wanted to see more.
    I'm not sure how to arrange that in HTML, offhand, but I suspect
    it can be done for common browsers.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.