Charters & goals.
Johan Van Schalkwyk
jvs@iconz.co.nz
Wed, 30 Nov 1994 23:23:30 +1300 (NZDT)
Dear Tuneful Mooses
This doc has three parts, and is a response to:-
(a) Fare: request that I outline differences between my ideas
and Mike's charter;
(b) Mike: Request for comments on charter (Revision 5)
(c) Mike: Request for goals.
Part 1: Critique of Mike's charter. Numberings are for his Revision 5.
----------------------------------------------------------------------
(Note that his charter jumps from 1.7 to 8. This will presumably be
revised)!
1.2. Lots of detail about coordinators. Can we not simplify this by
having it implicit in the rest of the charter definition.
Also, why have two types of coordinator? Surely the main
project will have its co-ordinator (presumably Fare), and
each sub-project will of necessity have a coordinator. Why
all the song & dance?
1.3. "All decisions can be challenged by a vote".
Fair enough, but should we not limit decisions within a project
to members of that project (encapsulation)? Otherwise, things
become very cumbersome.
Then also, the Call For Vote can be reduced in length by
eliminating the "Project" section (it is implicit), the
"Discussion At" section (again, is within the project).
1.3.4. "All votes [..] sent to [..] advocate"
Is it not the job of the coordinator to count up & post results?
(He can delegate, but I think that he should have his finger on
the pulse of activity, and this is one way of ensuring it).
1.3.x. Should we not have a _minimum_ percentage poll? (Worst case
scenario "Well let's wait until everyone is out-to-lunch / ill /
on holiday and then just you & me slip it through)!
1.3.y. Should not any successful vote become a "rule" within the project?
This would ensure that all votes are automatically numbered, and
also accessible, and also _BROUGHT TO THE ATTENTION OF PARTICIPANTS_.
This would also remove the need to have a separate "list of
measures" (1.3.8)
1.4.2. "Projects will be arranged hierarchically".
Okay if we have main project MOOSE (eugh) and subprojects (one down
on same level) WOMBATS and FRUITBATS, and a decision taken
in WOMBATS conflicts with that in FRUITBATS, who wins?
1.4.4. "All messages to tunes are directed to 'PROJECTS' by including.."
Again, I think there is too much centralization. Should not
messages be confined to the subproject they are intended to
affect, rather than cluttering up the main system. Also, if
we cannot even stamp incoming projects with a serial number,
does this mean that some sucker will have to sit and sort all
the incoming messages to various folders, remail them, etc.?
Or will we sit up ftp'ing wildly all night to get the most
recent ideas.
It would seem to me a good idea for all project messages to
be directed at the (poor) co-ordinator, who remails etc.
1.4.5. "Projects are defined by their charter, measures, decisions"
Surely it is easier to just have each project as a list of
"rules", added by votes. Each project must also abide by the
rules of ancestor projects (parents). I cannot justify to
myself the trifurcation into charter/measures/etc!
1.4.5.3. Allow the coordinator to make rules. If someone does't like
a rule, let him challenge it. If enough people don't like the
coordinator, let them vote in a replacement.
1.4.6. There seems to be unnecessary fine structure here: 1.4.6.1 is
surely just the whole charter (so why make it recur), 1.4.6.2
is the mechanism embodied in the charter, (so why have it
as a cumbersome subproject), and discussion is either informal
(by all means give it a label/have a discussion group, or
just post something to tunes without a fancy heading), or
formal in which case it is a vote directed at a project or
subproject. Likewise, announce is taken care of by the
administrator, or is an "announcement section" within a
project, or (ideally) is just the posting of a new rule
within that project!
1.5. Creating projects.
Okay, but again perhaps can be simplified. Can we not establish
the need for a project (rule) in the call for vote, and then
leave the administrative details to the coordinator (who
can make the appropriate rules) rather than having a great
big cumbersome list (1.5.2 etc) of what is being/should be
done)?
1.5.3. My simplification above (1.2, 1.4.4 etc) should remove the
need for 1.5.3.
1.6.1 -> 1.6.4. I like these.
1.6.5. "minimum files"
This would be simplified by setting things up according to
my comments on 1.4.5. above.
1.6.6. "additional files"
Initial RULE establishing project could contain these data.
(ie keep things straight and simple rather than introducing
unnecessary bifurcations)
1.7. "Posting messages"
Several of my ideas above (decentralization) would trim this
by confining vote messages to local projects. If you want, you
could make it a requirement that each co-ordinator post a
monthly message saying how things are progressing (or not)
with pointers to the relevant site(s) for further information.
(Is this not really what we are aiming for - APPROPRIATE
decentralisation).
*** SURELY, AS SOON AS WE HAVE "MOOSETUNES" (eugh) up and
running, our first task is to integrate every member into
a "seamless" persistent network that embodies our charter !!!
I THINK THAT THE WHOLE PROJECT WILL SUCCEED OR FAIL ON WHETHER
WE CAN RIGHT FROM THE START PRACTISE WHAT WE PREACH. IF WE CANNOT
EVEN STRUCTURE OUR OWN ORGANISATION WITHIN A "MOOSETUNES" (eugh)
FRAMEWORK, THEN WHAT PRICE THE WHOLE CONCEPT?
Part 2. My brief charter. (at the risk of being considered repetitive)
----------------------------------------------------------------------
Please feel free to snip, cut, hack, slash and burn. Even, flame! Just
_say something_ dammit.
I think that what we want is a minimal set of rules. The bureaucratically-
minded can always add to them. Does anyone feel that the following is
"too minimal"?
PROPOSAL: RULES FOR A REVISED CHARTER (SHORT!)
Rule 1. This project shall be called "yeS" (or "MOOSETUNES")
and its founder members shall be:
Francois Rene Rideau (project coordinator)
Mike Prince
Kyle Hayes
Johan van Schalkwyk
[fill your name in here]
Rule 2. A RULE may be created by either
the PROJECT COORDINATOR, or
a successful VOTE (as outlined in Rule 8) by MEMBERS of THAT
PROJECT.
Rule 3. A PROJECT is a rule containing:
1. the name of a PROJECT COORDINATOR
2. A list of MEMBERS
3. A list of sub-rules (eg. if project is 13 then ITS first rule
is 13.1, its second, 13.2 and so on)
Rule 4. Conflicting rules: Rules with lower numbers take precedence
over rules with higher numbers (and rules over sub-rules).
Rule 5. Rule alteration/removal: Only by a successful vote.
Rule 6. The project coordinator is responsible for adequate documentation of
that project, including its list of rules.
Rule 7. Each sub-project will terminate when either:
A call for vote within that project successfully requests
termination, or
A call for vote in the project ABOVE it forces termination.
Rule 8. REPLACEMENT of co-ordinator: Only by a successful vote within
that project.
Rule 9. In referring to a rule, accepted names may replace numbers
(e.g. 13.3 might become MOOSE.WOMBATS).
Rule 10. Voting procedure:
1. Message is posted to "VOTE" within that project, containing:
- the new rule;
- proposer;
- expiry date by which votes must be in;
- project coordinator (to whom you post your votes);
- explanatory text (if needed).
2. Minimum period of one week must elapse, during which members
post YES, NO, or SPOILED votes to the project coordinator;
3. Within 48 hrs of expiry date, coordinator posts new rule, if
proposal succeeded (60% YES, minimum 60% percentage poll).
Otherwise he posts note how vote failed.
Part 3. Goals (With reference to my recent postings to MOOSETUNES)
------------------------------------------------------------------
How about?
1. Maintain identity of each interacting "organism" (ie. don't
splurge things out all over so you don't know whether you're Arthur,
Martha, or HAL)
2. Do NOT do elsewhere what you can do locally!
3. Keep it straight and simple (KISS). Apply Occam's razor ruthlessly.
4. Finding "a strategic niche". Can we not relate this to our
problems with organizing the whole structure, and my little diatribe
in 1.7 above? I.E. turn our major weakness (lack of ability to organise /
find our own arse with both hands) into a strength. Is there a general
purpose system, disseminated in time and space, that can in a user-friendly
and perfectly general, object-oriented way, allow organisation of diverse
talents, with permanence etc? No. Not yet. But this is surely what we
want to create! So let's create it, and then USE it, refine it, and sell
it! If we can't do this, we will surely fail, and if we can, we may just
have our "niche". Perhaps we could design into it as an extremely simple
"point and shoot" hypertext system (that even I could use).
5. "must be malleable / no set UI".
Yes & NO!!
It is great to have a flexible system, but, let's face it, most people
are creatures of habit. Present John Citizen with more than several
options, and he will more likely than not crack wide open! Have a set
UI that is so damn good that no one in his right mind would want to change it
and then make it so easy to change that even Windows users can adapt it
to suit their perverted needs!
6. A low-level goal. Ruthlessly eradicate redundant instructions.
Again, KISS.
7. Establish the identity of the individual user. Treat him as an individual,
and respect that he is using the system as his own personal TOOL. People
enjoy feedback, especially warm positive feedback. Even build a simple
personality (as simple as Parry without the paranoid ideation!) into the
OS, and win the heart and mind of the user. Turn the OS into a combination
of an expert assistant and a waiter in a high-class restaurant!! And, above
all, respect the intelligence of the user!! If the system makes a fuck up,
let it apologise! Treat the user as a human being, not as a simple minded
dickhead who really should know that depressing SHIFT+Q with your left hand
and CTRL+ALT+Z with your right while pressing the N key firmly with your
nose is the only recognized way of indenting the paragraph!
Bye for now
JVS.