Proposed Organization

[Mike Prince]

Proposal for Tunes Organization
===============================
I have compiled comments about our organization and have presented an 
edited version of them below.  Following those is my suggestion for the 
organization of Tunes.

Luke
====
This project, this group, this initiative...

The last first. This initiative is THE step into our future. I believe 
that Mike is on to some things here that (coincidentally I have been 
mulling over in the back of my mind also) and are the future of computer 
engineering.

This group.
For this to work we need some structure both centralized and
decentralized. The centralized structures:
	1. Centralized communications. We need one re-mailer. Second we 
need a topics moderator. Someone who will pick the current topic to 
discuss and only forward mail along those topics. We are currently as a 
group suffering from brain diarrhea. That is we have too many good ideas 
oozing out of our brains. Lets agree to each keep a record book that we 
can jot down our ideas in, so that we can present those ideas in a 
concise and appropriate manner. Also we need to take time to mull over 
peoples ideas so that we can "work through them".
	2. We also need someone who will volunteer to be the central 
workbook keeper. In other words they are willing to keep a central 
design document that we submit our work to.

The decentralize structures:
	1. Eventually we need to form groups that are working on common 
pieces.  These groups must have team leaders, et cetera.
	2. We also need to have some formal processes to support our 
independent work.

Johan
=====
Organization. If we don't get this right, we might as well pack up and 
go home. I've seen a _great_ number of really good ideas in the past few 
days, and I imagine things will settle down but at present I have 
difficulty in keeping up with all the suggestions and counter-
suggestions.  Many of them seem to be saying the same / similar things 
in different words! The idea of having different subject groups with 
different editors seems good to me. I would like to take it a bit 
further:-

Is it not possible for someone originating a new idea/section to send, 
as the first part of the title, the following:
  (?)
Let the TUNES@ENS.FR mailer identify this as being a request for a new 
theme, stamp it with the next number in sequence, AND THEN PASS IT ON TO 
EVERYONE. (1) would be the first ever theme, (2) the second, and so 
on..Extending this idea, one could reply to e.g. thread number (3) with 
the message: 3()  in the header, and our reply would be stamped with the 
number 3(7) - if it were the seventh reply - before being re-mailed to 
everyone.  This approach would:-
	a. Clearly delineate who preceded whom:
		-- 3(6) precedes 3(7)..
	b. Enable immediate identification of various threads:
		-- eg thread 1 might be low level language ideas ..
	c. Tell you if you're missing items in the sequence:
		-- this is 7(23). Whatever happened to 7(21) and 7(22)?
	d. Be useful in assessing who is active, which threads are being 	
		used:
		-- currently active threads are 1, 3, 17, 4 etc.
	e. Be useful in requesting back copies / archives:
		-- please send me 1(7), 23(184) etc.
The idea could even be extended to sub-threads for a lovely branching 
tree structure: for example, IF thread (1) is "low level language" and 
you want to create & control the compiler section, you might send a 
message with the title:-
	(1?) LLL : Compiler Section - Moderator Joe Bloggs
and the TUNES@ENS.FR mailer responds by stamping your message with:
	(1.1) Compiler Section - Moderator Joe Bloggs
 -- or, if (1.1) already exists, then (1.2) and so on.

Kyle
====
I think he has some very good points here and I would like to argue for 
this kind of organization.

Due to the limited/scattered time most people have, it is not reasonable 
to be able to organize as a project group would in a company.  People 
are not going to be able to deal with things like deadlines effectively.  
This is not necessarily a problem.  Rather than trying to micromanage 
everything, I think that Luke's proposal be used as a basis for project 
work.

There needs to be enough centralization that people are kept aware of 
what others are doing and have some sense of progress.  At the same 
time, the constraints imposed by the 'net (time zones), work, school, 
play, etc. require that people be able to work on projects fairly 
independently.

The centralized part should be able to set goals and project tasks while 
individuals will carry out these tasks pretty much on their own. I don't 
really see much of a way to handle closely coupled collaborative work 
with the wide range of places and external work that people have to do.

I like the idea, but I think that this might place a bit of a strain on 
Francois-Rene to set this up.  It looked like he was using one of the 
"standard" list servers.  Anyone familiar enough with these to say if 
adding such functionality is feasible.

Actually, Johan describes the numbering/annotation system that is used 
by SCCS for source code control.  I have used this in a couple of 
projects (for source code) and it works well, but you need to have a 
sort of glossary that translates the number schemes back into something 
vaguely human understandable.  I.e. "what does 1.2.16(32) mean?"  "Hmm, 
1 is the low level topics, 2 is the VM, 16 is the register allocation 
recompiler stuff, OK..."

