Martijn Faassen wrote: > The Zope Framework project > ========================== > > :Author: Martijn Faassen > :Date: 2009-03-02 > > Introduction > ------------ > > This document offers suggestions to reorganize our community so we can > act more effectively. It does this by trying to clarify what our > community is about. The document tries to innovate minimally in > concepts and naming in order to provide a relatively small > evolutionary step forward that can still make us all work together > better. Even though this is an evolutionary step, it will still have a > big impact if implemented, so please read on. > > This document should be relevant to *all* the parts of our community > that build web applications, whether they use Zope 2, Zope 3, Grok, > Repoze, or applications built on top of these such as Plone or > Silva. While it talks a lot about Zope 3 this is because the Zope > technology within Zope 3 is used within all these projects. The > document wants to recognize this officially. > > The main innovations in concepts are the name "Zope Framework" to > distinguish it from the Zope 3 application server and the > "core"/"extra" concept. These are all hopefully descriptions of what > are current practices, simply making them more explicit. > > The biggest innovation is the introduction of a Zope Framework > Steering Group as a new entity that will be the steward for the > development of this framework. The steering group's primary aim is to > facilitate developers in the community so that they can continue to > maintain and develop the framework so that it is useful to all of us.
I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility, style policing, historical ownership) - discourage the contribution of stop energy (discourage the utterances of "don't", "stop", "this is wrong", "stop talking about this"). - focusing on externalizing software; each egg should stand on its own as something that a non-Zope person would be able to understand and use in isolation. This means documentation for each thing, as well as a sane dependency graph. This is *less* about giving this collection of software a group name ("the zope framework") and more about making people *forget* that it is a part of some larger thing. When a piece of software does not have a purpose in isolation but still lives in its own egg, kill it off and merge it back into whatever thing its most closely related to. - Stop trying to version control and treat all this software in some overall release. Let each piece of software have its own life. Likewise if a piece of software does not have its own life, kill it. - C _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )