> When we first opened the fishbowl, it was with the certainty that we
> wouldn't get it right immediately. That's why we went with the intentially
> low-tech approach of a pile of Wikis. That first step actually worked
> pretty well for a while until we hit critical-Wiki-mass and there were
> suddenly too many proposals / projects to follow easily. So please don't
> think that we are somehow attached to the current fishbowl implementation
> as some sort of be-all-end-all.

I think that there ARE problems that can not be solved on a mailing list or
in the fishbowl. One of them is doing a good general design (which we MIGHT
need for some of the Zope 3.0 issues). I followed all the stuff about the
CMF and formerly PTK and knew that it was heading to a direction I didn't
want, but at the same time I felt that it would not help if I just
contributed to the mailing list. Maybe this was a personal problem of mine,
but I don't think so.

IMHO, there are two possible approaches to problems like that (major design
issues I mean):

a) dictatorship, if the dictator is really good in his job (e.g. Jim Fulton
has done a great job with regard to the design of the ZODB )

b) meeting in real live (or at least in real time)

Some of the core architecture of the KDE KParts component model was
developed on the KDE 2 conference AFAIK. I think we might have to do
sessions like that at the upcoming Zope/Python conferences ...


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to