Right now a discussion is going on in python-dev about what is reasonable for special needs of developers who bring in modules to the stdlib.&nbsp; This of course brings up the idea of slimming down the stdlib, having sumo releases, etc.

That makes me think perhaps we should start thinking about collectively coming up with guidelines (which end up in a PEP; and yes, I am volunteering to write it) on deciding what is needed to accept a module into the stdlib.&nbsp; We can then use this to go through what is already there and trim out the fluff already there and get a list going of what will end up disappearing early on so people can know long in advance.

Now this has nothing to do with a stdlib renaming or anything.&nbsp; This is purely about figuring out what is required for accepting a module and for pruning out what we don't want that we currently have. So, to start this discussion, here are my ideas...

First, the modules must have been in the wild and used by the community.&nbsp; This has worked well so far by making sure the code is stable and that the API is good. Second, the code must follow Python coding guidelines.&nbsp; This means not just proper formatting and naming, but also that good unit tests are included as well.&nbsp; It also means that the module name might need to be renamed.&nbsp; Documentation must also be provided in the proper format before acceptance.&nbsp; All of this must be done *before* anything is checked in (use a branch if needed to hold the work on the transition).

Third, a PEP discussing why the module should go in.&nbsp; Basically, a documented case for why the module should be distributed in Python.&nbsp; It also gives python-dev a central document to read and refer to when voting on whether something should be let into the stdlib.&nbsp; Can also document differences between the public version and the one in the stdlib.

Fourth, the contributor must have signed a contribution agreement. Fifth, contributors realize that Python developers have any and all rights to check in changes to the code.&nbsp; They can do something like how Barry maintains external email releases and document that in the PEP.&nbsp; This is probably&nbsp; one of the more contentious ideas laid out here.&nbsp; But we need to worry about keeping the stdlib easily maintained since python-dev takes on responsibility for code once it's checked in so we need to keep this as simple as possible.&nbsp; Basically this eliminates PEP 360 for Py3K.

Now, another thing is backwards compatibility.&nbsp; Do we worry about portability to older versions like we do now with PEP 291, or do all new modules checked in give up the right to force developers to keep the code compatible to a certain version?&nbsp; This is another ease of maintenance/nice to external release issue.

<br><br>And that external release/ease of maintenance is going to be the sticky point in all of this.&nbsp; We need to find a good balance or we for scaring away people from contributing code.<br><br>-Brett<br>