Yet Another Charter

[Mike Prince]

I have taken to heart what Johan has composed, and it seems good.  I only 
hope he does not take offense to my minor changes.

I have tacked on the last sections of my previous charter, and have added 
goals from Kyle and Johan.

I would like to adopt the following charter;



PROPOSAL: RULES FOR A REVISED CHARTER (SHORT!)

1. This project shall be called "Q" or "Joy"
	and its founder members shall be:
		Francois Rene Rideau (project coordinator)
		Mike Prince
		Kyle Hayes
		Johan van Schalkwyk
		[fill your name in here]

2. This project shall be governed by a set of rules, organized hierarchically. 
	2.1 Conflicting rules: rules with lower numbers take precedence 
		over rules with higher numbers (and rules over 
		sub-rules).
	2.2 A rule may be added/removed/modified by; 
		2.2.1 a successful VOTE (as outlined in Rule 5) 
		2.2.2 the PROJECT COORDINATOR
	2.3 In referring to a rule, accepted names may replace numbers
		(e.g. 13.3  might become MOOSE.WOMBATS).

3. A PROJECT is a rule containing:
	3.1 the name of a PROJECT COORDINATOR
	3.2 A list of MEMBERS
	3.3 A list of sub-rules 

4. The project coordinator is responsible for adequate documentation of
	that project, including its list of rules.

5. Voting procedure
	5.1 Message is posted to "VOTE" with that project, containing:
		5.1.1 rule to be revised/deleted/added;
		5.1.2 proposer;
		5.1.3 expiry date by which votes must be in;
		5.1.4 project coordinator (to whom you post your votes);
		5.1.5 new rule text (if needed).
	5.2 Minimum period of one week must elapse, during which members
		post YES, NO, or SPOILED votes to the project coordinator;
		5.2.1 At least one-fourth of the members in projects
			affected by the rule must cast votes for the vote
			to be valid.
	5.3 Within 48 hrs of expiry date, coordinator posts results of vote.
		5.3.1 Rules pass by 2/3 or more of cast votes. 

6. Goals
========
	The following is a list of goals for our project;

	6.1 must be a friendly intuitive UI
	6.2 must have a lot of productivity apps (mail, wp, spreadsheet, 
		ie necessary apps)
	6.3 must fill a strategic niche (i.e. choose our customers well)
	6.4 must be maleable (no set ui, easy to personalize)
		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.5 use all the available resources (over net too)
	6.6 all the above must remain constant over all platforms (who 
		cares what hardware they are using).  My app here runs on all 
		my platforms.  No multiple shrinkwrap copies.
	6.7 must have a good development environment
	6.8 must be able to use all available resources (look above too)
	6.9 persistency  
		Considered to be part of the user friendliness 
		thing.  Not only is the ui the same, but the apps and all 
		objects in the system are exactly the way you left them.
	6.10 separate mechanism from policy
	6.11 support standards where feasible
	6.12 simple, portable strategies
	6.13 include marketable things, not gee whiz features
	6.14 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)
	6.15 Do NOT do elsewhere what you can do locally
	6.16 Keep it straight and simple (KISS). 
		Apply Occam's razor ruthlessly.
	6.17 Organization of diverse talents
		Turn our major weakness (lack of ability to organise) 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).
	6.18 A low-level goal. Ruthlessly eradicate redundant instructions. 
	6.19 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!
	6.20 Be able to use a distributed network of processors.
		6.20.1 coherency - is what I see what you see, 
			at the same time?
		6.20.2 reliability - how certain am I that I am not 
			getting garbage?
		6.20.3 time - is my time your time?
		6.20.4 causality
		6.20.5 efficiency
	6.21 Unify error detection _and_ correction and allow graceful failure.
	6.22 Approach problems holistically

7. Glossary
===========
	The glossary is available by ftp at .........

8. Survey
==========
	The following have been evaluated as to their ability to satisfy 
	our goals as set forth in Section 6.

8.1 Microkernels
-----------------
	8.1.1 Amoeba
	8.1.2 Mach
	8.1.3 SpringOS

8.2 Operating Systems/Environments
-----------------------------------
	8.2.1 UNIX
	8.2.2 NextStep
	8.2.3 Taligent
	8.2.4 ANDF (OSF)

8.3 Languages
--------------
	8.3.1 Forth
	8.3.2 C++
	8.3.3 Scheme