[Imc-lwg-general] template version of constitution

[Richard Malter]

 ***************
| What is this? |
 ***************

It's the * template version * of a charter for volunteer organization and 
function used by the imc london working group (wg). It is a template made up of 
modules. It should be self-explanatory.

We are trying out this version in London. We wish to encourage the hacking, 
testing, adopting, developing further, changing, etc, to improve on and find 
what is more helpful to another group in its circumstances. 

If you dislike it, rewrite it :-)




          ********************
          * CHARTER TEMPLATE *
          ********************

SUMMARY
-------

What will your group do? [put your objective(s) here] 

Why? [insert here] 
 
When?  [date you begin] 

The name of the group?  [your group name] 


MAIN 
----

* OBJECTIVE: 

[copy your group objective here]


* SCOPE (range of activities): 

Involvement of the group will depend on the interests of its 
contributors, and who may be located anywhere in the world. 


* TERM DEFINITIONS: 

Functional element = any task that furthers the objective of [your group name]
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: 

[your group name] has functional principles, which effectively form its
charter: 

1) [your group name] 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 [your group name] 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. 

4) Decision Making: 

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

Decision-making in the [your group name] 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 charter
of [your group name]), or that it would endanger the existence of the [your 
group name]. 

         <b> Those contributing to the implementation work in [your group 
name], 
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 listserves are: 
[your group name]-work@ [insert URL] (for implementation work) 
[your group name]-general@ [insert URL] (for 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 charter. It is their responsibility to coordinate the new 
(sub)group, and communicate outside of the group by writing 
regular summaries of progress or problems.
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 [your group name] 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, adopting, developing further, changing, etc, 
to improve on and find what is more helpful to another group in its 
circumstances. 

If you dislike it, rewrite it :-)