[Python-Dev] My patches

[Nick Coghlan]

Paul Moore:
> 3. There's nothing obvious I can do to move an issue forward. Sure, I
>  can make a comment, but that's about it. I'd like something that
> stood a bit more chance of getting noticed (like a status change, or
> maybe a list of people who think this is good to apply, which I can
> add myself to).

Speaking for myself, I rarely spend any time going through the
tracker looking for items I can help handle*. So one of the things I
find *most* helpful is when someone adds me to the nosy list for a
tracker issue, since that will drop an email into my issue tracker
folder with a link straight to the issue.

Obviously I'd prefer it if people only did that when I really can help,
but I don't mind getting the occasional misdirected issue if it means
that more problems in my areas of expertise are brought directly to my
attention.

(*I only spend a fairly limited amount of time on python at the moment,
and keeping up with python-dev, python-3000, reviewing the two checkins
list and looking into items that are brought directly to my attention
fills that up pretty well)

Tarek Ziadé wrote:
> Since it is a hard and long process  "to know it all"  in Python, and
>  to become a core developer
> 
> What about having two level of devs ?
> 
> + core developers + standard library developers
> 
> I mean, the standard library could be open ihmo to a wider range of
> people, or maybe even having people specialized in some packages,
> modules, even if they don't know anything about the C apis of the
> core.
> 
> Those "standard library developers" could be blessed to work on 
> specific areas of the standard library and "followed" by a core
> developer that can just make sure everything goes in the right
> direction without having too much extra work for that.

I think you'll that most of the "core devs" have areas where we're
confident of our domain knowledge and are happy to accept and commit
patches, and other areas where we're willing to review things and
provide recommendations, and then areas where we have next to no
knowledge at all. The standard library is pretty huge, and outside a few
generally useful core modules, which sections of it are useful to you
depends greatly on what kind of application you're working on.

To use myself as an example, if a bug or patch relating to the compiler
, the import system, runpy, contextlib, functools or a few others areas
is brought to my attention, I'll generally consider myself competent to
both assess the problem and apply any fixes (I may not consider the
issue *urgent*, or else I'll want to spend some time just mulling it
over, so the tracker item may still hang around for a while, but I'll
get to them eventually).

Then there are a few other areas (such as threading and
multiprocessing), where I'll take an active interest in matters (because
it's code I either use, or am likely to use at some point), but usually
defer to others when it comes to making the actual commits. This is
particular so when areas have clear owners (e.g. Raymond for itertools,
Jesse for multiprocessing, Facundo/Raymond for decimal) or are fairly
complex and I know I haven't studied them enough to understand them
properly (e.g. the memory allocator).

And finally, there are large swathes of the standard library that I've
never even used, let alone looked at in a code editor (such as nearly
all of the network protocol and database libraries, as what I personally
use Python for tends to be much lower level than that). For those areas,
I don't really consider myself competent to even provide effective
review, so I tend to ignore those patches completely.

In the past, even Guido has explicitly deferred to the appropriate
subject matter experts when it came to areas of the standard library he
personally didn't use much.

So I'd suggest thinking about developer responsibilities more in terms
of areas of expertise rather than "levels" of developers. Those of us
that happen to understand the guts of the compiler or the VM aren't more
competent globally or more trusted than those maintaining the various
modules in the standard library - just interested in different things.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------