REQUEST FOR VOTE (that means you!)

[Mike Prince]

Here is the lastest incarnation of our charter.  I believe it is very 
workable.  I want to thank Johan especially for his input (for all intensive 
purposes he wrote the first part). 

This document will be a starting place for our discussions and a resting 
place for our decisions.  I encourage everyone to cite a section in their 
discussions and suggest a revision to our document.  In this way we can 
move forward more easily.  The alternative is scattered discussions with 
great ideas remaining, scattered.  

VOTING
======
Please give me a YES or NO vote on whether we should adopt the new 
charter.

Thanks,

Mike



The Charter follows...


AOYU (As of yet un-named) Project Charter
=========================================

1. This project shall be called "Rogue" or "Joy"
	and its members shall be:
		Mike Prince (project 1-5 coordinator)
		Francois Rene Rideau 
		Kyle Hayes
		Johan van Schalkwyk

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 malleable (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
===========
	This project is coordinated by Mike Prince.
	
	The glossary is unavailable by ftp at this time.

8. Survey
==========
	This project is coordinated by Mike Prince.
	
	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
	8.3.4 Hermes

9. Distribution Language
========================
	This project is coordinated by Mike Prince
	
	Development of a minimal low level "symbolic assembly language" and 
	simultaneous creation of higher level stack based interpreted 
	language.

	9.1 Goals
		9.1.1 Absolute simplicity 
			minimal code. Core code of <= 20 lines!
		9.1.2 Designed for fast interpretation or efficient
			compilation
		9.1.3 compatability
			9.1.3.1 POSIX
			9.1.3.2 i386
	9.2 Specifications
		9.2.1 Word size?
		9.2.2 Data types, especially iro communication of 
			information between objects.
		9.2.3 Basic notation/evaluation
			Polish, Reverse Polish, Infix ...?
		9.2.4 CRCs on a low level from the start?
		9.2.5 Message format
		9.2.6 Semantics
		9.2.7 local memory management 
			9.2.7.1 persistence
			9.2.7.2 garbage collection
			9.2.7.3 security

10. High Level Language
=======================
	This project is coordinated by Francois-Rene Rideau. 

	10.1 Goals
	10.2 Specifications
		10.2.1 typing semantics
	     
11. Distribution
================
	This project is coordinated by Francois-Rene Rideau. 

	11.1 communication protocol
	11.2 scheduling
	11.3 security/recovery
	11.3 distributed memory management 
		11.3.1 persistence
		11.3.2 garbage collection
		11.3.3 security

12. Documentation
=================
	This project is coordinated by Francois-Rene Rideau. 

	12.1 documentation format & conventions
	12.2 documentation tools
	12.3 comparison with other system software

13. User Interface
==================
	This project is coordinated by Mike Prince.  
	
	13.1 basic abstractions
	13.2 integration to high-level/distribution language
	13.3 automatic adaptation to terminal capability
	13.4 layout manager