[stdlib-sig] MISC/maintainers.txt anyone?

[R. David Murray]

It has been mentioned here that some bugs languish in the tracker because
there is no one willing to say "yes" or "no" to them.  In at least some
cases this may be because it is unclear who the best person is to ask
for a decision when the participants in the issue don't feel qualified
to decide.  And in some cases, some of the people it may be unclear to
may be the very people who _could_ decide...if only they knew that they
were the closest thing to an expert on that module that we have.

In a discussion on IRC we came up with a proposal for a simple tool that
might help out in this situation.  I would like to propose that we create
a file, tentatively named MISC/maintainers.txt, that contains two tables:
(1) a table of all the modules in the standard library and (2) a table of
'areas of expertise' (things like Unicode, arithmetic, etc).  Table (2)
would be the simpler, and would just list people who felt they had
enough expertise in the given area to be willing to make judgement
calls on relevant issues on request.

Table (1) would list, I propose, three categories of people:
(a) 'official maintainer(s)', (b) experts, and (c) contributors.
An 'official maintainer' would be someone willing to take more-or-less
full responsibility for a module (such as Jesse for Multiprocessing).
Experts would be people who feel they have a good working knowledge of
the module and would not be afraid to sign off on the advisability and
quality of a feature/bug fix when there is a question.  Contributors would
be anyone else with a more than casual knowledge of the module, but who
aren't comfortable with signing off on the advisability of non-trivial
patches/feature requests.  My rational for including the third category is
to have a pool of people who can self-promote as needed.  These people
can decide that it is OK to make the decision once they see that
there is no one willing to declare themselves an expert in that module.
I unfortunately expect a non-trivial number of modules to fall into
this category.

The listing in the table would be by tracker id, to facilitate making
people nosy on issues.  The tracker id can be used to discover names
and email addresses if those are needed instead.

Obviously one problem would be keeping this up to date, since when someone
stops contributing they are fairly likely to not remove their name from
the list.  This task could be handled by anyone who does issue triage:
if a triage person notices a maintainer or expert who has not responded
to a request for decision on an issue, they can try pinging the person
directly, and if they still get no response, mark the person (or request
that the person be marked, if the triage person is not a committer) as
'deprecated'(*) in the maintainers file.

If this proposal or a modification of it is accepted I will volunteer
to create the file and canvas python-dev for names.

--David

(*) I mean 'inactive' of course. :)