Core contributor guidelines

For the sake of transparency, we are publishing our own core team contribution guidelines. We're hoping that this will help others understand how members of the core team deal with tickets, user submitted patches, test cases, new feature development, and last but not least, bug fixes.

Tickets

All tickets for CakePHP are submitted on cakephp.lighthouseapp, and this is the only location where we actually look at bug reports and enhancements (the legacy Trac installation is slowly being phased out).

After a ticket is submitted to the issue tracker, it is usually briefly reviewed by a core team member for validity. Tickets which are obviously not a bug report or a feature enhancement request (descriptions containing 'How can I [...]' are usually a dead giveaway) are closed and marked as invalid. The core team member closing the ticket should be courteous and brief in his/her reply, e.g.:

This is not a help forum. The ticket tracker is reserved for possible
bugs and feature enhancements to the CakePHP framework. If you are
looking for help on how to implement a feature or to better understand
how to use the framework correctly, please visit one of the following:

[The CakePHP Manual](http://book.cakephp.org)
[The CakePHP online API](http://api.cakephp.org)
[The CakePHP Google Group](http://groups.google.com/group/cake-php) 

or the #cakephp channel on irc.freenode.net, where we will be more than
happy to help answer your questions.

Thanks!

Tickets are closed upon their initial review if:

  • duplicate The issue described has already been submitted to the ticket tracker. In this case, the reviewer should politely point to the pre-existing ticket, and ask that any additional feedback/comments/test cases/patches be posted there.
  • wont-fix: The issue is one that has already been discussed and decided upon (e.g. we don't plan on supporting composite primary keys in CakePHP 1.x). In this case, provide a link to a relevant discussion, either on the ticket tracker or to the google group. If no such discussion has taken place publicly, provide the relevant information in the closing message of the ticket.
  • works-for-me: The issue described is quite obviously one that CakePHP supports, and the ticket submitter does not provide any additional information as to why the observed behavior differs from what he/she would expect.
  • invalid: The ticket is obviously invalid (e.g. spam, non-sensical), or the desired behavior is already possible with CakePHP. If the latter is true, respond with a polite, concise response with a link to the relevant documentation that describes what the person is trying to accomplish.

Tickets should be cleaned up as necessary, making sure that they are properly categorized, tagged and formatted.

If upon initial review the bug/feature enhancement seems valid, the ticket is left open.

Note: The initial ticket reviewer is not obligated to accept the ticket.

Ticket Lifecycle

Tickets start off with a pending status. This means the tickets have not yet been reviewed or confirmed. Once a ticket has been reviewed, the reviewer can do one of the following:

  • approve the ticket. Approved tickets are greenlighted for anyone with time to work on completing or fixing.
  • accept the ticket,
  • Put the ticket on hold usually because not enough information was given to reproduce the issue or the contributor has some additional questions about the issue.
  • close the ticket because of its invalid or duplicate nature.

Once tickets are accepted, the ticket owner should attempt to resolve the ticket. If for any reason they are unable to resolve it, it should be put back into the approved pool for someone else to address.

How you can help

By providing more information, patches, or tests for tickets that are pending approved and on hold they can be more quickly resolved and fixed/closed.

Commits

1.x Project

1.2 Contribution guidelines

CakePHP 1.2 is under maintenance mode, meaning that no new features will be introduced in this version. The only commits permitted on this branch are for bug fixes and the addition of test cases for pre-existing code. Any commits that are more than the most simplistic (e.g. typo in doc blocks) should be presented and reviewed by at least one other core team member.

All test cases must continue to pass, regardless of the size and/or complexity of the commit. Failing tests are unacceptable.

1.3 Contribution guidelines

CakePHP 1.3 is under maintenance mode, meaning that no new features will be introduced in this version. The only commits permitted on this branch are for bug fixes and the addition of test cases for pre-existing code. Any commits that are more than the most simplistic (e.g. typo in doc blocks) should be presented and reviewed by at least one other core team member.

All test cases must continue to pass, regardless of the size and/or complexity of the commit. Failing tests are unacceptable.

2.x Project

CakePHP 2.0.x is in maintenance mode. There is active work being done for new backwards compatible releases. We'll be releasing 2.1, 2.2, 2.3 and so on as needed. All features in these releases must be API compatible with previous releases.

Create your profile

Help contribute to these projects by taking a few moments to create your personal profile. Create your profile ยป

Pages