[Checkins] SVN: zopetoolkit/trunk/source/steeringgroup/ Christian and Martijn made some decisions about how we're going to manage

[Martijn Faassen]

Log message for revision 101530:
  Christian and Martijn made some decisions about how we're going to manage
  open issues and blueprints more publically. Also record some ideas about
  how we can improve the ZTK: we need to talk about these in public so that
  other people can help out.
  

Changed:
  U   zopetoolkit/trunk/source/steeringgroup/decisions.rst
  U   zopetoolkit/trunk/source/steeringgroup/openissues.rst

-=-
Modified: zopetoolkit/trunk/source/steeringgroup/decisions.rst
===================================================================
--- zopetoolkit/trunk/source/steeringgroup/decisions.rst	2009-07-04 14:29:36 UTC (rev 101529)
+++ zopetoolkit/trunk/source/steeringgroup/decisions.rst	2009-07-04 14:33:03 UTC (rev 101530)
@@ -151,3 +151,8 @@
 
   * We are in the process of developing a testrunner extension that
     will report on indirect imports, and a ZODB upgrade procedure.
+
+* The open issues will be moved to the launchpad blueprints and
+  launchpad answers. The blueprint specifications will be stored in
+  the ZTK documentation and linked to (each blueprint will be a
+  separate document).

Modified: zopetoolkit/trunk/source/steeringgroup/openissues.rst
===================================================================
--- zopetoolkit/trunk/source/steeringgroup/openissues.rst	2009-07-04 14:29:36 UTC (rev 101529)
+++ zopetoolkit/trunk/source/steeringgroup/openissues.rst	2009-07-04 14:33:03 UTC (rev 101530)
@@ -39,10 +39,22 @@
     * zope.interface, zope.schema, zope.component, zope.event,
       zope.i18nmessageid
 
+* publisher and traversal simplification: Shane Hathaway's WSGI
+  pipeline work, Jim's new bobo should be points to explore.
 
+* reusable components that include a UI. Might be separated into two
+  components (API and UI), or even three (API, web service and
+  UI). Example use cases are user management and tagging. Explore
+  Pinax for more examples. The irony and great potential of the ZTK
+  right now is that we *have* a component story that works pretty well
+  so we *should* be able to do great flexible UI components, but we
+  don't have a good story for this at all.
 
+* dependency refactoring: this is an ongoing process to try to flatten
+  the dependency structure between packages and allow greater reusability
+  of our code, and reduce the amount of code that is needed in a minimal
+  setup (less to understand, and less startup time).
 
-.. note:: 
-   We may want to move over the management of such issues to
-   launchpad? Not?
+* startup time: reduce the startup time of ZTK applications so that 
+  the paster auto-restart becomes more tolerable.