Re: Re: priorities for PEAR project as a whole

Im not beating a massive WIKI drum here but collaboration and communication are the basis of any successful project, it seems to me from my short time in PEAR that this is what is missing. I personally have always disliked mailing lists as a method - especially primary of communicating with a team, or community, a forum to me is just more elegant. http://forum.joomla.org/ except maybe Joomlas is a little large :) Joomla also monetise this area with google ads even though they are open sourece too. what i suggested was to immitate then evolve what http://framework.zend.com/ are doing, there front site is glamourous, has the necessary content and tools. I know that Zend and PEAR are different but the concepts are similar. PEAR is a long way ahead of Zend lets keep it that way. Fed up of rewriting all my code to move onto new platforms also :) I suggest writing a http://framework.zend.com/roadmap PEAR needs one of these, no-one knows where PEAR is going - sure it lurks deep it BeebleX somewhere, which list I am not sure :) What I really like is this though - http://framework.zend.com/wiki/dashboard.action - its impressive and will aid collaboration from not just core members but all PEAR community. Zend dont seem to offer a Mailist .. http://www.joomla.org/ is also one of my favourites To get proffesional design help - plan: I suggest an Official Wiki, I reckon a good introductory comment may be to run a competition to design the new logo (want this - http://www.joomla.org/content/view/259/70/) and front end design and concepts for PEARweb, with a prize 1. a link from the front page to the designers site, with PEARS PR and visitor count this is indeed a nice prize to win. A few marketing emails will generate a little buzz for that i think. Just something I think will aid in categorisation: I also suggest splitting PEAR up into two sections - CORE and COMPONENTS with the idea of getting developers focused on developing the real building blocks of PEAR. CORE being packages like MDB2 DATA_OBJECTS DATA_STRUCTURES etc COMPONENTS DB (I put this here as it is superseded by MDB2 I think?) PAGER NET_SMS etc ..... Also what happened to Google summer of code entrants http://php.net/ideas.php - did PEAR get any students to do these ideas? Sorry I do RANT sometimes - so take please forgive me if that pisses some people off, but once I start writing I cant stop.. Regards Ian Warner Director Triangle Solutions Ltd Alan Langford wrote:

On 2006 09 27 15:52, Greg Beaver wrote:

Hello all, I want to re-iterate the priorities for PEAR as a project that I brought up last spring, and see if we might be able to pull a few of you off of other projects for a short while to expedite this process. Summary: #1: make the PEAR website PEAR-installable, instead of syncing from CVS #2: add package groups for the website and for installer REST #3: any other changes, political or technical Long version: What problems do we have in PEAR at the moment? First, there is an awful lot of bickering over how we're going to do the PHP5 thing in PEAR. Second, almost all recent political decisions have not been clearly documented on the website. Third, we have lots of packages and very little oversight and cooperation between developers to do QA and assist each other with details. Most of these problems go back to the website, and the way that it directs the political and technical discourse in PEAR. Right now, it is hard - and also dangerous - to update the website, because it is synchronized directly from CVS. Hence, priority #1: #1: make the PEAR website PEAR-installable, instead of syncing from CVS. This will allow us to try out some experimental things, and also make it much easier to QA the website prior to a public release, spurring innovation and stability. Part of that innovation involves a technical change to the website that will enable a better political dialogue in PEAR: #2: add package groups for the website and for installer REST this will allow us to do a lot, especially with separating older packages from newer, and even grouping related packages in intuitive ways beyond static categories. #3: anything else deciding on the exceptions usage, re-organizing PEAR group - all of this can wait until we have a more dynamic front page and presence. Comments? Thanks, Greg

Man, go away for a couple of days and look what happens! As a relative outsider, I have to say that the web site has been a huge disappointment. Sure, it's my fault for not digging deeper, but it wasn't until I used the web based installer that I was forced to look at all the capabilities in PEAR. Granted it's grown a lot over the past two or three years, but during that time I've developed implementations of a number of packages that duplicate PEAR functionality that wasn't there before. Duplicate effort really irks me. Instead of inventing my own wheels, maybe I could have been working in a team to help build PEAR packages. There's a few things I'd love to see from the web site: * multiple views of packages, by title, by keyword (or tag, if you prefer), an overview list that includes package status, a big page with a short abstract of every package. * Something that lists what people are working on or want to work on, no matter how informal. Maybe some process where an idea can incubate from idea to concept, to development team, and finally to released packages. * User comments in the documentation, like the main PHP site. There are hundreds of developers out there with something to contribute. They should be able to have a voice without mastering docbook. * Some way of allocating effort for large scope projects. I'd love to help transition a package from PHP4 to "native" PHP5 (which in my book means far more than just E_STRICT), but I don't want to spend weeks on something just to discover that there are three others doing the same job -- I'd rather work closely with those folks to make the job easier and quicker.