Re: Package proposal misuse?

Ilia Alshanetsky wrote:

PEAR is not the only repository of PHP code/scripts, there are plenty of others. Your *great* code/ideas need not be lost if it is not accepted into PEAR for whatever reason. This is a good point, PEAR is not hotscripts php classes, it has a high barrier to entry and thats generally a good thing.

I think that if we're going to have this "policy" in place, we need to make it so that *all* (active?) PEAR-DEVs *must* vote on every package, even if its +0 - just to show acknowledgement. (As mentioned by stefan whilst I was writing this ;)

Forcing people to do this will only lead to invalid votes. Many would vote just for the sake of voting (some do so even now). Reviewing a package takes time, most people have day time job, school and other more important preoccupations, you need to be patient. The onus is not on the PEAR community to accept your work, but rather on you as the developer, to convince others that your code has merit. The problem might be solved by having more then 1 shade of +0, i don't have to review this code, i'll never use it etc.

developer mailinglist with "more votes please!" Instead improve the package, make changes and explain what you changed and maybe retry

We need feedback in this case... I assume its ok to post something with the subject "My_Package didn't get enough votes, please give me feedback"?

Perhaps, if a package/idea does not attract sufficient audience right away, it means that there is little interest in it's addition? I would imagine that a number of people would not feel confortable shooting down someone's work in a public forum. A lot of times packages get responses from a couple people and the follow up isn't public enough so things get lost. This is the case with things like PDS where someone like Greg gives lots of feedback which is never fully addressed in code so the rest of the developers just hold off until they see some progress.

To wrap up my thoughts, web voting could be useful but the most important of PEAR package acceptance isn't just the the +1 votes, but the review and suggestions that others give you about hte package. If PEAR moves to web voting we need to make sure that packages still get the same level of review and not just a quick look over by people. As others have said API review takes time, as does review of the coding patterns involved especially since were commited to BC once packages are stable, its not something you want to run into, thats what caused a multitude of template systems with no shared code or api. -joshua eichorn