On 2/21/06, Stephan Richter <[EMAIL PROTECTED]> wrote: > On Tuesday 21 February 2006 05:59, Reinoud van Leeuwen wrote: > > This seems to me a great step forward but I am missing something. > > The quality is measured by a number of metrics, but it seems nowhere is > > actually measured if the software does what it is supposed to do, if it is > > clear how it works and whether it is something you would advise other > > people to use. > > This is one of the major problems I've had in the past with things like > > the Perl CPAN repository: you can find lot's of modules that seem to solve > > your problem, but usually you discover what a module is really about when > > you've invested a lot of time in it. > > Right, I hear you. In fact, this is one of the reasons that we decided against > a name like "Zope Software Quality Program". With the proposed process, we > cannot guarantee 100% that the package is good. However, there are a couple > of safe guards: > > (1) If you write doctests as a narrative text file, you really have to think > hard about the functionality your package provides. I cannot stress it > enough, doctest text files are *key* to the success of the certification > program.
More importantly here, doctests will give people a good impression on what you can do. So I would like to change the doctest requirement (that sais that tests should be in doctest format unless that is not possible) to these documentation requirements: 1. Having at least one reasonably complete usage example. 2. All code examples in the documentation should be in doctest format, and included as a part of the standard test-run. (Maybe you had these in there and I forgot about them, in that case all is fine. :) ) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
