Re: Re: [DRAFT PROPOSAL] PEAR constitution

Hi Anant, Anant Narayanan wrote: > Hi Greg, > >> http://pear.php.net/~greg/constitution.txt > > Looks great for a first draft! Some comments: > > * Why do we actually need a president? What can the role of president > achieve that cannot be done by the PEAR group? IMHO; since the PEAR > group can override a veto by 2/3rds majority; why wait for presidential > approval? Adding one person on the top will delay decision making. The > size of the PEAR group can be increased to 8, and we can do away with > the president. All the responsibilities assigned to the president can be > transferred to the PEAR group (2/3rd majority required to pass an item) In your comments, you are ignoring the primary purpose of the president, which is to do external diplomacy, acting as a liaison with the PHP Group (EXTREMELY important job - they control our CVS, and we are after pear.PHP.net), and also replacing PEAR Group members who vacate mid-term. For most decisions, they will simply be rubber-stamped by the president the instant PEAR Group votes on them. A president who is trigger-happy with veto power will simply be voted out of office (one of the checks on power). Presidential approval could even be easily automated, such that an email is sent to the PEAR president with a link to approve or to veto. It won't delay anything significantly unless there is a reason to delay it, and in that case, we will definitely want a presidential veto. To me, the purpose of a president is obvious when one takes a look at some successful open source projects, even under the PHP umbrella: PECL has Wez Linux has Linus and so on. There is always someone on top, at least "spiritually" if not as a dictator. Until a few years back, PEAR had Stig. Having a benevolent leader is very, very important to getting anything done. Others may disagree with me, but I don't think it would be fair to say that the PEAR Group has achieved anything close to the level of leadership needed to run PEAR. Then take a look at the months since Pierre left and I decided to declare myself transitional PEAR dictator. Here is a short list of projects that have come to fruition that have always been "gee wouldn't that be nice if somebody would do that": - PEAR website statistics are fixed - documentation coverage is available for all packages - PEAR website is now synchronized from a release, opening up CVS to development Now, things that have not yet happened that should have happened 1-2 years ago: - PEAR has no plans for PHP5 beyond an exceptions mandate and an E_STRICT mandate for all new packages - PEAR has not been able to complete documentation - PEAR has not been able to define a clear roadmap of any sort. Obviously, there is a long ways to go before PEAR will be fully functional, but without someone to lead, PEAR becomes a bureaucracy without the ability to pull itself out of a mess, let alone to innovate. > * As for "expediting" important decisions; you can simply require 2/3rd > of the _active_ members in the PEAR group; without waiting for everyone. Forgive my bluntness, this won't work in the real world. How do you define active? With the current PEAR Group, this would mean that if Martin votes for something, it would pass, as he is 100% of the active members! This is not a healthy way to expedite decisions. What if 6 of the 7 members go on vacation, and an important decision comes up, does the 7th member simply decide what to do? With a president, this is a much clearer and more palatable way to handle these situations. Also, because actions taken by the president are by definition emergency, the PEAR Group can easily vote to undo a hasty and poorly executed decision. > * Ditto with the position of Vice president. The idea here is to > decentralize control as much as possible. The PEAR group as a whole > takes all decisions. The previous PEAR Group made decisions, and it took almost a year before Martin managed to commit them to the documentation (thank you Martin - this is no indictment of you or the PEAR Group, only the faults in the structure itself). We need someone who is responsible for things like this. I wrote to allow the position to rotate for this exact reason: being Vice President is more work than being a PEAR Group member. The Vice President is also necessary to fill in for the president. If there is no president, then all we really need is a secretary for the PEAR Group. > * The "collective" idea is great and we should really go ahead with > this. +1 to the mentor idea too. > > An alternative structure: Could you put this up on the web somewhere, with a version? I have several questions. Incidentally, your proposal is surprisingly similar to an early draft of a PEAR Constitution that I was working on with several other devs 2 years ago, it's definitely an option :). Here are the problems that I could not resolve in attempts to define how the government works: > 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. Who decides which packages go into a group? What if there is a dispute (should Console_Getopt go into the command-line parsing group or in the PEAR Installer-related group?), how is that resolved? Are packages allowed to be in more than one group? > 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". What if none of the packages in a group are very actively maintained, and the developers in that package don't want to be active in the government, how do you require them to participate? If one developer has a dispute with the group leader and therefore the group that can't be resolved, who do they appeal to? When do elections happen? How long are terms? Who decides whether a new package is accepted into PEAR? > 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. Who is responsible for granting CVS karma? How about pear website accounts? What about maintenance of the website server itself? I agree that most decisions should be decentralized that are currently centralized, the collectives idea is designed to do exactly what you are suggesting. However, I don't think that each collective should be responsible for sweeping decisions like overall QA requirements changes as PHP evolves (for instance, how exceptions are handled), and I don't think that a large PEAR Group will be able to make unpopular (but necessary) decisions. Most important, the PEAR Group had a majority of inactive members because there was no real pressure to do anything. For most of the package groups/collectives, there will be 1 or 2 super-active developers who will likely be elected to serve, with little chance of a replacement. In addition, the representative democracy you're proposing work in my country (USA) only because we have a supreme court to define how legislation works, and a president who can say "no way jose" to extremely divisive bills passed by a slim majority. In any case, if you feel strongly about your proposal, please put it in web page format, so that it can be easily voted on. Thanks for participating in this one, Greg