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

Two bug hunt days are held monthly, on the third Thursday and Friday of the month.

During those days, the Zend team will be in on Freenode 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. 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 have not yet signed a CLA and want to participate, you can get a copy of the form here:

Sign it and return it (you can email it, fax it, or send it via post); if you send it via post, you'll need to wait for confirmation that we've received it before we can accept code contributions from you.

Now, when it comes to the issue tracker, you'll need to determine if the issue:

  • is simply the reporter misunderstanding or misusing code OR
  • is a request for a new feature OR
  • is a reproducible issue

In the first case, comment on it and indicate the correct usage, and ask the component maintainer or somebody from Zend to review your response and mark the issue as resolved. In the second case, please try and focus on issue reports instead of feature requests during the bug hunt days.

That brings us to the final case, reproducible issue reports. With these, you'll need to do the following:

  • Capture the reproduce case as a unit test
  • Resolve the issue in such a way as to maintain backwards compatibility with existing usage. (In other words, don't change the signature of a method unless the signature is what is actually broken.)

From there, you then have two options:

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

If you need help creating the unit test or patch file, hop onto the IRC channel and ask for help.

How should you choose issues to work on? Answer the following questions, and you should be able to hop right in:

  • What components do you have expertise in?
  • What components are you interested in learning more about?
  • What issues have a high number of voters or watchers?

Bug hunting should be fun, so pick components and issues you're interested in. Ask questions on IRC if you don't understand how something works.

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