Re: Plans for pear.php.net

Martin Jansen wrote:

Guys, whilst I've nearly finished setting up our bug reporting system on bugs.php.net, this is the list of stuff that I will integrate on pear.php.net in the future: * Package suggestion system (PSS): PSS will provide an easy way for programmers to announce their script to the PEAR developers: Instead of posting an announcement on pear-dev (like it happens today) the programmers will be able to fill out a form on pear.php.net, which will generate an email sent to pear-dev. with a link like the php_bugs stuff eg.

http://pear.php.net/package_vote.php?vote=I_LIKE_THIS+GOOD_NAME http://pear.php.net/package_vote.php?vote=I_LIKE_THIS+BAD_NAME http://pear.php.net/package_vote.php?vote=DONT_MIND http://pear.php.net/package_vote.php?vote=DISAGREE I think lukas hit the nail on the head - quite often it's the package name which drags on, It would be nice to get down on the site what the naming strategy is.. - when are top level names added, eg. 'weather', and how do the pear website categories relate to the naming structure....

People with a website account will then be able to vote for the package for n days. After N days if not enough votes have been recieved (either +5/-3) etc. ??

then a reminder is sent out to pear-dev 'get of your ass and vote :)' and so on.... until the totals have been reached.

After n days, the package will be

     a) accepted, if there are more positive than negative votes and
        if there are at least 5 positive votes.
     b) rejected, if there are more negative votes than positive ones.
     c) postponed, if the positive votes are equal to the negative
        ones. In this case, the vote can be either restarted or one
        of the PEAR administrators has to give a final vote.

Once the vote is closed, the result will be mailed to pear-dev and to the contributor and a new package will be created on pear.php.net, if the package has been accepted. The intention of PSS is to reduce the traffic on pear-dev and to provide an easy way for future contributors to add their stuff. * Developer page: Similar to account-info.php a page will be set up for each developer where he can see, which bugs have been filed for packages he is maintaining. For an example of this, see http://qa.debian.org/developer.php?package=php4. I was wondering about the bug tracker - at present it will issue a bug to php-bugs@lists.php.net, and probably pear-dev.. however since php.bugs gets 100-200 a day sometimes, I often get up and just trash the lot (eg. filter on #) and might miss an important bug in one of my packages..

I guess a weekly 'pear-summary' if there are any outstanding bugs, and a monthly 'feature request' summary email would be a good idea.. Regards Alan

Both this tasks are things that I will realize in a medium- or longterm, as I will be pretty busy with university things in the next months. Comments are welcomed. - Martin