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