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, SVN 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 SVN 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.