[Imc-europe] Summary of dispatch meeting

ana penasana at yahoo.es
Fri Aug 15 12:06:04 PDT 2003


For those who find it easier to read a summary...

Summary of the irc meeting that took place on Tuesday 12th of August,
about dispatch.

As talked about on the imc-europe list:

http://lists.indymedia.org/pipermail/imc-europe/2003-July/001311.html
http://lists.indymedia.org/pipermail/imc-europe/2003-August/001317.html

dispatch documentation:

http://docs.indymedia.org/view/Local/KampagnenGipfelEtc in DE
http://docs.indymedia.org/view/Local/SummitPrepEn in english

dispatch page used for previous actions:
http://dispatch.indymedia.it

other useful links that came up:
http://docs.indymedia.org/view/Devel/TranslationTool
http://indymedia.gotdns.org/indymedia/

Participants:

ana from uk, london
Alsterwassermann from germany
XaViER from IMC PL
sri from .at imc - editorial (use of dispatchsystem)
linksrhein member of german translation team, customizer of the
translation tool -
sbunny Space Bunny from Edinburgh http://j12.org/sb/
Amor_AT .at imc - editorial
Anna from germany,

SUMMARY.

Def.: dispatch's job is to find out what really happened and what is
just a rumour, producing reliable info for the local imc’s.

This project breaks down in areas of task to do does project break down
into: tech, people system/structure, admin, access, co-ordination, ppl
in the streets. Big recognition to these people informing from the
streets, who are also part of the dispatch team, without them, there is
no info.

A few outlines of how dispatch works/doesn’t work; proposals later:

People who ‘know the system’ seem to spend lots of time telling ppl what
dispatch is and why to use irc channels, how to confirm news...

There is an urgent need for people, both for people on ‘location’,
locals, on the streets, and for dispatch/irc. We need to encourage ppl
to get involved.

During koln it was not dispatch team but translation team, we hadn't
contact with locals (although there was no plan to make anything like
this either) during wto-montreal was better but not good coordination in
cologne we had some contact to the local group, but it's a good example
how it doesn’t work well to not have a local team

During Geneva, it was too complicated for people to use two chat
channels, one for confirmed and one for unconfirmed news - we had people
there to help who didn't know what a chat is, and often we are so few
that we fill all 10 different roles at the time, there just is not the
time to explain all the steps.

During the last dispatch situations - tessaloniki, the noborder camp, we
started to argue a lot about where to work virtually, which was strange
because there was no local dispatch team taking things so we argued
where to put it. Mostly it stayed on the dispatch pages, and i thought
that wasn't wise because i don't think many ppl regularly go there to
look. Actually i didn't have the feeling people were out to coordinate
what they were doing, everyone was updating their site by themselves: a
huge waste of energy; so i propose if we want to continue using that
page we need to do some kind of PR action so that more people see a
sense in dispatch, more ppl cooperate regularly, and then everyone might
know to look for information on that page, which might have to be a bit
better structured. i find it hard to find things.. BUT i'm not sure
we'll manage to force the chaotic indymedia worls into such a
centralized thing.

Technical proposal (proposal 1). To construct a dispatch system which
will generate output to all local imcs which want those news on their
websites in their own language. With the example of the G8 summit, this
would be done in these ways:

- Automatically carry all information which was both verified and
translated over to the all local IMC websites which have "subscribed" to
the newsfeed
- Combine the news aggregation system by Zapata (it (semi-)automatically
collected all info posted on the different IMC with topic G8) available
at http://www.indymedia.org:80/g8/ and the system available at
http://www.biotechimc.org with the dispatch system
see this email,
http://lists.indymedia.org/pipermail/imc-europe/2003-July/001311.html
on the paragraph "characteristics of the dispatch system"

also take a look at the last two blocks on this drawing:
http://indymedia.gotdns.org/indymedia/

