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 _______________________________________________ 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 )