I. Governing structure (who runs things in PEAR?)

• One elected president

• An elected PEAR group of 7 developers

• Collectives of related packages

• Each package has developers assigned to the package

• Extra-governmental technical gurus - these people have shell access on the pear.php.net website, CVS karma for everything, and generally can do things that others cannot do.

II. Checks and balances

• Inactive collectives will be handled by the PEAR Group

• PEAR Group members have a term of 1 year, renewable indefinitely through election by PEAR developers

• PEAR president may be impeached by a 2/3 vote (5 votes) of the PEAR Group

• PEAR president may veto decisions from PEAR Group within 1 month of PEAR Group vote

• PEAR Group may override presidential veto with a 2/3 vote (5 votes) within 1 month of presidential veto

• PEAR president has a 1 year term, renewable indefinitely through election by PEAR developers

• This document may be amended by referendum (election)

• Any responsibility may be delegated as necessary, as long as the delegation is clearly and prominently documented at pear.php.net

III. President responsibilities

• Liaise with PHP Group

• Liaise with external projects/funders

• Promote PEAR as a repository, be the public voice of PEAR

• Approve or veto decisions from the PEAR Group

• Call elections through the web site

• Appoint committees to solve pressing problems, if approved by PEAR Group

• Appoint temporary handlers (people or groups of people) to solve emergency problems (problems with 24 hour to 1 week time frame)

• Recruit specific developers from outside of PEAR to enhance PEAR's quality

• Appoint people to fill temporary vacancies on PEAR Group until election can be held

IV. PEAR Group responsibilities

• Choose 1 member of the PEAR Group to act as vice president, who will stand in as the president if the president is incapacitated in some way (i.e. on vacation, or more serious issues). This position may rotate.

• Create and vote on actual language for all official PEAR policy that affects more than 1 collective (simple majority approves policy)

• Resolve disputes between collectives or between individuals and collectives

• Grant CVS karma requests

• Handle inactive collectives (either demote all packages to unmaintained, re-assign developers, or other logical solutions)

• Call elections through the web site

• Promote PEAR as a repository (working with the president as much as makes sense)

• Define coding standards

• Resolve larger licensing and legal issues (working with the president as much as makes sense)

• Define what constitutes a Collective (how to define it - categories? Related packages only?) and make final decisions about which collective a package should go in

• Document all communications and archive them, either through email list or some other publicly accessible format like a forum or wiki - the first elected PEAR Group should decide how to do this and amend the consitution. The PEAR Group may occasionally choose to hold secret communications until a bill is voted on, and then the communications must be made public. A summary of communications is acceptable, and should at the least document topics debated and alternatives to the final decision.

V. Collective responsibilities

• Create actual language for all official PEAR policy that only affects the collective

• Choose a person or persons who will liaise with the PEAR group. No restrictions are placed upon how to do this, each collective may decide internally

• Define and enforce API compatibility (self-police)

• Enforce Coding Standards as defined by the PEAR Group

• Enforce documentation creation. This can be done by outsourcing to volunteers, but it must be done for all packages in a collective.

• Define clear, public guidelines on code access (who has commit access to which packages, and what is acceptable boundaries).

• Self-promote the collective as a whole (this is non-restrictive, each collective should do this in their own way)

• Assign "mentors" for new developers in the collective (specific developers who are available through email/chat to answer questions of developers new to PEAR)

• Collectives are encouraged but not required to directly contact and collaborate with other collectives.

VI. Developer responsibilities

• Define package roadmap

• Fix bugs, implement new features

• Adhere to the collective requirements (documentation, allowing QA commits/releases)

• Package releases

• Meet coding standards

• Appeal to the collective if there are any package-related questions or technical issues

• Appeal to the PEAR Group if there are disputes with the Collective that cannot be resolved in the Collective.

VII. Extra-Governmental technical gurus responsibilities

• Accept the will of the developers: no changing election results, improper abuse of power or other evils that jeopardize the legitimacy of PEAR.

• Quick database fixes, upgrade of the PEAR database when changes are needed

• Cron job administration

• Details of who these people are, their karma, and their tech powers should be clearly and prominently displayed at pear.php.net

IX. Website Collective

The Website Collective is a special collective, consisting of developers with pear.admin karma (Website Administrators), and developers who contribute to and maintain the actual infrastructure code for pear.php.net.

Communication

pear-dev@lists.php.net (or php.pear.dev newsgroup) remain the official channels for all PEAR communications. Specific enhancements to the website may of course be created in the future to facilitate better communication.