Issue Tracker Tips

Version 22 by Wil Sinclair
on Nov 24, 2008 12:25.

<< Changes from 21 to 22

compared with

Version 23 by Marc Hodgins
on Nov 26, 2010 14:21.
(show comment)

Changes from 23 to 24 >>

Key

This line was removed.

This word was removed. This word was added.

This line was added.

Changes (2)

View Page History

...

h2. Found a bug?

{hide-from:group=confluence-users}
If you create an account in the system, you can login, [report a new issue|http://framework.zend.com/issues/secure/CreateIssue!default.jspa], or view existing issues.
{hide-from}
\\
\\
While viewing an issue, on the bottom left side of the page, click the "Watch it" link to receive notifications about resolution progress. Also, we appreciate your comments, feedback, and help testing and proposing patches.
\\
\\
Has your bug already been reported? Please search for a similar looking bug, before reporting a new bug.

h2. Looking for work

The issue tracker no longer assigns new issues to any particular person, they go to "unassigned" instead. This means that anyone is welcome to pick up an issue and decide to work on it. But when is it the right time to do so? And how do you know anyone else isn't working on it? If everyone follows a few simple rules, it will be clear.

# If you wish to work on an issue, make sure you are ready to do so before assigning it to yourself. If you think you might work on it later, add a comment indicating your interest but leave it unassigned so that someone else may be able to work on it sooner. If you really feel you are the one to do the job, then go ahead and assign it to yourself. There is a quick link on the issue viewing page to assign one to you.
# Once you begin work on an issue, you can mark it "in progress" so everyone else will stay out of the way while you get the work done. Just click the "Start Progress" link while viewing an issue that is assigned to you and off you go! Everyone can easily view "in progress" issues with a filter or dashboard portlet. When done, you can stop the progress by either resolving the issue or by turning it off with the "Stop Progress" link.
# If you are not going to work on an item assigned to you, or self-assigned. Then assign it back to "unassigned" so that others may pick it up.
# Always try to assign "Fix Versions" to issues you are working on to give intent if you can. (see: Working with Versions below)
# When committing a fix for an issue, follow these instructions to [autolink the Subversion commit to the issue|Subversion Standards].

h2. Working with Versions

# Issues can be assigned to versions meaning that you are intending to complete them by that time. Some times the project admins or component leads will place them in a version that they feel they need to be completed by.
# Issues are placed in versions via the "Fix Versions" field when editing an issue.

# If you place an issue in a version, be sure you are ready to meet the scheduled date.
# When picking up an issue to work on that is assigned to a version, be sure you are ready to commit to the scheduled date.

# When resolving an issue (as fixed), make sure it has a "Fix Version" set to the current release underway.

# When resolving an issue (as fixed), make sure it has a "Fix Version" set that corresponds to the release branch for which the fix was merged
# Issues marked as "Duplicate", "Not an issue", "Won't fix", etc, should not be assigned a "Fix Version"

# All versions should have a target date listed when viewing the roadmap within a project.

...

h2. I'm a component lead!

* All component leads get notifications for issues marked for their component. So if you are a component lead, make sure you are listed as such by e-mailing one of the Zend team (i.e., [Alex|mailto:alexander.v@zend.com], [Darby|mailto:darby@zend.com], [Matthew|mailto:matthew@zend.com], or [Wil|mailto:wil@zend.com]). This allows leads to remain current with the latest developments with issues in their areas.

h2. Other tips

* Feel free to comment on other issues to help clarify them, to add thoughts on implementation, and to add other problem cases.
* You can customize the home page of the issue tracker by setting up your own dashboard. You can have multiple tabs, each with portlets on it, and you can in-place edit the settings and layout by turning "configure" on. This gives you your own helpful customized view.
* When you find an issue that is a duplicate of another, then use the "Link" action to link it as a duplicate. Then resolve it as a duplicate so that they are linked together and one is no longer open.
* When you have an issue that is dependent on another, link them using the "link" action as dependencies to make that clear.
* Notice the "Recently Resolved" link in tiny letters on the component summary page. Issues that have been marked resolved, but not yet closed, should be reviewed and commented on (if needed). This allows opportunity for feedback before the issue is closed.
* [How to Report Bugs Effectively, by Simon Tatham|http://www.chiark.greenend.org.uk/~sgtatham/bugs.html]

h2. Changesets and Linking between Issues and the Changeset Browser

When doing:

{code}svn commit foo.php -m 'some description. Fixes ZF-###'{code}

The changeset linkage is automatically done by JIRA. No need for adding "changeset\[###\]" to issue comments (btw, that syntax doesn't work). To display the changeset information and links on the issue page, look for the "FishEye" link toward the bottom of every issue description page in our issue tracker. Also, after clicking the FishEye link, Comments will no longer be shown on any issue page, until you click on the Comments link.