[Zope-dev] Next steps on Zope 2.6 plan

[Brian Lloyd]

Hi all,

As talked about last week, I've updated the proposed features 
document for Zope 2.6:

http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures

...to cut out those proposals without volunteers. Now comes 
the hard part :^)

There are quite a few proposals there. The current list 
is still a "laundry list" - it reflects every idea that 
someone had and volunteered for without any consideration 
of whether the proposals are good / bad / indifferent.

Now we need to do a "quality chop" to turn the laundry 
list into an actual project plan consisting of only things 
that:

  1 Have volunteers committed to producing the code AND 
    associated documentation 

  2 Are generally agreed to be good ideas, for some 
    definition of "generally" and "good" :)

  3 Can realistically be completed (code and docs) by 
    the May 1 target we are setting for 2.6 alpha 1.

Getting from laundry list to project plan is made a bit 
harder this time around because this is the first really 
community-driven release, and we don't have any real process 
in place for getting there :(

I think that we have #1 above under control, and #3 does 
not bother me that much, but #2 is a tough cookie.

Right now, the laundry list includes some "competing" proposals 
(things that solve the same or similar problems in different 
ways), as well as some "better XXX" proposals that "compete" 
with things already in the core and some pretty big "overhaul XXX" 
proposals with wide ranging non-trivial impacts on documentation, 
packaging and other non-software concerns.

Somehow we need to get to resolution on these things. I know 
that realistically we'll be winging it for 2.6 (there's no 
way that we could get any sort of well-thought-out generally 
agreed upon process in place in time). But while we're winging
it, I'd like for us to be starting to think about these things 
and putting pieces in place as we're able.

One suggestion Casey had was to start to codify a set of rules 
that features have to abide by to be considered for inclusion. 

Some examples here would be:

  - A feature that is a "better X than X" (where X is a feature 
    or component already in Zope), has a much higher bar to jump 
    over since it will almost never be worth the user confusion 
    and extra documenation burden to add another component that 
    does almost (but not quite!) the same thing as an existing 
    builtin component.

    For example, if you have a "better Folder" implementation, 
    the right approach is to add your betterness to the current 
    builtin Folder, because Zope is not going to ship with two 
    kinds of Folder (with the associated two sets of docs, etc.) 
    without a very, very good reason *.

    * Exhibit A for multiple similar objects causing confusion: DTML 
    Document and DTML Method. 

  - A feature release should never contain more than one blow-it-
    up-and-redo-it type project (such as radical changes to key 
    parts of packaging or infrastructure). For example, it would 
    probably be a bad idea to totally redo the ZODB, packaging 
    and installation and the security system all in one release 
    (unless it is a major release like Zope2 -> Zope3). 

    The aggregate impact in terms of obsoleting existing knowledge 
    and documentation is too great to do many of these at once. It 
    takes time for users and developers to catch up after something 
    major is refactored, and we need to keep this in mind.

  - Features or components added to the Zope core should address a 
    clear and generally agreed-upon need. Otherwise, accumulation 
    of components over time will become a significant support 
    burden for the zope maintainers.

  - Features that affect the security system face a higher 
    analysis, design and documentation burden :^)

I'm sure there are many other good guidelines, but you get the 
idea. Having a set of ground rules that everyone agrees on will 
make it easier to keep focused on arguing edge cases (instead of 
every detail) when it's time to define a release.

Thoughts? I'll volunteer to maintain the guidelines document
on dev.zope.org if folks can send their guideline suggestions.






Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716       
Zope Corporation   http://www.zope.com