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

Hi, Scott Mattocks wrote:

And no additional duties! Seriously, what prevents anyone from establishing guidelines? PEPr is available and open to anyone. What prevents anyone from fixing bugs? Bug tracker is there and packages' source is available.

A lot of things prevent people from fixing bugs. Among them are fear of stepping on other peoples toes,

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

lack of ability,

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

lack of understanding of a package,

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

or pride.

Don't quite get it, please clarify.

A team dedicated to putting all these things aside and trying their best to make packages better is all I am asking for. Nothing prevents others from establishing guidelines but that doesn't mean it gets done. Why? Because no one is held accountable for getting it done. Everyone says, "Eh, someone else will write that up." And we end up with an out of date CS and no clear picture of what needs to be done.

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

So I suggest that anyone wanting to propose a new "team", "group" and / or "core" first answer these obvious questions: 1) What problems is the group intended to solve and what clearly defined duties will it have.

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?

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.