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.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -