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

[Richard Malter]

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


* 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 ] 


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

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 elegant word for the embeddedness of 
natural entities, which he called holons. Holarchy is nestedness, 
distinguishing it from pyramidal hierarchy, which implies superiority 
at the top and is the metaphor for command-and-control systems (1). 
A holon has at once the autonomy - in Greek, self-rule - of a whole 
in its own right and the dependence of a part embedded within larger 
holons (2). This means that a network can only exist when there is two way 
energy/communication exchange to and from each holon (group). 
1.http://www.ratical.org/LifeWeb/Articles/LSinetHF.html 
2.http://www.ratical.org/LifeWeb/Erthdnce/chapter4.html 


* FUNCTIONAL PRINCIPLES: 

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

0) The structure is one of nested groups. 

1) Imc-lwg or any of its nested groups are open to anyone who agrees 
to work according to these principles. 

2) The use of affirmative (positive) terms in describing both goals 
and ways of working. Defining what imc-lwg and nested groups are for, 
in place of describing what it might be against. 

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) Utilizing the holarchy paradigm to describe the organization and 
function of imc-lwg and nested groups. 

An example is nested groups in place of subgroups. 

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

5) 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 nested groups. Decision making within the nested 
groups 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 nested group, 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). 


6) 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 
(nested) 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's recommended to rotate
this position of coordination to spread the load. 

         <b> The new nested group 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 (nested) group 
and decided on by rough consensus (see 5). 


7) 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 nested group). 

         <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 nested group stops doing implementation longer than
the agreed period (see 6b), they cease to exist as a group.