Daniel Ribeiro has (re)published an article he originally wrote for the Web & PHP Magazine about becoming a PHP evangelist and helping to lead change in the community.

To evangelize is to effectively transfer information regarding one set of beliefs to another, with the final goal of converting each individual to the original belief. Isn't that what we do when we spread the word of PHP?! The idea behind being a PHP Evangelist is for an individual to speak passionately about PHP and be able to have strong and durable arguments for PHP, if questioned about his "faith" in the technology.

He talks some about the skills and things you'd need to become an evangelist - an advanced knowledge of the language, thinking "out of the box" about problems and how you can stand out from the other people in the community as a leader. He also recommends being technically adept as well and contributing to projects, either through support or actual development.

PHP evangelists are born to lead, to form opinions, influence the opinions of others and to have followers - and haters as well. Even if you think you were not born to be a leader or just don't want to be one, you will have to get used to public speaking if you wish to become a PHP evangelist.

The Aura Framework project has made a new post to their blog walking you through the steps you'll need to contribute back to the project with your ideas and bugfixes for their various components.

Sometimes you may have noticed a bug, or need a feature implemented, and need to contribute back to the aura community. These are some of the steps to help / contribute to aura project.

They walk you through: setting up git (well, point you to github's guide), fork the main repository and check out a copy, creating a remote to the "upstream" (main) repository and pulling the latest content from it into your fork. Included are the commands to run PHP_CodeSniffer and PHPUnit with the provided tests. From there, it's up to you and your code to contribute back, commit and make a pull request!

On the PHPClasses.org site there's a new episode of their "Lately in PHP" podcast wondering if the move of PHP to git will encourage more non-core developers to contribute to the project.

The PHP development migrated to a Git repository. With the integration with GitHub it became easier for non-core developers to submit pull requests with bug fixes and new feature improvements to PHP. Will this new possibility make it PHP core developers accept more contributions from non-core developers?

The episode also looks forward to the next release in the PHP 5.4.x series (5.4.1) and some of the stir that a recent post (to PHPClasses) about OOP caused in the community.

You can listen to this latest episode either via the in-page player, by downloading the mp3 or by subscribing to their podcast feed.

As mentioned in this new post from the php|architect site, the voting for their 2012 Impact Awards has begun!

We at php|architect want to honor those who give of themselves so that we can work with PHP and in this great ecosystem. We are standing on the shoulders of giants and want to pause to say thank you. The full details can be found on the Impact Awards page. Voting is open through the end of March and is open to all php|architect subscribers.

The categories for this year's event are "Up & Coming", "Best Cloud Platform" and "Best PHP Application Platform". Nominees across all of the categories include Joind.in, PintLabs, AppFog, Pagoda Box Drupal 7 and SugarCRM. If you're a subscriber, get in there and vote for your favorites!

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.