Latest version of Charter
Sat, 5 Nov 1994 20:53:18 -0800 (PST)
This document will outline a set of rules to facilitate the parallel
development of interrelated projects.
We shall have two types of people in our organization; Coordinators for
each project, and the body of members. Projects are arranged
hierarchically. A special General Coordinator acts to oversee all the
Coordinators of the root projects. Their responsibilities are;
All projects are subjugated to this Coordinator
Has same responsibilities as Coordinator, except does not
have a project of his/her own
Any other responsibilites defined in the charter
Calls for and administers votes on issues related to
project, or sub-projects
Handles requests to create sub-projects
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 absense or removal, until a new one could be
Any other responsibilities as defined by the project
Request for votes on issues
Participate in projects
Request new projects
The basic organizational unit is the project.
Projects will be arranged hierarchically.
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.
All messages to tunes are directed to projects by including
the project name before the message description in the
Projects are defined by their charter
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. Only Coordinators
can post to 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.
To create a project a member would send to the Coordinator to which the
new project would be subjegated, an ASCII e-mail message with the body
of the message containing the following:
REQUEST FOR PROJECT
Date: Date of proposal.
Project: The complete "path" of the project.
Description: A short description of the project.
Coordinator: Name and e-mail address of the coordinator.
Goals: The goals of the project.
Agenda: Very important. It will motivate the project and
provide others with expectations so we can plan together.
This is not a hard deadline that if not met is punishable
by death. Instead it helps us work together as a team.
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, etc.
After receiving the RFP there are four actions the Coordinator could
Decide to deny the project and post the RFP along with a statement
of reasons for denial to "announce:RFP Denial-Description".
Accept the RFP and immediately create the project. Post the RFP
Put to vote the RFP and post the RFP to "announce:RFP for Vote-
Description". Voting begins immediately and ends
on the deadline decided by the Coordinator.
Request discussion about the RFP by posting it to "announce:RFP
Discussion-Description". All discussion would take place
in the "organization" topic. A deadline must be posted by
the Coordinator stating when he/she will decide how to
Once the project is approved by vote or a Coordinator, the RFP becomes
the charter of the new project.
Modification/Removal of Projects
A project is defined by it's charter as set forth by the RFP. Any
changes to a project that would not affect its charter can be made by
the Coordinator. To make a change to the charter;
A member would contact the Coordinator for that project with the
The Coordinator, if s/he felt the change appropriate, would send
a Request for Charter Deviation (RCD) to the Coodinator to
whom this project is subjegated. The format of the message
would be the complete text of the current charter, prepended
with REQUEST FOR CHARTER DEVIATION, and the changes
indented 5 spaces and marked with a >.
The Coordinator receiving the RCD would have the same options as
Each project will have several files to maintain at our central archive.
Each file name shall be prepended by the project path.
All files in the archive will be at most one month out of date.
Here are the minimum files that need to be maintained by the
.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.
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 listserver
.projects A list of all projects and their coordinators
Only a Coordinator can post to announce or vote. Announce will be used
to update members on the status of projects, proposals for projects, and
general voting results. Vote will be used to call for votes and post
results. All other projects can be posted to by all members.
Any member has a right to request a vote.
A member would send a Request For Vote (RFV) of the following format to
any Coordinator, although the Coordinator of the project the vote would
have precedence over would make the most sense.
REQUEST FOR VOTE
Measure: A short description of the measure.
Project: Path of the project being affected by this measure.
Advocate: Name and e-mail address of the person posting this
Text: What the measure advocates.
The Coordinator has the right to deny a RFV. If the member is unhappy
about this, the RFV can be sent to another Coordinator, until the
supply of Coordinators is exhausted.
The Coordinator will post a message including the RFV and a deadline for
votes to be recieved to the affected project group, and to "vote".
All votes will be mailed to the Coordinator calling the vote.
The Coordinator will tally all the votes and post the results, including
the names and position taken of all those who voted.
All votes must pass by at least 2/3.
Any changes to the project charter must be voted on. Everything else is
up to the Coordinators discretion, if no vote is called for by a member.
There's another message following this one...