Re: Package proposal misuse?

I agree with re-focusing the attention from voting to the description of a package. Often, a package is proposed that implements a useful but niche-market technology. It is important to note that if I don't know anything about this technology, I don't vote because I don't consider myself qualified to vote on it. If you find people are ignoring your proposal, there's 1 of 2 possibilities to change this: - figure out exactly what problem it solves, and explicitly state why it will make our lives better to use it :) - re-write it so that it clearly solves a problem that needs solving and then do point 1 I would like to add one other question to the debate: should PEAR accept packages that don't exist or are not past alpha? There seems to be a bit of a race to get one's package into PEAR because the door closes once a competing project is accepted, and you are then at the mercy of that project's maintainers as to whether vital features you need are added or not. I can understand the rush to get a project into PEAR before this nightmare happens, but then we end up with a whole bunch of alpha-quality projects. The main problem is that if your project is not accepted and a competitor's is, then you're screwed. Perhaps the solution is two-fold: restrict packages to those that - exist :) - have undergone real-world testing and add the possiblity to link to competitor's projects from the package page so that if there is a really good package that does a similar thing in a different way, users can know about it. Obviously, this is not a good thing for programmer's egos (on some level, I would be mildly uncomfortable with having links to other php documentation systems on the phpDocumentor package page), but in the end it is a good thing for users and ultimately for PHP, because then I am prompted to check out the competition, and make sure that we do everything good they do and more, or lose all of our users :) If PEAR is going to be the standard PHP repository (and it is), then it is well worth the wait to get ONLY mature packages into PEAR. I'm not saying that a package can't release betas or snapshots, just that the API for a package must be well-thought out, fully tested, and documented before a package is even considered for acceptance. Obviously, writing with PEAR CS may be discouraging some people from writing for PEAR, and there is no solution for that, but as someone who hates some things about the PEAR CS, it's really not so bad, even if you do hate it :). Greg Mirco 'Meebey' Bauer wrote:

Lately I see this package proposals with "but I need more votes, please vote" If the package is not accepted within the first proposal this means that most of the active pear devs don't see the need for it or have some other reason why they didn't vote. Please respect this! Don't spam this developer mailinglist with "more votes please!" Instead improve the package, make changes and explain what you changed and maybe retry then. But just reminding of a package proposal is the wrong way... just my 2 cents...