Re: Re: Ethics of competing proposals

I *could* be missing something here, but the whole point of submitting proposals is to find the best proposal. Sometimes we're only given one alternative, but I think it's great to be able to choose between multiple proposals. Imagine if government worked as you seem to be suggestion PEAR should. Someone proposes person A becomes president, but person B is a much better candidate. It should be put to the voters as to which one is a better fit for the position. As a result I'm overjoyed to see multiple competing packages. It only means that PEAR is growing and gaining popularity. Sometimes the competing packages will be able to combine their efforts, but other times (due to the non-competing-packages rule) the PEAR community, through the PEPr process, will have to choose which one is the best package. --Joe On Jul 18, 2005, at 9:26 AM, Clay Loveless wrote:

On 7/18/05 9:09 AM Pacific Time, Lukas Smith (lsmith@php.net) wrote:

Just to make it clear. PEAR is a technical group. As such we are interested in the best code.

Thanks for clearing this up. : ) I'll leave a full response to this to those who are already upset about the quality of some PEAR packages, the PEAR package competition issue, etc. I have no personal axe to grind on this topic, but I know that others do.

While ego are involved its irrelevant to PEAR who maintains what as long as the code is good and well maintained. So if Luca gets the ball rolling, yet someone else provides the better code, then there is no reason to accept Luca's code. What you are suggesting sounds like a land grant due to creating inertia in a new direction.

I don't think I actually made a suggestion. What I'm questioning is how ethical it is for: 1. Person A to propose a package. 2. Person B to attempt to circumvent the entire PEPr process by simultaneously submitting a competing *proposal*. Based on what you're saying, this is okay to do? If so, I think it needs to be documented somewhere that the PEAR Group considers this acceptable behavior.

However I think we are still well on our way to a collaborative effort. ... I am quite confident this will work out and its obvious from the feedback that the PEAR world is sensitive enough to the problem that support is there when needed.

While I agree that it seems like things will work out well in this case, I think that the way we got here was atypical enough that it be explored and clarified as to what is considered to be acceptable behavior. Perhaps an RFC is in order regarding the notion that proposing a package may not guarantee that it ever gets to a vote, in case someone else steps up with a competing proposal? Or, an RFC for PEPr modifications to specifically handle competing proposals? -Clay --Killersoft.com --PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php