On Tue, Sep 15, 2009 at 6:38 PM, R. David Murray <rdmur...@bitdance.com> 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.
+1 I had started this as a googlesheet as part of a pycon talk, and was planning on an email later on asking for "owners". > 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. Hmm, tables in a text file? I can see it, it's just always wacky. +1 > 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. +1, provided we can get good information into this, this could help out a lot. Can I ask that instead of just a misc file, we put this in the official documentation, in ReST format? I'd like to be able to point to all official-like. Not to mention, sphinx and ReST are the One True Way. > 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. +1 > 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. +1 > If this proposal or a modification of it is accepted I will volunteer > to create the file and canvas python-dev for names. I accept it :) _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
