Proposal for "RFC_RulesOnRulesAndGuidlineProposals"

» Metadata	» Status
Category: RFC Proposer: Alan Knowles License:	Status: Finished Result: Accepted Sum of Votes: 10 (0 conditional) Search registered package
» 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 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. Long nested threads can become difficult to summarize, when the aim is to produce a consensus building document. 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) RFC's should be named by prefixed RFC_ to the Wiki style name of the RFC (eg. RFC_RulesOnRulesAndGuidlineProposals) Anyone may comment on the RFC using the PEPR system (or by emailing the author directly) NOBODY SHOULD RESPOND TO COMMENTS ON THE RFC 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. 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. 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. 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 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 revision 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 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.) 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: 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 do_not_reply@localhost 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" 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. 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 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 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
	PEAR package file (.tgz) Package source file (.phps/.htm)
» Timeline	» Changelog
First Draft: 2004-03-23 Proposal: 2004-03-23 Call for Votes: 2004-04-01