Charter

[Mike Prince]

On Sat, 5 Nov 1994, Francois-Rene Rideau wrote:
> A project coordinator may approve sub-projects...
> Why not have a hierarchy of coordinators, and a head-coordinator (that you
> may call secretrary if you want).
> instead of secretary. It simplifies everything.

Done (in hopefully the right way :)

> > 		Approves requests to change project goals
> The one who approved the project is responsible for that.

I want to keep people from totally rearranging their own projects without 
regard for how it fits into the big picture.  I've kept it that projects 
goals can only be changed by vote.

> Vote of 2/3 of concerned people may remove anyone

I've tried making a 2/3 necessary for everything, is that too much?

> > 	Goals:  The goals of the project.
> Should also contain the constraints to the means to obtain such goal.

What do you mean by constraints to the means?

> > 	Comments:  Descriptive text, references, etc.
> Why such administratrivia ?

What I meant by that was to provide a place to put the body of a greater 
description of the project.  Not to require it though (it's now optional)

> We'd better require him to write and maintain a report on subject,
> which should include those as the minimum.
> The request would be the head of the report, and would not include
> Agenda/Reason/Comments.

The agenda/reason/comments should be well thought out before asking for a 
new project.  Otherwise we'll be going off half-cocked in too many 
directions.

> > 	 .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.
> 
> Let's separate the Agenda from the Charter.

The agenda is important as it motivates the project.  Changing it 
is kind of a big deal.  So to emphasize its importance I'd like to leave 
it in the charter.

> And let's add a status/summary
> of discussions, where all ideas or coined and ordered by the coordinator, with
> choices explained. Merge those in a "status" file if you want.

Let's have this defined in the RFP, instead of mandating it for every 
project.  We can always make this mandatory later.  What I'm trying to 
stay away from right now is tons of red tape to get anything done.

> 
> > 	.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.
> Talk is not enough.
> The coordinator should summarize choices and decisions, and
> write docs for the project as it is decided.

Again, if its important we can make include it in the RFP.

I'd like to mail this out Monday.  It's good to create a good 
organizational scheme the first time around.  But it's pretty close now, and 
we can always change it later.  I'd like to get on with some work.

Talk to you soon,

Mike