Hi there, Thanks for kicking off this discussion, here's my "old grump" response. :) On 06/29/2010 05:24 PM, Hanno Schlichting wrote:
- Agree on a process for larger feature changes in "Zope". Things like zope.publisher vs. WSGI, changes to zope.interface semantics, security without proxies, the NoZCML movement, ... - we need to have a way to talk about these in a structured way, document things, create opportunities for feedback from various stakeholders and get a definitive answer on whether we allow it or not. There's different options for how exactly such a process might look like, but I think we definitely need one.
A way to support more drastic innovations in Zope? It's hard to make decisions when there's no code yet, and it's hard to start writing code when there's nobody to make a decision that might ever lead to such a change. I just know what I've been working on: * a new publisher * iface to replace zope.interface and zope.component I think deciding upon such directions as a community can only be done in a very broad sense ("we want to replace the publisher"); as soon as you get into details you might get a few useful ideas and then a lot of bikeshedding (or nobody talking). Whether such changes will ever make it will depend on a small group of people doing the initial work and then doing some marketing. I've been going around the Zope project for years now to get anything innovative done; the community in zope-dev only seems to support maintenance work that everybody can more or less agree on (and we have trouble even with that). I think in a large measure this is all right: the Zope project shouldn't radically change at every whim of a developer. It should however support a community in which developers can experiment with more radical improvements and then adopt them back again. We should support innovation better, and have a way to consolidate innovations back into the ZTK. Candidates include: * the work surrounding zope.sqlalchemy and z3c.saconfig; both already represent consolidations of earlier SA integration work. * Chameleon replacing zope.pagetemplate, and deprecating zope.pagetemplate? * javascript resource handling: we have zc.resourcelibrary, and hurry.resource (radically improving the former), and z3c.hashedresource. Most web frameworks aren't even aware that they need such features yet, but we've had them for a while. megrok.resource integrates them all in a usable way for Grok, but we could adopt this more widely. (But hurry.resource is not perfect; I think it'd be better to step out of Python land and create a Javascript packaging system somewhat modeled on Python's, with easy integration into Python projects. A sprint task?)
- Try to find a way how we can communicate cool new things we do in the various projects.
Good point. We used to have such ways: Conference presentations and dedicated Zope sprints. Let's have a few more of those? And putting more life into planet.zope.org would certainly help too. Regards, Martijn