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

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