The Proposed Solution

1. All RFC's should be proposed using the PEPR system (and hence cc'd to pear-dev)

2. RFC's should be named by prefixed RFC_ to the Wiki style name of the RFC (eg. RFC_RulesOnRulesAndGuidlineProposals)

3. Anyone may comment on the RFC using the PEPR system (or by emailing the author directly)

4. NOBODY SHOULD RESPOND TO COMMENTS ON THE RFC

   • This includes the author themselves

   • Repeated abuse by the author may result in RFC being rejected

   • Repeated abuse by others may result in them being unsubscribed from pear-dev for 1 week.

   • If you have a need to repond to responses - please email the author and the original respondant (not the list). - a summary of this discussion should be noted in the RFC

5. The RFC Author should update the RFC based on the comments received to represent the opinions presented. Either by updating the solution, or explaining differing opinion in the Comments section.

6. RFC's should take the form of

   • Title Block Containing

     • Title

     • Author (email simply encoded)

     • Revision

     • Status (Active|Final|Rejected|Replaced)

     • Replaces : Name of original RFC (eg. RfcProposals1)

   • Introduction (Short ~1-2 paragraphs)

   • The Issues (Detail discussion of need for RFC)

   • The Proposed Solution

   • Actions required if accepted.

7. After it has been proposed these section should be added

   • Comments - a summary of the opinion made about the RFC (if they are not represent in the updated RFC) Along with why the author has not included them in the Solution

   • Change log - a summary of the changes made to each revision

8. RFC's may under go any number of revisions, and put to vote (normally after a new revision of the RFC has been issued via PEPr, and no comments where added.)

9. Initial drafts of RFCs may be developed in private or in small groups. Once the RFC reaches a point nearing maturity, it should be made public (on the pear-dev mailing list) for comment.

10. All RFC's will be licenced under "Open Publication License" http://www.opencontent.org/openpub/

11. RFC's should not concern themselves with specific packages, or the addition of specific features. This should be done by discussions directly with package maintainers, or proposing competing packages.

12. PEAR group was set up to oversee PEAR, it's continued existance relies on support from the community, It is intended that the group is to have the power of veto over all proposals (however it well understands that continually doing this would seriously undermine its own authority, and veto should only occur in extremely serious situations.)

13. It is strongly recommended that contentious issues are broken out into separate RFCs, so they can be documented, discussed and voted on separatly.