[Zope-dev] the Zope Framework project

[Martin Aspeli]

Tres Seaver wrote:

> Different participants will report differently about the success, no
> doubt.  One unexpected outcome (for some) was classifying the
> "decisions" taken at the PSPS as "advisory", "just talk", etc:  having
> no force in governing the more "tactical" decisions.

I don't know why this should be surprising. Things only happen in open 
source when people do them. A deliberately limited cross-section of the 
Plone community (not all core developers were even invited, and more 
than half of the people there were not core developers at all, but 
included integrators, end users and businesses) could in no way make 
binding decisions "offline" in the space of two days, and somehow impose 
them on the other people who would actually have to do the work.

We did achieve what we wanted though: We discussed a lot of pain points 
and clarified a lot of things that people had been arriving at 
independently, but not quite expressed. We created a lot of consensus 
around things we wanted to focus on. That consensus helps us develop new 
versions of Plone.

>> (though I did hear positive news about it). I do have the 
>> impression the framework team strategy works reasonably well; it's been 
>> operating for about 2 releases now?
> 
> It works as a way of sharing the load with the release manager.  Because
> its members don't feel empowered to make longer-term decisions, I don't
> think it quite fits the model you have proposed for a steering group.

No, it doesn't, any apologies for jumping in with this and perhaps 
making it sound more "same" than it was. I think it's a useful example 
of how to *organise* such a thing, even if the exact tasks may be a 
little bit different.

> In effect, Hanno Schlicting is doing the "long-term" direction setting
> as the Plone4 release manager:  Limi is basically cheering him on.

I don't think it's quite as simple as that. The release manager has some 
veto rights and a loud voice, because he is tasked with thinking about 
how these things fit together. He doesn't get to wear a dictator hat.

The discourse on the plone-dev list (and conferences and sprints and 
IRC) is setting the long-term direction, as a product of the community. 
I think perhaps Plone has a better structure (release manager, framework 
team, Foundation) through which that discourse is channelled, in order 
to build consensus and, perhaps, make for some more productive 
discussions, than what we sometimes see on this list.

In my experience, having the right amount of structure (be that in a 
team, or a company, or a community) makes it easier to be productive and 
constructive. Maritjn's proposal addresses some of Zope's challenges by 
adding some structure where there is currently a void.

> Here is where I think we differ:  I can't imagine the group you are
> sketching out having much of *any* impact on day-to-day stuff.  In
> particular, I don't believe that a BDFL (whether an individual or a
> group) "channels" energies:  mostly, the BDFL serves as a "court of
> final appeal" when the developers can't reach consensus.

I think a good BDFL prods people into reaching consensus before it ever 
comes to that point.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book