Hey, Generally I believe that these rules if strictly applied wouldn't result in a usable ZTK. Hanno already mentions the testing dependencies, which we've barely started analyzing. Documentation in 'docs' would disqualify just about any package (and Reinout brings up a few objections). A number of thoughts: * even without radically pruning the ZTK particular subsets of the ZTK are becoming a lot more useful than when we started, due the dependency refactoring. This refactoring is ongoing. * we need some stability for those apps that already are built on top of Zope 3. These will still be using zope.app* packages for some time. Right now we can test lots of breakages of zope.app* packages by using the ZTK compattests. If we removed them from the ZTK soon, we'd need an equivalent testing infrastructure for an expanded ZTK, and management policy will be harder. I think we could translate these rules from "not be part of the ZTK" to goals for the ZTK packages: - we should aim for ZTK packages to be used by Zope 3 apps, Zope 2 and Grok. The code in the ZTK should be *used*. - ZTK packages should have narrative documentation. We should actively work to create such narrative documentation. - We strive to remove zope.app.* packages from the ZTK or its dependencies. This can sometimes be done directly but can also be done by refactoring dependencies, factoring out useful code away from ZMI code, etc. The implementation of these goals should be debated for individual packages. Of course this exposes us that the risk that nothing gets done and the ZTK remains as it is forever. A more aggressive set of rules might be seen as a way to force us to do something. I'm not sure whether that's a problem we need to solve: we do have people actively working on improving the ZTK, and this has been ongoing work for most of the year so far. I'm also not sure whether the solution of aggressive removal would work: if we don't do anything, would we really start threatening people with aggressive removal? Regards, Martijn