discussion: Goals et al, V

Mike Prince mprince@crl.com
Mon, 28 Nov 1994 11:10:04 -0800 (PST)

1. Charter

1.1 Purpose of Charter 
	Outline of rules to facilitate parallel development of 
	interrelated projects.

1.2 Membership Structure
	Types of member are:

	1.2.1 General Coordinator oversees all Coordinators All projects are subjugated to this Coordinator Has final word in settling disputes Has same responsibilities as Coordinator, except does not
			have a project of his/her own Any other responsibilities defined in the charter
	1.2.2 Coordinators for each project or sub-project Oversees project Posts project updates of general interest to announce The Coordinator with the most seniority would take over
			the responsibilities of the General Coordinator in
			cases of absence or removal, until a new one could
			be elected Any other responsibilities as defined by the project
	1.2.3 The body of members. Calls for votes on issues Cast votes Participate in projects

1.3 Voting
	1.3.1 All decisions can be challenged by a vote.
	1.3.2 Any member has a right to call for a vote.
	1.3.3 To call for a vote, a member posts the following message to the 
		topic "vote": 
	Measure:  A short description of the measure.
	Project:  Path of the project being affected by this measure.
	Discussion At:  Path of project discussion will take place in.
	Voting Ends:  Last day to cast a vote.
	Advocate:  Name and e-mail address of the person posting this
	Text:  What the measure advocates.

	1.3.4 All votes should be sent to the person named as advocate.
	1.3.5 When voting ends the person named as advocate sends a list sorted
		into yes and no votes, plus counts to the Coordinator of the 
		project named in the vote.
	1.3.6 If the vote passes by at least 2/3 the Coordinator posts the
		measure plus the voting results to "announce" and to the
		affected project
	1.3.7 If the vote fails the Coordinator simply posts the voting results
		to "announce".
	1.3.8 Once the measure is approved by vote, the measure is added to the
		affected projects list of measures.

1.4 Projects
	1.4.1 The basic organizational unit is the project
	1.4.2 Projects will be arranged hierarchically
	1.4.3 Projects are named The root project will be the leftmost in the name. Subprojects will be listed from left to right, delimited
			by periods, in order of precedence
	1.4.4 All messages to tunes are directed to projects by including
		the project name before the message description in the
		subject field
	1.4.5 Projects are defined by their charter, measures, and decisions The charter is defined initially by the text of the vote
			that created it. Measures are put forth by members and decided by votes Decisions are made by the project coordinator
	1.4.6 We will start with the following projects; charter
			The organization structure of our group 
			(as defined by this document).  This forum will be 
			used to discuss changes to our charter and our 
			groups organization. vote  
			All votes and their results will be announced 
			here, as well as in the projects in which they 
			affect.  The discussion will take place in the 
			project affected by the vote. discussion
			This will serve as the forum for debating new 
			project proposals and votes of general interest. announce  
			A forum which can only be posted to by 
			the Coordinators.  This is used to announce new 
			projects and their status, and for Coordinators to 
			update the group about on-going projects.

1.5 Creating Projects
	1.5.1 To create a project a member would call for a vote with the 
		following fields appended to the CALL FOR VOTE message.

	New Project Name:  The complete "path" of the project.
	Description:  A short description of the project.
	Goals and Constraints:  The goals of the project and limits to  
		achieving them.
	Reason:  Why do we need a new project/subproject.  This should
		be at most two paragraphs, which may contain references to
		the Comments section.
	Comments(optional): Descriptive text, references, anything
		deemed necessary but not included above.
	1.5.2 The RFP should outline how the project will work, and might 
		include; Any additional files that would be maintained Additional rules or mechanisms within the project An Agenda Etc [?]
	1.5.3 Voting is conducted normally except when a root project is being
		created, in which case the Head Coordinator receives the 
		results of the vote.
	1.5.4 The advocate of the vote becomes the Coordinator for the new 

1.6 Project Documents
	1.6.1 Each project will have several files to maintain at our central 
	1.6.2 Each file name shall be prepended by the project path.
	1.6.3 All files in the archive will be at most one month out of date.
	1.6.4 Every file will have as the first line the date it was last
		updated and the person who did the updates name or email
	1.6.5 Here are the minimum files that need to be maintained by the 
		Coordinator; .charter 
			This is a copy of the most recent incarnation of the 
			charter which defines the project.  If the project 
			was created through a vote all ballots cast are 
			listed. .talk.MonthYear  
			This is an archive of all that's been posted to that 
			project, stored in mailbox format, and broken down by 
			month into separate files.  This should be updated
			within 10 days after the end of each month. .vote.measurename  
			This is the text of a measure that has been put to 
			vote for that project and a list of those who have 
			cast ballots for or against that measure. .decision.decisionname
			This is the text of a decision made by the project 
	1.6.6 The charter project will have several additional files; .members 
			A list of members and their e-mail addresses. This 
			will initially be derived from the tunes mailserver .projects  
			A list of all projects and their coordinators

1.7 Posting Messages
	1.7.1 Only a Coordinator can post to announce.
	1.7.2 Announce will be used to update members on the status of projects, proposals for projects
		and general voting results.
	1.7.3 Only calls for votes can be posted to vote.  
	1.7.4 All discussion for votes will take place in the project named
		in the "Discussion At" field of the Call for Vote.  
	1.7.5 Any member can post a call to vote.  
	1.7.6 All other projects can be posted to by all members.

8. Goals
	The following is a list of goals for our project

	8.1 must be a friendly intuitive UI
	8.2 must have a lot of productivity apps (mail, wp, spreadsheet, 
		ie necessary apps)
	8.3 must fill a strategic niche (i.e. choose our customers well)
	8.4 must be maleable (no set ui, easy to personalize)
	8.5 use all the available resources (over net too)
	8.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.
	8.7 must have a good development environment
	8.8 must be able to use all available resources (look above too)
	8.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.
	8.10 separate mechanism from policy
	8.11 support standards where feasible
	8.12 simple, portable strategies
	8.13 include marketable things, not gee whiz features

9. Glossary
	The glossary is available by ftp at .........

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

10.1 Microkernels
	10.1.1 Amoeba
	10.1.2 Mach
	10.1.3 SpringOS

10.2 Operating Systems/Environments
	10.2.1 UNIX
	10.2.2 NextStep
	10.2.3 Taligent

10.3 Languages
	10.3.1 Forth
	10.3.2 C++