While there are many ways to give back to the Zend Framework project, let’s focus on the most important contribution: code. Moreover, we can talk about formal proposals for new component, but actually the most common situation that PHP developers face is finding a bug and, after digging in the framework code, being able to fix it with a small-sized patch.

The first thing you need to be able to get some code incorporated in the framework is signing a Contributor License Agreement, which essentially licenses your intellectual property (lines of source code) to Zend, that is thus able to guarantee a New BSD license on the releases of the framework. Every single line that enters the repository is freely distributable with any modifications, preventing external companies from suing the end users of the framework for copyright infringements, or requesting licensing fees.

That said, there are many ways to send your CLA: as a scanned image, a fax or by ordinary mail. Refer to the official wiki page for the details, which may be subjected to changes. Once the CLA has been sent, it will eventually be processed, and the waiting period is the hardest obstacle to pursuing your valuable contribution. Though, core framework developers usually can check if the CLA is already arrived at Zend, and merge your patches in the codebase even if it is not formally archived yet.

As important as licensing your code is easing the work for the core developers: file a ticket in the Jira issue tracker, that will trace the bug or the improvement history, and gather responses from the component leaders.

Because of the branching model of the project, you should work on the trunk of the Subversion repository, which contains both the library folder and the test suite to run with PHPUnit. The latter is not distributed with packaged releases, but testing is taken very seriously in the project and no code can be merged without test coverage. While typically you do not have commit acces to the trunk, producing a patch is a simple task:

• Expand the suite by writing a test that identifies the bug or the enhancement you want to tackle. This test should fail with the current version of the code.
• Fix the production code to ensure that the new test passes, and run at least the test suite of the whole component to make sure you’re not introducing a regression in functionality.
• Extract a diff and submit it in the related bug tracker issue. The patch should contain both the changes in the test suite and in the library code.

I have learnt during my contributor’s history that just including a unit test — which will have to be written anyway — along with a patch is what makes the difference between a ticket that sits in the tracker for months for lack of core developers’ time, and one that can be fixed in minutes and is integrated right away.