Fri, 4 Nov 1994 00:06:27 -0800 (PST)
This document will outline a set of rules to facilitate the parallel
development of interrelated projects.
We shall have three levels of people in our organizational hierarchy,
one Secretary, a Coordinator for each project, and the body of members.
Their responsibilities are;
Approves requests for new projects
Approves requests to change project goals
Calls for votes on issues
Approves and administers project related votes
Can request to change project goals
Can remove Secretary by a 2/3 vote of all Coordinators
Can call for general vote for new Secretary
The Coordinator with the most seniority would take over the
responsibilities of the Secretary in cases of absense
Participate in projects
Can request new projects
Requests for votes on issues
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
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: This will serve as the forum for debating new project
announce: A forum which can only be posted to by the Secretary
and 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 Secretary 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: Descriptive text, references, etc.
After receiving the RFP there are four actions the Secretary could take;
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". All votes would be mailed to the
"organization" topic. Voting begins immediately and ends
on the deadline decided by the Secretary.
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 Secretary stating when he/she will decide how to
Modification/Removal of Projects
A project is defined by it's RFP. To make a change to the RFP;
A member would contact the Coordinator for that group with the
The Coordinator, is S/he felt the change appropriate, would send
the Secretary a Request for Project Deviation (RPD). The
format of the message would be the complete text of the
original RPD, prepended with REQUEST FOR PROJECT DEVIATION,
and the changes indented 5 spaces and marked with a >.
The Secretary would have the same options as an RFP.
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
RFP 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 the Secretary or a Coordinator can post to announce. Announce will
be used to update members on the status of projects, proposals for
projects, and general voting 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
the Coordinator of the project the vote is relevant to.
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 will post a message including the RFV and a deadline for
votes to be recieved.
The Coordinator will tally all the votes and post the results, including
the names and position taken of all those who voted.
As far as projects are concerned I have left out everything. Tabla
Rasa. This weekend let's propose what subjects we want. Here's the
list to mill over in your head;
LLL, HLL, DIS, SEC, architecture, glossary, etc
It was brought up by Kyle that Coordinators should be elected by the
people over whom they preside. In my scheme I have the Secretary select
the Coordinator after an RFP. Since discretion is given to the
Secretary, he may decide to call a vote to select the Coordinator. I
feel that by leaving it up to the Secretary, with everyones feedback in
the beginning to set some precidents, then we can establish policy, and
that we do not need to cast it in stone for now.
Early in our development it should be rather obvious who should do what,
so I don't think anyones feeling should be hurt. Later on, once we've
had some time to mill these problems through, and come upon some new
ones, the path should be far more clear. There's also no law against
adding new laws.
I've renamed the project organization to charter.
Kyle suggested adding officers and goals to the charter project. We
will add those at his request and if there is no objection.
Kyle (again, you can see he's active) suggested adding the glossary and
survey projects. And again, I will let him suggest and discuss these,
and again if there is no dissension in the group they will be adopted.
Last of all for Kyle about projects, he recommended adding security,
distribution, and architecture projects after the survey project has
been born out. I'll let him argue these points as well.
Kyle expressed concern over the format of the RFP format. I am firm
about having a formal document presented in order to establish a new
project. It will encourage serious projects, and provide a guiding
document. It will also act as a quick reference for others curious
about the purpose of the project. I am versatile about the exact format
Kyle suggested having Coordinators send project updates to the Secretary
who would post to Announce.
There have been two opposing views of the term for the secretary, one of
three months, the other indefinite. For now, I'll advocate the
indefinite one. There is a clause for removing the Secretary, and
normally he will just step down and allow someone else to be elected.
With all of us having crazy schedules forcing re-election to line up on
some date relatively far down the unknown road is unreasonable. I
suspect secretaries will be overworked enough to generate a healthy
As far as archiving, I'll weekly do a backup onto my computer.
It's getting late for me now. My girlfriend just called with a borken
down car and its midnight. Gotta Go...
What do you think?