Proposed Organization

[Kyle Hayes]

Anything I snip out of Mike's proposal I support.

Mike Prince wrote:
> Proposal for Tunes Organization
> ===============================
[snip]
> 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.

Hmm, I think that a single coordinator will be able to handle several
projects at once.  Again, I cite the fact that due to the kinds of
connections and time differences we all have, it will be very hard
to have much tight collaborative work.  Also, consider that for many
technical projects, projects tend to have a single project leader for
each 4-6 team members.  Perhaps it would be better to have a single
person responsible for a given project and a couple of coordinators
each responsible for several projects.  Or, perhaps the project leader
and coordinator could be the same.  I think I prefer the last solution
though it will involve a lot of work for said coordinator.

As Daniel Newcombe noted, there are only 16 people on the list.
If you have a coordinator per project plus someone who is actually
doing the project, you are getting too top heavy.  The idea in this
kind of organization is that there should be a minimum of people
involved in organization.  Not fewer than the necessary number.
For the current size, I think one secretary and one or two coordinators
would be enough.  People can still wear two hats, but coordinating
is not always going to be easy and might take most of the extra time
you have.  If there are so many people in a project that it needs
its own coordinator, then the people in the project should get/choose/
find a project leader.

I think that the coordinator should be chosen either by general vote
or by the people who will work on the project.  Whether or not this
will lead to better coordinators is moot.  I think that the feeling of
getting everyone involved would be very beneficial.  I further
think that the secretary should only vote in the case of a tie.  This
helps break ties that could otherwise cause stalls in the pipeline.

Another note on voting: there is an electronic voting program out
there that I have seen referenced.  I believe it runs under X windows,
but I am not sure.  It might be good for tempers to be able to have
secret ballot voting and having a program count the results would help
reduce the temptation of partisanship on the part of the vote counter.
Basically, anything that can increase people's confidence in the 
fairness of the vote itself will help a lot.  Secret ballot voting
is probably not necessary for 95% of the issues we will run across,
but for those 5% I think it will be necessary.  Any ideas on this?

Also, some attempt should be made to assure that things remain stable
while guaranteeing that change can be made if necessary.  Consider the
case where a divisive vote is taken and course of action A is chosen by
a very narrow margin.  Suppose that after quiet lobbying, course B is
then reproposed two days later and passes.  Then A's supporters start
lobbying...  I think you get the idea.   If something passes a vote,
I think we should have more than 50% + 1 votes to overturn it.  Perhaps
the 2/3 rule used in most US government would work.

Yes, this idea limits the options available, but it also assures that
we will spend a lot less time lobbying and a lot more time actually
working.

> [initial project possibilities] 
> 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.

Hmm, I see this a little differently.  I think that an adoption of a
fundamental object model is quite important.  Having a good level of
security means that we need to look at it at all levels.  Similarly,
the choice of object model can have a strong effect on the kind and
extent of distribution.

I think I would propose this list of projects instead (note that some
are the same as Mike's).  First, I am breaking it up into stages.  I
put some estimation of the times each stage will take.  These are
just wild guesses, take them more as a statement of magnitude than
an actual amount of time.

Stage I: Now (two weeks, I think that Nov. 4 is a bit optimistic)

- charter -- this would be roughly the same as Mike's "organization"
  proposal but would also include things like how to handle voting,
  offices and officers.  This would include the overall goals of the
  MOOSE TUNES (where is Bulwinkle?) project.  It should set the rules
  for making projects, choosing coordinators.  Basically it would figure
  out the goal of the whole thing and how we are going to attack it.

  I don't think it should serve for any kind of votes.

- votes -- This project/subject would be used for general calls to
  vote.  All issues affecting things over the level of subprojects
  would be brought to a vote here.  Voting for Secretary, coordinators
  (if that should be done) would be here.  This could even be a hierarchy
  like any other project:

  votes -- for general MOOSE/TUNES-wide things
  votes.X -- votes for project/issue X (only used by members of X)
  etc.


Stage II: after Stage I is totally complete. (2 months, minimum)

- glossary -- definition of terms project.  Important that we all
  speak in the same jargon.  This project should be more to gather
  the terms used in other parts and make sure that we all agree on
  them.  Part of this will involve going to other people and seeing
  what they think of specific definitions.

- survey -- "To boldly go where no man has go before" NOT!  Much that
  I hate to admit that I haven't invented everything, there are a few
  good ideas out there :-)  Seriously, let's look at what other people
  have done and try to build on their results.  If the results show
  that an idea is nice in theory but bad in practice, we drop the idea.
  Often, seeing someone else's work will cause you to ask new questions.
  Thus, we can get more than just results and new ideas, we can get new
  ways of looking at things.  The result of this project should be a
  large description of the other projects/ideas found and what kinds of
  things look the best/most efficient/aesthetically pleasing etc.

