<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2176/25/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/Issue+Tracker+Workflow">Issue Tracker Workflow</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~mjordan">Matt Jordan</a>
</h4>
<br/>
<h4>Changes (44)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2. Description of the Issue Tracker Workflow <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h1. Overview <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">(This document is most beneficial for Asterisk bug marshals, however it is good reading for anyone who may be filing issues or wondering how the Asterisk Open Source project moves issues through from filing to completion.) <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">This document describes how issues move through the [Asterisk Issue Tracker|https://issues.asterisk.org/jira]. It is most beneficial for Asterisk bug marshals; however, it is also good reading for anyone who may be filing issues or wondering how the Asterisk Open Source project moves issues from filing to completion. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h1. Issue Tracker Workflow <br> <br></td></tr>
<tr><td class="diff-changed-lines" >The workflow in the issue tracker <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">should be</span> <span class="diff-added-words"style="background-color: #dfd;">is</span> handled in the following <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;"> </span> way: <br></td></tr>
<tr><td class="diff-changed-lines" ># A bug is reported and is automatically placed in the <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">'New'</span> <span class="diff-added-words"style="background-color: #dfd;">*Triage*</span> status. <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;"># The Bug Marshall team should go through bugs in the 'New' status to determine whether the report is valid (not a duplicate, hasn't already been fixed, not a Digium tech support issue, etc.). Invalid reports should be set to 'Closed' with the appropriate resolution set. Categories and descriptions should be corrected at this point.\[~russell:Note1\] <br>Issues should also have enough information for a developer to either reproduce the issue or determine where an issue exists (or both). If this is not the case then the issue should be moved to 'Feedback' prior to moving forward in the workflow. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;"># The Bug Marshall team should go through bugs in the *Triage* status to determine whether the report is valid (not a duplicate, hasn't already been fixed, not a tech support issue, etc.). Invalid reports should be set to 'Closed' with the appropriate resolution set. Categories and descriptions should be corrected at this point. <br>{note} <br>Issues should also have enough information for a developer to either reproduce the issue or determine where an issue exists (or both). If this is not the case then the issue should be moved to 'Waiting for Feedback' with the appropriate information requested. See [Asterisk Issue Guidelines|AST:Asterisk Issue Guidelines] for more information on what an issue should have before it is accepted. <br>{note} <br></td></tr>
<tr><td class="diff-unchanged" ># The next step is to determine whether the report is about a bug or a submission of a new feature: <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">## BUG: A bug should be moved into the status 'Acknowledged' if enough information has been provided by the reporter to either reproduce the issue or clearly see where an issue may lie. The bug may also be assigned to a developer for the creation of the initial patch, or review of the issue. <br>Once a patch has been created for the issue and attached, the issue can then be moved to the 'Confirmed' status. At this point, initial code review and discussion about the patch will take place. Once an adequate amount of support for the implementation of the patch is acquired, then the bug can be moved to the 'Ready for Testing' status for wider testing by the community. After the testing phase is complete and it appears the issue is resolved, the patch can be committed by a developer and closed. <br>## FEATURE: As new features should be filed with a patch, it can be immediately moved to the 'confirmed' status, making it ready for basic formatting and code review. From there any changes to style or feel of the patch based on feedback from the community can be discussed, and changes to the patch made. It can then be moved forward to the 'Ready for Testing' status. Once the feature has been merged, or a decision has been made that it will not be merged, the issue should be taken to 'Closed' with the appropriate resolution.\[~russell:Note2\] <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">** BUG: A bug should be moved into the *Open* status by clicking _Acknowledge_ if enough information has been provided by the reporter to either reproduce the issue or clearly see where an issue may lie. The bug may also be assigned to a developer for the creation of the initial patch, or review of the issue. <br>If a patch has been created for the issue, it is acceptable to modify the summary with the text "[patch]" to indicate that a patch is available for the issue. At this point, initial code review and discussion about the patch will take place, either on the issue or on [Review Board|https://reviewboard.asterisk.org]. One the patch has been sufficiently reviewed, the patch can be committed by a developer and the issue closed. <br>** FEATURE: New features must be filed with a patch. As such, the issues can be immediately moved into the *Open* status by click _Acknowledge_ and be reviewed for adherence to [Coding Guidelines|AST:Coding Guidelines] and [code review|https://reviewboard.asterisk.org]. From there any changes to style or feel of the patch based on feedback from the community can be discussed, and changes to the patch made. Once the feature has been accepted, or a decision has been made that it will not be merged, the issue should be *Closed* with the appropriate resolution. <br></td></tr>
<tr><td class="diff-changed-lines" ># If at any point in the workflow, an issue requires feedback from the original poster of the issue, the status should be changed to <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;"> 'Feedback'.</span> <span class="diff-added-words"style="background-color: #dfd;">*Waiting for Feedback*.</span> Once the required information has been provided, it should be placed back in the appropriate point of the <span class="diff-changed-words">workflow<span class="diff-added-chars"style="background-color: #dfd;"> by using the _Send Back_ button</span>.</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;"># If at any point in the workflow, a developer or bug marshal would like to take responsibility for doing the work that is necessary to [progress|http://www.asterisk.org/doxygen/trunk/structprogress.html] an issue, the status can be changed to 'Assigned'. At that point the developer assigned to the issue will be responsible for moving the issue to completion. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;"># If at any point in the workflow, a developer or bug marshal would like to take responsibility for doing the work that is necessary to progress an issue, the issue can be assigned to that developer and the issue moved into the *In Progress* state. At that point the developer assigned to the issue will be responsible for moving the issue to completion. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" ><span class="diff-changed-words">h<span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">2</span><span class="diff-added-chars"style="background-color: #dfd;">1</span>.</span> Workflow Summary <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" >The following is a list of valid statuses and what they mean to the work <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;"> </span> flow. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. New <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. Triage <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">This issue is awaiting review by bug marshals. Categorization and summaries should be fixed as appropriate. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">This issue is awaiting review or in review by bug marshals. Categorization of the issue, summary, description, version, and other related informationshould be fixed as appropriate. See the [AST:Asterisk Issue Guidelines] for more information. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" >h3. <span class="diff-added-words"style="background-color: #dfd;">Waiting for</span> Feedback <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">This issue requires feedback from the poster of the issue before any additional [progress|http://www.asterisk.org/doxygen/trunk/structprogress.html] in the workflow can be made. This may include providing additional debugging information, or a backtrace with DONT_OPTIMIZE enabled, for example. (See the doc/HOWTO_collect_debug_information.txt file in your Asterisk source.) <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">This issue requires feedback from the poster of the issue before any additional progress in the workflow can be made. This may include providing additional [debugging|AST:Collecting Debug Information] information, or a [backtrace|AST:Getting a Backtrace] with {{DONT_OPTIMIZE}} enabled, for example. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" >h3. <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">Acknowledged</span> <span class="diff-added-words"style="background-color: #dfd;">Open</span> <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">This is a submitted bug which has no patch associated with it, but appears to be a valid bug based on the description and provided debugging information. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">This is a submitted bug or new feature (with patch!) which has yet to be worked either by an Asterisk community developer or by a developer at Digium Asterisk developer, but appears to be a valid bug or new feature based on the description and provided debugging information. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. Confirmed <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{note} <br>An issue can also be in the *Reopen* state, indicating that it was closed but reopened for some reason. This state is semantically the same as *Open*. <br>{note} <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">The patch associated with this issue requires initial formatting and code review, and may have some initial testing done. It is waiting for a developer to confirm the patch will no longer need large changes made to it, and is ready for wider testing from the community. This stage is used for discussing the feel and style of a patch, in addition to the coding style utilized. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h3. In Progress <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. For Testing <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">This is an issue which is currently being actively worked by an assigned developer. At this stage, it would be appropriate to have a patch being developed or attached to the issue for review. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">This is an issue which has a patch that is waiting for testing feedback from the community after it has been deemed to no longer need larger changes. <br> <br>h3. Assigned <br> <br>A developer or bug marshal has taken responsibility for taking the necessary steps to move forward in the workflow. Once the issue is ready to be reviewed and feedback provided, it should be placed back into the appropriate place of the workflow. <br> <br>h3. Resolved <br> <br>A resolution for this issue has been reached. This issue should immediately be Closed. <br> <br></td></tr>
<tr><td class="diff-unchanged" >h3. Closed <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">No further action is necessary for this issue. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">The issue has been resolved, and a patch has either been committed or the issue has been rejected for some reason. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" ><span class="diff-changed-words">h<span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">2</span><span class="diff-added-chars"style="background-color: #dfd;">1</span>.</span> Severity Levels <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Severity levels generally represent the [number|http://www.asterisk.org/doxygen/trunk/structnumber.html] of [users|http://www.asterisk.org/doxygen/trunk/structusers.html] who are potentially affected by the reported issue. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Severity levels can be selected for an issue and may be viewed by bug marshals as a way to categorize issues for priority; however, a high priority does not necessarily entail that any bug marshal will treat that issue with any greater urgency. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. Feature <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{note} <br>The *Blocker* severity may be used by bug marshals as a way to indicate that the Asterisk developer community has decided that an issue is of such critical importance that it should prevent release of an issue. In general, this status should be used sparingly and may warrant discussion on the issue tracker if assigned to an issue. Issue reporters should not select the *Blocker* severity. <br>{note} <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">This issue is a new feature and will only be committed to Asterisk trunk. Asterisk trunk is where future branches will be created and thus this feature will only be found in future branches of Asterisk and not merged into existing branches. (See Release Branch Commit Policy below.) <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h1. Notes <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. Trivial <br> <br>A trivial issue is something that either affects an insignificant [number|http://www.asterisk.org/doxygen/trunk/structnumber.html] of Asterisk [users|http://www.asterisk.org/doxygen/trunk/structusers.html], or is a minimally invasive change that does not affect functionality. <br> <br>h3. Text <br> <br>A text issue is typically something like a spelling fix, a clarifying of a debugging or verbose [message|http://www.asterisk.org/doxygen/trunk/structmessage.html], or changes to documentation. <br> <br>h3. Tweak <br> <br>A tweak to the code the has the potential to either make code clearer to read, or a change that could speed up processing in certain circumstances. These changes are typically only a couple of [lines|http://www.asterisk.org/doxygen/trunk/structlines.html] <br> <br>. <br> <br>h3. Minor <br> <br>An issue that does not affect a large [number|http://www.asterisk.org/doxygen/trunk/structnumber.html] of Asterisk [users|http://www.asterisk.org/doxygen/trunk/structusers.html], but not an insignificant [number|http://www.asterisk.org/doxygen/trunk/structnumber.html]. The [number|http://www.asterisk.org/doxygen/trunk/structnumber.html] of [lines|http://www.asterisk.org/doxygen/trunk/structlines.html] of code and development effort to resolve this issue could be non-trivial. <br> <br>h3. Major <br> <br>As issue that affects the majority of Asterisk [users|http://www.asterisk.org/doxygen/trunk/structusers.html]. The [number|http://www.asterisk.org/doxygen/trunk/structnumber.html] of [lines|http://www.asterisk.org/doxygen/trunk/structlines.html] of code and development effort required to resolve this issue could be non-trivial. <br> <br>h3. Crash <br> <br>An issue marked as a Crash is something that would cause Asterisk to be unusable for a majority of Asterisk [users|http://www.asterisk.org/doxygen/trunk/structusers.html] and is an issue that causes a deadlock or crash of the Asterisk process. <br> <br>h3. Block <br> <br>A blocking issue is an issue that must be resolved before the next release of Asterisk as would affect a significant [number|http://www.asterisk.org/doxygen/trunk/structnumber.html] of Asterisk [users|http://www.asterisk.org/doxygen/trunk/structusers.html], or could be a highly visible regression. A severity of block should only be set by Asterisk bug marshals at their discretion. <br> <br>\**\* USERS SHOULD NOT FILE ISSUES WITH A SEVERITY OF BLOCK \**\* <br> <br>h2. Priority Levels <br> <br>Currently, the following priority levels are listed on the issue tracker: <br>* None <br>* Low <br>* Normal <br>* High <br>* Urgent <br>* Immediate <br> <br>However, at this time they are not utilized and all new issue should have a priority of 'Normal'. <br> <br>h2. Notes <br> <br># Using the "Need Triage" filter is useful for finding these issues quickly. <br># The issue tracker now has the ability to monitor the commits list, and if the commit [message|http://www.asterisk.org/doxygen/trunk/structmessage.html] contains something like, "(Closes issue #9999)", the bug will be automatically closed. <br>See [http://www.asterisk.org/doxygen/trunk/CommitMessages.html|http://www.asterisk.org/doxygen/trunk/CommitMessages.html] for more information on commit messages. <br> <br>h2. Release Branch Commit Policy <br> <br>The code in the release branches should be changed as little as possible. The only time the release branches will be changed is to fix a bug. New features will never be included in the release branch unless a special exception is made by the release branch maintainers. <br> <br>Sometimes it is difficult to determine whether a patch is considered to fix a bug or if it is a new feature. Patches that are considered code cleanup, or to improve performance, are NOT to be included in the release branches. Performance issues will only be considered for the release branch if they are considered significant, and should be approved by the maintainers. <br> <br>If there is ever a question about what should be included in the release branch, the maintainers should be allowed to make the decision. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;"># Using the filters in JIRA - such as the [Triage (Supported)|https://issues.asterisk.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=11493] filter is- useful for finding issues that need attention quickly. <br># The issue tracker now has the ability to monitor the commits list, and if the [commit message|AST:Commit Messages] contains the appropriate tag, e.g., "(Closes issue ASTERISK-9999)", the bug will automatically be closed. <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<h1><a name="IssueTrackerWorkflow-Overview"></a>Overview</h1>
<p>This document describes how issues move through the <a href="https://issues.asterisk.org/jira" class="external-link" rel="nofollow">Asterisk Issue Tracker</a>. It is most beneficial for Asterisk bug marshals; however, it is also good reading for anyone who may be filing issues or wondering how the Asterisk Open Source project moves issues from filing to completion.</p>
<h1><a name="IssueTrackerWorkflow-IssueTrackerWorkflow"></a>Issue Tracker Workflow</h1>
<p>The workflow in the issue tracker is handled in the following way:</p>
<ol>
<li>A bug is reported and is automatically placed in the <b>Triage</b> status.</li>
<li>The Bug Marshall team should go through bugs in the <b>Triage</b> status to determine whether the report is valid (not a duplicate, hasn't already been fixed, not a tech support issue, etc.). Invalid reports should be set to 'Closed' with the appropriate resolution set. Categories and descriptions should be corrected at this point.
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Issues should also have enough information for a developer to either reproduce the issue or determine where an issue exists (or both). If this is not the case then the issue should be moved to 'Waiting for Feedback' with the appropriate information requested. See <a href="/wiki/display/AST/Asterisk+Issue+Guidelines" title="Asterisk Issue Guidelines">Asterisk Issue Guidelines</a> for more information on what an issue should have before it is accepted.</td></tr></table></div></li>
<li>The next step is to determine whether the report is about a bug or a submission of a new feature:
<ul>
<li>BUG: A bug should be moved into the <b>Open</b> status by clicking <em>Acknowledge</em> if enough information has been provided by the reporter to either reproduce the issue or clearly see where an issue may lie. The bug may also be assigned to a developer for the creation of the initial patch, or review of the issue.<br/>
If a patch has been created for the issue, it is acceptable to modify the summary with the text "<a href="/wiki/pages/createpage.action?spaceKey=AST&title=patch&linkCreation=true&fromPageId=3702839" class="createlink">patch</a>" to indicate that a patch is available for the issue. At this point, initial code review and discussion about the patch will take place, either on the issue or on <a href="https://reviewboard.asterisk.org" class="external-link" rel="nofollow">Review Board</a>. One the patch has been sufficiently reviewed, the patch can be committed by a developer and the issue closed.</li>
<li>FEATURE: New features must be filed with a patch. As such, the issues can be immediately moved into the <b>Open</b> status by click <em>Acknowledge</em> and be reviewed for adherence to <a href="/wiki/display/AST/Coding+Guidelines" title="Coding Guidelines">Coding Guidelines</a> and <a href="https://reviewboard.asterisk.org" class="external-link" rel="nofollow">code review</a>. From there any changes to style or feel of the patch based on feedback from the community can be discussed, and changes to the patch made. Once the feature has been accepted, or a decision has been made that it will not be merged, the issue should be <b>Closed</b> with the appropriate resolution.</li>
</ul>
</li>
<li>If at any point in the workflow, an issue requires feedback from the original poster of the issue, the status should be changed to <b>Waiting for Feedback</b>. Once the required information has been provided, it should be placed back in the appropriate point of the workflow by using the <em>Send Back</em> button.</li>
<li>If at any point in the workflow, a developer or bug marshal would like to take responsibility for doing the work that is necessary to progress an issue, the issue can be assigned to that developer and the issue moved into the <b>In Progress</b> state. At that point the developer assigned to the issue will be responsible for moving the issue to completion.</li>
</ol>
<h1><a name="IssueTrackerWorkflow-WorkflowSummary"></a>Workflow Summary</h1>
<p>The following is a list of valid statuses and what they mean to the work flow.</p>
<h2><a name="IssueTrackerWorkflow-Triage"></a>Triage</h2>
<p>This issue is awaiting review or in review by bug marshals. Categorization of the issue, summary, description, version, and other related informationshould be fixed as appropriate. See the <a href="/wiki/display/AST/Asterisk+Issue+Guidelines" title="Asterisk Issue Guidelines">Asterisk Issue Guidelines</a> for more information.</p>
<h3><a name="IssueTrackerWorkflow-WaitingforFeedback"></a>Waiting for Feedback</h3>
<p>This issue requires feedback from the poster of the issue before any additional progress in the workflow can be made. This may include providing additional <a href="/wiki/display/AST/Collecting+Debug+Information" title="Collecting Debug Information">debugging</a> information, or a <a href="/wiki/display/AST/Getting+a+Backtrace" title="Getting a Backtrace">backtrace</a> with <tt>DONT_OPTIMIZE</tt> enabled, for example.</p>
<h3><a name="IssueTrackerWorkflow-Open"></a>Open</h3>
<p>This is a submitted bug or new feature (with patch!) which has yet to be worked either by an Asterisk community developer or by a developer at Digium Asterisk developer, but appears to be a valid bug or new feature based on the description and provided debugging information.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>An issue can also be in the <b>Reopen</b> state, indicating that it was closed but reopened for some reason. This state is semantically the same as <b>Open</b>.</td></tr></table></div>
<h3><a name="IssueTrackerWorkflow-InProgress"></a>In Progress</h3>
<p>This is an issue which is currently being actively worked by an assigned developer. At this stage, it would be appropriate to have a patch being developed or attached to the issue for review.</p>
<h3><a name="IssueTrackerWorkflow-Closed"></a>Closed</h3>
<p>The issue has been resolved, and a patch has either been committed or the issue has been rejected for some reason.</p>
<h1><a name="IssueTrackerWorkflow-SeverityLevels"></a>Severity Levels</h1>
<p>Severity levels can be selected for an issue and may be viewed by bug marshals as a way to categorize issues for priority; however, a high priority does not necessarily entail that any bug marshal will treat that issue with any greater urgency.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>The <b>Blocker</b> severity may be used by bug marshals as a way to indicate that the Asterisk developer community has decided that an issue is of such critical importance that it should prevent release of an issue. In general, this status should be used sparingly and may warrant discussion on the issue tracker if assigned to an issue. Issue reporters should not select the <b>Blocker</b> severity.</td></tr></table></div>
<h1><a name="IssueTrackerWorkflow-Notes"></a>Notes</h1>
<ol>
<li>Using the filters in JIRA - such as the <a href="https://issues.asterisk.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=11493" class="external-link" rel="nofollow">Triage (Supported)</a> filter is- useful for finding issues that need attention quickly.</li>
<li>The issue tracker now has the ability to monitor the commits list, and if the <a href="/wiki/display/AST/Commit+Messages" title="Commit Messages">commit message</a> contains the appropriate tag, e.g., "(Closes issue ASTERISK-9999)", the bug will automatically be closed.</li>
</ol>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/Issue+Tracker+Workflow">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=3702839&revisedVersion=2&originalVersion=1">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Issue+Tracker+Workflow?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>