[MUD-Dev] Re: DevMud RFC #1 - Was Re: DevMUD considerations and the Halloween article

[James Wilson]

On Mon, 02 Nov 1998, J C Lawrence wrote:

>Alan Cox has written a differently themed but equally useful and
>insightful analysis for a Slashdot article:
>
>  http://slashdot.org/features/98/10/13/1423253.shtml
>
>Key points: We have a lot of blather and no code.  We have no benign
>dictators (and I'm not volunteering).  In summary we have much hot
>air, exercised keyboards, and no product.

I found this anonymous comment (a response to Cox) especially salient:

	When a project is just germinating it sometimes doesn't 
	make sense to open the entire thing to discussion before 
	the core developer(s) has/have come up with basic ideas for 
	the project... Sure, the project should be announced to the 
	masses so that they can email people with their suggestions 
	and ideas, but perhaps mailing lists give people to much of a 
	sense of actually making a contribution when in fact all they 
	are doing is filling up other peoples mailboxes with spam. Once 
	the project is a little more established it makes sense to open 
	up a mailing list so that people can contribute bug fixes/submit
	problem reports (sometimes not even then IMHO).

as Ola has pointed out (thanks for being so mean, Ola!) there are few
seminal concepts that we agree on beyond "modules" and "reusable". even 
worse, and this is something I asked about a while ago and got entirely no 
answer, there is no authority figure to set direction or maintain 
editorial control.

>This needs to change.  

Indeed. Are y'all detecting a challenge? ;)

I think the first question is, WHO IS THE DEVELOPMENT TEAM? This question 
is especially proximate in that JC now has cvs set up, and someone has to 
decide who gets access. 

Therefore in the spirit of arrogance which makes me so wonderful, let me 
PROPOSE the following.

-----------------

DevMud RFC #1 (James Wilson)

Whereas
	1. it has been amply demonstrated that the babbling din on the
mud-dev mailing list is conducive only to going round in circles
	2. the various oracles and auguries and scriptures of our avowed
Open Source faith assure us that all OS projects need, among other things
		clear and realistic goals
		a real live system to play with and improve
		an expectation of utility
	3. expecting a phase for formal design without iterative cycles is
unrealistic based on the deep insight of this reporter

Let it be Resolved that

	1. those who have proposed various designs should put their shoulders
to the wheel, and come up with full proofs of concept. These should
be checked into discrete cvs directories in a central place for public view,
and should be accompanied by design documents explaining what principles, if
any, were driving forces.

  	2. each proof of concept should be announced on mud-dev upon its
inception, including a basic description of the general direction the proof
will take.

  	3. After this initial announcement, any collaborators should
correspond via channels outside of mud-dev until such time as they have
COMPLETED the proof of concept, at which time it is expected that they will
make an announcement and describe what, if anything, they have accomplished.

	4. If any of the proofs of concept appear to have any merit whatsoever, 
it will at this point be clear due based on quality of code and design who
the core development team is, and what directions seem fruitful.

---------------

since I've been bold enough to call it an RFC, please comment.

If this looks like it's no good, I'll be happy to shut up if someone has a
better proposal.

James