Just to clarify, I didn't propose taking the PEAR PEPr system verbatim.
To be honest, I have never really used it, beyond skimming through things
because it is handy that everything is in one place. I don't find our
feature/change request category in the bugs database to be all that
effective. Things tend to get lost in the noise there.
I am not sure it would be effective, but I think it might be worth a try
to have a single place for people to propose features and changes and to
have an organized record of decisions surrounding these proposals. At the
same time I absolutely hate using a web system for discussing things, so
such a system should have an email gateway.
As in:
1. Submit proposal to web app
2. web app sends it to internals@ or some other relevant list
3. Replies to that email automatically get picked up by the web app
4. Alternatively, you can add comments via the web app which would
also get bounced to the relevant mailing list
-Rasmus
On Thu, 26 Aug 2004, Andi Gutmans wrote:
> It might be nice to have this documentation in place for people to
> reference and for discussions (and most importantly to look back at for
> understanding design decisions). It also would make it easier for people to
> propose new features or changes in PHP.
> This doesn't necessarily have to do with voting. In general, the PHP
> project up to now has worked pretty well in this sense. Like in most
> open-source projects the maintainer of a certain piece of PHP usually has
> more say than others (and thank god we have many maintainers and not an
> individual person for the whole thing). That doesn't mean that overwhelming
> popular demand hasn't had it affects either. I think it's a balance which
> can only be reached by cooperation.
>
> Andi
>
> At 02:06 PM 8/26/2004 -0400, Greg Beaver wrote:
> >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
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
