RE: [PEAR-DEV] Re: PFC-RFC Update

> From: Christian Stocker [mailto:chregu@bitflux.ch] > Sent: Wednesday, February 26, 2003 8:28 AM > > I definitly agree that a group of about 5 people should be set > > in as a PEAR-QA-Group and should rate the packages by the > > characteristics you noticed. > > Either you propose a new PEAR-QA-Group or there's a missunderstanding > about my proposal. My proposed PFC-core-group (aka PFC-gc) should not have > to do QA for all those packages out there. That would be a hell of a > job... PFC-gc is merely there to control, if a package fullfills all > requirements. They base this desicion on some kind of report the 2 > independent peer-reviewer provide about the package. If they don't trust > the peer-reviewer, they still can dig deeper into the proposed packages. > > > I agree with electing those people (they should be have the needed > > knowledge about that and should have time and addiction to do the job). > > and that's hard to find these days, btw :) Therefore I'd really like to > get off as much work as possible from the PFC-gc and spread it among > others. Whoever has time and skills to do it and not accidently belongs > to PFC-gc. > > > My Idea for rating the classes is to give them points (e.g. stars) for > > matching some requirements. Initially every package should get 1 point. > > When fitting to the coding-standards it should get 2 points,... A scale > > from 1 to 5 is IMHO appropriate for that. > > I like the idea about having the information of "how many requierements of > PFC or fullfilled". I wouldn't rate them (I'm not a big fan of this 0..10 > rating systems, it's like to be back in school ... ), just a table with > the needed info. for example: > > Has unit-tests : no > Runs with E_ALL : yes > Runs on Platform : Windows/Unix > etc... > > And most importantly to me, this should happen on a self-description base. > Meaning the lead developer of each package decides which points he thinks > are fullfilled. This could be done within package.xml or via an > web-interface. I don't think, pear-developers will missuse this system. > It's a lot about trust anyway, 'cause I don't want to introduce > PEAR-police ;) > > > What about the way the classes are attempt to get rated? If this 5 > > people in QA-group have to rate every single release of a package they > > will have a huge amount of work to do. So, there should be a mechanism > > implemented for signing a new release as "to rate" or "same rate as last > > release" (more or less you should have the opportunity to mark a release > > as "to rate" only once per month or something else). > > This will not work, IMHO. How many packages are released each month? There > will be just a big queue in the "to rate" section and big pressure on > the pear-qa-team... > > To sum up: I see the negative point of the PFC-code vs. > this-is-bad-non-pfc-code proposal. Therefore some more information on > non-PFC-classes, why they are not bad at all, wouldn't hurt anyone. But > I really don't want too much work on single people and make the whole > system dependent on having people around with enough time. I very much agree with that Christian has said here. PFC's will serve as a role model. To get the badge the PFC-group will need to examine the package in the way Christian suggested. All others should have the ability to show on their package page what criteria's they fulfil. But this does not need to happen from outside observers. A commentary system would be enough to ensure that the package information matches reality. Regards, Lukas