Re: why creating "teams", "cores" and "groups" won't work this time, either

LOL Doesnt this duel confound the point Scott was making initially. Who actually says YES - Scott that is a great idea run with it, or NO stop wasting yours and everybodies elses time ?? If we are going to have a group created please make it one where people have the power to say YES and in a timely manner, the trouble is it takes too long to get a spark lit, most of the time you are left waiting like a lemon with a sour taste brewing. I havent got PEPr permissions and will not get them for just wanting to start ideas, I.e. I really liked the competition idea to get the site and concepts looked at by NON-PEAR people, I thought this was a no-brainer - Bertrand disagreed and the idea seems to have been shelved. The trouble is I cant just go ahead and do this as who is to say the winner's ideas will be implemented, probably be a 6 month discussion as to what colour to go for. My company has currently hacked nearly every Package we use, we have multiple extensions for quickforms, templates, paging DO etc. I would submit more patches but they just dont seem to get a response, so why waste my time really. I must apologise to Markus Tacker he let me into his Google Map Trac system almost instantly on a new branch, but the project I was doing with that got canned, so I havent helped as much as I could, but when time permits I would still like the opportunity to do that and I think that is still there. You know what would be cool is if I could just branch the package and then implement in PEAR also, the owner of the package could then see the this and no work is done except following a set branch if they choose. I reckon OPEN PEAR up to allow people to do this. I see so many packages where Coding Standards are not even applied - how they ever got past this is a wonder, I thought this was one of the main issues PEAR stood for. Is PEAR elitist seems to be a common question, but only a few know the answer :) Scott Mattocks wrote:

Alexey Borzov wrote:

Let's clarify here: QA team is expected to make changes to the package without package maintainers' approval?

From the Wiki page: "a) get the maintainer to fix them in a timely manner b) fix them themselves or c) find a new maintainer willing to fix the issues" I fully expect the QA team would proceed down the that list in order.

lack of ability,

Forming of QA team will magically raise the ability of its members?

The members of the QA team (whose responsibility it is to fix bugs) hopefully will have the ability to dive into code and figure out how it works. If they don't have that ability, then we as a community did a pretty poor job when casting votes.

lack of understanding of a package,

Forming of QA team will magically improve understanding of packages among its members?

The members of the QA team should be able to wrap their minds around pretty much any package. If they don't have that ability, then we as a community did a pretty poor job when casting votes.

or pride.

Don't quite get it, please clarify.

Some people refuse to fix bugs because they refuse to admit they made a mistake. We are all guilty of it at times.

Or maybe because these guidelines are not needed by anyone? You know the open source motto of "scratching one's own itch"?

If they weren't needed we wouldn't have large discussions about whether or not protected member vars should be prefixed with '_'. Are you really saying that we don't need a coding standard that stays up-to-date?

The QA group is designed to fix the declining level of quality in PEAR packages.

Oh, so this level is declining? Undoubtedly you have at least *some* facts to back up this statement?

I would say that the percentage of proposals that actually make it through to the voting phase is an indication of the declining level of quality. We get a bunch of almost implemented ideas that just stagnate. I'd also point to the number of package that never make it to a stable release as another indicator of low quality. I also think that the number of bugs that have been open for over three months is an indicator of declining quality. If you think open for only three months is too short of a time period, how about open for six months or over a year? None of those numbers are going down.

2) Can the problems be solved without creating the group. If the answer is "yes" then use Occam's razor [2].

If it could, we wouldn't have these problems now, would we?

We do have problems, but repeating past mistakes is the wrong answer.

And just giving up is the answer? I am trying to build on what worked before while fixing the things that didn't. What is your plan for resolving these issues? Thanks, Scott