I wrote (about CABAL policies on http://linuxmafia.com/mailman/listinfo/conspire):
I should actually cut the length of that in half, and probably will, now that I've notice that _it_ also is a bit too wordy.
Policy is now amended to:
General Linux forum for San Francisco Bay Area's CABAL user group, also gated to local NNTP newsgroup "cabal.conspire": For NNTP access, send your fixed IP address to postmaster@linuxmafia.com.
Our policy: the subscriber roster and public message archives will display unobscured addresses. If attempting to hide an e-mail address from spammers, don't post from it.
Jobs postings must be e-mailed to postmaster@linuxmafia.com, who'll post them or not. Reasons why not have included their posting to other local mailing lists. (We get tired of seeing the same posts everywhere.)
That's maybe 30% shorter, I think.
I've had a lot of experience with the Mailman "moderator" (as opposed to listadmin) mechanism, and find it not very useful, and to have problematic characteristics. I'd frankly urge continuing to ignore it. The reasons are a bit complex, and are most easily discussed in person. (I'm not saying there's any secrecy about it: It's just that it'd be more efficient to go into those details in person.)
In brief, Mailman's "moderator" role is a bit like a listadmin, but with deliberately curtailed powers. (This is per se a useful concept. What makes it of limited use is the implementation.)
In NON-brief {/me takes a deep breath}:
Within any given Mailman list's configuration, you can set two list-wide passwords: listadmin password, and moderator password.
The administrative login prompt (Web page) will authenticate you with either password: If you give the current listadmin password, you have access to all configuration and informational items. You can view all settings, change anything whatsoever about it, edit the Mailman-generated Web pages, view and process the admin queue, etc. You can also delete the entire mailing list, via a single Web-page pushbutton (with confirmation).
If you login using the current moderator password, you're shown, and can change, the admin queue _only_. On each held post, you can defer, approve, reject, or discard. In so doing, you can optionally check a checkbox beneath the held posting to add the sender address to a roster of senders to be either approved, rejected, or discarded prospectively.
During the several years when I was cleaning up and fixing SVLUG's mailing lists, I found a number of e-mail addresses on some of the mailing lists' autodiscard and autoreject rosters that almost certainly should not have been there: I recognised at least one, that of Anthony Ettinger, as that of a quit innocuous Web developer from Saratoga. Seeing no conceivable reason why his postings should be autodiscarded, I removed that listing and wrote to him, to explain this (as well as I could) and apologise on behalf of SVLUG for what was either some vanished volunteer's mishap or act of malice.
SVLUG, you see, had been issuing a "moderator" password to some volunteers to assist with held postings. All it takes is for one to frob the "add this sending address to the autodiscard roster" checkbox, and that person is killfiled indefinitely. Moreover, the moderator cannot review such actions to catch such errors, and cannot correct them even if he/she figures them out.
Probably, some such person at SVLUG messed up, at one point, and either didn't realise he/she had just backstabbed Anthony, or realised it but was powerless to fix the deed. A number of other such entries seemed doubtful, so I ended up removing all but a few obvious spambot ones.
So, the Mailman "moderator" role is one with extremely unlimited powers granted intentionally, plus one excessive and destructive power granted by accident. (Note that an unscrupulous "moderator" can use that privilege to killfile arbitrary addresses that aren't currently subscribed: Just sent mail to the list forged to apparently come from that address, wait for it to show up in the admin queue, then discard it and check the "autodiscard future posts" checkbox.) Mainly for this reason, I consider the role nearly useless pragmatically, and also an accident waiting to happen.
And therefore recommend that BALUG not use it.
What Mailman _really_ needs is (1) a role that allows someone to view all admin settings + admin queue but change nothing, (2) a role that allows one to view & process the admin queue + the autodiscard, autoreject, and autoapprove rosters, and (3) a role that allows someone to use the "invite" function without access to other admin settings except to view the membership roster. But it doesn't have those.