Note: Cross-posted to twisted-web and twisted-python. Decide between them for your follow-ups please :) This is intended to spark a little more discussion on splitting Twisted into subprojects, as discussed on Aussie-time on IRC (Jerub, jml, spiv and myself). It seems like the twisted-web project are planning to split off fairly soon: see http://twistedmatrix.com/pipermail/twisted-web/2004-April/000312.html It's pretty likely that this split will go ahead without any kind of imposed-from-above decisions about where the website will go, what the release cycle will look like, where the docs will move to, what the status of shared docs will be (I tend to focus on docs...) The nightmare scenario for splitting twisted into subprojects is that every subproject develops its own release code, release procedures, testing framework, website, documentation style, community, policies... etc etc. And shortly after that we all spiral into the sun or something. There appeared to us to be three possible ways of avoiding this: 1. Luck 2. Release code, release procedures, testing framework, website, documentation style, community, policies... imposed from above 3. Twisted Web (or whatever other project splits first) acting as a "model split": evolving release mechanisms, policy etc etc that are fundamentally sane and wonderful so that noone would think of doing things any other way. Since 3 looks like being the most achievable, this is basically an appeal to the twisted-web folk to keep in mind that they should, where possible, try and make twisted-web the Model of a Modern Twisted Subproject. And make it as easy as possible for other subprojects to copy whatever it is that they're going to do. I personally would like to offer my help in documenting subproject procedures as they evolve, and storing that documentation in some kind of prominent place. -Mary