cvs: peardoc /en/chapters rfcs-entities.xml rfcs.xml /en/chapters/rfcs qa-team.xml

http://cvs.php.net/viewvc.cgi/peardoc/en/chapters/rfcs-entities.xml?r1=1.3&r2=1.4&diff_format=u
Index: peardoc/en/chapters/rfcs-entities.xml
diff -u peardoc/en/chapters/rfcs-entities.xml:1.3 peardoc/en/chapters/rfcs-entities.xml:1.4
--- peardoc/en/chapters/rfcs-entities.xml:1.3	Sun May  3 16:56:43 2009
+++ peardoc/en/chapters/rfcs-entities.xml	Sun May  3 17:24:31 2009
@@ -1,3 +1,4 @@
 &chapters.rfcs.error-handling;
 &chapters.rfcs.header-comments;
+&chapters.rfcs.qa-team;
 &chapters.rfcs.version-naming;
http://cvs.php.net/viewvc.cgi/peardoc/en/chapters/rfcs.xml?r1=1.1&r2=1.2&diff_format=u
Index: peardoc/en/chapters/rfcs.xml
diff -u peardoc/en/chapters/rfcs.xml:1.1 peardoc/en/chapters/rfcs.xml:1.2
--- peardoc/en/chapters/rfcs.xml:1.1	Sun May  3 12:50:12 2009
+++ peardoc/en/chapters/rfcs.xml	Sun May  3 17:24:31 2009
@@ -9,9 +9,13 @@
   <partintro>
     <para>
       Request for comments are normative documents
-      about how PEAR works. RFCs get proposed through the PEAR's
+      about how PEAR works. RFCs get proposed through PEAR's
       <link xlink:href="&url.pear.pepr;">PEPr system</link>.
     </para>
