Hi there, Chris McDonough wrote: [snip] > I'm pretty sure a steering group and a rebranding of existing software is not > going to make us more effective.
I'm proposing a deconstruction, not a rebranding; a new name is introduced as an entity needs to be named, namely the Zope Framework. What is going to make us more effective is: * a recognition of current reality, i.e. the Zope Framework is not the same as the Zope 3 application server and it serves a far wider audience. * leadership > - encouraging radical change for experimentation purposes, releasing folks > from > various constraints (backwards compatibility, style policing, historical > ownership) Who is going to make that decision to encourage this? Allow this? You? Me? Who? Right now, *nobody* is making such decisions and nobody can properly get away with saying they allow it. Leadership is a way to get out of it. > - discourage the contribution of stop energy (discourage > the utterances of "don't", "stop", "this is wrong", > "stop talking about this"). +1, though a simple discouraging of utterance can't accomplish it by itself. What you need is active leadership that encourages such experimentation. > - 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. Sure, I agree with all this. Does everybody? What if we get 3 times -1 and 3 times +1 in a discussion on it? > 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. Someone's still developing all this software: our community. Someone needs to take responsibility for all this software. I'd say that group is the Zope project. Who decides to kill something off? Who decides whether a merge is okay? Who decides we should have a documentation website for a widely used component. > - 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. If you don't have a list of "known good" versions you don't know what to test together, unless you maintain a separate list for each library, which would require a lot of coordination overhead which a single list does not. If you say we shouldn't maintain a known good set, then other systems building on top of this will need to maintain their independent lists all by themselves, and there's less chance that Zope 2's, Zope 3's and Grok's list will agree. I think such an agreement is a good idea. Just because *you* tend to use a few selective libraries for your own efforts doesn't mean everybody else is. I think we should definitely support your use case, but not only your use case. A steering group would be aware of these use cases and balance them. Regards, Martijn _______________________________________________ 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 )