Wed, 2 Nov 1994 14:46:11 -0800 (PST)
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.
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
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
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
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
-- 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.
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
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
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.
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
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
- 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
The archive of the MOOSE mailing list will be available
from frmap711.mathp7.jussieu.fr, in ~rideau/pub/moose
Some idea in the project can have several status:
Not only is the idea in the specifications,
but it also has been implemented !
The idea has been agreed and has found its path in
the official MOOSE specifications.
The idea was voted and accepted, or not contradicted for
was proposed and not contradicted.
After next meeting, if still not contradicted, agreed.
was proposed, and discussed.
must be voted or its decision delayed at next meeting
The idea was voted, and rejected.
not defined yet:
Nobody has talked about such a thing being or not in the
of course, we're not maintaining a list of such ideas 8)
defined not to be
The official specifications reject such an idea.
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
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
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
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
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
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.
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;
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
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
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
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
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
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
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
.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
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
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,