Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (5)

View Page History
During those days, the Zend team will be in #zftalk.dev on [Freenode|http://freenode.net/] for the entire work day. We will be triaging bugs ourselves, but, more importantly, we will be there to help facilitate *you*, our contributors and users, in resolving issue reports.

As an incentive, each month, we will ship a Zend Framework t-shirt to the individual that assists in the most issue resolutions during the bug hunt days, whether via patches or direct commits. Contributors are tracked by who the tickets were "assigned" to, so be sure to assign all tickets that you resolve to yourself in order to be counted. Quarterly, we will evaluate overall contributions, including documentation, bug fixes, and newly contributed components, and award a developer with their choice of a Zend Studio license or Zend Framework Certification voucher. (Caveat: one t-shirt per person per year, and one license/voucher per person per year, folks!)

For those interested in participating in the bug hunt days, the rules are simple: have a signed CLA on file, and resolve issues in the tracker.
* If you already have commit access, commit the test and fix to the repository, and either resolve the issue or ask somebody from Zend to review and resolve. Don't forget to merge your changes to the 1.9 release branch!

* If you do not have commit rights, create a patch with the unit test and fix, and attach the patch to the issue. Ask the maintainer or somebody from Zend to review and apply the patch. Usually posting in #zftalk.dev something to the effect of "Hello, patch attached to ZF-12345 is ready for review. Is anyone available?" will get the attention of someone available to do a commit for you.

If you need help creating the unit test or patch file, hop onto the #zftalk.dev IRC channel and ask for help.
* *Don't change return values.* Consumers of the code operate on the return values, so changes to those will, again, introduce backwards compatibility breaks.
* New methods are allowed, but try to minimize the number of them and how the rest of the class interacts with it. In particular, be cognizant of any interfaces the class is implementing, or having consuming classes utilize the new method.
* In extreme cases where a "rename" of a function is required or you feel it is critical to change the method signature to address an issue, then mark the existing method in the docblock as "@deprecated since <version> <explain reason>", create the new method, and modify the existing method to proxy to the new method so that its behavior remains unchanged. Write a unit test to confirm that the behavior. At some point in the future (i.e. a major version number change from 1 to 2, where BC breaks are acceptable), and only at this time, the deprecated method may be removed from the codebase.

h3. Create a patch

h3. Attach the patch or commit it
Attach the patch to the issue, and then assign it to the component lead. Alternately, if you have commit rights, you can skip creating the patch, and commit it directly. If the functionality affects the current minor release, be sure to merge your commit to the appropriate release branch.
Attach the patch to the issue, and assign it to yourself. Notify the component lead or someone with commit access in #zftalk.dev that the patch is ready for review. Alternately, if you have commit rights, you can skip creating the patch, and commit it directly. If the functionality affects the current minor release, be sure to merge your commit to the appropriate release branch. Once the commit has been made, update the ticket to reflect the fix version (i.e. "Next Mini Release") and mark the ticket as resolved (fixed).

h3. Lather, rinse, repeat