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 )
Chris McDonough wrote:
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.
I got a (small) taste of what this could be like with PythonMethods; Michel Pelletier sent me WebDAV methods and prompted me to carefully hunt down unneeded transaction-provoking attribute changes. Jeff Rush sent a document_src for source viewing and PrincipiaSearchSource for ZCataloging. The methods were very small - a handful of lines each - I had just never thought about them. Somebody really ambitious (my hand is *not* raised!) could write a simple guide on zope.org. Start with a checklist of "features" or "design aspects" such as "WebDAV enabling", "Persistence issues", "Searching", "Direct Traversal", etc. Have each item link to a description of the "feature" and a simple set of example methods and issues. Frankly, even some very hurried and rough notes from DC about which base objects and interfaces are deprecated and which are up-and-coming would be fantastic (or does this exist, somewhere?). I would be happy to take something like that and edit it into a more polished document, but I can't write it... I just look at existing classes and copy what seems to work :-(. Consider 'isPrincipiaFolderish', 'isDocTemp', and their ilk. These seem to be ad-hoc flags for the sort of thing Jeff plans to replace with interfaces, and I had no idea until recently that I should be using them in my own Products. This is *not* the usual cry for DC to provide more documentation; It is, rather, a request for more raw information. I suppose that the best thing I could do would be to get up to speed with ZDP and make some rough outlines, so that at least the folks with the deep Zen will have a framework on which to heap their wisdom without spending a lot of time organizing their thoughts. Evan @ 4-am
Chris McDonough wrote:
Though I can't speak at all for DC regarding this matter (this is probably Chris Petrilli's or Brian Lloyd's territory),
Can you get them to speak up on this issue? :)
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.
Right, that's the good way to start, at least. Some guidelines and hints would be very useful.
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).
Yes, that's another way to get the ball running quickly. How do we set this up, though? Some procedures would be in order. I've whipped up a suggestion: * appoint a number of 'Product reviewers'. Basically the Digital Creations product gurus should appoint the first product reviewers (at least 2), which hopefully include themselves. * A particular version of a product is considered to be 'Zope compliant' if at least 2 product reviewers did a thorough review and approve, and no product reviewer at all vetos anything. * Set up a mailing list, Zope-review, to handle product review discussions only. The product reviewers are subscribed, along with product developers who want reviews, and anyone else that's interested. The list discussions may by necessity diverge into debates about standards and guidelines. It may also go into technical discussions on product development, but ideally the latter discussions should be moved to Zope-dev so more people can profit from the information; development questions should go to Zope-dev too. * If a product developer finishes a product that the current product reviewers think is good (and substantial enough), such a product developer can be appointed by them as product reviewer him or herself. Such a developer should be nominated by a product reviewer, and no other product reviewer should veto the appointment. * Being a product reviewer is of course voluntary; you don't have to do anything or to accept any appointment. The idea is to bring structure and some dependability to the review process, not to enforce anything. Nobody _has_ to go through review. And there's of course the open-source ego-boost effect of being able to say you're a 'Zope product reviewer'; if you are that, you *must* be a Zope guru, eh? :) This status effect will hopefully help motivate people to participate in the review process. * Participating developers that are not official product reviewers may of course review each other's code too; this is only good for everybody involved. Such informal product reviews will informally count when official product reviewer status is considered. * Care should be taken that all this procedure does not actually slow down the development process. The entire review process is voluntary; you may still distribute unreviewed products. The goal of the process is to improve the design and code of both Zope and products, and to get to an idea of what it means to be 'Zope compliant', not to make things more difficult (in fact, this should make everything easier!).
I would be willing to work on both.
Great! As I'm developing two Zope products (XMLWidgets and ZFormulator), I can help people field-test whatever you or others come up with. Regards, Martijn
participants (3)
-
Chris McDonough -
Evan Simpson -
Martijn Faassen