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

Hi, There are once again proposals to create some special groups inside PEAR. The obvious problem with such proposals is the fact that PEAR already had such groups and it didn't quite work out. I don't think it'll work this time either and would like to voice my doubts. The main issue with creating a group having a cool sounding name and additional rights (with no additional duties and responsibilities) for its members is the fact that it attracts the wrong kind of people. Namely, people who like to be in groups with cool sounding names and like additional rights. These people also tend to spend quite a bit of time arguing in the mailing lists rather than doing their duties, which aren't clearly defined, anyway. Since Scott Mattocks was really kind to give a perfect example of the proposal that won't work [1], let's dissect it. Sorry, Scott, nothing personal. ========== QA Team Responsibility: Ensure that all proposals and packages are maintained in a timely and effective manner and in accordance with established guidelines. The QA team should establish guidelines defining standards of quality and and what it means to be an active, effective package maintainer. Once these guidelines have been established, the QA team's sole responsibility is to enforce them. The QA team is charged with making sure that packages are up-to-date, as bug free as possible and are maintained by someone that can and is willing to put in the effort needed for the package. The QA team must identify packages and code segments that do not meet PEAR standards of quality or formatting and 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. ========== So what do we see here? [x] cool sounding name [x] additional rights (pestering package developers) 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. 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. 2) Can the problems be solved without creating the group. If the answer is "yes" then use Occam's razor [2]. [1] http://oss.backendmedia.com/PEARThinkTank/index.php?area=PEARThinkTank&page=Scott_Mattocks_Ideas [2] http://en.wikipedia.org/wiki/Occam%27s_razor