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

Georg Brandl g.brandl at gmx.net
Wed Sep 16 10:47:26 CEST 2009


M.-A. Lemburg schrieb:
> Georg Brandl wrote:
>>> Having a table in the official docs at least gives people an idea who
>>> to +noisy on bugs. How many multiprocessing bugs have you had to
>>> reassign, or even *add* me to because people outside of our group
>>> don't know?
> 
> As general note: I have the impression that the noisy list feature
> of the bug tracker is not exactly ideal to get attention for certain
> bugs from the right people.
> 
> Perhaps it's better to just ask the various developers to setup
> email filters for this purpose; or maybe in addition to using the
> noisy lists.
> 
> I've done that and while it's not perfect, it works a lot better than
> relying on someone putting me on e.g. the platform.py-related ticket
> noisy list.

That's why at PyCon (or was it Europython?) we thought about a "tags"
field for issues.  The main use for tags would be module names (and
it should be advertised as such in the UI for submitting bugs)
with auto-nosy associations for module maintainers.

(I don't want to call it "module name" because I could envision other
useful tags as well.)

>> Hey, I got another idea! What about we simply add a second set of docs, for
>> developers?
>> 
>> We have lots of information scattered throughout the website, the source
>> and the heads of important people (the most volatile sort), that, put
>> together, should make a nice set of docs that could be collected (and made
>> a sphinx tree).
> 
> Wouldn't a developer wiki (readable for everyone, writable only
> for developers) be a better and more direct way to handle this ?

The source would be in the repo, so that's already writable for all
developers (without them having to sign up to just *another* system,
with another password etc.), and for the public an automated regular
build, like I suggested in response to Laura, would be even nicer
than a read-only wiki.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



More information about the stdlib-sig mailing list