PEP: Procedure for Adding New Modules (please comment)

[Martijn Faassen]

Hi folks,

I've been working on a text for PEP 2. Currently, PEP 2 is a 3 line
text written by Eric Raymond:

http://python.sourceforge.net/peps/pep-0002.html

Tim Peters suggested we fleshed it out, so I've made the attempt. I've
conferred with Eric to make sure I wasn't stepping on any toes there.

The PEP that follows officially has no number yet; it hasn't been
assigned one yet. My hope is of course i'tll be accepted as PEP 2.

Carlos Ribeiro has also been working on a text, which may become a 
separate PEP or may be merged into this one. The two texts are 
fairly complementary; Carlos talks more about guidelines for what
the modules should look like, while my text talks more about the
acceptance procedure. I'm in communication with Carlos about further
development of that text.

Comments are very welcome. I'll attempt to integrate any feedback and
will try to move this forward if the feedback is positive.

This text assumes the community will play a large role in developing and 
maintaining any standard library modules. So, community, please give 
some feedback.

Title: Producedure for Adding New Modules

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 5 give some guidelines on this. The
    continued maintenance of existing modules is an integral part of
    the decision on  This
    PEP also introduces concepts (integrators, maintainers) relevant
    to this 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 frequently is a group
    of people such as for instance 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; 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 compability 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.

    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

    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').

    A related question is integration with the Python documentation
    process. Contributions should come with good documentation that
    can be integrated with the Standard Library documentation. Should
    we detail this more in this PEP?
    
    Should the current standard library be subdivided among such
    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 mytical Catalog?

Copyright

    This document has been placed in the public domain.

-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?