[Python-checkins] CVS: python/nondist/peps pep-0002.txt,1.2,1.3

[Barry Warsaw]

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv25464

Modified Files:
	pep-0002.txt 
Log Message:
This PEP has a new champion Martijn Faassen, and it actually contains
text now. :)

Committing for Martijn, after minor formatting and style changes.


Index: pep-0002.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0002.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** pep-0002.txt	21 Mar 2001 17:35:05 -0000	1.2
--- pep-0002.txt	11 Mar 2002 17:23:14 -0000	1.3
***************
*** 2,17 ****
  Title: Procedure for Adding New Modules
  Version: $Revision$
! Author: esr@snark.thyrsus.com (Eric S. Raymond)
! Status: Deferred
  Type: Informational
! Created: 07-Aug-2000
! Post-History:
  
  
! Abstract
  
!     This PEP will describes review and voting procedures for
!     incorporating candidate modules and extensions into the Python
!     core.
  
  
--- 2,193 ----
  Title: Procedure for Adding New Modules
  Version: $Revision$
! Last-Modified: $Date$
! Author: faassen@infrae.com (Martijn Faassen)
! Status: Draft
  Type: Informational
! Created: 07-Jul-2001
! Post-History: 07-Jul-2001, 09-Mar-2002
  
  
! Introduction
  