My guess is that if it could automatically generate numbers, the list 
server could work with arbitrary text strings.  I would prefer this as I 
found it annoying to constantly look up what these codes mean.  If 
possible (a big if), it would be nice if we could use a more USENET 
approach to topic naming.  My above example could be 
lowLevel.VM.RegAlloc(32) instead of 1.2.16(32).

I am just burbling in my beer on this one, but it would be nice to have 
things recognizable at a glance.

One part of Johan's idea I think would be really great would be the idea 
of sequence numbers.  I am getting stuff completely out of order and I 
have to wait and look at stuff that is a few hours old just to make sure 
that I have the entire thread at that point.  Even if only sequence 
numbers could be prepended to the subject line, I think that would be 
great.  It would give me a chance to figure out the order in which 
things should be read.

Rideau
======
Proposed Organization chart:
We divide work between a hierarchical list of subjects.  Message 
"Subject:" field will begin by the list of subjects (well, using 
abbreviations).  Each subject has got a maintainer.  The maintainer 
will; who must maintain a file about what was said about the subject.  
He must provide regularly updated versions through ftp and/or mail.  He 
also must animate the debate about the subject.  Decisions are done by a 
vote of concerned people.  If nobody disagrees, the maintainer of a 
subject may also take decisions.  The subject maintainer is responsible 
for the vote.  If no decision is reachable through vote, the maintainer 
will ultimately choose, or reorganize a new vote later.  If the 
maintainer's choice is vetoed by a member, a maintainer for a "higher" 
subject in the hierarchy is called to decide (or reorganize a vote).  
Ultimately, an absolute arbitrary judge is to decide (or say who among 
those who know will decide).  The ultimate judge is chosen according to 
an arbitrary but known in advance method. Suggestions: one of the 
project founders, and/or a rotation between members. His identity may 
change with time, as long as there is no way to contest it.  Any 
decision may be later changed if someone can provide new arguments.  The 
same procedure applies for the new decision.  The choice for subject 
maintainers and absolute judge choice method are a decision among 
others.

We still need an initial absolute judge.  If we join PIOS or Merlin, I'd 
propose the project initiator, else myself.  I also propose myself (or 
anyone willing for that ungrateful job) as a maintainer for the 
organization subject (whose mail symbol will be ORG if no one 
disagrees).

 [MOOSE Administration]
-----------------------
- MOOSE People			Fare		Members & contacts
- MOOSE Manifesto		Fare		Our goals and means
- MOOSE Administration		Fare		How we organize
- MOOSE Specificating tools	Fare		What will we use ?
- MOOSE pre-Specifications	Fare		A first wish/hate list.
- MOOSE Glossary		Fare		Internal vocabulary explained
- MOOSE Howto			Fare		How to reach each other
- MOOSE ToDo			Fare		What next to do

References:
-----------
The archive of the MOOSE mailing list will be available
from frmap711.mathp7.jussieu.fr, in ~rideau/pub/moose

Idea status
-----------
Some idea in the project can have several status:
	finished/(well)implemented
		Not only is the idea in the specifications,
		but it also has been implemented !
	defined
		The idea has been agreed and has found its path in
		the official MOOSE specifications.
	agreed
		The idea was voted and accepted, or not contradicted for
		enough time.
	proposed
		was proposed and not contradicted.
		After next meeting, if still not contradicted, agreed.
	discussed
		was proposed, and discussed.
		must be voted or its decision delayed at next meeting
	rejected
		The idea was voted, and rejected.
		not defined yet:
		Nobody has talked about such a thing being or not in the 	
		project.
		of course, we're not maintaining a list of such ideas 8)
	defined not to be
		The official specifications reject such an idea.

Kyle
====
I agree with Mike Prince.  Until there is some sort of organization this
is all just hot air.

I think there should be an emphasis on letting people do projects alone.  
In view of the type of connection we have with each other and the time 
constraints everyone has, I don't think that we can have much closer 
collaboration than that on projects.  However, some things need to be 
done together.

Just to throw out some ideas, how about this:

Two fixed central positions: secretary and coordinator.

