Re: Re: PFC-RFC Update

From: Date: Tue, 25 Feb 2003 22:21:19 +0000
Subject: Re: Re: PFC-RFC Update
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-13901@lists.php.net to get a copy of this message
El Mar 25 Feb 2003 18:41, Markus Wolff escribió: > On Tue, 25 Feb 2003 22:15:07 +0100 > > "Tobias Schlitt" <toby@php.net> wrote: > > The only difference between my idea and the actual discussed > > model should be to define the quality not only in 2 steps (PFC > > and not PFC), but in some more steps, so that classes can grow > > into PFCs while working on them. > > Hm, I must have missed your last post on this (not too difficult > regarding the mail traffic during the last week or so)... so I don´t > know if you might have proposed something like this already, but here´s > what pops in my mind when I read the above paragraph: > > - Introduce a rating system where people can vote for several criteria > of the PFC independently. Example: > - Compliance to coding standards: 4.5 points average > - PEARDoc documentation: 3.5 points average > - PHPUnit test scripts: 1.3 points average > - Actively maintained: 2.6 points average > - ... etc. ... > - Overall rating: 4.7 points average > - Everyone with a PEAR account can vote, the points are the average > number of points given by the voters I agree with Tobias that a binary system (PFC/Non PFC) is not the ideal, and a system with PFC and "on the way to become" PFC packages is better. Users should be able to view "how" PFC compliant a package is. It seems very different to me saying "package X is non PFC", than saying "package X complies with 13 out of 14 criteria needed for PFCness". That said, I don't think voting is a good idea for checking compliancy for all 14 criteria. Working with error-reporting set to E_ALL, working with register_globals = off, and others, are more of a yes/no nature. > - A core PFC group will have to personally review a PFC candidate and > manually elevate it to "Approved PFC" level. This last manual step is > IMHO neccessary to avoid manipulation of the voting mechanism and > ensure quality. This seems like a good idea.

« previous php.pear.dev (#13901) next »