Charter

Mike Prince mprince@crl.com
Fri, 4 Nov 1994 00:06:27 -0800 (PST)


Tunes Charter
=============
This document will outline a set of rules to facilitate the parallel 
development of interrelated projects.

Membership Structure
====================
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;

	Secretary
		Appoints Coordinators
		Approves requests for new projects
		Approves requests to change project goals
		Calls for votes on issues
	Coordinator
		Oversees project
		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
			or removal.
	Members
		Participate in projects
		Cast votes
		Can request new projects
		Requests for votes on issues

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
		subject field.

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
		proposals.
	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.

Creating 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 
		"announce:RFP Accepted-Description"
	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 
		proceed.

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
		desired changes.
	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.

Project Documents
=================
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 
Coordinator;

	.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

Posting Messages
============================
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.

Voting
======
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
		measure.
	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.

Notes
=====
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 
though.

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 
turn-over.

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?

Mike