Charters & goals.

Johan Van Schalkwyk
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

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! 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: is
	surely just the whole charter (so why make it recur),
	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

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
	running, our first task is to integrate every member into
	a "seamless" persistent network that embodies our charter !!!


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"?


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 
	a successful VOTE (as outlined in Rule 8) by MEMBERS of THAT

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