The secretary would be a sort of chair to moderate discussion.  It would 
be the responsibility of the secretary to control discussion about major 
topics and projects.  Once some agreement has been reached and a sort of 
specification has been hammered out, the secretary could hand the 
project over to the coordinator.  The secretary would be the one to call 
for votes and discussion on topics.  If someone has any ideas or 
proposals for a project, that person should hand it off to the 
secretary.

The coordinator would coordinate projects.  S/he would gather the specs 
and monitor ongoing projects as closely as possible.  Part of this 
monitoring would be to make sure that the project is going in the 
direction that everyone else thinks it is and that it is moving along.  
The coordinator should bring big changes to the secretary for a general 
vote.

I think that is psychologically important to have the two positions be 
separate.  The coordinator is to some extent an overseer and as such 
should be divorced from the actual decision making.  This should reduce 
tension a bit.

Perhaps a librarian would be good, but I think that the secretary can do 
that as well.

Other positions would be filled purely on a volunteer basis.  The 
secretary would solicit votes and discussion on a proposed project and 
when it was decided, solicit volunteers.  There are going to be some 
things more popular than others and the secretary will have to deal with 
cajoling people to work on their second choice.  The day to day/week to 
week project work will be followed by the  coordinator.  People can 
certainly be involved with more than one project.  However, I think they 
should be primarily involved with one or at most two.  It is far too 
easy to spread yourself thin.

I think the secretary would act as an important central point for things 
like argument summaries etc.  It helps no one to read the same argument 
four times in four different ways.  Obviously the secretary could be 
partisan, so perhaps the secretary shouldn't get a vote.

The positions of secretary and coordinator should rotate or be up for 
election relatively often.  Both positions would be a lot of work and I 
can't imagine that people would be really interested in doing only that.

For each project, we should have a clear statement of goals and what 
kinds of things we expect to get from it.  If it is a coding project, we 
want code back from it and some sort of documentation telling the rest 
of the people how to use it.  A project might be just research in which 
case some sort of report would be the deliverable.  People within a 
project would have pretty much total control over how and what they did 
as long as it meets the initial goals set up for the project.  The 
coordinator can act as a sounding board to make sure that the project 
stays aimed at the target everyone agreed on.  This does mean that goals 
will have to be made such that implementation is left up to the people 
working on the project so that they have as much freedom as is possible.

This sounds pretty draconian compared to what we have now (total 
anarchy), but some sort of center is needed to both handle discussion 
and day to day project work.  It sounds like a lot, but it isn't really.  
People would not be told to go do something against their will, there 
must be a lot of discussion so that everyone has their viewpoint put 
forth and understood by all.  Think of it as a committee with 
subcommittees doing projects.  Then again, in view of how people react 
to committees in government in the US, perhaps I should use a different 
term :-)

Initially, I think we should first concentrate on how to organize 
people.  Then, we can concentrate on the ideas and try to get some sort 
of spec for MOOSE TUNES.  That spec should be something like a list of 
projects for people to dig into.  Probably the first set of projects 
should be researching existing work.  There is a lot out there and we 
would be foolish to reinvent the wheel all the time.  Tech reports, 
theses etc. are great sources of ideas.  People have tried to implement 
a lot of the things I have seen discussed on this list.  I think we 
should try to find out some results before just jumping into design.  A 
lot of seemingly good ideas turn sour near the end of design or even 
coding.

I hope this stimulates some discussion on this topic.  My personal 
experience with Internet projects is that without some clear form of 
organization nothing happens.  Perhaps I have just been unlucky, but I 
have yet to talk to anyone that has had a different experience.

Best,

Kyle

Mike's Compromise Proposal:
===========================
Everyone has very good ideas.  Let's see if I can squeeze them into one.

We should create a blanket organization to oversee the development of 
multiple projects.  The organization would be composed of members.  The 
organization would have a Secretary elected by all members.  Each 
project would have a Coordinator appointed by the Secretary.  There 
would be an Council composed of all the Coordinators plus the Secretary.

The Council would elect an Alternate Secretary to take over in case of 
illness, absence, or impeachment of the Secretary.  The Secretary could 
also name a Pro-tem Secretary to act on his/her behalf for periods of 
not more than 15 days.

I support creating a hierarchy of topics as suggested by Johan.  I also 
believe we should adopt the naming convention for topics that Kyle 
advocated.  Though I believe that only the Secretary can create new 
topics.  I suggest that each _topic_ actually be a project.  And that 
the subject line of our communications take the form of;
	"project.subproject:Description_of_message"
NOTE: In this document all text enclosed in quotes is the argument to 
the Subject: line of an e-mail message.

