Re: On PEAR quality issues and natural selection

On Apr 9, 2004, at 7:08 PM, Hans Lellelid wrote:

Yes, absolutely. From my perspective PEPr has changed nothing about what gets accepted or rejected; (Do you think it has?) it's just made the process more systematic. It hasn't even changed who can vote, has it? I guess I'm basing my criticism on the idea that PEAR is not an open community -- far from it.

The opposite is true. I joined pear as a volunteer and I found it very, very open. It all depends on what you want to do. Everyone can volunteer starting from the base (docs, bugs) and eventually propose a package or join an existing one. That is very open to me.

I do not see anything coherent about the libraries that PEAR provides and yet I see a lot of selectivity in what gets allowed to be part of PEAR. My suggestion is this: allow anything that meets basic documentation and code quality requirements to be part of PEAR.

There is a need to select the right packages, there are some rules, PEPr seems very fair to me.

<snip>

PEAR does not strive to be for everyone! If it did, it would be a far more open community. It would accept packages regardless of whether they were "almost the same" as existing packages. It would ensure that anyone who had taken the time to write clean code and document it could have their package available through PEAR. This is operating under the "more open" assumption rather than the "more controlled" model (e.g. of JFC).

It is meant to be the official repository, as such quality is the key. As a new volunteer I didn't experienced this "hidden control" or "thinking inside the box "mentality. There is a group, a PEPr and a number of rules. If you want to help with bugs and documentations, I am sure you can do that anytime.

From all I have seen most proposals actually make it into PEAR.

Even if that's true, imagine how many more people would be making proposals if PEAR weren't renowned for being an ego-driven, closed community? Think about all the PHP tools out there ... why are so few of them PEAR packages?

PEAR doesn't need to be just a repository or class collection but the official repository with the highest possible quality. If you think that some of the package do not meet the highest standards of quality you can submit a patch or propose a contribution within an existing package or again close a bug. I don't see any ego-driven behavior but possibly some potential developers getting their proposal dinged (with comments and all) and getting it too personal. <snip>>

Yes, I don't see DataObjects integrating these changes. This brings me to another point, though; a lot of the competition would be removed if there was less ego on PEAR. Another way of putting this is that anyone who is a developer on a project should be allowed to commit changes to that project. This is also related to the bugfix issue.... why can't anyone who is granted developer status on a project fix bugs on that project!? I highly encourage anyone working on my projects to fix bugs. They don't need to "ask me permission" to fix documented bugs; this is ludicrous. Obviously the direction of a project needs a manager, but it doesn't need a micro-manager. Because the Lead might have a different idea on how to close that specific bug.

Regards David Costa