Let's discuss the things we want to work on here:

Zope 2.12 eggification

• Objective:
• check Philipp von Weiterhausen eggification efforts so far and proceed from that.
• see Zope2.buildout project in svn.zope.org. It describes the 'Zope2' egg which is a Zope 2 distribution minus the Zope 3 libraries, ZODB, RestrictedPython, zdaemon and a few Zope-2-specific packages that have been factored out, largely because they are obsolete or might become obsolete (zLOG, Interface, etc.)
  
• The goal is having a Zope egg containing the current Zope 2 core except some modules like the ZODB, transaction and some others (check the related posting of Chris McDonough, URL missing). The egg will have dependencies to the related eggs of the KGS.
  
• Lead: Andreas Jung
• Supporters:
• Hanno Schlichting

High-availability in zc.buildout infrastructures

• Objective:
• The Python index server (PyPI) is still a single-point-of-failure. From time to time we counter that the server is not available
• A buildout-driven infrastructure depends very much on PyPI and requires that the system has to be running - at all the time.
• This task is more about discussion and brainstorming about the issue in order to figure out reasonable solutions (local caching, independend PyPI mirrors etc.)
• Tasks:
• Extend zc.mirrorcheeseshopslashsimple with a configuration option to mirror packages/eggs locally and integrate it with haufe.eggserver. See also this and this (Mentor: Andreas Jung).
  
• Lead: Andreas Jung
• Supporters:
• Daniel Kraft
  

ZODB

• Objective:
• Haufe Mediengruppe currently runs a Zope 2.8 version with various ZODB extensions and fixes. Check which of them are of interested for the ZODB core.
• ...
  
• Lead: Jim Fulton, Dieter Maurer
• Supporters:

Acquisition aware local component registry

• Objective:
• Build a local component registry which returnes utilities acqusition wrapped in the same way as they were stored without storing acquisition proxies.
• Lead: Michael Howitz
• Supporters:

Caching

• Objective:
  
• A tool, where you can register arbitrary Zope-Objects and that cares about invalidations for you. Maybe together with a tool, that defers the invalidation-events until commit-time and that does things only once per object.
• Lead: Jan Stiller
• Supporters: Josip Delić
  
• use-case:
  
• register content-objects in a CMS and benefit from automatic invalidation and (eg) memcached-speed for access

Devilstick

• Objective:
• Devilstick is a new framework to describe and manage data for Zope. It targets to be used in zope 3, currently it has many zope2 and Plone dependencies. Make it work in zope3!
  
• The model-interpreter needs a refactoring. Partially this already happend, but need to be finished and tested.
  
• Lead: Jens Klein, Robert Niederreiter
  
• Supporters: Markus Leist
  
• tasks:
  
• rewrite model-interpreter and model-importer: new XML-format, enable meta-modelling.
• get rid of zope2 acquisition and make it independend of Zope 2 and Plone for all components outside plone.* namespace.
• use z3c.forms and widgets 

Enterprise-level fulltext indexing

• Objective:
  
• Fulltext indexing was and is always a hot-topic for Haufe as a publisher. Right now Haufe is basically using ZCatalog + TextIndexNG3 for Zope-based applications + our own search engine. Andi Zeidler has been working on the SOLR integration into Zope/Plone. A discussion and brain-storming about the available solutions, the pros-and-cons and a vision for the future for a unique fulltext-indexing platform for Zope might be interesting.
  

• Lead:
  

• Supporters: Andreas Jung