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@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
