Tres Seaver wrote:
>> (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.
Okay, that's interesting. Undoubtedly some ideas about long term
direction sneak into a framework team to guide them with decision
making, but it's not exactly the same model indeed.
>> So you have one mechanism to set long term directions (and I think
>> another one, namely Alexander Limi), and another to execute these long
>> term directions and make smaller decisions in the light of them.
> In effect, Hanno Schlicting is doing the "long-term" direction setting
> as the Plone4 release manager: Limi is basically cheering him on.
Ah, so Plone currently has long term direction as they think 2 releases
ahead of just one?
I guess my proposed Steering Group would take on some of the aspects of
both. I think you could set up a Steering Group per release with a bit
more mandate to cover long term directions than perhaps the Plone group
has. There'll be continuity as some of the membership will carry on to
the next release typically.
>> In reality of course a lot of micro decisions can result in a long term
>> direction, so there's a gray area there.
>> For the Zope Framework I think it's more important to get the day to day
>> decision making working in our community than it is to do the long term
>> setting of directions and planning. We do have some form of long term
>> direction emerging that we can recognize often enough (though we can do
>> a lot better still). The core problem in my mind is the day to day
>> decision making and channeling of energies.
> 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.
Okay, I guess we do differ here. I think a leader can provide
encouragement and stimulate people into action, point out interesting
outstanding tasks, and make sure that people who are motivated actually
get grip on improving the project and don't get discouraged. Of course
all these things only happen *some* of the time. It's hardly magic. But
it does contribute in my experience.
>> I myself am inclined, for the Zope Framework, to start with the day to
>> day team. I think it can deduce at least some long term directions from
>> the community on the mailing list and usage in practice (also by
>> consultation). We could amend such a process with a strategic planning
>> summit construction, later.
> If the team you are talking about is going to manage a "root KGS", or
> something, from which Zope2, Zope3, Grok, etc. derive their own
> versions, then it seems to me that success lies in keeping that KGS
> smaller than larger, and focused mostly on the "libraryin" bits.
> Expanding the core KGS later will be lots easier than shrinking it.
I agree the end product should be smaller rather than larger and more
But it should also be concerned with turning a larger set of libraries
into better libraries. Imagine we had defined the KGS to contain zope.*
and not zope.app.* back in december 2008. It wouldn't have had a
container implementation, which I think is an interesting piece of
shared technology. If we did it today we'd have had zope.container.
That's why I think it should start inclusive and then focus heavily on
turning it into a better set of libraries.
In my mind such a "turn it into a better collection of libraries" is one
of the most important long-term activities for the framework developers.
I think that's something everybody can be on board about. In the end
it's a tree of packages where people should be able to participate at
any node, but I do think we need to keep an overview of the tree as well.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -