compared with
Current by Martin de Keijzer
on Feb 14, 2011 13:36.

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

Changes (37)

View Page History
h2. Found a bug?
<h2>Found a bug?</h2>

{hide-from:group=confluence-users}
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{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}
\\
\\
{hide-from}]]></ac:plain-text-body></ac:macro>
<p><br class="atl-forced-newline" />
<br class="atl-forced-newline" />
While viewing an issue, on the bottom left side of the page, click the "Watch it" &quot;Watch it&quot; link to receive notifications about resolution progress. Also, we appreciate your comments, feedback, and help testing and proposing patches.
\\
\\
<br class="atl-forced-newline" />
<br class="atl-forced-newline" />
Has your bug already been reported? Please search for a similar looking bug, before reporting a new bug.</p>

h2. Looking for work
<h2>Looking for work</h2>

<p>The issue tracker no longer assigns new issues to any particular person, they go to "unassigned" &quot;unassigned&quot; 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.</p>

<ol>
# If <li>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.</li>
# Once <li>Once you begin work on an issue, you can mark it "in progress" &quot;in progress&quot; so everyone else will stay out of the way while you get the work done. Just click the "Start Progress" &quot;Start Progress&quot; link while viewing an issue that is assigned to you and off you go! Everyone can easily view "in progress" &quot;in progress&quot; 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. &quot;Stop Progress&quot; link.</li>
# If <li>If you are not going to work on an item assigned to you, or self-assigned. Then assign it back to "unassigned" &quot;unassigned&quot; so that others may pick it up.</li>
# Always <li>Always try to assign "Fix Versions" &quot;Fix Versions&quot; to issues you are working on to give intent if you can. (see: Working with Versions below)</li>
# When committing a fix for an issue, follow these instructions to [autolink the Subversion commit to the issue|Subversion Standards].
<li>When committing a fix for an issue, follow these instructions to <ac:link><ri:page ri:content-title="Subversion Standards" /><ac:link-body>autolink the Subversion commit to the issue</ac:link-body></ac:link>.</li>
</ol>

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 that corresponds to the release branch for which the fix was merged. Usually this means marking it as "Next Mini Release" or "Next Minor Release" and the release manager will then convert resolved (fixed) issues tagged to these versions to the actual release version (i.e. 1.11.4) when the release is tagged.
# 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>Working with Versions</h2>

h2. I'm a component lead!
<ol>
<li>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.</li>
<li>Issues are placed in versions via the &quot;Fix Versions&quot; field when editing an issue.</li>
<li>If you place an issue in a version, be sure you are ready to meet the scheduled date.</li>
<li>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.</li>
<li>When resolving an issue (as fixed), make sure it has a &quot;Fix Version&quot; set that corresponds to the release branch for which the fix was merged. Usually this means marking it as &quot;Next Mini Release&quot; or &quot;Next Minor Release&quot; and the release manager will then convert resolved (fixed) issues tagged to these versions to the actual release version (i.e. 1.11.4) when the release is tagged.</li>
<li>Issues marked as &quot;Duplicate&quot;, &quot;Not an issue&quot;, &quot;Won't fix&quot;, etc, should not be assigned a &quot;Fix Version&quot;</li>
<li>All versions should have a target date listed when viewing the roadmap within a project.</li>
</ol>

* 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
<h2>I'm a component lead!</h2>

* 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]
<ul>
<li>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., <a href="mailto:alexander.v@zend.com">Alex</a>, <a href="mailto:darby@zend.com">Darby</a>, <a href="mailto:matthew@zend.com">Matthew</a>, or <a href="mailto:wil@zend.com">Wil</a>). This allows leads to remain current with the latest developments with issues in their areas.</li>
</ul>

h2. Changesets and Linking between Issues and the Changeset Browser

When doing:
<h2>Other tips</h2>

{code}svn commit foo.php -m 'some description. Fixes ZF-###'{code}
<ul>
<li>Feel free to comment on other issues to help clarify them, to add thoughts on implementation, and to add other problem cases.</li>
<li>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 &quot;configure&quot; on. This gives you your own helpful customized view.</li>
<li>When you find an issue that is a duplicate of another, then use the &quot;Link&quot; 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.</li>
<li>When you have an issue that is dependent on another, link them using the &quot;link&quot; action as dependencies to make that clear.</li>
<li>Notice the &quot;Recently Resolved&quot; 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.</li>
<li><a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How to Report Bugs Effectively, by Simon Tatham</a></li>
</ul>

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.

<h2>Changesets and Linking between Issues and the Changeset Browser</h2>

<p>When doing:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[svn commit foo.php -m 'some description. Fixes ZF-###']]></ac:plain-text-body></ac:macro>

<p>The changeset linkage is automatically done by JIRA. No need for adding &quot;changeset[###]&quot; to issue comments (btw, that syntax doesn't work).</p>