PEP: Procedure for Adding New Modules (please comment)

[Bruce Sass]

On 5 Jul 2001, Martijn Faassen wrote:
> Bruce Sass <bsass at freenet.edmonton.ab.ca> wrote:
<...>
> > With the maintainers of the existing library being the group of core
> > developers?
> What happens with the existing library is strictly outside the scope of this
> PEP, though I could of course broaden it. I'd *like* to say something
> like that, yes. Perhaps I ought to.

<cut, shuffle, paste...>

> >>     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.
>
> > That would be up to the group currently responsible for them.
>
> You mean PythonLabs/python-dev? (along with such other groups like the
> XML-SIG for the xml modules).

Right, however they want to do it... who knows, they may try to
renounce their claim on pretty much every lib and ask the Integrators
to find maintainers for them (first test of how to handle
Maintainerless libs?).


> > Will maintainers be given access to the servers, if so then
> > there should be set procedure to verify who they are (email don't cut
> > it!)
>
> Hm, do I want to get into technical details of how maintainers can be
> contacted?

No, but like with the doc standards, it should be mentioned so there
is little chance of confusion.  Perhaps reference to another PEP,
which outlines how one becomes a maintainer, what is expected of
maintainers while they are active, how to stop being a maintainer
temporarily or premanently, etc.

> I think email should be enough; the maintainer should notify
> the integrators if his or her email address changes!

If everything a maintainer does is checked before it hits cvs, then
email is enough.  If maintainers will be allowed to checkin stuff then
they should need to jump through some serious hoops before they are
allowed access.  To disregard this is like saying, "why lock the
doors, they can break a window and get in"...  why have doors at all,
eh.

> Perhaps there could
> be a maintainer-SIG or something like that. If a maintainer cannot
> be contacted easily then that's just a bad job by the maintainer, right?
> (Perhaps there should be a note that the integrators have the right to
> reject a maintainer that's inactive and look for another one..?)

I thought the Integrators == maintainer-SIG.

Consider this scenario... A maintainer is going mountain climbing for
a couple of months.  You don't want there to be any confusion about
whether they are active or not, and you don't want to drop'em unless
they take a drop (which you may or may not hear about).  So you need
an official contact method the Maintainers can use (to minimize the
chance of a missed communication), you may also need a replacement
maintainer (depending on time, lib, etc., guidelines would help), and
there should be a set procedure to follow if contact is lost (easily
done if all you have is an email address).

You can either codify it in a PEP, let the Integrators each handle
it how they want on a case by case basis, or let them fight it out
and arrive at a consensus (and maybe do it again when someone new
joins the team)...

I see both this and the documentation standards issues as things that
are crucial to the well being of this scheme, but have enough issues
of their own (unrelated to the mechanics of contributing to the
standard library) that they should have their own PEP (which seems to
be how Python is starting to codify practices of the meta variety,
but any type of "official" documentation would work just as well).


- Bruce