Re: PEAR group elections - 2011?

On Sun, May 1, 2011 at 12:13 PM, Daniel O'Connor <daniel.oconnor@gmail.com> wrote: > On Sun, May 1, 2011 at 6:47 PM, Alexey Borzov <borz_off@cs.msu.su> wrote: > > > Hi Daniel, > > > > > > On 25.04.2011 11:30, Daniel O'Connor wrote: > > > >> As much as I love being part of the pear group; and realizing I've done > >> nothing overly strenuous during that time; do we want to put in a bit of > >> focus this time around re finding candidates / establishing a bit of a > >> plan > >> for the year? > >> > >> IE: http://pear.php.net/group/ is a shade out of date. > >> > > > > It seems to me that number of PEAR Group members is a bit higher than the > > number of current active PEAR developers... > > > > > https://www.ohloh.net/p/pear/contributors?query=&sort=latest_commit&commit=Update > - > 67 according to ohloh; down from 80 ~6 months ago. > > I agree we're not attracting new developers at a sufficient rate; and the > current contributors are going onto different parts of their lives and > careers. > PEAR doesn't really have to be "attractive", it's not backed by a company like Symfony or ZF. But in my opinion, at the moment it's too difficult to submit a new package. By difficult, I mean it is time consuming and involves a lot of bureaucracy and a lot of prior knowledge of the process. There is also too much confusion about what is Pyrus (never heard of that), Phar, PEAR 1, PEAR 2, Pear package manager, PHP5 support, Namespace support, PEAR Exception, PEAR Error, etc, etc. Personally, if I had to contribute a new PEAR package today, I wouldn't know where to start. So if you could simplify the process of contributing a package and add an up-to-date step-by-step tutorial, that would help PEAR grow again, in my opinion. I'd also get rid of the "no duplicate package" rule and allow more packages to get into Pear, and maybe add a review process where PEAR Group members and other PEAR veterans could write package reviews after integration into Pear (not before as it is today) and vote for package quality/usefulness/design/stability. Criterium like "does it have unit tests ?" could improve the package note and visibility, while "Does it have many unsolved issues ?" would lower it. Then, contributing could also be more "rewarding" for the contributor (stats, package promotion on other channels: twitter, rss, planet php, reddit, etc, improved member page). Maybe create some kind of badges or ranking like in Stackoverflow or WoW, these things work well in geek communities :) I'd like to have a PEAR veteran badge ;) PEAR member page has a high ranking in Google, so it deserves some attention. Cheers, -- Bertrand Mansion Mamasam