Re: Zope summit topics

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

_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )