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

On 2006 10 12 17:02, Joshua Eichorn wrote:

Gregory Beaver wrote:

Hi everyone, I have asked Josh Eichorn, head developer of HTML_AJAX and co-head of PhpDocumentor to head up the start of an effort to clearly define PEAR's mission. At this point, we are simply at the stage of exploring ideas, a brainstorming session. Once all of the ideas are in a simple list, then a small task force will organize them, and attempt to prioritize them based on what you want, and what is possible with the current setup. Once we have a smaller list, it will be presented for discussion to all of you once again, hopefully resulting in a clear mission within the month. At this point I'll turn it over to Josh, and he will coordinate how we will gather your ideas. Thanks, Greg

I'll be grabbing the various items i've heard so far, but it would help a lot if people could reply to this message and post anything you'd like to see PEAR do or do better. These items can be anywhere from "make pear a leader in the PHP development community" to "make it quicker to get a pepr account" Concrete goals are always useful, but remember part of the goal of this is come up with a mission for PEAR that will help us decide which of the concrete goals are most important. Also note, I'm making a list not writing a book, please no rants and long messages try to keeps things a list. Your help, is much appreciated. -josh "What do you want PEAR to be" eichorn

I apologize for the length of this. Really there's just nine points with some explanation for each. It is perhaps useful to ask "what makes PEAR distinct" from other sources of PHP code. If I were to compare PEAR to a package I might find in another repository, why is it different? My list would go like this: 1) Works. All packages are functional or expected to be functional in the near term. Finding a great package description is of no use if it's been in the "planning" stage for the past two years. 2) Integrated. Nobody wants to try to deal with a complex system that uses, for example, three different XML-RPC modules, just because three components of that system chose different implementations. PEAR has done a fine job of this and it is IMO one of its biggest strengths. 3) Documented. A package without user docs is borderline useless. The PhpDoc headers can be helpful, but really if you can't figure out the API by looking at the code, there's a big problem with the code. It's the user docs that make or break a package. 4) Reliable. Everyone should be able to install packages with a "local QA" option that allows them to run quality assurance tests on a package by package basis. Reporters of bugs should be strongly encouraged to submit QA tests that demonstrate the bug, and when validated, these cases should automatically be added to the QA suite. 5) Peer reviewed. I agree that a package shouldn't be marked stable before user docs are in place, but it's difficult to test for good documentation through a purely automated process. It would be nice if a package could only get promoted once some predetermined number of other developers (with appropriate or even weighted karma) "certify" or "sponsor" the release as something that they've looked at in detail; that the documentation is clear, complete, and accurate; and that they personally feel it is of sufficiently high calibre to enhance PEAR's overall reputation. Sponsor's names should become a permanent part of the record of each release, so that it's a meaningful act. 6) Standardized. I think we should enhance the PHP_Beautifier and PHP_CodeSniffer tools and the "Format for PEAR" capability to the point where they do a very good job of meeting our coding standards. One of the QA tests should be that all new packages and all changes to those packages are consistent with the output of the formatter. (This could probably be automated if we switched to Subversion for revision control.) 7) Collaborative Planning. Non-developers should be able to tell us what they looked for in PEAR but didn't find. Developers should be able to express interest in and form teams around ideas for new packages. This isn't to say that someone new can't come along and submit a package that does the same job, but I think it would help PEAR be in a position to create new in-demand packages more quickly, thus becoming even more relevant and useful. 8) Collaborative Development. Authors need to recognize that by contributing to PEAR, they are giving up some control over that code. Others should be able to propose enhancements to a package without having them arbitrarily rejected by the maintainers. I would expect that some sort of process like PEPr could be put in place so that if enough developers supported a proposed enhancement, then the group as a whole could override the wishes of the package's maintainers. 9) Collaborative Documentation. By far the most useful nuggets of documentation seem to be gained from insights of other people who are trying to make use of a package. Some sort of *structured* way to capture feedback from these users -- and ideally some way to have readers users promote the useful comments while burying the useless ones -- would make a huge contribution to the usefulness of PEAR. I also think that PEAR could benefit from a Libraries / Frameworks / Applications hierarchy, but I think that's better addressed once we have got the fundamentals in place.