!     The Python Standard Library contributes significantly to Python's
!     success.  The language comes with "batteries included", so it is
!     easy for people to become productive with just the standard
!     library alone.  It is therefore important that this library grows
!     with the language, and that such growth is supported and
!     encouraged.
! 
!     Many contributions to the library are not created by core
!     developers but by people from the Python community who are experts
!     in their particular field.  Furthermore, community members are
!     also the users of the standard library, applying it in a great
!     diversity of settings.  This makes the community well equipped to
!     detect and report gaps in the library; things that are missing but
!     should be added.
! 
!     New functionality is commonly added to the library in the form of
!     new modules.  This PEP will describe the procedure for the
!     _addition_ of new modules.  PEP 4 deals with procedures for
!     deprecation of modules; the _removal_ of old and unused modules
!     from the standard library.  Finally there is also the issue of
!     _changing_ existing modules to make the picture of library
!     evolution complete.  PEP 3 and PEP 5 give some guidelines on this.
!     The continued maintenance of existing modules is an integral part
!     of the decision on whether to add a new module to the standard
!     library.  Therefore, this PEP also introduces concepts
!     (integrators, maintainers) relevant to the maintenance issue.
!     
! 
! Integrators
! 
!     The integrators are a group of people with the following
!     responsibilities:
! 
!     - They determine if a proposed contribution should become part of
!       the standard library.
! 
!     - They integrate accepted contributions into the standard library.
! 
!     - They produce standard library releases.
! 
!    This group of people shall be PythonLabs, led by Guido.
! 
! 
! Maintainer(s)
! 
!     All contributions to the standard library need one or more
!     maintainers.  This can be an individual, but it is frequently a
!     group of people such as the XML-SIG.  Groups may subdivide
!     maintenance tasks among themselves.  One ore more maintainers
!     shall be the _head maintainer_ (usually this is also the main
!     developer).  Head maintainers are convenient people the
!     integrators can address if they want to resolve specific issues,
!     such as the ones detailed later in this document.
! 
! 
! Developers(s)
! 
!     Contributions to the standard library have been developed by one
!     or more developers.  The initial maintainers are the original
!     developers unless there are special circumstances (which should be
!     detailed in the PEP proposing the contribution).
! 
! 
! Acceptance Procedure
! 
!     When developers wish to have a contribution accepted into the
!     standard library, they will first form a group of maintainers
!     (normally initially consisting of themselves).
! 
!     Then, this group shall produce a PEP called a library PEP. A
!     library PEP is a special form of standards track PEP.  The library
!     PEP gives an overview of the proposed contribution, along with the
!     proposed contribution as the reference implementation.  This PEP
!     should also contain a motivation on why this contribution should
!     be part of the standard library.
! 
!     One or more maintainers shall step forward as PEP champion (the
!     people listed in the Author field are the champions).  The PEP
!     champion(s) shall be the initial head maintainer(s).
!     
!     As described in PEP 1, a standards track PEP should consist of a
!     design document and a reference implementation.  The library PEP
!     differs from a normal standard track PEP in that the reference
!     implementation should in this case always already have been
!     written before the PEP is to be reviewed for inclusion by the
!     integrators and to be commented upon by the community; the
!     reference implementation _is_ the proposed contribution.
! 
!     This different requirement exists for the following reasons:
! 
!     - The integrators can only properly evaluate a contribution to the
!       standard library when there is source code and documentation to
!       look at; i.e. the reference implementation is always necessary
!       to aid people in studying the PEP.
! 
!     - Even rejected contributions will be useful outside the standard
!       library, so there will a lower risk of waste of effort by the
!       developers.
!   
!     - It will impress the integrators of the seriousness of
!       contribution and will help guard them against having to evaluate
!       too many frivolous proposals.
! 
!     Once the library PEP has been submitted for review, the
!     integrators will then evaluate it.  The PEP will follow the normal
!     PEP work flow as described in PEP 1.  If the PEP is accepted, they
!     will work through the head maintainers to make the contribution
!     ready for integration.
! 
! 
! Maintenance Procedure
! 
!     After a contribution has been accepted, the job is not over for
!     both integrators and maintainers.  The integrators will forward
!     any bug reports in the standard library to the appropriate head
!     maintainers.
! 
!     Before the feature freeze preparing for a release of the standard
!     library, the integrators will check with the head maintainers for
!     all contributions, to see if there are any updates to be included
!     in the next release.  The integrators will evaluate any such
!     updates for issues like backwards compatibility and may require
!     PEPs if the changes are deemed to be large.
! 
!     The head maintainers should take an active role in keeping up to
!     date with the Python development process.  If a head maintainer is
!     unable to function in this way, he or she should announce the
!     intention to step down to the integrators and the rest of the
!     maintainers, so that a replacement can step forward.  The
!     integrators should at all times be capable of reaching the head
!     maintainers by email.
! 
!     In the case where no head maintainer can be found (possibly
!     because there are no maintainers left), the integrators will issue
!     a call to the community at large asking for new maintainers to
!     step forward.  If no one does, the integrators can decide to
!     declare the contribution deprecated as described in PEP 4.
! 
! 
! Open issues
! 
!     There needs to be some procedure so that the integrators can
!     always reach the maintainers (or at least the head maintainers).
!     This could be accomplished by a mailing list to which all head
!     maintainers should be subscribed (this could be python-dev).
!     Another possibility, which may be useful in any case, is the
!     maintenance of a list similar to that of the list of PEPs which
!     lists all the contributions and their head maintainers with
!     contact info.  This could in fact be part of the list of the PEPs,
!     as a new contribution requires a PEP.  But since the
!     authors/owners of a PEP introducing a new module may eventually be
!     different from those who maintain it, this wouldn't resolve all
!     issues yet.
! 
!     Should there be a list of what criteria integrators use for
!     evaluating contributions?  (Source code but also things like
!     documentation and a test suite, as well as such vague things like
!     'dependability of the maintainers'.)
!     
!     This relates to all the technical issues; check-in privileges,
!     coding style requirements, documentation requirements, test suite
!     requirements.  These are preferably part of another PEP.
! 
!     Should the current standard library be subdivided among
!     maintainers?  Many parts already have (informal) maintainers; it
!     may be good to make this more explicit.
! 
!     Perhaps there is a better word for 'contribution'; the word
!     'contribution' may not imply enough that the process (of
!     development and maintenance) does not stop after the contribution
!     is accepted and integrated into the library.
! 
!     Relationship to the mythical Catalog?
! 
! 
! Copyright
! 
!     This document has been placed in the public domain.
  
  
***************
*** 20,22 ****
--- 196,199 ----
  mode: indented-text
  indent-tabs-mode: nil
+ fill-column: 70
  End: