[Zope-dev] the Zope Framework project

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Paul Everitt wrote:
>> On 3/2/09 10:13 PM, Martin Aspeli wrote:
>>> We recognised that there was a problem in trying to make sure we
>>> represented the interests of various stakeholders, and that we needed
>>> someone to think "big picture" in terms of what technologies we adopted
>>> and how we used them.
>> Just to be clear, I believe the Plone framework team has specifically 
>> disavowed management of Plone's "strategy".  Meaning, they approve PLIPs 
>> on a release-to-release basis.  They don't make edicts like "replace 
>> Archetypes".
>>
>> This was the vacuum that the "strategic planning summit" advertised 
>> itself as addressing.
>>
>> I think this clarification is informative to Martijn's discussion.
> 
> That's interesting indeed.
> 
> It's hard to know whether Plone's method of a "strategic planning 
> summit" is working on the long term as you only had one as far as I 
> know.

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.

> (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.

> 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.

> 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.

> 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.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrXI/+gerLs4ltQ4RAvf1AKCpRxuSfU6pOzhv5GNCwoOioZwmCwCgsXK/
M7L/DTDqiGyu/lhdBw56e2s=
=vnGh
-----END PGP SIGNATURE-----