[IMC-Tech] Draft: How to properly shut down an IMC

boud boud at riseup.net
Sat Sep 12 17:15:54 PDT 2009


hi everyone,

i've edited the draft:
  https://docs.indymedia.org/Global/DeadImc#Proposal_draft_2009

i suggest that people make changes directly on the wiki, or if there
are difficult points, bring them up here on the list. The following is
to explain the changes i made. The general point is that AFAIK, we have
always tried to make it clear that an IMC is not just a website, an IMC
is a (loose and open) collective of people. The other point is our
attempt to oppose systematic patterns of domination in the world.

i tend to agree with all of mark's points here. i don't see that we
need to invent any new "shutting down an imc" process, since we don't
have any formal agreement on how to make network wide decisions, but
we do have what seems to be de facto agreement that anything that is a
network wide decision should be a bottom-up decision from a local imc
"up" through imc-process. There are no principles or general
restrictions on what sort of proposals a local imc can make on
imc-process, AFAIK. The only "difficulty" is that we expect certain
anti-domination things (like multi-language, local consensus of that
IMC) on emails sent to imc-process. Is this really so difficult if
we want to have any hope for evolving beyond a semi-global network to
a global network? In any case, as mark said - several imc's have proposed
that other imcs (usually in the same region) be removed from the cities
list and AFAIR, there were no great controversies on imc-process regarding
IMCs that were clearly no longer maintaining their websites. The proposals
were accepted and the imc's removed from the cities list.

On the other hand, i do think that there is one "political" aspect
that could cause controversy, for obvious reasons, and that would be
when an imc from a rich/English-speaking/colonial region of the world
proposes closing down an IMC in a
poor/non-English-speaking/economically-dominated region of the world.
(The "/" are "and/or".)

In other words, someone external to indymedia does need to learn about
our bottom-up principles/ideals, that's true. But s/he only needs to
convince one local IMC to make a proposal to imc-process. It's
reasonable for geographically distant IMCs to feel that they don't
have the right to make the decision, even if it seems an easy
decision. On the other hand, if IMCs in a whole region are
dysfunctional, then it's probably reasonable for a distant IMC to make
a proposal like this, despite the risk of colonial/hierarchical
concerns. That's why the first three steps of the process as i
restructured the text are: local, regional, global.

i haven't modified the tech aspects of the proposal, except to make
a rough suggestion regarding "we're closing, howto reorganise" notices
on frozen websites.

i think that not having a frozen/archival website with a clear "howto
reorganise" notice is a great loss. i realise that this does take some
tech work, but IMHO the experience from france.indymedia.org, which had
a "howto" notice like this for the many years until it eventually stopped
being maintained and/or dns was turned off, shows that the freeze 
and howto notice helped to encourage many local city imc's in france
to organise as imc's.

We could probably have a reasonably standard template that we translate
into a few major languages, and ask a local to translate into the local
language if needed.

horizontalidad
boud



On Tue, 8 Sep 2009, Alster wrote:

> mark burdett wrote:
>> Hopefully suspending a hacked cms instance is something that a
>> reasonable webhost has a process to do on its own?  Whereas "shutting
>> down an IMC" is a larger process where we can notify the network that
>> an IMC is inactive and the network can agree to delist this IMC until
>> it re-forms.
>
> So, you may have the steps this would take on your mind? Can you
> document what you think it would take on the wiki for us?
> I put my initial suggestion here, ready to be edited and improved upon:
>
> https://docs.indymedia.org/Global/DeadImc#Proposal_draft_2009
>
> Feel free to change it to your liking, or to add your own suggestions
> instead.
>
>> I was involved in delisting a few US IMCs last year e.g.
>> http://lists.indymedia.org/pipermail/imc-process/2008-August/0813-01.html
>> http://lists.indymedia.org/pipermail/imc-process/2008-June/0605-ai.html
>> and I didn't find the process at all difficult or time-consuming
>> (although I realize there are quite a few more inactive IMCs out there
>> that need to be delisted). I am happy to serve as a volunteer "grim
>> reaper" if someone would like some help shutting down an IMC.
>
> If you ever happen to have some spare time, you're welcome to get
> started with these:
> https://docs.indymedia.org/Global/DeadImc#Hand_tested_non_existing_when_te
>
> Note that this list is a bit old by now, it dates back to 2007, I think,
> but I'm sure the very most of these will still be as inactive as they
> used to be back then. Keep in mind that just shutting down the websites
> is not enough, it also involves notifying the global working groups to
> delete or archive all their accounts and data such as:
> * DNS entries
> * contact DB users and IMC listings
> * mailing lists
> * email aliases
> * SoS queues (if any)
> * ...
>
>> I'd say the technical work of figuring out how to create a static
>> archive of an indymedia site (and in the process hopefully cleanup any
>> backdoors as well as spam, malware etc. which may be hosted there) is
>> more difficult and time-consuming than the process stuff. but I may be
>> able to help w/ this technical work too, especially if I'm familiar
>> with the CMS (e.g. I am pretty clueless about the dada CMS)
>
> So, since I don't think I can drive two things, I'd be very happy if you
> would like to push this further.
>
> Alster
> -- 
> GPG key   http://zimmermann.mayfirst.org/pks/lookup?search=0x05059C17
> GPG FP    1B8B 128F 8435 541C B3A5 1B7E CF5A 9D55 0505 9C17
> Info      https://docs.indymedia.org/view/Main/AlsteR
>
>



More information about the imc-tech mailing list