[Imc-lwg-general] * the CONSTITUTION of imc-lwg v1.04 *

[Richard Malter]

*************************************** 
*  the CONSTITUTION of imc-lwg  v1.04 * 
*************************************** 


* OBJECTIVE: 

To work on the developing Indymedia network in London, the UK and the Republic
of Ireland. Including: work on the imc-uk web site; work on facilitating
new city/region IMC's; work on facilitating technical network to support 
emerging independent media; or for example the setting up a different 
website based on the Open Publishing (OP) principle 
[rough consensus working OP definition for the Indymedia network here
http://www.physics.usyd.edu.au/~matthewa/catk/openpub.html 
and summary explanation here
http://nyc.indymedia.org/help/help.html] 


* SCOPE (range of activities): 

Involvement of the group will depend on the interests of its 
contributors (currently involved in tech, legal, volunteer groups), 
and who may be located anywhere in the world. 


* TERM DEFINITIONS: 

Functional element = any task that furthers the objective of imc-lwg 
and that does not contradict it's constitution. >>>needs examples<<<

Implementation work = the various steps taken after the design stage 
(discussion, advice, consultation) involved in the production or 
maintaining of a functional element. 

Holarchy = Arthur Koestler's word for the description in a systems/holistic 
approach of the form and, or pattern, of an organization of some kind. 


* FUNCTIONAL PRINCIPLES: 

The imc-lwg has functional principles, which effectively form its
constitution: 

1) Imc-lwg is open to anyone who agrees to work according to these principles. 

2) The use of only affirmative (positive) terms in describing both goals 
and ways of working. Defining always what imc-lwg and subgroups are for. 

An example is that the negating term 'non-hierarchical' - which 
belongs to the hierarchy/non-hierarchy paradigm, is not made use of, 
since it is a contradiction and stumbling block to build positive 
creative structures and practices based on a negating term. It also 
strengthens the concept by first establishing it in order to negate it. 

3) All group discussion and decision-making must be carried out 
publicly, via email, (recorded) on publicly accessible web archives. 
This is in order that everyone gets equal access to information from 
which decisions are made, and is able to participate in the actual 
decision-making, unlimited by geographical location or time 
constraint. 
* to be ammended to analyze communication to find what/when elements must be 
carried out in public. *

4) Decision Making: 

"We reject kings, presidents and voting. We believe in rough 
consensus and running code." David Clark, MIT 

Decision-making in the imc-lwg is made by rough consensus between the 
COORDINATORS of the subgroups groups. Decision making within the subgroups 
is made by rough consensus by the people in the group. 

Consensus is calibrated to the circumstances. An example to explain 
what is meant is: 

         If a group of 20 people are in danger of being shot dead by 
gunmen, a decision for the group on how to try to escape the gunfire 
will have to be made by a certain deadline and not necessarily can 
everyone be completely 'happy' with the decision - because otherwise 
they might all lose their lives. Consensus, in these circumstances: 
the rougher the better. 

         <a> A decision can be made even though not everyone in a 
group agrees to it. A decision can only be stopped by an objection 
that it would contradict any functional principle (the constitution 
of imc-lwg), or that it would endanger the existence of the imc-lwg. 

         <b> Those contributing to the implementation work in imc-lwg, 
or any given subgroup, can contribute to the related 
decision-making within that specific group and can block a decision. 
Anyone can contribute to the discussion about the decision. 
For this the two email lists are: 
imc-london-wg-work@lists.indymedia.org (implementation) 
imc-london-wg-general@lists.indymedia.org (discussion). 


5) Road to a Functional Element: 
         
         <a> a COORDINATOR is a delegate decided on within a group that 
wants to bring another functional element to life. The coordinator 
must have a publicly available email address, and must understand 
this constitution. It is their responsibility to coordinate the new 
(sub)group, and communicate outside of the group by writing 
regular summaries of progress or problems (e.g. similarly to the
imc-summaries list). Note: communication back to the group is not 
necessary as everything is publicly archived. It is recommended to rotate
this position of coordination to spread the load. 

         <b> The new subgroup has to propose the goals of
each functional element it wants to create in measurable terms, 
the period it will continue, and the period of notice if it stops. 
If the goals cannot be defined and measured, the functionality of an
element cannot be decided on and later assessed, and also whether or not
someone is contributing to the implementation work cannot be determined. 
         
         <c> Once the design stage of a new element has been completed 
by the proposing group, it is passed on to the larger (sub)group 
and decided on by rough consensus (see 5). 


6) Road to Exclusion: 

         <a> based on previous experiences of many failed attempts to 
bring new functional elements to life, and of being unable to 
document this, in order to have a record of progress, we are 
introducing a simple rule for someone's exclusion from work as a 
group coordinator, or from work on a particular functional element 
(ie within a subgroup). 

         <b> it is essential to commit oneself only to those tasks 
that one can actually carry out. 
         
         <c> failure to do so (committing, but not carrying out) more 
than twice in a row, excludes that person from further work (only) 
on that functional element he/she is currently working on. Note: only 
being consistently inconsistent excludes. 

         <d> in any case, letting the coordinator know as soon as 
he/she knows that he/she will not be able to carry out the work 
he/she committed to do is a requirement 

	 <e> when a subgroup stops doing implementation longer than
the agreed period (see 6b), they cease to exist as a group.

7) Utilizing the holarchy paradigm to describe the organization and 
function of imc-lwg and subgroups. 
(If you can find a more helpful/accurate description please let us know).
The parts of a holarchy are called 'holons'. A holon has 
at once the autonomy of a whole in its own right, 
and the interdependence as part of a system/ecology.

One meaning of this is that an ecology, or system, or network, can only exist 
when there is recipricol energy/communication exchange between parts.
See these sites for further explanation:
http://www.ratical.org/LifeWeb/Articles/LSinetHF.html 
http://www.ratical.org/LifeWeb/Erthdnce/chapter4.html 

8) This is an experiment and a model. We are trying out this version here; but 
we encourage the hacking, testing, borrowing parts of, changing etc, to improve 
on and find what is more helpful to another group in its own circumstances. If 
you dislike it, rewrite it :-)