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
1.2.1.1 All projects are subjugated to this Coordinator
1.2.1.2 Has final word in settling disputes
1.2.1.3 Has same responsibilities as Coordinator, except does not
have a project of his/her own
1.2.1.4 Any other responsibilities defined in the charter
1.2.2 Coordinators for each project or sub-project
1.2.2.1 Oversees project
1.2.2.2 Posts project updates of general interest to announce
1.2.2.3 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
1.2.2.4 Any other responsibilities as defined by the project
1.2.3 The body of members.
1.2.3.1 Calls for votes on issues
1.2.3.2 Cast votes
1.2.3.3 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":
CALL FOR 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
measure.
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
1.4.3.1 The root project will be the leftmost in the name.
1.4.3.2 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
1.4.5.1 The charter is defined initially by the text of the vote
that created it.
1.4.5.2 Measures are put forth by members and decided by votes
1.4.5.3 Decisions are made by the project coordinator
1.4.6 We will start with the following projects;
1.4.6.1 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.
1.4.6.2 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.
1.4.6.3 discussion
This will serve as the forum for debating new
project proposals and votes of general interest.
1.4.6.4 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.
REQUEST FOR PROJECT
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;
1.5.2.1 Any additional files that would be maintained
1.5.2.2 Additional rules or mechanisms within the project
1.5.2.3 An Agenda
1.5.2.4 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
project.
1.6 Project Documents
---------------------
1.6.1 Each project will have several files to maintain at our central
archive.
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
address.
1.6.5 Here are the minimum files that need to be maintained by the
Coordinator;
1.6.5.1 .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.
1.6.5.2 .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.
1.6.5.3 .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.
1.6.5.4 .decision.decisionname
This is the text of a decision made by the project
Coordinator.
1.6.6 The charter project will have several additional files;
1.6.6.1 .members
A list of members and their e-mail addresses. This
will initially be derived from the tunes mailserver
1.6.6.2 .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++