Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22304
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 09 Mar 2006 12:27:25 -0700
In-reply-to: <1fc601c643aa$68c46300$6402a8c0@foxbox>
To: internals@lists.php.net
Message-ID: <200603091227.25162.benjcarson@digitaljunkies.ca>
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: 7bit
Content-disposition: inline
References: <7.0.1.0.2.20060309124054.06c31238@zend.com>
	<1fc601c643aa$68c46300$6402a8c0@foxbox>
User-Agent: KMail/1.9.1
Subject: Re: [PHP-DEV] Give the Language a Rest motion
From: benjcarson@digitaljunkies.ca (Benj Carson)

> How do we do it?  Unfortunately, I can't come up with a real mechanism
> to 'enforce' a due process and reasoning for new features.

One mechanism that the MapServer project[1] has adopted is that all "major" 
features require an RFC before they are accepted and implemented.  Whoever 
is proposing the feature or change writes the RFC, which outlines what the 
impact of the change will be on users, how much code it touches, whether 
there are any BC breaks, etc.  Once the RFC is finalised, the core group of 
developers vote on the RFC and if the vote carries the feature is 
implemented.  (There's more to it than that, but this is the basic idea.  
See [2] for the full policy.)

Writing the RFC helps the person requesting the feature to stop and think 
about the implications of the change and to identify any potential 
technical hurdles before plowing into the code.  It also helps everyone 
else by having a concise, concrete description of the proposed feature that 
can be referred to during discussions.  When the feature is debated on 
their dev list everyone is one the same page.  Any changes or suggestions 
that come up during discussion can be included in the RFC.

Another benefit of this policy is that it increases the legitimacy of the 
project in corporate settings.  The so-called "Enterprise User" can point 
to it and say, "Hey, here's how these guys make decisions, it makes sense.  
My manager will like that".

The drawback to this scheme is that not many programmers like writing design 
documents, and would much rather just bang away at code.  This could have 
the effect of deterring potential contributors.  (That said, I haven't 
personally had any problem submitting patches to Mapserver.)

Anyway, just something to consider from a list-lurker...  PHP is a much 
bigger project than MapServer, so having a process as structured as theirs 
might not be feasible.  However, requiring RFCs for core language changes 
might be a good compromise between trying to implement any and every fancy 
new language feature and stopping core language development altogether.


Benj Carson

[1] http://mapserver.gis.umn.edu/
[2] http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1/