Here is some proposed wording. Since it is more of a clarification of what it takes to garner support -- which is just a new section -- rather than a complete rewrite I&#39;m including just the diff to make it easier to read the changes.<div>
<br></div><div><br></div><div>







<p class="p1"><b>diff -r 49d18bb47ebc pep-0011.txt</b></p>
<p class="p2"><b>--- a/pep-0011.txt<span class="Apple-tab-span">	</span>Wed May 14 11:18:22 2014 -0400</b></p>
<p class="p3"><b>+++ b/pep-0011.txt<span class="Apple-tab-span">	</span>Fri May 16 13:48:30 2014 -0400</b></p>
<p class="p4">@@ -2,22 +2,21 @@</p>
<p class="p1"> Title: Removing support for little used platforms</p>
<p class="p1"> Version: $Revision$</p>
<p class="p1"> Last-Modified: $Date$</p>
<p class="p2">-Author: <a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a> (Martin von Löwis)</p>
<p class="p3">+Author: Martin von Löwis &lt;<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>&gt;,</p>
<p class="p3">+        Brett Cannon &lt;<a href="mailto:brett@python.org">brett@python.org</a>&gt;</p>
<p class="p1"> Status: Active</p>
<p class="p1"> Type: Process</p>
<p class="p1"> Content-Type: text/x-rst</p>
<p class="p1"> Created: 07-Jul-2002</p>
<p class="p1"> Post-History: 18-Aug-2007</p>
<p class="p3">+              16-May-2014</p>
<p class="p5"> </p>
<p class="p5"> </p>
<p class="p1"> Abstract</p>
<p class="p1"> --------</p>
<p class="p5"> </p>
<p class="p2">-This PEP documents operating systems (platforms) which are not</p>
<p class="p2">-supported in Python anymore.  For some of these systems,</p>
<p class="p2">-supporting code might be still part of Python, but will be removed</p>
<p class="p2">-in a future release - unless somebody steps forward as a volunteer</p>
<p class="p2">-to maintain this code.</p>
<p class="p3">+This PEP documents how an operating system (platform) garners</p>
<p class="p3">+support in Python as well as documenting past support.</p>
<p class="p5"> </p>
<p class="p5"> </p>
<p class="p1"> Rationale</p>
<p class="p4">@@ -37,16 +36,53 @@</p>
<p class="p1"> change to the Python source code will work on all supported</p>
<p class="p1"> platforms.</p>
<p class="p5"> </p>
<p class="p2">-To reduce this risk, this PEP proposes a procedure to remove code</p>
<p class="p2">-for platforms with no Python users.</p>
<p class="p3">+To reduce this risk, this PEP specifies what is required for a</p>
<p class="p3">+platform to be considered supported by Python as well as providing a</p>
<p class="p3">+procedure to remove code for platforms with little or no Python</p>
<p class="p3">+users.</p>
<p class="p5"> </p>
<p class="p3">+Supporting platforms</p>
<p class="p3">+--------------------</p>
<p class="p3">+</p>
<p class="p3">+Gaining official platform support requires two things. First, a core</p>
<p class="p3">+developer needs to volunteer to maintain platform-specific code. This</p>
<p class="p3">+core developer can either already be a member of the Python</p>
<p class="p3">+development team or be given contributor rights on the basis of</p>
<p class="p3">+maintaining platform support (it is at the discretion of the Python</p>
<p class="p3">+development team to decide if a person is ready to have such rights</p>
<p class="p3">+even if it is just for supporting a specific platform).</p>
<p class="p3">+</p>
<p class="p3">+Second, a stable buildbot must be provided [2]_. This guarantees that</p>
<p class="p3">+platform support will not be accidentally broken by a Python core</p>
<p class="p3">+developer who does not have personal access to the platform. For a</p>
<p class="p3">+buildbot to be considered stable it requires that the machine be</p>
<p class="p3">+reliably up and functioning (but it is up to the Python core</p>
<p class="p3">+developers to decide whether to promote a buildbot to being</p>
<p class="p3">+considered stable).</p>
<p class="p3">+</p>
<p class="p3">+This policy does not disqualify supporting other platforms</p>
<p class="p3">+indirectly. Patches which are not platform-specific but still done to</p>
<p class="p3">+add platform support will be considered for inclusion. For example,</p>
<p class="p3">+if platform-independent changes were necessary in the configure</p>
<p class="p3">+script which was motivated to support a specific platform that would</p>
<p class="p3">+be accepted. Patches which add platform-specific code such as the</p>
<p class="p3">+name of a specific platform to the configure script will generally</p>
<p class="p3">+not be accepted without the platform having official support.</p>
<p class="p3">+</p>
<p class="p3">+CPU architecture and compiler support are viewed in a similar manner</p>
<p class="p3">+as platforms. For example, to consider the ARM architecture supported</p>
<p class="p3">+a buildbot running on ARM would be required along with support from</p>
<p class="p3">+the Python development team. In general it is not required to have</p>
<p class="p3">+a CPU architecture run under every possible platform in order to be</p>
<p class="p3">+considered supported.</p>
<p class="p5"> </p>
<p class="p1"> Unsupporting platforms</p>
<p class="p1"> ----------------------</p>
<p class="p5"> </p>
<p class="p2">-If a certain platform that currently has special code in it is</p>
<p class="p2">-deemed to be without Python users, a note must be posted in this</p>
<p class="p2">-PEP that this platform is no longer actively supported.  This</p>
<p class="p3">+If a certain platform that currently has special code in Python is</p>
<p class="p3">+deemed to be without Python users or lacks proper support from the</p>
<p class="p3">+Python development team and/or a buildbot, a note must be posted in</p>
<p class="p3">+this PEP that this platform is no longer actively supported.  This</p>
<p class="p1"> note must include:</p>
<p class="p5"> </p>
<p class="p1"> - the name of the system</p>
<p class="p4">@@ -69,8 +105,8 @@</p>
<p class="p1"> forward and offer maintenance.</p>
<p class="p5"> </p>
<p class="p5"> </p>
<p class="p2">-Resupporting platforms</p>
<p class="p2">-----------------------</p>
<p class="p3">+Re-supporting platforms</p>
<p class="p3">+-----------------------</p>
<p class="p5"> </p>
<p class="p1"> If a user of a platform wants to see this platform supported</p>
<p class="p1"> again, he may volunteer to maintain the platform support.  Such an</p>
<p class="p4">@@ -101,7 +137,7 @@</p>
<p class="p1"> release is made. Developers of extension modules will generally need</p>
<p class="p1"> to use the same Visual Studio release; they are concerned both with</p>
<p class="p1"> the availability of the versions they need to use, and with keeping</p>
<p class="p2">-the zoo of versions small. The Python source tree will keep<span class="s1"><b> </b></span></p>
<p class="p3">+the zoo of versions small. The Python source tree will keep</p>
<p class="p1"> unmaintained build files for older Visual Studio releases, for which</p>
<p class="p1"> patches will be accepted. Such build files will be removed from the</p>
<p class="p1"> source tree 3 years after the extended support for the compiler has</p>
<p class="p4">@@ -223,6 +259,7 @@</p>
<p class="p1"> ----------</p>
<p class="p5"> </p>
<p class="p1"> .. [1] <a href="http://support.microsoft.com/lifecycle/">http://support.microsoft.com/lifecycle/</a></p>
<p class="p3">+.. [2] <a href="http://buildbot.python.org/3.x.stable/">http://buildbot.python.org/3.x.stable/</a></p>
<p class="p5"> </p>
<p class="p1"> Copyright</p>
<p class="p1"> ---------</p></div>