I hate to cross-post this, but would it be possible to limit this
discussion to a single list (e.g. zope3-dev, maybe)? I'm interested
in this topic, but my mail client isn't smart enough to filter it out
to only one place and I'm sure there are a lot of other people with
the same issue.
On Feb 21, 2006, at 9:45 AM, Stephan Richter 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
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
the Perl CPAN repository: you can find lot's of modules that seem
your problem, but usually you discover what a module is really
you've invested a lot of time in it.
Right, I hear you. In fact, this is one of the reasons that we
a name like "Zope Software Quality Program". With the proposed
cannot guarantee 100% that the package is good. However, there are
of safe guards:
(1) If you write doctests as a narrative text file, you really have
hard about the functionality your package provides. I cannot stress it
enough, doctest text files are *key* to the success of the
(2) At least in the Common Repository, people will read check-in
(3) At higher certification levels, other people must support the
This is also not 100% bullet proof, but it is something.
Overall, I also expect that the community has little tolerance for
attempts to break the system. If someone detects foul play all he
has to do
is complain on the mailing lists.
Would there be room for a voting or feedback step in the process
people that have tried the module could enter a rating?
Ah, rating and feedback. :-) This was discussed in the pre-proposal
well. The problem with feedback and rating is that to do it right, it
requires a lot of resources that we do not have. Here is a scenario:
1. A user U trashes a package because an important feature F is
package P. So far so good. It is his right to do so.
2. The package P authors see the comment and fix it in the code.
the process works.
3. But then the user U of the post, must retract his comment. What
if he is
not available? Not so good. The alternative would be to ask a
manager, who might know nothing about the issue and will need a lot
reviewing the complaint and solution. Not so good.
While rating and feedback is good, to do it right in a process like
costs a lot of resources.
Having said that, I see the need to address the issue. Here are two
1. Add a "Future Possibilities" section to the proposal collecting
later iterations of the process. This would allow us to address
some of the
common concerns and say: If we have time and resources, this can be
2. There is already a provision in the process that a package can
warning. Currently the ZSCP states that the warning can only be
issued when a
package does not fulfill the quality metrics for a given release.
I could add another provision that a warning can be issued, if X
members and 1 certification manager verified a bad package. Each
carries an arbitrary comment that could describe the reason of the
This way we can use the existing communication channels (mailing
IRC) for feedback and still have a way to formalize feedback. I
guess in this
case we would also need a "resolve" action that could resolve a
What do you think?
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-users mailing list
Zope3-users mailing list