[Zope-dev] Product standardization

[Chris McDonough]

Though I can't speak at all for DC regarding this matter (this is
probably Chris Petrilli's or Brian Lloyd's territory), I like the idea
of having a slightly more formal definition of what constitutes a "good"
product, even if that definition only consisted of a couple of pages of
"shoulds" and "shouldn't"s.  I also like the idea of a loose sort of
peer review (other than someone just downloading the product, finding
out it doesn't work, and posting to the mail lists).  I would be willing
to work on both.

Chris McDonough     mailto:chrism@digicool.com
Digital Creations   http://www.digicool.com
Publishers of Zope  http://www.zope.org

> -----Original Message-----
> From: Martijn Faassen [mailto:m.faassen@vet.uu.nl]
> Sent: Wednesday, January 05, 2000 9:38 AM
> To: zope-dev@zope.org
> Subject: [Zope-dev] Product standardization
> 
> 
> Hi there,
> 
> Many of us are developing products for Zope; either in pure 
> python, pure
> ZClasses, or a combination. I'd like to make the products I'm 
> making as
> 'Zope compliant' as possible; that is, they should use:
> 
> * the standard Zope web interface
> * they should follow the standard Zope security conventions
> * when possible, they should implement a number other standard Zope
> interfaces, such as the properties interface and the object manager
> interface.
> 
> The problem is that there is, as far as I know, no:
> 
> * standard Zope web interface definition
> * standard Zope security conventions description
> * description of other standard Zope interfaces
> 
> This is in part a documentation problem, but in part it's simply that
> the standards are probably undefined. The classes to inherit from are
> there in many cases, but I personally am in the dark concerning many
> issues. I just practice 'voodoo programming' where I just do stuff
> because I know I have to, but haven't a clue why. This is bad. 
> 
> So, could we start somekind of process in order to define 
> what it means
> to be 'Zope compliant'. I have in mind:
> 
> * standards documents 
> 
> * guidelines documents
> 
> * motivations and explanations of the standards and guidelines.
> 
> * tutorials and examples, such as products like the 'Boring' product
> that give working and compliant examples.
> 
> * a peer review process; developers review each other's 
> product code for
> standard compliance. Product users can do part of the 
> reviewing as well.
> 
> * Perhaps somekind of 'official approval stamp', that at least gives a
> clue that the product you're using is mature and complaint. Though we
> should watch out that this process wouldn't slow down development.
> 
> Doing this could help us in many ways; we learn more about 
> how to write
> a product, we learn more about how to write a *good* (secure, usable)
> product, and finally the development of Zope itself is helped by
> pointing out what people use/should use, and suggestions for future
> directions.
> 
> Any comments, ideas?
> 
> Regards,
> 
> Martijn
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> 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 )
>