python-peps/pep-0002.txt

PEP: 2
Title: Procedure for Adding New Modules
Version: $Revision$
Last-Modified: $Date$
Author: Martijn Faassen <faassen@infrae.com>
Status: Final
Type: Process
Content-Type: text/x-rst
Created: 07-Jul-2001
Post-History: 07-Jul-2001, 09-Mar-2002



PEP Replacement
===============

This PEP has been superseded by the updated material in the Python
Developer's Guide [1]_.

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?

References
==========

.. [1] Adding to the Stdlib
   (http://docs.python.org/devguide/stdlibchanges.html)

Copyright
=========

This document has been placed in the public domain.

..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   fill-column: 70
   coding: utf-8
   End: