Re: Expect more!

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. 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. --- Pierre-Alain Joye <paj@pearfr.org> wrote: > On Fri, 14 Feb 2003 16:42:58 +0100 > Martin Jansen <mj@php.net> wrote: > > > I agree. But how should we realise that? If we start saying "No, we > > don't accept your package, better merge it into XYZ." people will > > loose interest in the contribution, because of the new changes they > > have to apply to their code. > > I really do not know how to realize/manage that. Even with feature > requests, the sad endless thread about IT araises this problem too. > > I follow lukas whike he says the most important thing is the quality, > quality of codes, quality during the lifetime of the package (ie BC), > the lifetime itself. > > imho, we are at a critical point here. More and more people are involved > in PEAR, and more and more use it. We have to move ahead carefully. ===== --- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Research: http://metallo.scripps.edu/ Personal: http://www.castagnetto.org/ __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com