[Zope-dev] the Zope Framework project

Martijn Faassen faassen at startifact.com
Tue Mar 3 13:25:41 EST 2009


Tres Seaver wrote:
[snip]
>> (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 
library-like.

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.

Regards,

Martijn



More information about the Zope-Dev mailing list