We Need Order First

[cosc19z5@bayou.uh.edu]

Firstly, sorry if the topic sounds a bit arrogant, but it's
tough to pick a subject that's descriptive, humble sounding,
and not too long :).

I believe Fare Rideu (sorry if I misspelled it), made a reference
to order in one of his postings, and I felt it important enough
that I wanted to put in my two cents' worth.

Right now this mailing list is in the discussion phase, so there may not
necessarily be any action as a result, but given the quality of the
discussion and the people involved I'm sure something will occur once
a concensus has been reached.

This brings up a good point -- a more managerial issue.  How will we
reach a consensus?  I didn't notice any kind of authoritative
structure in place to make decisions based on discussions, and
without such a structure it would seem that we'd be doomed to just
argue forever.  Is there in fact such a structure and I completely
missed it?

What I'm thinking of is something like an agreement amongst those
involved to abide by whatever results a democratic vote holds, and
for someone to tabulate the votes and return results, and to mention
specific topics for discussion and votes.

I like all the enthusiasm I'm seeing, and I like the idea of a lispOs,
but things are going in many different directions, so it would be nice
if one particular aspect of the discussion would be fixed, voted upon,
and the next discussion would be based on whatever the people agreed
upon.

What I'm visualizing is 2 key people who will "move" things along.
The first will be the one who counts and tabulates the votes, and
the second will be someone who is experienced in software engineering
concepts and who can therefore present proper topics that we will
all be obligated to discuss.  A vote may determine who the "leader"
is, although finding a tabulator will be interesting (maybe the
maintainer of this mailing list?  I'll volunteer as well if
need be).  We could of course vote on a tabulator in public and
the results would be "common" knowledge.  All votes could be
in public even after that, just so others could see the results
for themselves (and avoid suspicions), but at least one person
will declare winners and so forth which should hopefully
simplify things somewhat.  I suggested the maintainer since the
maintainer already has authority by controlling this list.

Then discussion could proceed according to a procedure where the
"leader" mentions a topic with a subject like "CFV: XXXX", and
people post their ideas, or support for other ideas within a
certain timeframe.  Then when it is decided which one wins,
that subject is abandoned (unless something severe arises, in
which case another vote could be called based on the "leader's"
decision).  Then another subject arises based on whatever topic
won the last time, and again votes are tabulated, and so forth
until we have a concrete plan of action, then a division of labor
could be planned.

Now with that in mind, here is a crude outline of an example of
what I'm talking about (whether or not it's worthwhile is of
course up to you :)):

1) What is the Eventual Goal?

	This will basically be a vote on what we want to achieve in
	the end -- ie: where we want to be when we can say "We are
	finished, we have what we want".  While I understand the
	dangers of aiming big, I also understand that it is helpful
	to know where we want to be, so that this eventual goal will
	serve as a guiding principle.  Not knowing this, we may try
	to reach a humble milepost and possibly paint ourselves into
	a corner.  This way, we'll aim small, but do so with the
	understanding of where we want to be, and thus code with
	that in mind, thus allowing for future expandability, or
	at least making it less painful.


2) What should our first milestone be?

	This is where we realistically set our sites on an attainable
	goal, one that can be achieved within a reasonable timeframe.

	
3) Planning

	This may in fact be subdivided into several topics, but would
	basically be an agreement on the big-picture division of
	modules, data structures, implementation language, platform
	and so forth.  This is where we agree to coding standards
	so that when we bring our code together, a minimum of agony
	will occur.  We'll also plot a timeframe and how to "deliver"
	the code and so forth.



4) Division of Labor

	This is where we decide who does what.  I can see this as
	a volunteer basis, but like all the other discussion to be
	guided by the "leader".  



5) Discussion of achieved milestone

	We then discuss any issues, shortcomings, etc... of the
	milestone we just achieved before moving on.  Since any given
	milestone will probably serve as a foundation for the next,
	it is important to review and make sure everything is ok.


The process could then be repeated for the second milestone.  It is
conceivable that at any phase of this discussion problems and flaws
will arise, which is why the idea of a highly experienced "leader"
is IMO such a desirable one.  This "leader" would know common
pitfalls, and have enough authority to decide of challenges to
a currently agreed-upon course of action are worthwhile.

Don't get me wrong, I like the discussion that is going on, but we
need to keep track of this and make sure it is leading us towards
a concrete goal.  While putting a little extra power in the hands
of a few may not be appealing, having equal authority spread out
to people with conflicting interests is even less appealing.  At
least with authority, we have a better chance of getting somewhere.

So any thoughts, ideas, etc...?  I'm hoping the maintainer will
temporarily take an authoritative role if this idea is found
worthwhile, just so someone with authority will guide the process
of formation. 	

-- 
Cya,
Ahmed