Re: Re: PFC-RFC Update

Hi > 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. chregu