On the PEAR Group blog there's a new post welcoming all new contributors to the project and pointing out that the PEAR account on Github has officially passed the 200 repository mark in the move from SVN to Git.

PEAR is about providing the PHP community with reusable, effective components - this has been our mission since day 1. If there is anything we can do to make that goal happen, to assist you as an individual or company, I would strongly encourage you to let us know - we're here to help.

They mention the work of two individuals that have done good work on a specific package, meldra and Gemorroj - perfect examples of how the move to Github has made it simpler to implement changes that have been "waiting in the wings" on the XML_Feed_Parser and Image_Barcode2 packages.

If you've had changes you've wanted to make to a PEAR package in the past but haven't ever gotten them submitted, there's not a better time than now.

Derick Rethans has a new post to his blog today talking about some work that's been done to speed up XDebug's code coverage generation. Changes in the coming 2.2 release have some improvements that make things perform better and put less stress on PHP in the process.

Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.

These changes were from a combination of contributions from Taavi Burns and a new ini setting that will allow you to enable or disable the code coverage in XDebug. Benchmarking shows a good amount of time reduction in coverage runs - dropping anywhere from a few seconds to over a minute. He also mentions the idea of "modes", shortcuts to predefined settings for different types of reporting (like "profiling" or "tracing").

Since the CodeIgniter project has put much more emphasis on open source and having others contribute back to the framework they love, they've had questions about the best places to get started and the steps to contribute back. They've posted this Contribution Guide to help answer some of those questions.

CodeIgniter is a community driven project and accepts contributions of code and documentation from the community. These contributions are made in the form of Issues or Pull Requests on the EllisLab CodeIgniter repository on GitHub.

There's a few helpful hints on things like submission guidelines, the PHP style guide for the project, PHP version compatibility, which branch to submit requests against and a quick how-too guide on getting up and running with git/github if you're not familiar with it.

Volker Dusch has a suggestion for all of the PHP projects (or, really Open Source projects in general) that can help keep things cleaner in your codebase and make for simpler times when merging contributions - including your coding standard along with the rest of your project.

Let me elaborate on [an important] point: Contribution. Most developers i know care about producing good code, especially then they are contributing to an open source project! Those people will respect your coding standard, naming scheme and every thing else that they can check for before sending you all patch/pull request. So try to make that part easy.

He talks about doing things the hard way - reformatting everything by hand each time someone contributes - or the easier way of enforcing the coding standard as a part of the contribution flow. He mentions PHP_CodeSniffer and the PHP Mess Detector as a part of a Jenkins installation (easily built from this handy project).

Cal Evans has snuck in a seventh part of his six-part series looking at what you, the client, can do to help make the relationship and contract between you and your developer better. This new post talks about doing your part.

robably the second most common reason I've seen projects fail is because the client fails to live up to their commitments. No I'm not talking about hitting your payment milestones, I'm talking about delivering your content.

Without everything they need to get the job done, the developer(s) cannot hit the marks you both laid out in the contract. Show them that you're committed to the project by delivering your side of things too.

Don't be the reason that it misses it's delivery date. Also, don't expect your developer to work extra hours to get the project back on schedule just because you failed to meet your obligations.

If you're around the Manchester area (or will be in February) you should consider attending the PHP Unconference Europe 2011 happening February 19th and 20th.

For the past four years, a group of enthusiasts have been organizing an unconference about PHP and related web technologies in Hamburg, Germany. What started off as a gathering of only fifty people, has grown over the course of three years into an event, which has received much following and attention within the German speaking PHP community. [...] The mission of PHP Unconference Europe is to bring together an international group of around 200 people, who have detailed knowledge of PHP and related web technologies.

For 2011, they've set up the European unconference to provide a whole new group of those with tech-related interests to come together and present the topics they want to hear about. Contribution ideas can be made via their Contribution System. Topics already suggested cover topics like Phing, document generation with the Zend Framework, project management and working with spreadsheets in PHP.

The tickets are already on sale, so if you'd like to attend, pick yours up and reserve your spot today! The cost is £40/46 Euro for the two day event.

Following along the theme of Elizabeth Naramore's post on open source involvement, Brandon Savage has posted some thoughts of his own (and reinforces hers) on encouraging developers to get involved and out contributing to some of their favorite projects.

Leaders of the open source community are always trying to encourage others to contribute. Volunteer contributors are always in short supply, and most open source projects are driven by volunteers, so recruitment is a big component of any open source project lead.

One of his main points to add to Elizabeth's list was that the architecture of the application matters. He gives an example of a project (the Phergie IRC bot) that is well-architected and makes adding in new plugins simple because of planning. He also shares a few other suggestions to help encourage open source participation like good documentation, good involvement from project leads and mentoring the "newbies" to help get the ball rolling.

Federico Cargnelutti has written up a brief look at PHP's contribution to Open Source. More specifically, how its helped the online community save money and have better software for it.

Open source developers don't write FLOSS applications because they have to, they write them because they want to. Motivation is not always driven by money, most of the time PHP developers do it for the joy of it.

He lists some of the motivation factors behind the work that a lot of PHP (and Open Source) developers do for and in the community like the potential to learn, credibility/notoriety, sense of purpose and the possibility of a financial reward. He also includes just a few of the Open Source projects PHP developers have contributed to the community such as WordPress, Magento and Gallery.

On the Blue Parabola blog Keith Casey asks the question "how do you measure an individual's contribution?"

In the past few weeks, I've been working fast and furious at getting web2project to our v1.0 milestone. As part of that effort, I track open issues, problematic modules, community feedback via the forums, death threats via all methods, and other related aspects.

He suggests a few different ideas for measuring how much a user has contributed: lines of code, commit count, issues they've reported, number of issues closed or community involvement. Of course, none of these can truly measure how much an individual has participated in a project, especially since it could be a mix of several of them combined into a whole as the "involvement persona" of any given person.

The PHPUnit Pocket Guide has been updated, according to this new post on Sebastian Bergmann's blog today - the addition of a Japanese version.

Masahiro Takagi has contributed a translation of the PHPUnit Pocket Guide, which is the official documentation for PHPUnit.

PHPUnit is one of the most popular unit testing pakcages offered for PHP today. The addition of this translation can only help push it out to even more of the world to use.