Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <412E2689.6020000@php.net>
Date: Thu, 26 Aug 2004 14:06:01 -0400
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@php.net>
Cc: Sebastian Bergmann <sb@sebastian-bergmann.de>,
	internals@lists.php.net
References: <cgl23k$rhf$1@sea.gmane.org> <Pine.LNX.4.58.0408261044010.1295@t42p>
In-Reply-To: <Pine.LNX.4.58.0408261044010.1295@t42p>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Learning from Python: PEPping the PHP Development
From: cellog@php.net (Greg Beaver)

Rasmus Lerdorf wrote:

> On Thu, 26 Aug 2004, Sebastian Bergmann wrote:
> 
>>  At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2]
>>  on the Python development process.
>>
>>  I really wish we had a process similar to Python's PEPs [3] [4] for PHP.
>>
>>  Having guidelines for issues like adding a new module [5] or deprecating
>>  a module [6] not only makes the development consistent but also
>>  transparent to our users.
> 
> 
> It smells a little too processy to me, but I wouldn't mind a system that
> borrowed some of the ideas.  Like a single collection point for feature
> proposals and a common format for them.  We could simply steal PEAR's PEPR
> infrastructure for this (http://pear.php.net/pepr/pepr-overview.php).

PEPr has been pretty useful, but there are some pitfalls with the 
current design of PEPr.  It seems that in the proposal stage, most 
developers don't even notice a package.  At the voting stage, the 
proposal can't be modified (for obvious reasons), and so many flame wars 
have erupted from those who have not noticed it versus those who have 
devoted lots of energy to it.  Also, since developers tend to be gone 
occasionally, the voting period of 2 weeks can sometimes be too short to 
get a real sense of consensus.

I'd say the best aspect of PEPr is the centralized location for all 
ideas.  Using voting to make decisions is in my opinion somewhat of a 
failure though.  Voting could more successfully be used to determine 
popularity/necessity of a feature or proposal (i.e. allow people with 
cvs accounts to not only vote, but to change their vote as they learn 
more about a feature).  Then the developers can react better to the 
users' changing needs.  Also, PHP has very active and clear leaders in 
Zeev and Andi, and so decision-making won't need to be as democratic as 
it might otherwise have to be.

I don't mean to discourage the idea, but if you do decide to go with a 
PEPr-like system, it would be good to learn from PEAR's first go at it.

Greg