On 05/03/2007 20.30, Phil Thompson wrote: > 1. Don't suggest to people that, in order to get their patch reviewed, they > should review other patches. The level of knowledge required to put together > a patch is much less than that required to know if a patch is the right one.
+1000. > 2. Publically identify the core developers and their areas of expertise and > responsibility (ie. which parts of the source tree they "own"). I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires *much less* knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules. My suggestion is: - keep a public list of official maintainers for each and every package/module in the standard library (if any, otherwise explicitly specify that it's unmaintained). - if there's no maintainer for a module, the *first* volunteer can become so. - *any* patch to stdlib which follows the proper guidelines (have a test, don't break compatibility, etc.) *must* be applied *unless* the maintainer objects in X days (if a maintainer exists... otherwise it will just go in). > 4. Acceptance by core developers that only half the "job" is developing the > core - the other half is mentoring potential future core developers. Acceptance that any patch is better than no patch. There are many valid Python programmers out there, and there are many many patches to stdlib which really don't even require a good programmer to be written. -- Giovanni Bajo _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
