Charter

[Mike Prince]

Before I start addressing your concerns, I totally changed the whole thing 
again.  Sorry.  I had a change of heart last night.  Instead of trying to 
make this charter perfect the first time around and have it address every 
thing that could go wrong or that's needed, I just gutted it, and left in 
place the mechanism for change.  In the next week we'll all work together 
trying out the voting methods and changing the charter as everyone sees 
fit.  I realized last night that we're spending way too much effort on 
this thing that can evolve with us.  Let's mail it out tomorrow and get 
on with things.

Thanks for working with me on this.  I really want to get back to work on 
the project though.

On Sun, 6 Nov 1994, Francois-Rene Rideau wrote:

> You wrote that the General Coordinator had no  project, which is false:
> his project is TUNES/PIOS/MOOSE itself.
I was sort-of going to view it this way;  We have one project called 
charter, that defines our entire organization and how we work.  The 
General Coordinator could be in charge of that, or someone else.  This is 
unifying the way all Coordinators work, even the General Coordinator.

> > 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.
> That seems ok, but limits the action of coordinators too much to me.
> Let's say there's a training period for such changes, during which any
> voice against the change would require the vote to be.

I changed it yet again, Coordinators can make decisions, but everything 
can be overturned by a vote.  Actually this is kind of undefined right 
now, this coming week we can all vote on a solution.

> >>> 	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?
> Well, e.g.
> Build a dos compatible file-system *in such language*, *with such interface*,
> etc.
> Or write a low-level language *with a stack-based semantics*.

Should the section be called Goals & Methods?  Goals & Means?  Goals & 
Constraints?  (Constraints sounds kind-of, uh, constraining or negative).
I renamed Goals to Goals & Methods.  Let me know if thats ok.

> > 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.
> Well, the Agenda will have to change according to new ideas appearing.
> e.g. those who study the LLL may have to choose later if it will be
> a RISC-like thing or a Forth-like thing, according to new studies, etc.
> So it's Ok for Reasons and Comments, but the Agenda should be outside the
> RFP (although it shoud be surveyed by the over-coordinator).
ok.  I've taken agenda out.

> >> 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.
> You can't have the current status of the project in the RFP !!!
> It includes latest results, and won't have to be changed by only votes.

What I meant by defined in the RFP, is that the RFP states the project as 
having one.  I.e. "the Coordinator shall maintain a status file which is 
at most one week out of date.."  Same for summary.  Again, if this is a 
problem we'll vote for a change next week.

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

> Of course *NOT*: if already was known in advance, there would be no *project*,
> only an existing, finished *object* !!!
> What would be the coordinator's role if not maintaining a summary of the
> talks and works ?

Again the RFP would designate that these are needed, the RFP obviously 
would not be the repository for this information.

For instance the glossary might just specify mechanisms for people adding 
to it, and the work-in-progress.  It might have a record of all 
discussion but no works per se.

The bottom line, the RFP says what your going to do and a little about 
how you're going to do it.  It is not limited in what it can specify.

Also,  as you can see from my most recent rendition of the charter, I'm 
going to complete simplicity.  All we really need are the mechanisms for 
controlled change and growth, and a way of organizing our topics.  
Everything else can be added as needed.

Let's get this thing done soon!  I'd like to mail it out tomorrow.

Mike