A bunch of half-cooked proposals for listwork policy.
Other proposals for Listwork
: A previous proposal by GaBa
, that was included in this
There was another proposal from deanna, it was been lost in the
archive mess, and has been relocated here:
Proposal from Po-A
Proposal that pietro, jb, luis and gaba made in porto alegre
Listwork is the team that is in charge of the e-mails and lists
management for Indymedia. Listwork people have access to the
content of all mailling lists, be they open of closed to the public,
have access at the e-mail aliases @indymedia.org (know to whom e-mails
aliases at indymedia.org are redirected, be it people e-mail or list),
can create, modify and administrate, etc. these mailling lists and
e-mail aliases. While this work is not very difficult technically
speaking, it has consequences regarding privacy and communication in
A significant part of Listwork met in Porto Alegre this week and came
with a proposal. This proposal is aimed at consolidating one of our
important medium of communication both technically and structurally.
Listworkers and system administrators
Currently, about 20 Indymedia techies are having access to the e-mail
server. How they did it to sarai is as unclear as the access policy
to Indymedia global servers (stallman, kropotkin, etc.), not all of
them are part of the listwork team or the administrator team of the
server, all of them are trusted.
While there is no specific problem with who has access to this
computer, we feel that it would not hurt to clarify who can be granted
an access to this computer, how and what for, the propositions follow.
Being a listworker, a sysadmin or becoming one
- As a general rule, people that have access to this computer should have a specified role (listworkers or system administrators) and accept
- to follow the proposed "acceptable behavior" of listworkers and system administrators. Also, as nobody is expected to be listworker or system administrator all her life, such a role (and the associated access) should expire after a certain period of inactivity;
- a new member `candidature\xB4 should be backed by a collective: when one writes to listwork saying she wants to participate, listwork should inform the IMC collective this person is part of and ask if they have concerns about this candidature;
- as a significant part of listwork is composed by IMC-less techies, we think it is ok to grant access to techies trusted by listwork;
Acceptable behavior, do and don't
Listworkers and sysadmin cohabit in a list/mail server. Listworker
do the mailling list and e-mail aliases jobs, sysadmins should not do
Both of them should respect privacy of list users and alias users: closed lists are generally closed for a reason; same for list members.
Of course, debugging lists, mail software and similar insanities
sometimes make it impossible not too look at what goes on in a list,
say, but this should be reduced to the minimum.
Listworkers should not act on behalf on list administrators and users,
except if list administrators or users need help and specifically ask
for it. As an example, a listworker should not think she is a privileged e-mail user (that can approve her messages, etc.) and should
not act this way (unless she really wants it, of course); listworkers
and sysadmins should not feel free to look what goes on in private
lists where they have not been invited, etc.
No e-mail should be left unanswered in listwork@indymedia, no query
Other things go there.
Mailling lists are created on the fly, Listwork people use to do
basic verification about who's requesting the list (does she participate in an IMC collective, etc.) when possible and when time permits, but there is no generalization of that. We think this should
be changed and propose what follows:
How mailling lists are created
- New collectives mailling list creation should be backed by the New-Imc working group: when a recently born collective or a still to born IMC wants a mailling list to be created, Listwork is to ask New-IMC if things are fine and if it is ok to create such a list;
- new lists for a collective should be backed by the collective: listwork should verify that a local collective is OK to have this new mailling list created, etc.
- global lists creation should be backed by their `parent' list (as an example, imc-tech should be OK with imc-sysadmin creation, etc.).
- other lists creation should be backed by process or a similar group, at the very least, a global process group should come with a proposal for what is to be done for creation of lists with fuzzy status.
How they are destroyed
A list is proposed for destruction after a certain period of inactivity
or when members of the list ask for its destruction. Also when there are 100 or more postings held for moderation. This should be
backed by members of the lists or by the collective this lists belong
to. The same people decide if archives are to be kept or not.
There has been a 'cleaning' process for some months. Some lists had 100, even 1000 mails held for moderation. One we have a list of lists with a serious number of postings held for moderation, here is what is done:
1.send email to the owner, offering help in finding more volunteers
and/or offering a new password in case they forgot it.
2.send an email to the list in question, explaining the situation and asking for
3.Have a look at the archives. If there are have been posts in the last
month (that would be from july onwards), send an email to the posters
'offering the admin job' to them. If there are no posts for a monthor
they are spam, send the list to graveyard.
It has been also proposed to send to graveyard lists with no posts for the
last 6 months, but because of a bug that makes some private archives
only available from july onwards, i ended up proposing 'let's just dump
all these lists with no posts for a month'. It might seem a short period
o time but take into account that we're talking of lists with more than
100 posts in moderation whose owner either doesn't exist, or doesn't
receive emails, or doesn't care.
How they are revived
After a list has been destroyed, it is possible that a group wants to have it back.
This is handled the same as for mailing list creation: a new
list is created, we
do not put the old list back in production. This is congruent with the standard
How they should be used
We currently have no acceptable use policy for lists. We propose to
use the following ones for administrators and users. Also, we propose
- no list should be left without an administrator. When no more administrator are left for a list, ask for someone from the list to volunteer and validate a candidature the same way that list are created; simply block the list after some time when no no administrator shows;
- administrators of existing lists and of lists to be created should agree to follow the AUP of list administrators. Manage to find another administrator when they don\xB4t;
- by way of the lists administrators (if they feel like that), inform users there is an AUP for them to follow;
Acceptable user policy for list administrators
A list administrator should respect the privacy of the users of
the lists and be concerned with it. As an example, she should contact
listwork when it is necessary to hide posts and can\xB4t do it by herself.
More AUP things go there.
Acceptable user policy for list users
AUP things go there.
Last but not least, we plan to rename all mailling lists in the same
falshion than e-mails: instead of imc-uk-tech, let\xB4s have email@example.com, not only it will make our system scalable (consult
your local system administrator to know why) but also it will let
collectives choose how they plan to name their lists, etc.
How they are created
Aliases are created on the fly: usually, when firstname.lastname@example.org
to be email@example.com
, he asks listwork who, after some basic
checking (when time permits, generally) creates the alias. All the
cool kids have an @indymedia.org e-mail address, but the process is a
bit weird as we have no way to really check that aliases are OK, that
collectives agree, etc. Also, a tiny amount of IMC volunteers have
aliases (those that learn they can have one, in general). Since we
think that every IMC volunteer should have her own alias but know that
our system will never scale, we would like to change things that
- forget about @indymedia.org aliases and change them to @collective.indymedia.org, where collective is to be replaced by the name of the collective a person is part of. Not only it will simplify the relations between all IMC volunteers called Bob, but also it will be make our system waaaaays more scalable by letting us have different e-mail servers in a simple manner. We plan to ask people that have @indymedia aliases to release them after a certain period;
- once this is done, clean the current alias table, then ask local collectives to back people that want e-mail aliases @collective;
- we plan to ask collectives if their alias table is ok on a periodic basic.
How they are destroyed
Spam, spambots and the rest of it
Our list server receives a great deal of spam. We shall use all practical
techniques to deceive spambots and reduce the level of spam that makes it to the
mailing lists, and at the same time reduce the number of false positives (i.e.
messages that are not spam but are wrongly tagged as spam by the filters).
(this may be a separate document - some mail sites require that we have a privacy
policy, so we might have to be verbose here).
Posts that infringe on the privacy of users are either hidden or entirely removed
User information is not shared with third parties.
Abuse reports are received at firstname.lastname@example.org
- 24 May 2004 Reformated a bunch.
- 28 Sep 2004 Added graveyarding stuff in 'how they are destroyed'
- 12 Mar 2005 Moved Gaba's proposal to another page, added some stuff and reordered a bit.