RE: [PEAR-DEV] Re: About the package proposal interface

Hello, > > Are the PEAR guiding members worried that the QA team > > will be bogged down with a large number of not-necessarily-useful > > packages? If so, doesn't this suggest the QA team should be expanded, > > rather than packages rejected? > > Both, reject packages and create a QA team. But that's my > humble opinion. Pierre, maybe I missunderstand you but if you want a possibility to reject a package this has to be done by the PEAR group. And if the group starts to reject packages you can stop thinking about a new proposal system cause this will be useless then. If a small group of individuals is able to reject votes of the majority you'll have to fight endless wars and will loose your developer base. Then it's even better to only let the group decide about a package and don't let anyone vote. The main problem of PEAR is that there are too much opinions what PEAR should be. And you want to be democratic but aren't satisfied with the outcome of democratic processes. This can get serious if it isn't solved soon. Now you are thinking about ways to create rules to change the outcome of the democratic processes. Please believe me - it's better to simply say 'we decide and you follow' than letting the base only think they are in a democratic process. One thing also should to be clearified: If a dev proposes a package he wants to give something to the community. My personal opinion: A package that follows the quality rules, solves a problem and isn't allready there should go into pear. This could even be decided by the QA team as this decision is based on simple to test facts and not on philosophic issues. regards Daniel Khan