RFC - Rules on 'Rules and Guideline Proposals.

I will not respond directly to comments on this - just update the documenent based on comments recieved.. (it is the first of 2 proposals that came out of discussions during the php|cruise) RFC - Rules on 'Rules and Guideline Proposals. ----------------------------------------------- Due to recent events in the way that regulations have been proposed -the following is put for comment on the future method for introducing new rules, or guidelines into the pear community. The Issues ---------- For PEAR to continue to grow, and encourage contributors, testers, writers and users. It is important (in the view of the RFC author) to make the decision process within PEAR to be as open and fair as possible. Due to historical issues of long, rather pointless, and heated discussions on the pear-dev mailing list, certain people have prefered to use the pear-group 'private' mailing group to start the process of rule changes. This, (in the view of the author of this RFC) is something that is a serious mistake and must strongly be prevented in the future. To summarize the problem * Public RFC's previously have ended up in 'flamewars' and pointless

     discussions.

* This public battering has discouraged contributors to put forward

     ideas to improve PEAR.

* It is impossible to guage the global support for Private RFC's on

     the pear group

* Private RFC's will never represent the view of all users and

     contributors to PEAR.

The Proposed Solution. ---------------------- * All RFC's should be proposed using the PEPR system (and hence cc'd

     to pear-dev)

* Anyone may comment on the RFC using the PEPR system (or by

     emailing the author directly)

* NOBODY SHOULD RESPOND TO COMMENTS ON THE RFC (including the

     author) - repeated abuse may result in being unsubscribed from
     pear-dev for 1 week. (the only response an author may make is to
     update the RFC)

* The RFC Author should update the RFC based on the comments

     recieved to represent the opinions in the document.

* RFC's should take the form of

         o Introduction
         o The Issues
         o The Proposed  Solution
         o After it has been proposed - a summary of the opinions on
           the RFC (if they are not represent in the updated 'issues')
         o Actions required if accepted.

* RFC's may under go any number of revisions, and put to vote

     (normally after a new revison of the RFC has been issued via PEPR,
     and no comments where added.)

Actions Required if accepted. ----------------------------- Changes to the pepr proposal system: * While the current system could be used it would be appreciated if

     the author could add the following features
         o RFC Category
         o No requirement for tgz/etc for RFC 'packages'
         o BIG warning messages on the bottom of package comments
           should say 'DO NOT EVER RESPOND TO THIS COMMENT - update
           your package, package description or RFC to reflect these
           opinions'
         o reply to address on comments messages should be
           idiot@localhost!!

---------------------------------------------------------- (RFC = Request for comments) for those who are wondering.. Regards Alan -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com