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.

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!

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.

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!

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.

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").

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.

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).

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.

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.