Re: PEAR's mission statement - let the fun begin

I agree with this - PEAR being more open is one of my points. I mentioned before that I think PEAR should dictate what PACKAGES it wants, i.e. in the package list should be all the packages that need to be coded - not the other way round of people proposing them. As PHP itself starts encompassing what PEAR actually do, i.e. exceptions and the like then the need for some of the core PEAR packages will reduce, thus where will PEAR be when PHP6 comes out, probably still deciding on how to handle PHP 5 :-) I digress. I think PEAR should concentrate on some niche packages also - i.e. Web Services is a good example. So instead of waiting for proposals a list of all the possible Web services should be gathered and then a call for developers to code these. A lot of the companies that have web services have examples already done, but the level of code in these and coding standards is something to be desired. And then what PEAR can do is go to these companies and say hey - we will look after the PHP wrappers anyway - if your guys want to code these then please code these within PEAR. PEAR automatically gets some Kudos, and hopefully these packages remain up to data and consistent. The companies then have an easy way to distribute and developers an easy way to use the web services - everyone wins. This model can be expanded to other nice packages also. Daniel O'Connor wrote:

To get code into PEAR, it has to run a gauntlet of picky, fussy developers who will be against a package going into pear for very minor deviations from coding style. The level of feedback and the place it starts tends to be around the very start of a package - there's no ongoing review. What I would like to see is PEAR an 'open for everything' attitude. It should be really easy to publish any code you like through PEAR. It should be really; really easy for end users and developers to leave feedback for a package. This feedback should be right there on the front page of the package. Automated ratings of a package should be available too - a combination of "95 out of a 100 people download this package when they see it", users have rated this package "4 out of 5 stars", and this package is "50% documented (PHPDoc)". If it's crap, people will say so; and do it loudly. Though it should be dead easy to publish code (minimal review; sort out ridiculous from plausable pepr entries); it should be very hard to reach a 1.0; stable release (stringent review; documentation; tutorials; it should be possible to put out a call-to-arms in getting a package ready for 'stable'). Take a look at an addons.mozilla.org page https://addons.mozilla.org/firefox/722/ Mozilla doesn't endorse any of the addons - they could be total and utter junk. They trust end users and community leaders to provide honest feedback and leave it at that. In short: PEAR should be more 'open', and relax standards in terms of getting packages in - apply them when packages want to take the 'stable' badge. PEAR should be about helping you sharpen a tool to be ready for use; even if that means you have a whole lot of dulled or blunt ones which never get used.