List "policy"/description tweaks.
These are changes I have in mind for the lists. This isn't for the (shorter) text that appears on our main http://%5Bwww.%5Dbalug.org/ web pages, but rather on the more detailed Mailman list pages, e.g.: http://lists.balug.org/listinfo.cgi/balug-talk-balug.org
What I show below is draft of text changes (I'd also do similar on Balug-Admin regarding automagic subscrition to Balug-Announce). The text below doesn't include the relevant URLs (those would be linked appropriately from the text), and there may also be some slight tweaking of e-mail address configurations (most notably admins and moderators for the lists, and any related @balug.org aliases - I'll coordinate with Rick Moen to be sure anything we do there is and works reasonably).
------------------------------------------------------------------------
Balug-Announce
This is a low-volume* announce-only (non-discussion) mailing list to cover items of key interest to Bay Area Linux Users Group (BALUG) and its members (e.g. meeting announcements/programs, important announcements, BALUG "news" items of note, and items highly likely to be of interest to many/most BALUG folks and related Linux community).
If you subscribe to any of BALUG's lists, you should subscribe at least to Balug-Announce.
For more general BALUG and related discussion, see the Balug-Talk list.
If you think you have something highly worthy of being sent to the Balug-Announce list, send it to the Balug-Announce list moderators, and we'll consider sending it along, including it, or providing a short reference to it. Note, however, in most cases it is typically more appropriate to post an item to Balug-Talk, and if we deem it appropriate to do so, we may then cross-reference the item posted on Balug-Talk and/or include some of its relevant content on item(s) we send to Balug-Announce.
Balug-Announce does not have the "digest" option enabled, as its mailings should be important, and might sometimes be time critical. Note however that the mailings may, however, be in a digest-like form (e.g. a single mailing may include several items of note, and may also have a very brief summary or subject of each noted near the top of the e-mail's body).
Balug-Announce is publicly archived.
*approximately 1 to 3 e-mails per month - we aim to keep the average at or below 3 per month
------------------------------------------------------------------------
Balug-Talk
This is a public discussion mailing list for Bay Area Linux Users Group (BALUG). Items should generally be reasonably appropriate/relevant to the group (e.g. Linux and Open Source, in, around, or including the greater San Francisco Bay Area, etc.). Please try to use/update Subject: on mailings to reasonably summarize what the posting is about. If you feel compelled to post on something rather to quite off-topic, kindly try to indicate so in the Subject: (e.g. start it with "[O.T.]" or something like that). And of course, don't spam the list. We intend to interpret the above, notwithstanding the below, rather liberally.
Job postings - job postings/listings are disallowed*, with one exception**. Note however that there isn't a prohibition against noting one's availability for job/contract work, posting a "position wanted" item, or discussion about employment and employers, job markets, recruiting/hiring/firing, whether or not not the list should allow job posting and under what circumstances, how to and not to do a job posting and where, etc. The prohibition is to be interpreted rather narrowly - just don't post a job listing or collection of job listings, or something with the rather exclusive intent to refer to your, your company, or your agency's job listing(s) or job site.
If you're looking for places where job postings are permitted/welcomed, you may want to check some other resources (e.g. SVLUG Jobs or BayLISA Jobs, or consult the policy regarding such for SF-LUG).
Balug-Talk is publicly archived
NOTE: Subscribers to Balug-Talk should also be subscribed to Balug-Announce. If you're subscribed to Balug-Talk, but not subscribed to Balug-Announce, you may find yourself automagicly also added as subscribed to Balug-Announce. If for some reason you don't want that to happen (e.g. you use distinct e-mail addresses for each to route/filter/sort more to your preferences), send an e-mail note to Balug-Announce list admin indicating what e-mail address you don't want automagicly added to Balug-Announce, and why, and we'll add it to our exceptions list.
* Job posting policy (general prohibition) may be subject to change/adjustment over time, mostly based upon majority (or at least plurality) of wishes of users subscribed to Balug-Talk (e.g. policy might be adjusted slightly or significantly, or BALUG might decide to create a separate "jobs" list).
** If you have been scheduled and confirmed to give a talk/presentation at BALUG, or have rather to quite recently given such a talk, you are permitted to make a job posting/announcement to BALUG-Talk. It may be advisable to include short mention towards the top of the e-mail that reminds folks how this specificly fits within list policy (e.g. "Thanks for having me for the ... BALUG talk. Per the list policy, here are the currently open positions I'd like to mention:"). Please, only one job posting e-mail per talk/presentation. It may be highly advisable to include relevant links and/or contact information in the posting where folks will be able to obtain updates on the position(s) (e.g. description changes, position closed, additional positions opened, etc.) so one doesn't feel tempted to "need" to make a follow-up posting to the list about the position(s).
------------------------------------------------------------------------ See also, e.g.: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-October/000419.h... (starting about halfway down that item) for a bit of earlier discussion on some of these items.
Rick,
Let me know if you have any problems/issues/concerns regarding these configuration changes I have in mind to make to BALUG's lists:
I'd like to change the list administrator address(es) from: balugadmin@balug.org rick@linuxmafia.com to: balug-list-admin@balug.org (you and I are both included in the above alias; balugadmin@balug.org apparently hasn't existed for quite a while, and just bounces) key rationale: provide consistent presentation on the Mailman web pages about list administrator/owner address(es); we (BALUG sysadmins, presently myself and Jim Stockford) can change members of the balug-list-admin@balug.org alias at will.
Also, I'd like to set the presently null list moderator address(es) to: balug-list-moderator@balug.org Likewise, you and I are included in that alias.
Also, I'd like to change: Discard held messages older than this number of days. from 3 to 21 and change: Should the list moderators get immediate notice of new requests, as well as daily notices about collected ones? from Yes to No rationale: stuff snagged for admin/moderator is mostly just spam and occasionally non-subscriber post attempt (accidental or intentional), it's highly unlikely any such held item would be so time critical as to warrant notification to list admin/moderator more than once per 24 hours; also, since the bulk of it is notification about spam anyway ... not sure about your preferences, but I'd prefer to get notified about such less often (once per day I think I'd find rather/quite tolerable, once for every e-mail that's held, I've found to be quite annoyingly excessive). Also, though I presume we'd fairly regularly dispense with the held items, by extending the maximim hold time, we reduce the risk of possibly losing an item that might get held and be something we wouldn't want to discard.
I presume also that the admin/moderator functions can be done quite reasonably (or even preferably) via the web interface, and needn't be handled via e-mail originated with From: address of list admin/moderator.
Let me know if you have any problems/issues/concerns regarding these configuration changes I have in mind to make to BALUG's lists.
Also, I have in mind some policy tweaks to make - those were basically mentioned in earlier posting (noted below) - and they'd also be noted to the lists when the policies are actually updated.
references: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-October/000420.h...
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Let me know if you have any problems/issues/concerns regarding these configuration changes I have in mind to make to BALUG's lists:
Thanks for taking leadership on this, Michael. Hoping you'll take this feedback in the spirit intended, since I'm about to say "I recommend against", in several particulars. ;->
I'd like to change the list administrator address(es) from: balugadmin@balug.org rick@linuxmafia.com to: balug-list-admin@balug.org (you and I are both included in the above alias; balugadmin@balug.org apparently hasn't existed for quite a while, and just bounces) key rationale: provide consistent presentation on the Mailman web pages about list administrator/owner address(es); we (BALUG sysadmins, presently myself and Jim Stockford) can change members of the balug-list-admin@balug.org alias at will.
I think there are disadvantages that outweigh that, and would prefer you not do it. For a long time, I've thought that it would be better if we _did_ move to more consistent presentation, but in the exact opposite fashion, by replacing "balugadmin@balug.org" with whatever address or addresses lie behind it.
Why, you ask? Several times, I've wanted to remind myself of who the listadmins[1] are of, say, balug-talk. So, I go to http://www.balug.org/ , and follow links to http://lists.balug.org/listinfo.cgi/balug-talk-balug.org . I look down at the bottom, and -- oh frell. Damn, it says only:
Balug-Talk list run by balugadmin at balug.org, rick at linuxmafia.com
Well, I think to myself, that's, as my old boss used to say "almost useful" (i.e., not useful), and I still, to this day, have really not idea who's on the listadmin roster for any of our lists -- except myself.
I happen to think it's really useful from any number of perspectives to have the end-destination addresses be visible, there. It's a form of documentation for ourselves and for the membership. It also means people can be added and removed from the admin rosters (and remove themselves) without needing shell access to edit a security-sensitive e-mail alias.
The fact that balugadmin@balug.org turns out to be a non-functional address and go nowhere illustrates, in fact, one reason why aliases should simply not be used for this purpose: Being a hidden mechanism, any breakage will tend not to be apparent.
Anyhow, I have both pragmatic and ethical reasons why I make my recommendation. The pragmatic ones are outlined above. The ethical one is basically: I make a point of standing behind what I do, by name. I've seen several LUGs' Mailman lists where abusive listadmin practices get hidden behind indirect mail addressing, so that the public cannot readily tell who's the backstabber. So, I've made a particular point of acting as little like that as possible -- and accountability requires visibility. (This is also why I put my name and e-mail address on my LWN and similar Web-forum postings, even where it's not required or traditional: Pseudonymity gets abused much too badly in such places, and I want to make a particular point of standing behind what I do and say.)
Also, I'd like to set the presently null list moderator address(es) to: balug-list-moderator@balug.org
Again, I'd recommend you didn't.
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.)
Unless you've used it yourself, it's possible that you might be making assumptions about how it functions. (Please don't think I'm being patronising in saying that. I've just noticed people often make assumptions about that feature based on its name and their intuition, that don't match its actual implementation.)
Likewise, you and I are included in that alias.
Again, I'd strongly recommend not using aliases for this purpose -- same reasons as above.
Also, I'd like to change: Discard held messages older than this number of days. from 3 to 21
If you like. However, I strongly doubt that any legitimate mail (e.g., sent from a non-subscribed address) isn't going to be noticed within three days by any of the people getting the listadmin nagmails. I set that value because of three-day holiday weekends, to make sure nothing legitimate gets overlooks.
In my experience, setting it to three weeks is just going to increase the number of Mailman listadmin nagmails you get for held spam. I think you'll soon be changing it back ;-> , but please make up your own mind.
and change: Should the list moderators get immediate notice of new requests, as well as daily notices about collected ones? from Yes to No rationale: stuff snagged for admin/moderator is mostly just spam and occasionally non-subscriber post attempt (accidental or intentional), it's highly unlikely any such held item would be so time critical as to warrant notification to list admin/moderator more than once per 24 hours; also, since the bulk of it is notification about spam anyway ... not sure about your preferences, but I'd prefer to get notified about such less often (once per day I think I'd find rather/quite tolerable, once for every e-mail that's held, I've found to be quite annoyingly excessive). Also, though I presume we'd fairly regularly dispense with the held items, by extending the maximim hold time, we reduce the risk of possibly losing an item that might get held and be something we wouldn't want to discard.
Yes, good idea.
I presume also that the admin/moderator functions can be done quite reasonably (or even preferably) via the web interface, and needn't be handled via e-mail originated with From: address of list admin/moderator.
Realistically, this is going to be just a post from a non-subscribed address about once every few months on average. Otherwise, it's just spam that Dreamhost's lousy anti-spam setup lets sail straight through.
Let me know if you have any problems/issues/concerns regarding these configuration changes I have in mind to make to BALUG's lists.
to the lists when the policies are actually updated.
references: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-October/000420.h...
Your draft was very thoughtful, so at the time I didn't want to say anything that would seem critical. Since you're specifically asking my feedback: Your text is much too long to actually get read by real-world subscribers.
There is no good solution, on that matter: Most people just never will read any documentation no matter how concise and clear -- or not read it at the right time, or forget -- or deliberately ignore what they saw, or not understand it. However, my experience suggests that really, really short policy text is what works best. (This also conveys that you're serious: People are much, much less likely to take seriously policy texts with long explanations.)
Here's is the complete policy text on CABAL's main mailing list's listinfo page:
This is a general discussion forum for the San Francisco Bay Area's CABAL Linux user group. It is also gated to the cabal.conspire local NNTP newsgroup. (Please write to postmaster@linuxmafia.com, specifying your fixed IP address, if you want access to our NNTP news server.)
Per list policy, our (subscriber-accessible) membership roster and public message archives display unobscured posting addresses. If you're trying to hide your e-mail address from spammers, avoid this list.
While we appreciate the need for jobs postings, they easily overwhelm this small mailing list: So, you must submit them via e-mail to the listadmin, who'll decide whether to post them on your behalf. Reasons why the answer has been "no" in the past have included their having already been posted to other local LUG mailing lists. (We get tired of seeing the same posts everywhere.)
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.
[1] For completeness: The Mailman roster in question is not actually the set of listadmins, per se, but rather is the set of e-mail addresses that will receive "something needs your attention" nagmails from the MLM. The _actual_ people capable of carrying out administrative actions are the complete set of all people who know the mailing list's current listadmin password. These may be disjoint or overlapping but non-identical sets, but most often aren't.
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.
Argh. Typos.
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.
^^^^ "quite"
So, the Mailman "moderator" role is one with extremely unlimited powers
^^ should be "limited"
granted intentionally, plus one excessive and destructive power granted by accident.