| What is the purpose of this document? (Previous) | (Next) PEAR Group Administrative Documents | ||||
| |
|||||
|
|||||
Official Constitution
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 constitution. 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.
IVa. Vice President responsibilities
Post PEAR Group decisions on the web site, and add them to official documentation if necessary. Decisions are not binding until documented on the website.
Stand in as president until the next election if the president resigns, or is otherwise unable to serve.
Appoint a replacement on the PEAR Group if he/she becomes president
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.
Website Administrators responsibilities (as part of website collective)
Approve/Deny new pear.php.net account requests
Manage karma requests for existing accounts
Pull invalid releases (QA)
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.
| What is the purpose of this document? (Previous) | (Next) PEAR Group Administrative Documents | ||||||||
| |
|||||||||
|
|||||||||