A bunch of half-cooked proposals for listwork policy.

Other proposals for Listwork

ListWorkPolicyGaba: A previous proposal by GaBa, that was included in this one (afaik).

There was another proposal from deanna, it was been lost in the archive mess, and has been relocated here:

http://archives.lists.indymedia.org/listwork/2002-May/002065.html

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 the network.

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 that.

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 be ignored.

Other things go there.

Lists

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 volunteers.

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 netiquette.

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 that:

• 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.

List administrators must comply with the privacy policy spelled bellow.

More AUP things go there.

Acceptable user policy for list users

AUP things go there.

Renaming lists

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 tech@uk.indymedia, 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.

Aliases

How they are created

Aliases are created on the fly: usually, when bob@yahoo.com wants to be bob@indymedia.org, 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 way:

• 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).

Privacy policy

(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 by listwork.

User information is not shared with third parties.

Abuse

Abuse reports are received at abuse@indymedia.org.

-- JiBe - 24 May 2004 Reformated a bunch.

-- AnA - 28 Sep 2004 Added graveyarding stuff in 'how they are destroyed'

-- JiBe - 12 Mar 2005 Moved Gaba's proposal to another page, added some stuff and reordered a bit.