Re: Expect more!

<jcastagnetto@yahoo.com> wrote : > Just my 0.02 > > The peer-proccess at the moment involves people suggesting a package, and it > being accepted after +5 votes. This is OK for now as the size of the > repository > is still manageable. But it will not be OK for the future. > > We should attempt to have a way to not only propose packages, make them easy > to > be reviewed and accepted/rejected, but to also have some record of the > process. > > It could be something as simple as a 'New Package Proposal' form/section in > PEAR. Each time someone proposes a package, a page is created for that > proposal > (perhaps an entry on a db table or something), and a mail goes to pear-dev. At > that page, people can vote for it and add comments/suggestions/hints/etc. > > After a reasonable period (perhaps a couple of weeks or so), the votes are > tallied, and if they are above a threshold, the package is accepted and added > to PEAR. If they are in a in-between range, they can go through a second round > of review if the authors wants to do that, or withdrawn (btw, proposed > packages > should be able to be withdrawn before any decision is made at any time). If > the > result of the votes is negative, it is rejected. In some cases, it might be > decided that it would be better to merge the code w/ an existing package. The > final decision would then be put in the proposed package page, and the page > contents locked. > > We could even come up w/ a cute acronym for these, the PPP (PEAR Package > Proposals). Basically, if I for example decide to propose a package that > solves > NP-complete equations in under 2 seconds (yeah, right), I will fill a form, > and > will be assigned a PPP number that I can refer too (in the same way we can > refer to bug report numbers). This would be useful, if for example, the > package > I propose is rejected because of serious short-comings or flaws, but the later > when I see the light of reason, get my stuff together and manage to change > some > of the basic quantum laws in the Universe [grin], I rewrite or modify it to > make it actually work, in a new submission I could then refer to the old PPP > number so people would be able to judge the reworked package in context. > > An advantage of a system like the one above is accountability and historical > data. We would be able to always check why something was accepted or rejected. > And, in principle, we can reuse the bug reporting system for much of the stuff > above, including the voting system and such. The only thing we got to make > sure > is that once something is decided that the page gets locked so it will not be > changed further, but that is a solvable technical problem. That's a very good idea. +1. People could vote directly on the PPP page and this page would generate a mail saying Mr. X voted pro the PPP or against, keeping track of the votes and developer comments. IMO, code should not be stored on PEAR, just a link. Who will take care of that ? > Finally, there should be a distinction between what is going to encompass the > PFC (PEAR Foundation Classes) set of packages (any clues on this Stig?), and > the rest of the packages in PEAR/PECL. I never heard about PEAR Foundation Classes. Bertrand Mansion Mamasam