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

Hi, Scott Mattocks 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

The maintainer usually doesn't fix bugs for 2 reasons: 1) He is unable to 2) He doesn't want to fix them In case (1) pestering the developer will not solve anything. In case (2) is the QA team expected to know what is a bug and what isn't better than the actual package author?

b) fix them themselves or

If the potential members of the potential QA team can already fix bugs, why aren't they doing it right now?

c) find a new maintainer willing to fix the issues"

This is already covered in "orphaned packages" RFC: http://pear.php.net/pepr/pepr-proposal-show.php?id=192 This RFC does mention some QA team, though, but most of the actions outlined within can be carried out by anyone. They can even be automated.

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.

So you imply that PEAR has a supply of genius developers who are able to dive into the code of any package and fix every bug present? And the only thing that prevents them from doing that now is the fact that they weren't voted in the QA team?

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?

Well, this RFC was obviously needed and thus was written and accepted. I fail to see how this counters my point.

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.

Would it be better if these packages made it into PEAR and started to stagnate there?

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.

You have a point here.

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?

Let's identify the precise issue we are trying to handle here: there are packages with lots of open bugs that are not getting fixed. Let's also note that PEAR's goal is not to "fix bugs in existing packages", but "provide quality reusable components for PHP developers" or something like this. Therefore here are my solutions to the buggy packages problem: 1) Allow competitive packages into PEAR. This will have the following benefits: * If numerous bugs in existing packages are caused by poor architectural decisions, this will allow to start from scratch. * The author of existing package will have an incentive to fix bugs --- possibility of having a competitor. Of course, the new package should be "not worse" than an existing one. *But* a maintained package is also infinitely better than unmaintained. 2) Enforce the "orphaned packages" RFC. This may need some dedicated group of people to do, but they don't need additional rights and can volunteer instead of being voted in. 3) Possibly require documentation and test suites for stable packages. Without these it is almost impossible for people who don't know the packages inside out to fix bugs in them without introducing new ones. *After* these steps are implemented, we may consider creating a dedicated group of people who will care for orphaned packages until a permanent maintainer is found or a better package is accepted and the old one is deprecated.