cvs: peardoc /en/chapters rfcs-entities.xml /en/chapters/rfcs rules-on-rules.xml

http://cvs.php.net/viewvc.cgi/peardoc/en/chapters/rfcs-entities.xml?r1=1.6&r2=1.7&diff_format=u
Index: peardoc/en/chapters/rfcs-entities.xml
diff -u peardoc/en/chapters/rfcs-entities.xml:1.6 peardoc/en/chapters/rfcs-entities.xml:1.7
--- peardoc/en/chapters/rfcs-entities.xml:1.6	Mon May  4 05:31:53 2009
+++ peardoc/en/chapters/rfcs-entities.xml	Mon May  4 17:42:24 2009
@@ -3,4 +3,5 @@
 &chapters.rfcs.header-comments;
 &chapters.rfcs.protected-members;
 &chapters.rfcs.qa-team;
+&chapters.rfcs.rules-on-rules;
 &chapters.rfcs.version-naming;

http://cvs.php.net/viewvc.cgi/peardoc/en/chapters/rfcs/rules-on-rules.xml?view=markup&rev=1.1
Index: peardoc/en/chapters/rfcs/rules-on-rules.xml
+++ peardoc/en/chapters/rfcs/rules-on-rules.xml
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="chapters.rfcs.rules-on-rules"
         xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
