discussion: Goals et al, V
Mon, 28 Nov 1994 11:10:04 -0800 (PST)
1.1 Purpose of Charter
Outline of rules to facilitate parallel development of
1.2 Membership Structure
Types of member are:
1.2.1 General Coordinator oversees all Coordinators
18.104.22.168 All projects are subjugated to this Coordinator
22.214.171.124 Has final word in settling disputes
126.96.36.199 Has same responsibilities as Coordinator, except does not
have a project of his/her own
188.8.131.52 Any other responsibilities defined in the charter
1.2.2 Coordinators for each project or sub-project
184.108.40.206 Oversees project
220.127.116.11 Posts project updates of general interest to announce
18.104.22.168 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
22.214.171.124 Any other responsibilities as defined by the project
1.2.3 The body of members.
126.96.36.199 Calls for votes on issues
188.8.131.52 Cast votes
184.108.40.206 Participate in projects
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
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
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
1.3.7 If the vote fails the Coordinator simply posts the voting results
1.3.8 Once the measure is approved by vote, the measure is added to the
affected projects list of measures.
1.4.1 The basic organizational unit is the project
1.4.2 Projects will be arranged hierarchically
1.4.3 Projects are named
220.127.116.11 The root project will be the leftmost in the name.
18.104.22.168 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
1.4.5 Projects are defined by their charter, measures, and decisions
22.214.171.124 The charter is defined initially by the text of the vote
that created it.
126.96.36.199 Measures are put forth by members and decided by votes
188.8.131.52 Decisions are made by the project coordinator
1.4.6 We will start with the following projects;
The organization structure of our group
(as defined by this document). This forum will be
used to discuss changes to our charter and our
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.
This will serve as the forum for debating new
project proposals and votes of general interest.
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
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
184.108.40.206 Any additional files that would be maintained
220.127.116.11 Additional rules or mechanisms within the project
18.104.22.168 An Agenda
22.214.171.124 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
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
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.
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.
This is the text of a decision made by the project
1.6.6 The charter project will have several additional files;
A list of members and their e-mail addresses. This
will initially be derived from the tunes mailserver
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.
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)
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
The glossary is available by ftp at .........
The following have been evaluated as to their ability to satisfy
our goals as set forth in Section 8.
10.2 Operating Systems/Environments