cvs: peardoc / global.ent /en/chapters group.xml

From: Date: Sat, 16 Dec 2006 15:02:15 +0000
Subject: cvs: peardoc / global.ent /en/chapters group.xml
Groups: php.pear.doc 
Request: Send a blank email to pear-doc+get-9101@lists.php.net to get a copy of this message
mj Sat Dec 16 15:02:15 2006 UTC Modified files: /peardoc global.ent /peardoc/en/chapters group.xml Log: * Merged two PEPr proposals into the documentation # Bug: #4852

http://cvs.php.net/viewvc.cgi/peardoc/global.ent?r1=1.77&r2=1.78&diff_format=u Index: peardoc/global.ent diff -u peardoc/global.ent:1.77 peardoc/global.ent:1.78 --- peardoc/global.ent:1.77 Sat Dec 16 12:21:59 2006 +++ peardoc/global.ent Sat Dec 16 15:02:15 2006 @@ -1,6 +1,6 @@ <!-- -*- SGML -*- - $Id: global.ent,v 1.77 2006/12/16 12:21:59 mj Exp $ + $Id: global.ent,v 1.78 2006/12/16 15:02:15 mj Exp $ Contains global "macros" for all the XML documents. @@ -105,9 +105,11 @@ <!ENTITY url.pear.package.upload 'http://pear.php.net/release-upload.php'> <!ENTITY url.pear.pepr 'http://pear.php.net/pepr/'> <!ENTITY url.pear.pepr.edit 'http://pear.php.net/pepr/pepr-proposal-edit.php'> +<!ENTITY url.pear.pepr.proposal 'http://pear.php.net/pepr/pepr-proposal-show.php?id='> <!ENTITY url.pear.tasks.xsd 'http://pear.php.net/dtd/tasks-1.0.xsd'> <!ENTITY url.pear.account 'http://pear.php.net/accounts.php'> <!ENTITY url.pear.account.new 'http://pear.php.net/account-request.php'> +<!ENTITY url.pear.developer 'http://pear.php.net/user/'> <!ENTITY url.pear.group 'http://pear.php.net/group/'> <!ENTITY url.pear.group.licenses 'http://pear.php.net/group/docs/20040402-la.php'> <!ENTITY url.pear.group.doc.proposals 'http://pear.php.net/group/docs/20040402-la.php'> http://cvs.php.net/viewvc.cgi/peardoc/en/chapters/group.xml?r1=1.1&r2=1.2&diff_format=u Index: peardoc/en/chapters/group.xml diff -u peardoc/en/chapters/group.xml:1.1 peardoc/en/chapters/group.xml:1.2 --- peardoc/en/chapters/group.xml:1.1 Sat Dec 16 12:23:03 2006 +++ peardoc/en/chapters/group.xml Sat Dec 16 15:02:15 2006 @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-1" ?> -<!-- $Revision: 1.1 $ --> +<!-- $Revision: 1.2 $ --> <chapter id="group"> <title>PEAR Group Administrative Documentations</title> @@ -231,6 +231,313 @@ naming conventions. </para> </sect1> + + <!-- http://pear.php.net/pepr/pepr-proposal-show.php?id=192 --> + <sect1 id="group.orphaned"> + <sect1info> + <author> + <firstname>Arnaud</firstname> + <surname>Limbourg</surname> + </author> + + <abstract> + <para> + This document is based on the <ulink + url="&url.pear.pepr.proposal;192">PEPr voting</ulink> initiated by + PEAR's <ulink url="&url.pear.developer;arnaud">Arnaud + Limbourg</ulink>. The purpose is to define when a package is + orphaned and how to handle this. + </para> + </abstract> + </sect1info> + + <title>Orphaned Packages</title> + + <sect2> + <title>The Problem</title> + + <para> + Sometimes a package is left without care for a long time. It + becomes lonely and full of bugs. This is a very sad situation + and somebody needs to step up to remedy it. + </para> + </sect2> + + <sect2> + <title>What can be considered an orphaned package ?</title> + + <para> + The following are considered orphaned packages: + </para> + <itemizedlist> + <listitem> + <simpara> + A package with bugs open for longer than 2 months and the + developers have not commented on the bug or made any + commits to CVS during that time frame. + </simpara> + </listitem> + <listitem> + <simpara> + A package that has no open bugs and has bug fixes committed + to CVS but does not have a release within 6 months of the + bugs being fixed. + </simpara> + </listitem> + <listitem> + <simpara> + A package owned by somebody who is commonly known to be + inactive. + </simpara> + </listitem> + <listitem> + <simpara> + A package denounced by its leads (i.e. The lead actually + says that he is no longer maintaining it on pear-dev) + </simpara> + </listitem> + </itemizedlist> + </sect2> + + <sect2> + <title>Contact process</title> + + <para> + A QA core-team member tries to contact the current maintainers + and developers (cc'ing the QA list) asking about an update + about their work on the package. + </para> + <para> + A package lead answers: + </para> + + <itemizedlist> + <listitem> + <simpara> + he states that he has no interest in the package anymore, + he allows QA team to take the necessary steps + </simpara> + </listitem> + <listitem> + <simpara> + he states that he still intends to work on the package, but + is busy at that point. Either a timeframe will then be + decided upon by the lead and QA during which some activity + must occur (i.e. I'm going to be busy the rest of this + month but I'll get back to it on the 3rd of next month) OR + a second lead developer will be sought to continue + development + </simpara> + </listitem> + </itemizedlist> + + <para> + he states that he still intends to work on the package, but is + busy at that point. Either a timeframe will then be decided + upon by the lead and QA during which some activity must occur + (i.e. I'm going to be busy the rest of this month but I'll get + back to it on the 3rd of next month) OR a second lead developer + will be sought to continue development + </para> + </sect2> + + <sect2> + <title>Finding a new lead</title> + + <para> + A message will be sent to pear-dev asking for volunteers. + </para> + + <sect3> + <title>Somebody steps up</title> + + <para> + If you are willing to take over a package you must notify the + QA list and state who you are and why you want to take over. + </para> + <para> + If the QA team feels the person who stepped up is appropriate + and capable, the team will make this person a new + maintainer. In case several persons step up a case by case + study will be carried out to assign new maintainer-ship. + </para> + </sect3> + + <sect3> + <title>Nobody wishes to take over</title> + + <para> + A QA core team member will mark the package as orphaned. + </para> + </sect3> + + <sect3> + <title>Orphan status</title> + + <para> + If a package is orphaned, a warning and a call for + maintainers will be displayed on the main package page. + </para> + </sect3> + </sect2> + + <glossary> + <glossentry> + <glossterm> + QA team + </glossterm> + <glossdef> + <simpara> + Refers to the whole QA team (core and mailing list members) + </simpara> + </glossdef> + </glossentry> + <glossentry> + <glossterm> + QA core + </glossterm> + <glossdef> + <simpara> + Refers to the 6 elected QA team members + </simpara> + </glossdef> + </glossentry> + </glossary> + </sect1> + + <!-- http://pear.php.net/pepr/pepr-proposal-show.php?id=188 --> + <sect1 id="group.pepr_orphan"> + <sect1info> + <author> + <firstname>Tobias</firstname> + <surname>Schlitt</surname> + </author> + + <abstract> + <para> + This document is based on the <ulink + url="&url.pear.pepr.proposal;188">PEPr voting</ulink> initiated by + PEAR's <ulink url="&url.pear.developer;toby">Tobias + Schlitt</ulink>. The purpose is to define what to do with + orphaned PEPr proposals. + </para> + </abstract> + </sect1info> + + <title>Orphaned PEPr Proposals</title> + + <sect2> + <title>The problem</title> + + <para> + It happens more or less often that + </para> + + <orderedlist> + <listitem> + <simpara> + PEPr proposals get stuck in a specific proposal phase, + </simpara> + </listitem> + <listitem> + <simpara> + PEPr proposals get accepted, but no package is registered / + released. + </simpara> + </listitem> + </orderedlist> + </sect2> + + <sect2> + <title>The solution</title> + + <para> + In these two cases PEAR QA should step in and try to get in touch + with the specific proposers. If the proposer is no more + interessted in the proposal, PEAR QA should search for a new + maintainer for the package or the proposal should be deleted. + </para> + <para> + For these steps the following time frames are proposed: + </para> + + <itemizedlist> + <listitem> + <simpara> + For proposals in stages "draft" and "proposal" + </simpara> + <itemizedlist> + <listitem> + <simpara> + PEAR QA posts a reminder comment to the proposal after + 1 week of inactivity. + </simpara> + </listitem> + <listitem> + <simpara> + If the proposer does not react within 2 weeks, the + proposal gets deleted. + </simpara> + </listitem> + </itemizedlist> + </listitem> + <listitem> + <simpara> + For proposals in stage "finished" + </simpara> + <itemizedlist> + <listitem> + <simpara> + PEAR QA tries to contact the maintainer 4 weeks after + the proposal is finished and no release has been + throwen. + </simpara> + </listitem> + <listitem> + <simpara> + If the maintainer can not be contacted within 4 weeks, + PEAR QA starts searching for a new maintainer. + </simpara> + </listitem> + <listitem> + <simpara> + If no new maintainer is found within 4 weeks, the + proposal gets marked as orphan. + </simpara> + </listitem> + </itemizedlist> + </listitem> + </itemizedlist> + </sect2> + + <sect2> + <title>Orphan marker</title> + + <para> + Finished proposals should not be deleted, but marked as + orphan. This marker should have the following content: + </para> + <itemizedlist> + <listitem> + <simpara> + To the name of the proposal the following tag will be + added: <literal>[QA-ORPHAN]</literal>. + </simpara> + </listitem> + <listitem> + <simpara> + To the describtion of the proposal the following text will + be added at the top: "This proposal has been marked orphan + by PEAR-QA on &lt;DATE&gt; because of the inactivity of the + proposer. This means, that the proposal is invalid from + this date on. If you have a similar proposal or want to + re-activate this proposal, feel free to create a new PEPr + proposal for it.". + </simpara> + </listitem> + </itemizedlist> + </sect2> + </sect1> </chapter> <!-- Keep this comment at the end of the file Local variables:
« previous php.pear.doc (#9101) next »