Mailing List Cleanup Proposal

7 posts / 0 new
Last post
Mailing List Cleanup Proposal

(Adapted from

I think there's agreement that it would be useful to clean up mailing lists that are no longer being used.

In terms of the specific process, (IMHO) this is something that has to be done non-disruptively. This means getting in contact with each individual list, and talking stuff over. (There are 110 of them, so this process will take a while.)

Here is my first draft at a proposed cleanup process.

For each mailing list:

  • Write to each mailing list + mailing list owner, asking: "is this list still active, or can we retire it?"
  • If list says it is active, then leave as is.
  • If list says decides it can be retired, then go to "retire" case below.
  • If no response after one week, assume that the "still active?" question never made it do the list. Add an obit member as list owner, and repeat the process. (Sending the "still active?" question as list owner ensures that it will get through to list members).
  • If no response after two weeks, go to "retire" case below.

Retire Case:

  • Attempt to get some form of consensus on what to do with mail archives. If people would like to keep them, then keep them. If people would like to have the archives deleted, then delete them.
  • Attempt to get some form of consenus as to whether people would like to remain on a low-frequency announce list (i.e, "everyone"). If people are amenable to being on an announce list, then add them. If they're not amenable, then don't. (In this step, we'll have to honor individual requests).


  • There are a couple of cases where this procedure may not be suitable. I'm thinking of lists like daily digest and info tent. We'll probably need to take these on a case by case basis.

Record keeping:

It would be great if several people were willing to take on this work. (And, I think that there are several people willing). It light of that, I'd suggest keeping a `Changelog' of clean up work. This doesn't need to be very elaborate. For example, we could create a wiki page where each section is a mailing list name, containing contains a bullet point list of steps taken.

The changelog would serve two purposes:

  1. To avoid duplicate work (i.e., you can see who's done what)
  2. To provide transparency. If someone asks, "what happened to mailing list X", you can point to the changelog and say "we talked to persons Y and Z, and decided to do this ..."
list cleanup

Anyone's an Occu-hero for taking on such a worthy and time-consuming task.  Would help with oureach to dis-enchanted Occu-straglers.  Then-- a proposal from another comment thread--maybe an e-newsletter, that , you know, actively goes forth rather than waiting to be summoned. All good for outreach to former Occupiers...
What about outreach to the rest of the 99%?

And what about archives?

This proposal doesn't address what to do with mailing list archives (for the case where a mailing list is deleted).

I suppose we should leave this up to the individual lists; we can find a place to store archive copies, or opt not to archive them.

Re: What about archives?

On second thought - if folks are interested in keeping the archives, then it's probably easiest to keep the list as-is.

Wiki Pages for Work in Progess

Wiki Pages for mailing list cleanup work in progress:

Proposal for archiving mailing lists

In the process of cleaning up mailing lists, several have taken the
position "we don't need this list anymore, but we definitely want to
save the archives". So, I'd like to propose an archive strategy.

First, we create a hosting order called "".
I don't picture this being much more than a couple of directories
containing .tgz or .zip files.

Next, use wget (or similar utility) to download archives from a
mailing list.

Finally, tgz the downloaded archives, and scp to

I can picture us using as a general archive
site. For example, we can move materials from there. We could also
(say) wget, tarball, and put that there
as well.


Handling code + database site archives

Brandon notes (via that we should redact email and password hashes, if we release website archives as code + database dumps. I completely agree. In this case, we should also redact any configuration files that might have username/password information.