Re: On PEAR quality issues and natural selection

Richard York wrote:

The documentation on PEAR itself is difficult to navigate and confusing. The documentation assumes too much knowledge of the reader, even of an experienced developer.

Then help. We have very little arm raising in this respect.

I'd be delighted to, if I understood it well enough to document it. The creators of this and that widget should be documenting, not the clueless.

Well I wonder how downloads all these packages? I am sure they are not all clueless about how the package works.

Documentation on documentation is another lacking area of PEAR, there's a link to the docbook website, but no explaination of how to write the bloody documentation, nor of how to access CVS and place it in CVS. You can get a CVS account, but no explaination of how to use it. No examples of well formed docbook xml, PHPDcoumentor is good, but its not PHPDocumentors job to explain how to add code snippets and tables and all that.

Sorry your attitude sucks. Its not that I am unwilling to write documentation. I spend alot of time on PEAR. But I can only spend this much on PEAR. The same applies to alot of developers. Few users have taken the time to write documentation after getting help on one of the lists. We have gotten really few contributions, btw the pear-doc team accepts plain text docs.

Man, my attitude doesn't suck. There's no need to get defensive.

I was not getting defensive. I was more getting annoyed by this attitude . Docs in PEAR are severely lacking. However if you think that the docs for PHP itself have been written by the developers you are very wrong. Actually alot of developers were sort of hoping that opensourcing their apps would result in people helping them. However your attitude sounds more like with opensourcing they also have a responsibility to write docs. However making documentation a requirement inside PEAR (maybe even just for stable packages) is something that can be discussed however. It doesnt seem to follow in with the anything goes survival of the fittest theme that was also brought up in this thread.

I also feel the code structuring guidelines should be expanded to include

the one true brace convention, on all control structures, not just functions... this other convention is difficult to read and most professionals don't use it (at least none that I've encountered).

WTF? so now you want more beauracracy?

No just fexibility. Though this isn't clear in my message, one or the other- a choice of either. Its a matter of personal taste, my eyes get tired and I find that the one-true brace convention is easier to read. Flexibility is anti-beauracratic.

Err I dont get it. So do you want to remove or expand the regulations?

I am shocked with all of these comments. I am sure there must be ways to critize PEAR in coherent ways. But it seems you guys are jumping from one argument to another. There is one theme to all of this: very little interest in cooperation. This however is an assumption made inside PEAR. Maybe this is naiv.

Critism is where growth starts. I feel you are taking such things personally.

Of course I am. PEAR is important to me. This doesnt mean that I dont appreciate idea to how to improve PEAR.

My comments come as one new to PEAR. I don't feel that such discussions are non-constructive. If no one points out what everyone else assumes, how does anything get changed?

discussions are generally a good idea if they are contructive. I have seen little in this thread that fits this criteria. Most of the comments are driven by fairly incoherent personal tastes but not really a concept of how PEAR could work differently. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07