> 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.

Perhaps I need more beer but whats: F=MA?
--
  Andy McKay.


----- Original Message -----
From: "Michel Pelletier" <[EMAIL PROTECTED]>
To: "Erik Enge" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 13, 2001 9:46 PM
Subject: Re: [Zope-dev] Introducing ZopePrints.


>
>
> 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
5995
>
> 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
>
>
> _______________________________________________
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )
>


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

Reply via email to