An archive of proposals needed? (Was Re: What is a ``reflective'' system?

[Jordan Henderson]

"MD" == marcus@cathcart.sysc.pdx.edu (Marcus G. Daniels) writes:

> >>>>> "JH" == Jordan Henderson <jordan@Starbase.NeoSoft.COM> writes:
> 
> JH> This is exactly why we need some form of Project
> JH> Coordination/Steering Committee here.  I don't remember there
> JH> being wide consensus on Flux and I've even seen some ambivalence
> JH> toward CMU-CL.  If people would just form teams to research
> JH> various things, then it would be clear which direction we were
> JH> working.  This would not squelch other ideas.  People who wanted
> JH> to go in different directions would just form their own teams.  It
> JH> seems like now we are all waiting around for unanimity and then
> JH> we'll all go off in the same direction.
> 
MD> At some point, it would be nice if a person maintain a web site that keep
MD> tabs on all the different people that have documents or programs to
MD> share.  Maybe even a FAQ indicating, among other things, the longstanding
MD> disagreements.  Together, we've only got 1200 messages in two mailing
MD> lists, so I think things aren't so out of control.

I've been thinking of a way that I could make some positive 
contribution to this effort.  I could set up a web page on a well
connected site in the US to hold documents, pointers to the list
archives, instructions for getting on/off the various lists.  I've
only got 10 MB web space, but that should be enough for a while.
(And, I might be able to get some more, as necessary.)

I think a good thing to have would be an archive of proposals, we
could call them RFCs (Request For Comments).  These can be anything,
manifesto drafts, architecture, etc.  But, they should be specific,
and not just ramblings about philosophy or postering about positions.
Each of these documents will have authors attached to them that "own"
the proposal.  People will be encouraged to forward comments directly
to these people for revisions.  We could use a standard revision numbering
system for the RFCs and the revisions.  For example, if the manifesto
document were RFC 1.0, then the first revision would be 1.1, etc.

I would exercise no editorial control except to reject proposals that
have no pertinent content (I will be reserved about rejections).  If
someone complains to the list and someone agrees with them that their
RFC be accepted, I promise to accept it.  Mostly, these proposals would
be technical, but not limited to that.  The proposals could include
policitical documents about the structure of a future organization,
licensing issues, etc.  If someone feels diametrically opposed to a
proposal, then they can submit a counter-proposal as another RFC, and 
I will link the two on the page that introduces each RFC.  I think a 
good structure would be a page that introduces the RFC, gives it's 
number, a short name, an abstract, links to all of the revisions and
links to alternate proposal, or related proposal RFCs.

Hey, I could do this anyway just by extracting posts to the list and
advertising they are there, but I want it to be a positive thing.  
Before I start, I'd like to hear your comments about the process I'm
proposing.  I hope that this will address the traffic concerns to 
some extent.  I'm thinking that we can get people working on public
documents, and sending review comments around to the authors, rather
than everybody seeing all of the discussion.

This would be an unofficial function for an unconstituted group, but done
well, it might help us all see the subjects clearly and reduce the chatter.

MD> On a related note, I've noticed some folks are not particularly taken
MD> with this notion of a persistent store.  Any interest in splitting
MD> to another list?

I agree, but really if my idea above about a proposal archive works, then
the POS stuff would mostly go off-line to the people interested in this
issue discussing amongst themselves and coming up with new RFC revisions.

I would like to see LispOS implemented on top of LispVM (I feel an RFC
coming on), but I feel the splitting into two groups may hinder the two
from being implemented in a complementary fashion.

If I get any positive feedback about this, then I'll set it up.

-Jordan Henderson
jordan@neosoft.com