Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

Contributing to Zend Framework

Read the license

Zend Framework is licensed under the New BSD License. It can be found here.

Sign the Contributor License Agreement (CLA)

To contribute source code or documentation at any level (from a few lines, to a patch, to a proposal, to an entirely new component), you must first sign the Contributor License Agreement. This will also give you access as a developer in the issue tracking system and the wiki.

Subscribe to the appropriate mailing lists

Please join the Zend Framework community by subscribing to the mailing lists that interest you, using the e-mail account you wish to send messages from.

You can also view all messages through our archives on Nabble.

List List name Separate posts Digest posts Archives
Announcements fw-announce Subscribe, Unsubscribe Digest Subscribe, Digest Unsubscribe Archives
General fw-general Subscribe, Unsubscribe Digest Subscribe, Digest Unsubscribe Archives
Contributors zf-contributors Subscribe, Unsubscribe Digest Subscribe, Digest Unsubscribe Archives

How to subscribe

To subscribe, send a mail to (listname)-subscribe@lists.zend.com (e.g., fw-announce-subscribe@lists.zend.com) with any subject and body.

Please remember to subscribe using the e-mail address you use to post messages.

How to unsubscribe

Every mail sent by a list contains mail headers. (To view them in Thunderbird, use Ctrl-U.) For example:

  • List-Post: <fw-general@lists.zend.com>
  • List-Help: <fw-general-help@lists.zend.com>
  • List-Unsubscribe: <fw-general-unsubscribe@lists.zend.com>
  • List-Subscribe: <fw-general-subscribe@lists.zend.com>

In general, to unsubscribe, send a mail to (listname)-unsubscribe@lists.zend.com (e.g., fw-general-unsubscribe@lists.zend.com) with any subject and body.

Old lists

These lists are no longer recommended.

List List name Archives
Core fw-core Archives
Database fw-db Archives
Documentation fw-docs Archives
Google Gdata fw-gdata Archives
Internationalization fw-i18n Archives
Formats fw-formats Archives
MVC fw-mvc Archives
Server fw-server Archives
SVN (Commit Notifications) fw-svn  
Web Services fw-webservices Archives

RSS

RSS feeds and custom event notifications are also available from our website.

Contribute to the wiki

Report, work on, and resolve issues in the issue tracker

The issue tracker is the place to submit issues of all types. This includes bugs, change requests, feature requests, and small patches. See Submitting a Bug Fix. If large enough, feature requests should be submitted as a proposal. The issue tracker is also the place to track the release roadmap and view the current status of framework components.

If you find yourself constantly submitting patches and having the need for direct access to the Subversion repository, ask and your request will be considered. Please read the Subversion Standards before submitting code via Subversion.

To be assigned an issue, you must sign the CLA.

Please read [Issue Tracker Etiquette] before working on issues.

Review Subversion commits

As code comes into Subversion, it is displayed in our Fisheye browser with the changesets listed with full diffs. Review commits and double-check the work of others—the more eyes, the better. This is also a great way to get a feel for the framework coding style and culture.

Review and submit a proposal

Proposals are contributed by developers and end-users of the Zend Framework. Our proposal wiki space shows the current status of proposals and manages the review process. Submit new proposals here, or help review other submissions as part of our collective intelligence.

Learn PHPUnit

Zend Framework development is backed by extensive unit testing. We use PHPUnit extensively as our testing framework. For code to be accepted, it must be tested and covered by a unit test. Please see our testing standards guide and tutorial for more information.

Developers are expected to keep documentation and unit tests in sync with changes to code.

Review the coding standards

All framework code is covered by the PHP Coding Standard (draft). Learn it, love it, live it.

Please "watch" the page above using the "envelope" icon on the top-right side of the page. Confluence (the wiki system we use) has a robust e-mail notification system, accessed through "Preferences" after logging in. From there, click on the "Watches" folder tab, and see the link to "E-mail preferences".

Learn best practices

Common sense

API changes should be committed in parallel with updated documentation.

Factory methods, classes, and patterns

For the following, we define "factory" as a class or method that creates instance objects of one or more classes other than the class of the factory.

Direct instantiation is the preferred choice, and factory classes should be avoided if at all possible. Only when sufficient need exists should they be considered. Sometimes the code in a factory method could be moved to a common, shared superclass.

Container API guidelines

For the time being, we have decided to avoid trying to micromanage implementation details of framework components with containers to suit potential points of reuse throughout the framework. Zend_Session, for example, must wrap a nested PHP array ($_SESSION), not the recursive data structure found in Zend_Config. In a few months, we can revisit this issue and discuss whether implementations of existing components with container data structures should be refactored.

However, we would like to propose API conventions to help maintain consistency in style for accessing and manipulating container objects, without requiring complicated refactoring of container interfaces, classes, and implementations across diverse components.

When getting and setting data in a random-access container using keys, we suggest the following required, basic operations:

  • __get()
  • __set()
  • __isset()
  • __unset()

When appropriate, containers should also implement the standard PHP Countable and Iterator interfaces, if only to facilitate debugging by those using the container class.

If the keys used for getting and setting use characters not permitted in PHP identifiers, then use methods named get(), set(), isset(), and unset() instead of the magic methods. Due to the international flavor of Zend Framework, please carefully consider whether those speaking other languages will need to use get($propName) and set($propName, $value). Using consistently-named methods for the same purpose across multiple classes increases readability and ease of use. Mixing the $object->propName and $object->get('propName') styles, on the other hand, can lead to confusion. Pick one and be consistent.

Only implement ArrayAccess and __call() if they are relevant and do not overlap in functionality with the other accessors.

Please note
This section discusses accessing items in a container data structure, not other properties of the object wrapping the container. Accessor methods for these other properties might have different requirements. Defined extension points should be represented by normal functions to access the properties they encapsulate.

Join a project team

Zend Framework development is done on the basis of large teams working together on related components. It is our experience that having these discussions in bigger groups (which previously were held most directly with Zend) fosters an environment where ideas and proposals are more mature, and also where less work needs to be done afterward due to a significantly shortened peer review process.

Project team wiki pages

  • Team members (add yourself if your name is missing)
  • Team's components
  • Who is working on which components, including coordinators
  • Major milestones
  • Tasks needed to accomplish milestones
  • What help is needed (very important!)

Project team responsibilities

Each project team is responsible for producing status updates in the form of newsletters.

  • Zend project team members help and work with community members on each team
  • Newsletters are to be mailed to fw-general and the team-specific mailing list
  • Updates are to be published every two weeks to the wiki
  • All team members can help update the team's wiki page
  • All team members can help author a wiki page containing the status update

We need each team to study the other team's wiki pages and borrow ideas to improve their wiki team page. The pages don't need to be identical, and some things will work better for different teams. Don't be afraid to improve something someone else edited. Be creative!

Also, coordinators and everyone else should help identify tasks to list under "Help Wanted" sections. We are an open community, and each project team should be receptive and open to finding areas for community members to help.

Contribute code

Component leads and significant contributors will be granted direct access to the Subversion repository. Please read the Subversion Standards before submitting new code via Subversion.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.