[BALUG-Admin] list subscribed to list "vs." ...

[Michael Paoli]

Quoting "Rick Moen" <rick@linuxmafia.com>:

> Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
>
> Just to reconfirm something I said the very first time this came up,
> SVLUG solves the problem totally transparently to the members, as
> follows:

(list subscribed to list ...)

> At the time I suggested do likewise, I was told (here) that it was not
> possible to do it without problems.

I don't recall having said "problems" ... I did say "potential
complications" ... perhaps not best wording, but in either case, each
method has its own unique advantages and disadvantages.  Either approach
is valid and quite workable.

"Speaking" about the method chosen for BALUG, I earlier stated:
< The above noted approach has the advantages of:
< * it avoids the potential complications of lists subscribed to lists
<   and differing options/configurations (e.g. we want "announce" to be
<   non-digested, but we want folks to have digested form be option for
<   "talk"; if we subscribed "talk" to "announce", then those getting
<   "talk" digested, and not subscribed to "announce" would only see
<   "announce" within digested "talk" e-mails)
< * it allows users to have separate per-list e-mail subscription
<   addresses if they desire such, and provides means for them to
<   request not being automatically added to "announce" based on
<   subscription to "talk" and/or "admin".

Anyway, ... those may not be exactly/precisely the various pros/cons
comparing the different methods (and may also vary a bit depending on
implementation details) ... but in any case, each method does have its
own distinct advantages and disadvantages (e.g. list subscribed to list
offers more simplicity in many/most ways; separate + (nearly) automagic
addition +- exception mechanism allows some more flexibility, avoids
some duplicate emails being sent to subscribers, allows users more
per-list flexibility (e.g. distinct email addresses), but adds some more
complexity for administration), ... and on and on one could go comparing
them.

Anyway, the present BALUG method seems pretty well settled in and users
(even newbies coming to the lists) seem to mostly understand it rather
to quite well (as far as I'm aware, we haven't gotten a question or
specific item about that from any subscriber (or potential subscriber)
... certainly not recently, perhaps not ever) ... and users seem to now
mostly "do the right thing" when subscribing ... e.g. the number of
folks I find subscribing to a BALUG list other than "announce", but not
subscribing to "announce" is relatively small ... digging a bit more
into list data (since the subscription totals don't reflect turnover
information) ... between 2009-01-10 2009-03-27 total turnover on all
BALUG's lists (adds and drops less auto-add) was 36 ... plus 3
auto-added ... so seems well over 90% get it right (rough small number
statistics figure anyway - I don't think I saved more detailed
historical "auto-add" data for more detailed analysis).  So, ... being
lazy(/efficient :-)) ... since it seems to work rather/quite well, I'm
inclined to leave that general setup as it is (if it ain't broke, don't
fix it).  It also lends itself well to (future) automation.  The script
bits that do the "heavy lifting" (logic) - pretty compact, per wc(1):
   7  40 365
With mailman CLI commands, cron, and a wee bit of glue logic/script,
that can become fully automated process (well, except adding/removing
email address from the "exception" list - but thus far there have been
zero such requests - so that seems pretty easy to maintain).

references:
http://lists.balug.org/pipermail/balug-admin-balug.org/2007-October/000419.html