[Python-Dev] Encouraging developers

[Stephen J. Turnbull]

Giovanni Bajo writes:

 > On 05/03/2007 20.30, Phil Thompson wrote:

 >> 1. Don't suggest to people that, in order to get their patch
 >> reviewed, they should review other patches. The level of knowledge
 >> required to put together a patch is much less than that required
 >> to know if a patch is the right one.

 > +1000.

Been there, done that.  If the submitter doesn't have a pretty good
idea that a patch is "the right one", he's making substantial demands
on core developer time.  "+1000" suggests you think that core
developers are using their time with ruinously low efficiency.

I think the "review some patches" test is exactly the right one.  The
requirement is not that you channel the BFDL, it's that you read the
patch and bring your own knowledge of the problem to bear.  This has
three benefits: (1) the reviewed patches get some comments; (2) the
reviewed patches come to the attention of a committer; (3) the
reviewer comes to the attention of a core developer, and can be
considered for commit privileges, etc.

An informal version of this process is how XEmacs identifies its
Reviewers (the title we give to those privileged to authorize commits
to all parts of XEmacs).  People who care enough to make technical
comments on *others'* patches are rare, and we grab the competent ones
pretty quickly.

 >> 2. Publically identify the core developers and their areas of
 >> expertise and responsibility (ie. which parts of the source tree
 >> they "own").

The XEmacs experience has been that the core developers are "ministers
without portfolio".  You can't wait around for the "owner", who may be
on Mars, and you rarely need to.

 > I think this should be pushed to its extreme consequences for the
 > standard library. Patching the standard library requires *much
 > less* knowledge than patching the standard core. Basically, almost
 > any Python developer in the wild can quickly learn a module and
 > start patching it in a few days/weeks -- still, the stdlib is a
 > total mess of outdated and broken modules.

The mess is not "total", as Josiah Carlson points out.  To the extent
that it is a mess, it is the consequence of a process similar to the
one you propose to institutionalize.

 > My suggestion is:
 > 
 >   - keep a public list of official maintainers for each and every
 > package/module in the standard library (if any, otherwise
 > explicitly specify that it's unmaintained).

This is what XEmacs does; it works, but it's not as effective as you
might hope.  What happens for us is that many modules are maintained
by an interest group disjoint from the core.  By giving a
representative of the interest group commit privileges, things get
addressed pretty quickly and competently.  However, this is a
convenience for users of the module more than a way of kickstarting a
development process (note that the interest group already exists).

This requires a separate distribution of the standard library.

Two points: recall the ElementTree thread.  There were other plausible
candidates.  The XEmacs policy in such case is that they are all
considered equally, and all are allowed to be distributed with the
package distribution.  In Python, this would conflict with TOOWTDI.

Second, where the stdlib module is closely bound to the core, the
maintainer ends up being the group of core developers.  It can't be
any other way, it seems to me.

 >   - if there's no maintainer for a module, the *first* volunteer
 > can become so.

I doubt this will work.  It is usually the case that the first
volunteer is acceptable, but it shouldn't be policy.

 >   - *any* patch to stdlib which follows the proper guidelines (have
 > a test, don't break compatibility, etc.) *must* be applied *unless*
 > the maintainer objects in X days (if a maintainer
 > exists... otherwise it will just go in).

This is an obviously bad idea.  The stdlib needs to be deliberately
pruned, not arbitrarily patched.