advantage is that, people would not need to look at the dispatch system
as it would only be a intermediary storage for texts etc (contents);
there still would be need for attracting people to take part in the
actual dispatching, but with the results spread all over the local imcs
people wouldn’t have to look at the dispatch system

Concerns about this technical proposal, also called working model:

Concern 1: necessary involvement of techies in a way that we depend on
them.

Response 1 to concern 1: you don’t need lots of specialized techies to
run such a system. With increased usage, more and more people would get
to know how it works and how to set it up and how to admin.
Response 2 to concern 1: whatever technical tool you use, you will be
somewhat dependent on techies... the trick is, to make a system that is
also stable and dependable; in the case of a dispatch system, it should
be a central system, with the ability to create separate "projects" in
it, like g8, cancun, whatever: continuously run, with as little
maintenance as possible.

Concern 2: need for lots of people for this solution, and as it happens
now dispatch is always short of ppl

Response to concern 2: in the diagram,
http://indymedia.gotdns.org/indymedia/, what you see there are *roles*,
not persons, and a person can have several roles.

Response to this: often ppl doing dispatch are the same as people
writing – as they are the ppl who have a proper overview and motivation
to do a summary – ppl already do lots of jobs.

Concern 3: it might result into 100 2-line articles on all websites
getting the feed. This is not good because: often during summits you get
lots of little informations that need to be checked, and then be out
together into a story that THEN can be published, maybe 2 hours later,
when you are sure of what actually happened. for this it's absolutely
necessary to have a local group, physically there. Should not publish
everything that's confirmed right away [automatically]. i think we need
something to confirm information that then can be worked with [not
automatically], and THEN will be published [not automatically], when the
dispatch thinks it's ready to be published. don't think all the chaos
should be published.

Response 1 to concern 3: Yes it would be useful to have the ability for
each local imc to select which article will be posted to their site and
it should be possible to them to remove a formerly posted news and
replace it by a different and more detailed version afterwards.

Response 2 to concern 3: it is also important to have many short news
(but maybe not at the front page) because they are needed for analysis.

Response 3 to concern 3: what dispatchers do is handle mostly
information. They should leave the choice to the people that want to use
the information: post it, not post it, but use it for articles…

Concern 4: It feels like an ideal solution that's far from the realitly
we face now, or a technical solution not knowing what working model we
want first…

Response: it looks technical but it can also be considered a working model.

*proposal* 2. better PR and also better contact with locals who put info
at dispatch, need to get more ppl interested.
- also, a lot more effort to get the information out IN TIME that people
should cooperate with indymedia and that their knowledge (of an action)
is very important

*proposal* 3. go on with developing different specialised systems for
different purposes. For example three different systems like a dispatch
system, an aggregator system or a translation tool. Maybe interconnected
with rss-feeds.

*proposal* 4. try and make the system easy and manageable, making no one
indispensable – easy to use. Eg. two chat channels, one for confirmed
and one for unconfirmed news, was too complicated for people in Geneva.

*proposal* 5. Form a dispatch group who feels responsible. Then invite
those who do dispatch not on irc primarily. - Need to have a presence as
imc dispatch, then advertise yourself...

Proposal 6. maybe a split into those who'd like to develop tech tools,
and those who want to think about what they will be useful for. 26

Proposal 7: production of articles could be done by each IMC, meaning,
each IMC could write full articles on the dispatch system and thus allow
others IMCs to translate tem for their own IMC – more logical than
having ten people [one on each imc] write a similar article; especially
thinking of IMCs who have different priorities and/or don't have people
who are interested enough AND have the time to write an own article.

Proposal: meet again in two weeks

Proposal 8: for next action, people who want to work on dispatch
coordinate some preparation in this list first, say 1 week in advance to
allocate roles and make plans

Proposal 9: first gather docs on the wiki, then ask people to join the
discussion

Proposal 10: translate it

Proposal: wiki for all these ideas:
http://docs.indymedia.org/view/Global/WebHome
or
or http://docs.indymedia.org/view/Devel/DispatchSystem




More information about the Imc-europe mailing list