Re: Re: Rejected packages

Craig Constantine wrote:

<snip> i think we should leave pepr the way it is. The problem seems to be lack of general participation by pear developers. If we feel the members of the collective will active enough to decide via a collective-specific pepr, then they'll be active enough to decide via a global pepr [as is now.] We could add a "collective" selection in the pepr proposal to make it easier for everyone see where the proposal relates. The collective's web area could then have a "show all pepr proposals related to this collective." Here's an idea. Instead of requiring x votes, why not make it so that the PEAR Group appoints one or two (or perhaps more then that, even) people be in charge of the package approval process. Those people check to see if a proposed package is in compliance with the PEAR coding standards and if so, they accept the package. Otherwise, they reject.

I mean, near as I can tell, the chief reason packages get rejected, anyway, after a lack of votes, is because they didn't follow the PEAR coding standards. Have packages been rejected for any reasons other then those two? If not, then what's the point of having multiple people say (in the form of a vote) that a package isn't doing what it needs to be doing when one person saying it is more then sufficient? It's not as if the PEAR coding standards are so subjective that a consensus needs to be taken, anyway. Plus, by making such appointments, you get a certain level of accountability. ie. if the people in charge of approving packages aren't doing their job, they can be replaced. The fact that they can be replaced - that said people can lose their "title" or whatever - may motivate them even more then they would have, otherwise, been motivated.