Re: Group/Community Disconnect

Hi Paul, I've completely bought my argument now that PEAR needs less democrasy, so you'll have to forgive that reversal on my part. I just feel that this open policy stuff is an uphill battle that just doesn't need to be fought. There's a lot of value in a more tightly controlled code too. Paul M Jones wrote:

Hans Lellelid wrote:

Lukas, I think you should be a stronger leader -- nay, dictator, of PEAR.

I signed up for PEAR in Mar 2003, before PEAR Group was appointed. I signed up under the idea that published coding standards, common error handling, standard naming conventions, peer review, and peer voting would be the determiner of success in PEAR.

Well, it has been the mark by which packages are accepted. None of those things address issues of usability and coherence in the library, however.

I did not sign up to submit myself to the whim and will of a Group (or Dictator), appointed for life, that does not publish its internal communications.

:) Would you really oppose an elected leader? Would you mind that much if you had voted for Group members? Perhaps the "appointed for live" would also be optional ;)

PEAR Group needs to open its hands, not clench its fists. Open the policies just a bit; new and great things will happen. Does that mean PEAR Group will need to change its vision of what PEAR should be? Perhaps -- but maybe it *ought* to be changed.

Naw, the mistake is that PEAR wants to do the right thing & keep people involved, but also wants to have everything work together -- and PEAR has a self-imposed committment to maintaining packages & ensuring quality. This level of quality committment is incompatible with the current open system. I think it's what you're butting up against here.

To illustrate: Of the 6 negative votes for Savant, 5 are from the Group. All of the 12 positive votes are from regular non-Group developers. What does this say about the disconnect between the Group and the community?

It says that clearly the community do not care one bit about any larger goals of PEAR. And indeed -- why would they? The messages on this list from members of the PEAR group (and Greg who's vote was conditional for the same reason that others gave -1) suggest that the problem here is not that your package is bad, but that the right thing to do for PEAR is not to accept another package only to then turn around and deprecate all of them in favor of a unified approach. The messages in support of adding Savant tend to be along the lines of "why not another when we already have so many?". That's not really a reason. You don't need Savant to be accepted in order to then collaborate to propose the right solution. The "equal footing" argument doesn't make any sense; anyone can come propose a solution that involves some new code & ideas from existing packages, including you. Others with no packages in PEAR have already done this.

The PEAR community is speaking; PEAR Group should listen.

I don't see any overwhelming mandate here. Many developers like your package (I'm sure it's a great package), and they think therefore that it should be accepted. This is irrespective of any vision for PEAR. Hans