Proposal for "RFC_RulesOnRulesAndGuidlineProposals"

» Metadata » Status
» Description
Title: RFC - Rules on 'Rules and Guideline Proposals.
Author: alan at akbkhome dot com
Revision: 3
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

  1. No formal procedure for proposing and approving RFCs has been
  2. Public RFC's (or ideas) previously have ended up in 'flamewars' and
    pointless discussions.
  3. Long nested threads can become difficult to summarize, when the aim
    is to produce a consensus building document.
  4. This public battering has discouraged contributors to put forward
    ideas to improve PEAR, or even keep subscribing to pear-dev.
  5. It is impossible to gauge the community support for rules that have
    been decided and enforced by the pear group.
  6. Without clear wide ranging support, rules, guidelines will never
    represent the view of all users and contributors to PEAR.

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)

    o This includes the author themselves
    o Repeated abuse by the author may result in RFC being rejected
    o Repeated abuse by others may result in them being unsubscribed
    from pear-dev for 1 week.
    o 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
  6. RFC's should take the form of

    o Title Block Containing

    * Title,
    * Author (email simply encoded)
    * Revision
    * Status (Active|Final|Rejected|Replaced)
    * Replaces : Name of original RFC (eg. RfcProposals1)

    o Introduction (Short ~1-2 paragraphs)
    o The Issues (Detail discussion of need for RFC)
    o The Proposed Solution
    o Actions required if accepted.

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

    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
    o 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" />
  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
  13. It is strongly recommended that contentious issues are broken out
    into separate RFCs, so they can be documented, discussed and voted
    on separatly.

Actions Required if accepted.

Changes to the PEPr proposal system:

  1. 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'

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

    o BIG warning messages on the bottom of package comments
    author will update the RFC to reflect these opinions'
    o reply to address on comments messages should be
    o Comments visible on 'a' Summary page, with tags saying "has
    been adressed by updating the RFC", "won't fix"
    o A licence link on the PEPr system indicating that all RFCs
    are published under the "Open Publication License"

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.
Revision 3 : 24 March 2004
- changed suggested email address (Martin Jansen)
- clarified Comments on Comments notes (Lukas et al)
- Added naming standard for PEPr/ID (Lukas)
- typos (Jason Rust)
- Added note about Contentious issues

* 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) (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 pedantic 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 concequences (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 volunteers 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 volunteering to do it.)
* Ian Eure, Lukas Smith: Commented on the varying views about Comment on
comments. (While the rule is not intended to restrict open discussion,
it is there to focus comments on the issue at hand, helping the RFC author
gather views for the document.) - The document has been updated a bit
to clarify this issue.
* Lukas Smith: copyright note - have added that to the wishlist for PEPr.
- It's a bit silly to add it to each document if we can do it via PEPr.

(RFC = Request for comments) for those who are wondering..
» Dependencies » Links
» Timeline » Changelog
  • First Draft: 2004-03-23
  • Proposal: 2004-03-23
  • Call for Votes: 2004-04-01