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.
* 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?
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
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.
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -