By submitting PHP Resources you own, or know of, you'll help us build the largest PHP Resource website on the net. Please double check that your resource doesn't already exist before you submit it!!. We thank you for helping make this a better website.
All collective members have full commit access and can commit minor
bugfixes without requesting permission or notifying lead developers.
However, as a courtesy, it is expected that all developers will communicate
with a package's lead developers prior to taking action.
If a dispute over a commit arises, it is also expected that the commit
in question will be reverted pending a review.
This rule is intended to encourage open and friendly collaboration. For an example of this commit model, the PHP project developers often commit minor fixes for thread-safe errors, spelling mistakes, and other obvious mistakes without consultation.
Exceptions can be made to this rule with explicit PEAR Group approval documented on the website.
All design decisions should be discussed freely in a Collective, and
each Collective is responsible for enforcing these decisions in
their own way. Some Collectives may require packages to adhere to basic
interfaces, others may require common data storage formats, but
individual package maintainers must adhere to these decisions or
discuss ways of improving them. No cowboy coding!
Ultimately, individual package developers have the full freedom
to innovate without expecting too much interference, but are expected
to learn how to both give and receive constructive criticism as a part
of the privilege of having their code hosted at pear.php.net.
All collective members can pull a release within 24 hours if there is
a major regression or security bug. If at all possible, the primary lead
maintainers should perform this action, but Collectives function as a
unit, and have the role of policing huge problems.
Competing packages are allowed at the alpha level in PEAR2.
All alpha/devel stability packages have no claim to a package name.
If a better package comes along that does the same thing, wants your
package's name and achieves beta status, you have to either join forces or
change the name of your package. The limit is that newer packages have to
be unarguably better in implementation. It is up to the Collective to
define "unarguably better"
To become beta, a package must undergo extensive review.
documentation must be complete.
full test suite must demonstrate 50% code coverage
API must be approved by 2/3 of the collective developers
(this will probably be a blanket stamp for most packages)
all developers in a collective (including alpha package
maintainers) can vote on whether a package is ready for
beta status
a final name for the package must be chosen by the
lead developers of the package that does not conflict with the
existing beta+ packages. Names are chosen on a
first-come-first-serve basis.
Packages can be proposed either as 1) A completed, or relatively complete
package to Pepr 2) A concept, or proof-of-concept to
svn.pear.php.net/PEAR2/sandbox For proof-of-concept packages they should
Post a public notice to the pear-dev mailing list stating
the intention to begin development.
Request a new package be created on the pear.php.net website
Undergo a review by the collective (as defined in the previous
section) when ready to move from alpha to beta stability
Once the review is complete, the package developers may request
an official vote by the collective on whether the package is ready.
The vote is conducted through PEPr. Unsuccessful packages may request
a second review after fixing issues noted by the collective.
Successful packages may then move their development directly
from svn.pear.php.net/PEAR2/alpha into svn.pear.php.net/PEAR2
using svn move.
