Re: Re: priorities for PEAR project as a whole

Alan Langford wrote:

On 2006 09 29 03:19, Martin Jansen wrote:

On Fri Sep 29, 2006 at 02:5902AM -0400, Alan Langford wrote:

<snipped/>

Usually there is no development team; instead single developers write code outside of PEAR and come to us when they are finished or have something to show. This is a very good point indeed - I feel the same way - maybe the strictness of the porposal structure scares many wouldbe PEAR developers away. Maybe CORE PEAR users should propose what it wants - write the plan up then broadcast the need for developers to develop the package. At the moment developers come as stated with a Package idea that is mostly completed. I suggested in a previous email that I think the packages should be split into CORE package and more peripheral packages, and from this email it seems to me that specifying what is CORE may be a good organisational process, and also specifying what packages are missing from this CORE set that will move PEAR even further ahead of wannabe competiion.

Allowing people to join PEAR on an adhoc basis with limited permissions is a good idea, ie lowest permissions allow for Comment submission - bug requests - trackback posts. this would build up the community in terms of marketing new packages and concepts.

That's exactly the nature of the problem: over the past couple of years, I've developed my own Captcha tools, XML-RPC clients and servers, database schema transformation tools, and a lot more... now almost all of this effort is essentially duplicated in PEAR (although even that is frequently not obvious given the structure of the web site). Then again sometimes the documentation is so poor that it's easier to just implement something you know you'll understand -- hardly an optimum long term solution. Somehow the model of letting n developers work alone in silence on some package and then adopting the first one that stumbles out of the gate seems woefully inefficient. It seems a lot like a competitive for-profit model in a context that's all about giving stuff to the community. If we had a bunch of people saying things like "Hey, I need more functionality in Image_Graph" then the project lead could point that person at the wiki / mailing list / whatever, let them pick one of the outstanding tasks and get some commitment to doing some real work on it. If we had a place where people could say what their interests are (in the context of PHP libraries, rather than hobbies), then maybe a few people with common interests could get together and start laying out a plan for a new package. Certainly a wiki is a great tool and a good start, but there are things where a supporting application is very useful. For example, I'd like to do a developer search based on a set of interest tags and be able to see what the matching people think they can contribute. Hopefully this comes across as I intend: as positive ideas to try to help a great set of packages become better and more successful. I AM willing to make a contribution to this effort, but I have two big projects on the go and a family that expects me to show up... I have to be careful about what I sign up for if I'm going to stand a chance of delivering on my commitments.