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.
- C
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
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.
(2) At least in the Common Repository, people will read check-in
messages.
(3) At higher certification levels, other people must support the
package.
This is also not 100% bullet proof, but it is something.
Overall, I also expect that the community has little tolerance for
malicious
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
where
people that have tried the module could enter a rating?
Ah, rating and feedback. :-) This was discussed in the pre-proposal
phase as
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
missing in
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.
Very cool,
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
certification
manager, who might know nothing about the issue and will need a lot
of time
reviewing the complaint and solution. Not so good.
While rating and feedback is good, to do it right in a process like
the ZSCP
costs a lot of resources.
Having said that, I see the need to address the issue. Here are two
suggestions:
1. Add a "Future Possibilities" section to the proposal collecting
ideas for
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
done.
2. There is already a provision in the process that a package can
receive a
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
community
members and 1 certification manager verified a bad package. Each
warning
carries an arbitrary comment that could describe the reason of the
warning.
This way we can use the existing communication channels (mailing
list and
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
warning.
What do you think?
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
