Martijn Faassen wrote: > It might be we are able to establish a "framework team" without > elections by just picking out the bunch of people who are interested in > this.
That's been the Plone approach to creating the "framework team". Some people just decided to do it and didn't even bothered to ask publicly on any mailing list. If you want to mimic the Plone approach you do: Martijn, Stephan and Andreas form the "Zope Framework" team. They decide by themselves if they should take on exactly two more people or not. If one of the three doesn't want to do it, the other two find someone else. Their only task is to release version 1 of the "Zope Framework" by this summer. It's primary concern is to serve as a common stable ground for Zope 2.12, Zope 3.5 and the next Grok version. As part of such a release they get the power of deciding what packages are part of the release and which versions of them. They are responsible for taking care of proper release procedure and documentation of the release. If they cannot encourage people to help them, the shitty work is on them. And that's it. Obviously you get to do some decisions which are really about strategies beyond the release, but you can only execute them in the limited scope of the one release. By the end of it, you look at what you got, find some new people (with some overlap to the old team) to steer on the next version of the Zope Framework and see how it goes. You don't try to organize all of Zope at once, but claim your own little field. If everything goes well, you established communications between three large communities and they have a way of discussing changes based on their technical merit. Maybe "Zope Framework" version 2 brings even further reduced dependencies and ditches the publisher for a real WSGI story. But that's not the discussion right now. You can try to bake more leadership of the overall Zope community into this, but I think this is a fruitless fight right now. Reduce the scope, try make some things better and don't step on other peoples feet if you don't need to. For example don't try to push out style-guides for the entirety of the svn.zope.org repository. They lead to bike-shed discussions and discourage contributions. Hanno _______________________________________________ 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 )