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-announcehttp://mail.zope.org/mailman/listinfo/zope )