>
  <info>
    <title>Rules On Rules And Guidline Proposals</title>

    <abstract>
      <para>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.</para>
    </abstract>

    <date>2004-04-01</date>
  </info>

  <para>
    This RFC has been voted on and accepted in PEPr as
    <link xlink:href="&url.pear.pepr.proposal;39">proposal #39</link>.
  </para>

  <section xml:id="chapters.rfcs.rules-on-rules.issues">
    <title>The issues</title>

    <para>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.</para>

    <para>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.</para>

    <para>To summarize the problem</para>

    <orderedlist>
      <listitem>
        <para>No formal procedure for proposing and approving RFCs has been
        available.</para>
      </listitem>

      <listitem>
        <para>Public RFC's (or ideas) previously have ended up in 'flamewars'
        and pointless discussions.</para>
      </listitem>

      <listitem>
        <para>Long nested threads can become difficult to summarize, when the
        aim is to produce a consensus building document.</para>
      </listitem>

      <listitem>
        <para>This public battering has discouraged contributors to put
        forward ideas to improve PEAR, or even keep subscribing to
        pear-dev.</para>
      </listitem>

      <listitem>
        <para>It is impossible to gauge the community support for rules that
        have been decided and enforced by the pear group.</para>
      </listitem>

      <listitem>
        <para>Without clear wide ranging support, rules, guidelines will never
        represent the view of all users and contributors to PEAR.</para>
      </listitem>
    </orderedlist>

    <para>(RFC = Request for comments) for those who are wondering..</para>
  </section>

  <section xml:id="chapters.rfcs.rules-on-rules.solution">
    <title>The Proposed Solution</title>

    <orderedlist>
      <listitem>
        <para>All RFC's should be proposed using the PEPR system (and hence
        cc'd to pear-dev)</para>
      </listitem>

      <listitem>
        <para>RFC's should be named by prefixed RFC_ to the Wiki style name of
        the RFC (eg. RFC_RulesOnRulesAndGuidlineProposals)</para>
      </listitem>

      <listitem>
        <para>Anyone may comment on the RFC using the PEPR system (or by
        emailing the author directly)</para>
      </listitem>

      <listitem>
        <para>NOBODY SHOULD RESPOND TO COMMENTS ON THE RFC</para>

        <itemizedlist>
          <listitem>
            <para>This includes the author themselves</para>
          </listitem>

          <listitem>
            <para>Repeated abuse by the author may result in RFC being
            rejected</para>
          </listitem>

          <listitem>
            <para>Repeated abuse by others may result in them being
            unsubscribed from pear-dev for 1 week.</para>
          </listitem>

          <listitem>
            <para>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</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>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.</para>
      </listitem>

      <listitem>
        <para>RFC's should take the form of</para>

        <itemizedlist>
          <listitem>
            <para>Title Block Containing</para>

            <itemizedlist>
              <listitem>
                <para>Title</para>
              </listitem>

              <listitem>
                <para>Author (email simply encoded)</para>
              </listitem>

              <listitem>
                <para>Revision</para>
              </listitem>

              <listitem>
                <para>Status (Active|Final|Rejected|Replaced)</para>
              </listitem>

              <listitem>
                <para>Replaces : Name of original RFC (eg.
                RfcProposals1)</para>
              </listitem>
            </itemizedlist>
          </listitem>

          <listitem>
            <para>Introduction (Short ~1-2 paragraphs)</para>
          </listitem>

          <listitem>
            <para>The Issues (Detail discussion of need for RFC)</para>
          </listitem>

          <listitem>
            <para>The Proposed Solution</para>
          </listitem>

          <listitem>
            <para>Actions required if accepted.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>After it has been proposed these section should be added</para>

        <itemizedlist>
          <listitem>
            <para>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</para>
          </listitem>

          <listitem>
            <para>Change log - a summary of the changes made to each
            revision</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>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.)</para>
      </listitem>

      <listitem>
        <para>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.</para>
      </listitem>

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

      <listitem>
        <para>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.</para>
      </listitem>

      <listitem>
        <para>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.)</para>
      </listitem>

      <listitem>
        <para>It is strongly recommended that contentious issues are broken
        out into separate RFCs, so they can be documented, discussed and voted
        on separatly.</para>
      </listitem>
    </orderedlist>
  </section>

  <section xml:id="chapters.rfcs.rules-on-rules.actions">
    <title>Actions Required if accepted</title>

    <para>Changes to the PEPr proposal system:</para>

    <orderedlist>
      <listitem>
        <para>While the current system could be used it would be appreciated
        if the author could add the following features</para>

        <itemizedlist>
          <listitem>
            <para>RFC Category</para>
          </listitem>

          <listitem>
            <para>No requirement for tgz/etc for RFC 'packages'</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Wishlist for PEPr (not essential to use it however).</para>

        <itemizedlist>
          <listitem>
            <para>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</para>
          </listitem>

          <listitem>
            <para>Comments visible on 'a' Summary page, with tags saying "has
            been adressed by updating the RFC", "won't fix"</para>
          </listitem>

          <listitem>
            <para>A licence link on the PEPr system indicating that all RFCs
            are published under the "Open Publication License"</para>
          </listitem>
        </itemizedlist>
      </listitem>
    </orderedlist>
  </section>

  <section xml:id="chapters.rfcs.rules-on-rules.comments">
    <title>Comments</title>

    <itemizedlist>
      <listitem>
        <para>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..</para>
      </listitem>

      <listitem>
        <para>Jon Praise: mentioned Pythons PEPs (Python Enhancement
        Proposals) http://www.python.org/peps/pep-0001.html (some
        modifications made based on this document)</para>
      </listitem>

      <listitem>
        <para>Lukas Smith: mentions that any opinions not incorporated should
        detail the authors reasoning for not including them. (added)</para>
      </listitem>

      <listitem>
        <para>IRC discussions:</para>

        <itemizedlist>
          <listitem>
            <para>RFCs would be created on pedantic issues - like adding
            feature X to a package (see rule on RFC issues)</para>
          </listitem>

          <listitem>
            <para>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)</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Stefan Neufeind: Would like to see notes auto-attached to PEPr
        like : modified Action list to include wishlist.</para>
      </listitem>

      <listitem>
        <para>Toby : Called for volunteers to help out implement Wishlist (see
        mailing list for details)</para>
      </listitem>

      <listitem>
        <para>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.)</para>
      </listitem>

      <listitem>
        <para>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.</para>
      </listitem>

      <listitem>
        <para>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.</para>
      </listitem>
    </itemizedlist>
  </section>
</chapter>