+    <para>
+     All RFCs listed here have been accepted by the PEAR developers though
+     PEPr voting.
+    </para>
   </partintro>
  
 &chapters.rfcs-entities;

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

    <abstract>
      <para>There has been talked about forming QA team, but no action yet
      taken. The following is proposal of how the QA team will work, what
      rights they have and so on.</para>
    </abstract>

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

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

  <section xml:id="chapters.rfcs.qa-team.issues">
    <title>Current issues</title>

    <para>There is no official QA team for PEAR. There are only a few people
    who try to help with QA issues but they don't have any official status or
    rights to resolve issues themselves if needed. PEAR claims quality but
    that can't be met if there is no real QA team. PEAR group has been talking
    about fine tuning karma for all users so the current "user has access to
    everything under /pear in cvs" karma policy will be eliminated and thus QA
    needs special karma when that happens. More importantly, there is
    currently no formal process or entity to handle orphaned packages or
    urgent fixes to packages.</para>

    <para>To summarize the problem:</para>

    <orderedlist>
      <listitem>
        <para>No QA team = can't claim Quality</para>
      </listitem>

      <listitem>
        <para>Nobody has defined how the QA team is supposed to work, how it
        should be structured and what its rights (karma) are supposed to
        be.</para>
      </listitem>
    </orderedlist>
  </section>

  <section xml:id="chapters.rfcs.qa-team.membership">
    <title>QA team membership</title>

    <section>
      <title>How the initial members are chosen</title>

      <para>If there are more applicants than seats, there should be an open
      election, where everyone may cast as many votes as there are seats (only
      1 vote may be cast per candidate). Of course, if there are less people
      than seats, all may be accepted and the remaining seats can be filled by
      QA group vote. Once the core team is formed all further team members can
      be voted in as per the rules stated below.</para>

      <para>There will be a QA core team with a limited number (no more than
      7, with the pear group this should give a sufficient amount of people
      with enough karma that can react to bad releases) people with extended
      "core-QA-karma". In order for the QA core team to react quickly, the
      core QA team should be spread out across all time zones as good as
      possible. This rather small number should empower the QA team
      sufficiently to handle issues but doesn't trivialize access
      rights.</para>

      <note>
        <para>This issue needs more discussion since Klaus raised a <link
        xlink:href="http://news.php.net/article.php?group=php.pear.dev&amp;article=26756">good
        point in his post</link> but the problem is that it isn't wise to give
        many users so much karma.</para>
      </note>

      <para>All other people interested are free to join the QA team. However
      potential new members for the QA team (core and non core) must be voted
      in by a 2/3 majority of the existing members of the QA team (core and
      non core). This is to prevent that the addition of new members is done
      even though there is a considerable amount of opposition, as this could
      lead to internal quarrels which could result in reducing the QA teams
      ability to efficiently address QA issues. Removing a member from either
      group requires a 2/3 majority as well.</para>

      <para>For casual helpers the QA mailing list will of course remain
      open.</para>

      <para>All members of the QA team (core and non core) are eligible to
      participate in QA team votes.</para>

      <para>Any member that leaves the QA team loses all his special karma
      which he may have received due to his membership. If any member of the
      core QA team leaves and as a result a time zone gets under staffed, QA
      should actively try to find a replacement.</para>

      <note>
        <para>When voting for a new member voters must be sure that the person
        has been helping with bug fixes in the past or has the potentials to
        help with that.</para>
      </note>
    </section>
  </section>

  <section xml:id="chapters.rfcs.qa-team.voting">
    <title>Voting</title>

    <para>All votes (except membership related votes; see above) require a
    simple 50% majority. Any member of the QA team may call for a vote at any
    time. All voting is done on the QA mailinglist.</para>

    <para>The core team may overrule any decision (this includes votes on
    memberships) of the QA team and may decide to hold their own internal vote
    to make the ultimate decision on how to proceed. Furthermore, the core QA
    team may also hold votes without even consulting the QA team. However this
    should be only done in rare cases. All members of the core QA team may
    make decision on their own if a decision is time critical (like pulling a
    broken release). However the core QA team should be aware that making too
    many decisions on their own may lead to alienating the other members and
    therefore if possible it should always be attempted to at least consult
    other members of the team.</para>
  </section>

  <section xml:id="chapters.rfcs.qa-team.rights">
    <title>QA rights/responsibilities</title>

    <section xml:id="chapters.rfcs.qa-team.rights.fixrelease">
      <title>Fixing bugs/making releases</title>

      <para>If any QA related issues are found in a package that QA has not
      been granted permission to change without consulting the maintainer,the
      QA team will file a bug report. If the issue remains unresolved for 1
      month (2+1+1 weeks; see below), QA may fix it themselves.</para>

      <para>If the issue isn't fixed with in two weeks QA will email the
      maintainers about the issue (if the bug system won't have auto bug
      report notices every X week in the future) and if the problem isn't
      fixed within one week from that, QA will send yet another email to the
      maintainers and if no answer nor fix to the problem is provided within
      one week, all members of the core QA team will get the permission to
      modify any file needed to fix that QA issue as well as make a new
      release.</para>

      <para>If any <emphasis>major</emphasis> QA issues are found in any
      package and the QA team doesn't have permission to change that package
      without contacting the lead first then the QA team will file a bug
      report. Any major issues can stay open for 2 weeks (5+5+4 days; see
      below), QA may fix it themselves.</para>

      <para>If the issue isn't fixed within 5 days QA will email the
      maintainers about the issue (if the bug system won't have auto bug
      report notices every X week in the future) and if the problem isn't
      fixed with in 5 days, from that QA will send yet another email to the
      maintainers and if no answer nor fix to the problem is provided with in
      4 days, all members of the core QA team will have permission to modify
      any file needed to fix that QA issue as well as make a new
      release.</para>

      <para>The same time frames apply when the QA team want to make a release
      because of unreleased fixes/improvements which are only available via
      CVS, or when the QA team wants to determine if a package has been
      orphaned (using the time frames specified for non major issues).</para>

      <para>The QA team can decide what are major issues after discussion on
      the QA Mailing-list.</para>

      <para>The QA team will for this reason keep track of those QA issues in
      their pear web subsection. This would only be for having overview over
      which package maintainers need to be emailed for reminders and such
      things.</para>
    </section>

    <section xml:id="chapters.rfcs.qa-team.rights.orphan">
      <title>Orphaned Packages</title>

      <para>The QA team can use the above stated rules to determine if a
      package is orphaned. The core QA team gets lead rights on all orphaned
      packages until the original maintainer returns or a new maintainer is
      found.</para>
    </section>

    <section xml:id="chapters.rfcs.qa-team.rights.deleting">
      <title>Deleting Package releases</title>

      <para>The core QA team also has the permission to delete any release
      that might have any issues that have been found after the release, to
      reduce the effects of the problem. This right must be exercised with
      caution.</para>

      <para>Package maintainers can also grant QA the rights to make a
      releases for their packages.</para>
    </section>
  </section>

  <section xml:id="chapters.rfcs.qa-team.pearweb">
    <title>pearweb QA subsection</title>

    <para>It seems that there is a lack of QA material in the manual that
    people agree on and there is also need to make it move visible for people
    so they will actually follow those rules/guidelines. The QA team will
    therefore get its own QA subsection in the manual and will have control
    over it just like package maintainer controls package related docs in the
    manual.</para>

    <para>The QA team also gets its own subsection on pearweb so people can
    more easily access QA material which is too dynamic or just related to the
    QA team own internal documentation purposes. There the QA will, for
    example, publish their latest decisions.</para>

    <para>Furthermore here the QA team will be able to provide interfaces to
    QA team services. For example, here the QA team could offer an interface
    for maintainers to configure the access rights they want to grant the QA.
    Finally the core QA team can add QA related notes to each package homepage
    to communicate QA related information to the user base.</para>

    <section>
      <title>Approving first stable release</title>

      <para>The QA team needs to approve the first stable release of any major
      version.</para>

      <para>For this purpose maintainers upload the release to PEARweb and
      contact the QA team with a link to the release, then QA will decide if
      the release is ready or not. The core QA team will at this point approve
      the release through PEAR web and release it for the maintainer.</para>

      <note>
        <para>The QA team must always inform the current lead maintainers of
        any changes that are done to a given package using the currently
        configured email addresses on pear web.</para>
      </note>

      <note>
        <para>The core QA team may delegate tasks as much as possible to other
        QA team members. However no access rights will be assigned just for
        the sake of delegating a task (so members of the QA team may package a
        new release, but only members of the core QA team will have the
        necessary rights to upload the release).</para>
      </note>
    </section>
  </section>

  <section xml:id="chapters.rfcs.qa-team.summary">
    <title>Summary</title>

    <para>QA core group access rights:</para>

    <orderedlist>
      <listitem>
        <para>Max 7 core members that get the core-QA-karma</para>
      </listitem>

      <listitem>
        <para>The core QA team will get more permission to fix issues and make
        release of packages if reported problems are not fixed in a specific
        time frame</para>
      </listitem>

      <listitem>
        <para>The core QA team assumes lead over orphaned packages</para>
      </listitem>

      <listitem>
        <para>The core QA team gets the rights to delete releases of packages
        if it determines that the release has severe issues</para>
      </listitem>

      <listitem>
        <para>The QA team is allowed to add QA related notes to package
        homepages</para>
      </listitem>

      <listitem>
        <para>QA team needs to approve an first stable release for a given
        major version number (done by votes)</para>
      </listitem>

      <listitem>
        <para>The entire QA team will identify QA problems, will help writing
        QA related documents, will help people resolve their QA problems and
        such things</para>
      </listitem>

      <listitem>
        <para>More focus is needed on writing QA related things in the manual
        and make then more visible</para>
      </listitem>

      <listitem>
        <para>Make a little QA corner at pear.php.net so QA is more visible
        for people and package devs are more aware of the QA team and how it
        works.</para>
      </listitem>

      <listitem>
        <para>Keep track of what QA does regarding packages that QA doesn't
        have permission to edit through a wiki of some sort</para>
      </listitem>
    </orderedlist>
  </section>

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

    <orderedlist>
      <listitem>
        <para>Forming of the QA team, electing the persons who should for the
        core of the QA team.</para>
      </listitem>

      <listitem>
        <para>Giving the core dudes full CVS karma on the pear CVS module, as
        well as full access rights to package management part of pear
        web</para>
      </listitem>

      <listitem>
        <para>Make that little QA pear page</para>
      </listitem>

      <listitem>
        <para>Improve the QA manual pages</para>
      </listitem>

      <listitem>
        <para>Discovering which packages' lead(s) allow QA to help keeping
        their package QA approved</para>
      </listitem>

      <listitem>
        <para>Better coordination of the work which is done, who is going to
        do what. Know in advance who is going to write some more entries to
        the manual and so on.</para>
      </listitem>

      <listitem>
        <para>Make a wiki page of some sort for the info tracking regarding QA
        editing package that QA doesn't have permission to edit.</para>
      </listitem>
    </orderedlist>
  </section>
</chapter>