On 12 Feb 2001, Erik Enge wrote:
> The rationale behind this is that the community at large would benefit
> from this by having _real_life_ case studies so when their time has
> come to implement an application in Zope, they don't fall into the
> same traps and pitfalls we did. Instead of benchmarks, the Zope
> community would use implementation documents to decide whether Zope is
> up for the job or not, that's what really helps.
We would love to see this description from you. We inside DC have our own
problem solving development process that is large, complex, slow, but
often (IMO) accurate if done well. It is based partly on the "Rational"
model developed by the Three Amigos:
partly on chaos theory, Jim's three laws of engineering (1. F=MA, 2. You
can't solve a problem unless you know the answer, 3. You can't push a
rope) and on the abundance of Thai food.
We also have a "fishbowl" experiment community process, a "dogbowl"
content managment design process, a documentation process, and one
horse-choking travel policy.
I think it would be great to get examples of your problems in a case study
format, but also in a higher-level, pattern like description. Your
description sounds like it is based on the problem and the goals, which is
> I'm quite sure that it will also work as a tool for finding gaps and
> holes in either Zope or its tools and Products.
> We would like to start a project going in the Fishbowl which aims at
> creating the right tools to document a project as described above.
The fishbowl is the perfect place to do this. In a conversation with
other people including Brian who is the "keeper of the fishbowl" we
realized that documentation artifacts come out of the fishbowl almost as
much as the software. In fact, that's one of the whole reasons for the
fishbowl, to come up with better software because we thought about it and
wrote down some words before we started hacking code. Instant
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -