Re: [pear-webmaster] feature additions: most popular releases, package download rank

NOTE : If you cant understand my English, contact me on #pear@efnet Gregory Beaver > Hi, > > I would like to add 2 things to pear.php.net to help get a sense of the > most used packages, and help motivate PEAR folks to take a look at who > is using their code. > (This reply is a alone-brainstorming, pick idea or critic its, don't let me in my fog) I have some proposal as - Be able to filter search/browse on stable or stable+rc status, requirements, - display in web command to install the package - dependence's tree (display a tree of alls packages) - involve user to submit via a form : * new tests * new samples (document or runable as demo) * use cases, feedback, ... - one documentation per package (cut the complete manual like rdoc in Ruby) I think Pear.php.net need to expose also "where" and "when" to use a package and not only "how". Trackback is a good system but everybody don't have a blog. Perhaps "Pear's user general blog" can born and propose a moderated blog where an account is offer to users of pear packages. You can note that some props are existing but hidden under an other name. "encourage user to submit via a form" -> bugtracker can work for this... Pear is many thing and it's not showed - PEAR is a packaging project (packages pear can be on many channels) - PEAR is a community, with team, sub-team, coders, users, writers, testers, sharing some times to a project. - PEAR is a class repository project with rules (official pear channel) I thing not be wrong if I say - that a class writer can be out of the community (I never talks on #pear or lists, with many many maintainer) - that a package can be out of the rules of class repository - that a class in the repository project can be efficient and never packaged - that a member of a package can never package or code a class All that to show that the tree PEAR up there aren't the same "PEAR". use in thread (outside our community sphere). I think that these differences would be shown. Because some coders agree to less than the tree. Let understand that they can found an interest in one of them before learn to agree others. In practice I think to coders which again want do all home made. Let them understand to packages their own class, later to discover feedback of community, and perhaps later follow pear coding rules Let understand to simple user that make a constructive feedback can begin to tell a complete history of their experience. They don't need to produce a patch or a doc to feedback an enter in community. (Yes with a patch or a doc or tests ... It's much better ..) -- Moosh -- claroline.net -- php.net === Php & Pear & MySQL === http://moosh.et.son.brol.be/ (fr) 11-2006 Forum PHP http://www.afup.org/ (fr) 02-2007 FOSDEM 07 http://www.fosdem.org/ (en)