An alternative structure:

Create a set of groups within PEAR that consist of a similar set of packages (eg: the Web Service Group; the Math Group; the Gtk Group). This is _not_ the same as PEAR categories; two or more categories may be clubbed to form one group. Ideally; we have around 10-15 such groups of 30-40 packages each.

A "group lead" is elected by all developers involved in packages belonging that particular group. A developer votes for a particular group only once; however may vote in different groups as long he/she is a part of it. All group leads automatically make up the PEAR group. Yes, this will increase the size of the PEAR group, but then; why not? This way we ensure equal representation of all aspects of PEAR and keep the group "rolling".

A similar system for the "group QA lead"; and all group QA leads make up the PEAR QA team. Each group QA lead is responsible for the quality of all packages in his/her group.

This encourages a decentralized and healthy environment.

Hoping that the year of PEAR is a grand success :)

Cheers,
-- 
Anant