PEAR Group - Administrative Documents
» Handling Package Proposals
Important note: The information provided in this document has been superseded by the web-based proposal interface PEPr. Details on the proposal process are explained in the New Maintainers' Guide that is part of the PEAR manual.
Published: 04th September 2003
Proposed packages cannot be released without going through the following process. Packages found to be in violation will be summarily removed. We plan to incorporate the actual voting into a web interface to simplify the rights management and counting aspects.
Initial Proposal
In order to make a proposal anyone can mail the pear development list with the details of his proposal. It is expected that the proposer reviews other similar packages in PEAR which cover similar functionality and state where the differences lie and provides links to the source code of the package as a .phps file(s) along with examples of how to use that code to enable code review (note: in rare cases exceptions can be made to the source code regulation however especially for newcomers it will be very unlikely that a proposal is accepted without some initial code).
Calling for a vote
After some discussion on the list the proposer can "call for a vote" by sending a mail to both the PEAR developer list and the PEAR group list. In this period the actual voting will take place. The proposer should only do this once he/she feels confident that people have agreed on a package name. After one week following that request the vote is closed and the results are tallied up.
Votes
Only the votes of active members of the PEAR community (must have a pear web account, however the proposer himself is not counted) are counted, however anyone may vote. Votes require that a final choice of package name is specified.
The votes are added up, which means that one -1 offsets a +1. However -1 vote should always be considered to be serious and may lead to decisions being made on a case by case basis by the PEAR Group who reserves a veto (it is intended that in the future the PEAR QA team will assist the PEAR Group in such situations). Therefore a -1 vote *must* contain a comment explaining that decision, it is desirable that votes in favour (+1) should also be accompanied with an explanation when appropriate.
It is also expected that every voter make the level of review clear in the vote and that every voter at least skim all provided information from the proposer (especially if code/examples are provided).
Conditional votes
Conditional votes are not to be counted as final votes, instead they serve to show what conditions have to be met. It's up to the voter to decide in the end of the conditions have been met and make a final vote. It should be made very clear that it is a conditional vote to avoid confusion.
Voting Results
A vote is accepted if the total of all votes exceeds +5.
In case the proposal is not accepted the package can be further discussed on the list and the proposer may attempt to make another "call for vote" (it is expected that this is only done for sensible reasons).
In case the proposal is accepted the package may be registered by the proposer and a mail should be send to the PEAR Group (it is intended that in future the PEAR QA team will handle this) who will then set the package as approved (however the PEAR Group reserves final judgement).
In order for the PEAR Group to approve a package the person who made the proposal should include in the email to the PEAR Group list all relevant information (package name, license, category, type summary, full description, project homepage, links to all votes in the mailinglist archive etc.)