stats: list membership (~482 total uniques)
total uniques up slightly (by about 5%) from not too long ago.
list subscribers (does include also those with delivery disabled): $ wc -l */memb*`date -I` 27 balug-admin/membership_2007-10-21 304 balug-announce/membership_2007-10-21 251 balug-talk/membership_2007-10-21 $ sort -u */membership_*`date -I` | wc -l 482
Note also that it appears we have a fairly large number of folks that are subscribed to "talk", but *NOT* subscribed to "announce". Theoretically (at least logically) that shouldn't be the case (in general - typically exceptions being per-list e-mail addresses), but it is totally under "user" control. A quick count of that: $ { sort -u balug-talk/membership_`date -I`
cat balug-announce/membership_`date -I` \ balug-announce/membership_`date -I`; } | sort | uniq -u | wc -l
172 ... nevertheless *that* number is down moderately from not too long ago.
After considering various options, what I'm inclined to do to "rectify" that, is after announcing it and noting it on the lists appropriately, for e-mail addresses that are on the "talk" and/or "admin" list lists, they'll get periodically added to the "announce" list - unless they specifically notify "us" (list admin(s)) that they want to be on an "exception" list (e.g. if they have and want to use separate per-list subscription addresses). The process would be semi-manual at least initially, but would, longer term, be fully automated (well, except for the being added to the "exception" list - that might require manually adding the e-mail address to a file). 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". I'm also inclined to set up an alias for the balug list admin(s) - that way folks have a consistent e-mail address that can be used for that. (Mailman lists and displays the list admin e-mail address(es) - it looks a lot more clean if there's a "generic" address for that function, rather than listing all the individual folks that are in the set of list admins for any given list).
references/excerpts: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-September/000404...