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

Reply via email to