The use of projects will simplify the organization and development of 
our groups ideas.  I propose the following initial projects;

	organization:  The organization structure of our group (as
		defined by this document)  This would also serve as the
		forum for casting general votes and 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.
	glossary:  Standard definitions of our terms.  This way we all 
		speak the same language.
	kernel:  Formerly LLL, discussion of low level stuff
	HLL:  Discussion of the high level language

I have left out SEC and DIS.  Security conversations have floated 
between kernel and communications to the high level language.  Likewise 
DIS can cover a number of domains.  I would like to subjugate each of 
these to a particular domain, say creating subprojects "kernel.security" 
and "HLL.security".  But we'll decide that later.

To create a project a Request For Project (RFP) message is sent to the 
Secretary.  If that project is subordinate to another project it would 
inherit all the properties of the parent.  Otherwise it would become a 
root project.

The RFP would have the following form;

	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.

The RFP would be submitted in ASCII directly to the Secretary.  The 
Secretary must respond within 5 days.  If a response has not been issued 
within that time then the Alternate Secretary would take control of the 
RFP.

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.

Only the Secretary or a Coordinator can post to announce.  This will 
minimize noise for that topic.  I suggest we use announce to update 
members on the status of projects and proposals for projects.

The Secretary and Coordinators would make up the organizations officers.  
In time we may determine that special positions may need to be created.  
This is feasible under the project system.  If we need a public 
relations person, or librarian, we create a project with such a name, 
and the Coordinator for the project will fill the roles outlined by the 
Goals: section of the RFP.

Modification/removal of projects.  A project is defined by it's RFP.  To 
make a change to the RFP (including changing the Coordinator) a member 
would e-mail the Secretary a Request for Project Deviation (RFD).  The 
Secretary would have the same options as an RFP.  The format of the 
message would be the complete text of the original RFP, prepended with 
REQUEST FOR PROJECT DEVIATION, and the changes indented 5 spaces and 
marked with a >.

The Secretary shall have a term of 1 year.  Beginning November 1st.  All 
votes shall be registered by members after Octerber 20th and before 
October 26th.

The Secretary may be impeached by at least a 2/3 vote of the 
Coordinators, or by at least 1/2 of the current members.  If the 
Secretary is Impeached the Alternate Secretary, as previously selected 
by a majority vote of the Coordinators, will fulfill the roles of the 
Secretary until a general election can be called.  The general election 
must be called within 10 days of the impeachment.  All votes must be 
registered within five days after the election is called.  The new 
Secretary will take office two days after the voting has closed.

If the Secretary steps down the process is identical to that of an 
impeachment.

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 organization project will have several additional files;
	.members  A list of members and their e-mail addresses. This
		will initially be derived from the listservers re-mailing
		list
	.contributors  A list of those who have made significant
		contributions to our organization.
	.projects  A list of all projects and their coordinators

Most project decisions should be arrived at through casual discussion.  
If a member is not happy with a decision arrived as such he/she may 
formalize a decision into a measure and call for a vote.  A vote is 
called by sending a Request for Vote (RFV) to the coordinator of the 
project it would affect.  A RFV would take the form of;

	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.

Remember that all child projects might also be affected.  Measures in 
higher projects take precedence over lower projects.  No lower project 
may vote for a measure that would contradict a higher projects measure.  
However a higher project may vote for a measure affecting a lower 
project with the permission of the Secretary.

Similar to RFP, the Coordinator has five days to respond to this 
request.  In no action is taken within that time, it should be brought 
to the attention of the Council whom will then reside over it.  The 
coordinator would post the RFV to the "announce" topic but discussion 
would take place in the topic being voted on.

All votes are mailed directly to the Coordinator.

I think that about sums it up.  Remember this is a "rough" draft and I 
expect to make changes to it.  Friday is very soon, but we just might 
make it.

One last comment, Kyle is very correct about research.  We (very much 
including myself) have been winging it about doing research into what's 
already out there.  We MUST at least have a short blurb on each of our 
competitors and their deficiencies we hope to make up, in order to 
justify our own existence.  I believe Francois-Rene is already drafting 
one such document.  That should be our first goal after organizing.

Yet another _last_ comment:  It has been mentioned that the naming of a 
group/project is important.  TUNES, MOOSE, PIOS, are still interim names 
as far as I'm concerned.  A serious name, though having little real 
impact internally on a project, can only help us when interacting with 
others.  Let me know if you have any recommendations.

Hope to hear from you soon,

Mike