RFC - Rules on 'Rules and Guideline Proposals. Rev.2

Ok. Final Draft (hopefully)- speak now or forever hold your peace... Title: RFC - Rules on 'Rules and Guideline Proposals. ------------------------------------------------------ Author: alan at akbkhome dot com Revision: 2 Status: Active 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 standards, rules, conventions, recommendations 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, Some rules have been made in the privacy of the pear-group mailing lists with little consultation with the community at large. 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 * No formal procedure for proposing and approving RFCs has been

     available.

* Public RFC's (or ideas) previously have ended up in 'flamewars' and

     pointless discussions.

* This public battering has discouraged contributors to put forward

     ideas to improve PEAR, or even keep subscribing to pear-dev.

* It is impossible to gauge the community support for rules that have

     been decided and enforced by the pear group.

* Without clear wide ranging support, rules, guidelines 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 by the author may result in RFC being
     rejected), or the culprit 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 presented. Either by updating
     the solution, or explaining differing opinion in the Comments
     section.

* RFC's should take the form of

         o Title Block Containing

Title, Author (email simply encoded) Revision Status (Active|Final|Rejected|Replaced) Replaces : (ID of original PEPR RFC if appropriate)

         o Introduction (Short ~1-2 paragraphs)
         o The Issues   (Detail discussion of need for RFC)
         o The Proposed Solution
         o Actions required if accepted.
     After it has been proposed
         o 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

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

* 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.)

* 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.

* All RFC's will be licenced under "Open Publication License"

     http://www.opencontent.org/openpub/

* 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.

* PEAR group was set up to oversee PEAR, it's continued existance

     relys 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.)

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'

* Wishlist for PEPr (not essential to use it however).

         o BIG warning messages on the bottom of package comments
           should say 'DO NOT EVER RESPOND TO THIS COMMENT - the RFC
           author will update the RFC to reflect these opinions'
         o reply to address on comments messages should be
           idiot@localhost!!
         o Comments visable on 'a' Summary page, with tags saying "has
           been adressed by updating the RFC", "won't fix"

Changelog --------- Initial Release : 8 March 2004 Revision 1 : 9 March 2004 - add 'standards, conventions, recommendations' - add note concerning private discussions of RFCs. - changed order of RFC sections (added some notes) - added Changelog - formalized Comments section - change the issue paragraph describing the current pear-group define/solve/approve process - tidied up Issues slightly - added notes about commenting on package features - added veto power of pear-group. Revision 2 : 12 March 2004 - typo on jon's name - split actions into actions and wishlist - more comments. Comments -------- * Greg Beaver: main comment added, "Poorly thought-out RFCs should not be made public." - was not added as it was considered obvious... and a little difficult to define.. * Jon Praise: mentioned Pythons PEPs (Python Enhancement Proposals) http://www.python.org/peps/pep-0001.html (some modifications made based on this document) * Lukas Smith: mentions that any opinions not incorporated should detail the authors reasoning for not including them. (added) * IRC discussions: - RFCs would be created on pendantic issues - like adding feature X

     to a package (see rule on RFC issues)

- how should Pear-group be involved in a proposal / approval.. what

     if in a whim of chaos it decided to add support for GPL packages
     without understanding the concequnces (see pear-group veto)

* Stefan Neufeind: Would like to see notes auto-attached to PEPr like : modified Action list to include wishlist. * Toby : Called for voluteers to help out implement Wishlist (see mailing list for details) * Richard York: Asked for automated tracking of responses to Comments - so they get appended to PEPr. (while nice, I'm not sure this is directly related to the RFC, and really depends on someone voluteering to do it.) ---------------------------------------------------------- (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 -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com