list subscribers (does include also those with delivery disabled): $ wc -l */memb*`date -I` 27 balug-admin/membership_2007-09-03 264 balug-announce/membership_2007-09-03 258 balug-talk/membership_2007-09-03 And a rough approximation of unique e-mail addresses (note that some folks use unique per-list addresses): $ sort -u */membership_*`date -I` | wc -l 457
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
185
references: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-July/000391.html http://www.balug.org/#Lists file://new.balug.org/home/balug/e-mail_lists/
i like a simpler approach: talk and admin with maybe a couple of specialized, ad hoc lists.
On Sep 3, 2007, at 10:56 AM, Michael Paoli wrote:
list subscribers (does include also those with delivery disabled): $ wc -l */memb*`date -I` 27 balug-admin/membership_2007-09-03 264 balug-announce/membership_2007-09-03 258 balug-talk/membership_2007-09-03 And a rough approximation of unique e-mail addresses (note that some folks use unique per-list addresses): $ sort -u */membership_*`date -I` | wc -l 457
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
185
references: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-July/ 000391.html http://www.balug.org/#Lists file://new.balug.org/home/balug/e-mail_lists/ _______________________________________________ Balug-Admin mailing list Balug-Admin@lists.balug.org http://lists.balug.org/listinfo.cgi/balug-admin-balug.org
Unfortunately that ends up not working so well.
Most notably, when the "talk" list gets quite hopping (which does and has happened, and can happen again at any time), * lots of folks drop from the "talk" list due to volume, or change to getting it in digested form * lots of folks miss noting important BALUG announcements - as they'd be mixed in with lots of other "talk" e-mail (or worse yet, be just one part of someone large daily digest of BALUG "talk" e-mails combined into a single e-mail). * many folks *do* want the high-level important announcements, but don't want all that other "talk" traffic, and only want a quite low volume of e-mails from BALUG (like one to a few e-mails per month maximum). * many BALUG folks tend to forget about specific BALUG meeting dates and/or don't generally look at the BALUG web pages for the latest details about upcoming meetings, and primarily rely upon the "announce" (or other) e-mails to remind them of when the next BALUG meeting is (and if the talk/presentation is or may be of particular interest to them).
If I recall correctly, it was more-or-less out of exactly those factors, and persons requests and suggestions, that the "announce" list came into existence (and the last of those reasons which also tends to favor its continuing to exist).
About the only downside to separate "talk" and "announce" lists - at least as presently implemented - we don't have any particularly simple means of ensuring that everyone on the "talk" (and "admin") list(s) is also subscribed to "announce". There are alternative approaches to that, however. One approach is have "talk" subscribed to "announce", and then remove from "announce" those that are subscribed to "talk" ... but having a list subscribed to a list tends to cause its own sets of issues/problems (we probably wouldn't want to do that without well testing it out and making sure we had any serious issues reasonably addressed). Another approach that works for some, is requiring some key word or string on the Subject header for the "announcement" items - but that tends to push the burden of filtering to easily pick out the most important items to the users (or their clients) - and since "talk" is unmoderated, there's also nothing preventing any subscriber from tossing in such trigger strings on any message they send to the list.
Longer term, we should probably further investigate having "talk" subscribed to "announce" ... that would be a relatively clean method - particularly if we also augment that with some automation (e.g. periodically and automatically remove from "announce" e-mail addresses that show up there that area also on "talk"). That's likely also much more feasible to implement once we're fully migrated off of DreamHost.com.
i like a simpler approach: talk and adminwith maybe a couple of specialized, ad hoc lists.
On Sep 3, 2007, at 10:56 AM, Michael Paoli wrote:
list subscribers (does include also those with delivery disabled): $ wc -l */memb*`date -I` 27 balug-admin/membership_2007-09-03 264 balug-announce/membership_2007-09-03 258 balug-talk/membership_2007-09-03
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
One approach is have "talk" subscribed to "announce", and then remove from "announce" those that are subscribed to "talk" ... but having a list subscribed to a list tends to cause its own sets of issues/problems (we probably wouldn't want to do that without well testing it out and making sure we had any serious issues reasonably addressed).
FWIW, the reason I mentioned that tactic is that it's what SVLUG does, for the lists I admin for them. (I didn't create that setup, but inherited it.) I can't think offhand of any adverse side effects.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Note also that it appears we have a fairly large number of folks that are subscribed to "talk", but *NOT* subscribed to "announce".
Just an idea: In some groups, the announce list's address is included on the subscriber roster of the talk list -- and subscribers of the latter are duly informed that the announce list is redundant for them.