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

[Michael Foord]

Late to the party.

+1 for a list
+1 for maintainers not owners

Michael

R. David Murray wrote:
> 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. :)
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig


-- 
http://www.ironpythoninaction.com/