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: http://www.everything2.com/index.pl?node=the%20three%20amigos&lastnode_id=12... 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 really great.
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.
Indeed.
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 documentation. Good luck! -Michel