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

Alexey Borzov wrote:

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?

In case (1) the QA team should proceed to b). In case (2), simply not wanting to fix a bug is a problem. The QA team needs to be able to take the appropriate steps to resolve the issue. This may mean making a change to another developer's code and even making a release of a package. It's an ugly situation but at time it may need to be done. And yes, six people looking from the outside can know what is a bug better than one person on the inside.

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.

But this doesn't get done. And I strongly feel that if the QA team was renewed on a regular basis, it would get done. The people responsible would still have the desire to do the job they volunteered to do.

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?

I am not trying to imply anything. I am trying to state that PEAR is made up of some of the greatest minds in the PHP community and yes, we can dive into any package and fix every bug. And with community given rights and responsibilities it will get done. Without community given consent, we will end up with maintainers sitting on patches and refusing to implement fixes which are in the best interest of the community. And I do believe that a team of people can know what needs to be fixed better than the package author. Peer review is essential to driving quality.

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?

It would be better if there was a group of people who have devoted their time to help get these packages through (or taken out of) the system. If we have people helping new developers to move their ideas from draft proposals to fully functioning, high-quality packages then quality will move in a positive direction.

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.

I completely agree with the goal of PEAR, but I think you have lost focus on what I am proposing. I am not proposing that we fix all issues this week. I am proposing that we put into place a structure and process that will empower others to help move PEAR in a positive direction and hold them accountable for what they say that they will do. A result of this structure and process will be an increase in the quality of packages that make up the PEAR project.

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.

I disagree about allowing competitive packages, but that will open up a can of worms so lets talk about that later if that's OK.

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.

In my proposal, all team members are people who have volunteered. The vote is to allow the community to say who they trust to take on these responsibilities. I don't want just anyone that volunteers to go messing with my packages, and I am pretty sure you feel the same way.

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.

This is already a requirement: http://pear.php.net/manual/en/developers.contributing.php But again, those responsible for enforcing it have lost interest. Scott