Stage III:  After most of Stage II, but perhaps before the termination
  of the survey project.  (two months???)

- survey -- now at a lower priority, but still there is so much out there
  that it does not make that much sense to just stop looking outside the
  group for new ideas.

- security -- Because this is an issue that transcends layers, it
  should be a primary topic.  It will influence other things to
  varying degrees and thus should be treated initially.  This project
  should set goals about security and define the kinds of subtopics/
  subprojects to look into security issues.  Be paranoid.

- distribution -- just like security this is a thread that will run
  throughout all phases and parts of MOOSE TUNES.  Goals like security.

- architecture -- This is where discussion of things like CISC vs RISC
  virtual machines, object models, message passing, etc. should all begin.
  We need to define a solid (and implementable) object model here before
  we dive off into other things like designing persistent stores and
  how to handle specific hardware.  This group should splinter relatively
  quickly, but there needs to be an overall concept to guide us.

Stage IV: to be defined by Stage III. (a week? a year? forever?)

(Note that stages are sequential and projects within a stage are
in parallel.)

Some of these projects would continue on in perpetuity.  The survey
project should never quit.  Neither should the charter and glossary
projects.  However, their importance could be reduced and only a person
assigned to each (or even on person for two projects if it seems that
there is that little to do).

> The RFP would have the following form;
> [snip]

My gut feeling says that something quite this formal will never actually
be used.  Better to have this as the kind of information that should
be in a Request-For-Project than mandate this format.  For such a 
general thing it is hard to see in advance just what kinds of things
will be necessary to include.
 
> [The RFP would be submitted in ASCII directly to the Secretary.  The 
> Secretary must respond within 5 days.]

With some exceptions for holidays etc.  I.e. if you file it on
December 22nd, don't expect a response until after the eggnog
wears off.  Why not say one week?

> After receiving the RFP there are four actions the Secretary could take;
> [snip]

Agreed except for the renaming of the projects that I proposed above.

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

I would say that only the Sec can post for general issues and the
coordinators will post (within their project(s)) for project and subproject
level issues.  Since the coordinators already have to take major changes
to the Sec, let the Sec deal with the big stuff.

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

Hmm, I think that deviation from the goals of a project should be
handled by the project coordinator.  That person should act to get
a coherent description together of the proposed changes and take it
to the Sec.

Replacement of the coordinator
should be either by vote within the project, or by direct petition
to the Sec.  On the third hand, the process could be written into
the goals for each project.  I think I like one of the first two
ideas better though.

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

Some of you are in school (I am not, it just looks like it
from my address).  Are you sure that you will be available for
twelve months?  Internships, summer jobs etc. tend to take people
away from the net when they are students.  Shorter terms would
allow these people to participate in other ways than as project
members.  Maybe three months is not bad unless we have enough people
who can be assured of their time...

> [project files]

I pretty much agree, but it would be nice to periodically archive
this stuff somewhere in on place.  Could ens.fr be used?  Can anyone
volunteer a few tens of spare megabytes to store this stuff?  Perhaps
we should have a permanent Archivist.
 
> 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

I am not sure what you mean by contributors.  Do you mean people
who did more work than was called for?  Do you mean people whose work
we build on?  Is this a bibliography?  (I think there should be one,
it helps immensely to be able to trace where ideas came from.)

(apply my comments on RFP to all levels of voting.)
 
> 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.

Good point.  I have to admit that I am fed up to the eyeballs with
names that have an X in them; X-Windows, linuX, uniX, miniX...
I agree that names like SpUDMUFFiN won't help either.  People
remember names that seem to mean something.  There is certainly
nothing wrong with choosing a name that is _not_ an acronym.  It
is actually becoming a trend not to use acronyms.

I'll second Daniel's call, keep the overhead to a minimum.  I'll
add the caveat that there must be some organization, zero is not
an effective minimum for more than three or four people.

Best,
Kyle