Review Board 1.7.16


Document Asterisk open source issue tracker workflow

Review Request #367 - Created Sept. 15, 2009 and submitted

Leif Madsen
trunk
Reviewers
asterisk-dev
Asterisk
The purpose of this document is to briefly describe the various statuses an
issue can be placed in, and what that status means. It also describes the
general workflow and progress of an issue from New to Closed.
make progdocs was run, and I reviewed the resulting HTML to make sure it wasn't skuppered.

Diff revision 1 (Latest)

  1. /trunk/include/asterisk/doxygen/mantisworkflow.h: Loading...
/trunk/include/asterisk/doxygen/mantisworkflow.h
New File

    
   
1
/*

    
   
2
 * Asterisk -- An open source telephony toolkit.

    
   
3
 *

    
   
4
 * Copyright (C) 1999 - 2009, Digium, Inc.

    
   
5
 *

    
   
6
 * See http://www.asterisk.org for more information about

    
   
7
 * the Asterisk project. Please do not directly contact

    
   
8
 * any of the maintainers of this project for assistance;

    
   
9
 * the project provides a web site, mailing lists and IRC

    
   
10
 * channels for your use.

    
   
11
 *

    
   
12
 * This program is free software, distributed under the terms of

    
   
13
 * the GNU General Public License Version 2. See the LICENSE file

    
   
14
 * at the top of the source tree.

    
   
15
 */

    
   
16

   

    
   
17
/*!

    
   
18
 * \file

    
   
19
 */

    
   
20

   

    
   
21
/*!

    
   
22
 * \page MantisWorkflow Workflow Guidelines for Asterisk Open Source Issue Tracker

    
   
23
 *

    
   
24
 * \AsteriskTrunkWarning

    
   
25
 *

    
   
26
 * <hr/>

    
   
27
 *

    
   
28
 * The purpose of this document is to briefly describe the various statuses an

    
   
29
 * issue can be placed in, and what that status means. In addition, the simple

    
   
30
 * workflow and transition between statuses will be discussed.

    
   
31
 *

    
   
32
 * \section StatusDefinitions Issue Status Definitions

    
   
33
 *

    
   
34
 * \subsection New New

    
   
35
 *       The 'New' status is where all bugs start. This is an issue which has not

    
   
36
 *       received a review by a bug marshal to move it to an appropriate next

    
   
37
 *       status. Steps required to move to the next logical step include:

    
   
38
 *

    
   
39
 *       \arg checking Category and Severity are set correctly

    
   
40
 *       \arg verifying the issue does not look like a support issue (if so, note

    
   
41
 *            the reporter should use the appropriate support channels, and change

    
   
42
 *            status to Closed)

    
   
43
 *       \arg determine that enough debugging information has been provided so that

    
   
44
 *            a developer can move the issue forward (e.g. on SIP issues, that the

    
   
45
 *            standard SIP debug and history, console output, and configuration

    
   
46
 *            file information has been provided, or in the case of a crash issue,

    
   
47
 *            that a proper backtrace has been provided)

    
   
48
 *

    
   
49
 *       If the necessary information has not been collected, then the issue

    
   
50
 *       should be moved to Feedback status, and the missing information be

    
   
51
 *       requested by the reporter*.

    
   
52
 *

    
   
53
 *       When all required information has been collected, the issue can be moved

    
   
54
 *       to the Acknowledged status.

    
   
55
 *

    
   
56
 *       \note (*) issues which remain in the Feedback status for more than 2 weeks

    
   
57
 *             without feedback from the reporter should be marked as

    
   
58
 *             Closed/Suspended

    
   
59
 *

    
   
60
 * \subsection Acknowledged Acknowledged

    
   
61
 *       The 'Acknowledged' status is the first step to issue resolution. It is

    
   
62
 *       an issue that has been filed correctly, the categorization and severity

    
   
63
 *       have been set, and that initial debugging information has been

    
   
64
 *       collected.

    
   
65
 *

    
   
66
 *       A developer may then review the issue tracker for Acknowledged issues

    
   
67
 *       and to determine whether additional information is necessary (i.e. that

    
   
68
 *       a crash issue with backtrace requires valgrind output, or other

    
   
69
 *       non-standard debugging feedback).

    
   
70
 *

    
   
71
 *       Issues may be moved to the next step in the workflow when the developer

    
   
72
 *       has either determined the issue is Confirmed, requires additional

    
   
73
 *       Feedback, is an issue that has already been resolved (or does not need

    
   
74
 *       to be resolved), in which case it should be Closed.

    
   
75
 *

    
   
76
 * \subsection Confirmed Confirmed

    
   
77
 *       The 'Confirmed' status represents issues which have been verified as

    
   
78
 *       existing in the current branch(es), and has all necessary information to

    
   
79
 *       be accepted into Acknowledged status. The general qualifier for an issue

    
   
80
 *       being moved to Confirmed is more than one community member stating the

    
   
81
 *       issue exists.

    
   
82
 *

    
   
83
 *       Confirmed issues may also contain patches created by developers which

    
   
84
 *       need to be applied in order to gain further knowledge or debugging by

    
   
85
 *       the original reporter, or any other community member who has verified

    
   
86
 *       this issue as existing. The developer will then move the issue to

    
   
87
 *       Feedback status while waiting for information from the reporter(s).

    
   
88
 *

    
   
89
 *       Issues with patches that are candidates for inclusion into the various

    
   
90
 *       branches that should resolve the issue are to be moved to the

    
   
91
 *       Ready for Testing status.

    
   
92
 *

    
   
93
 * \subsection ReadyForTesting Ready for Testing

    
   
94
 *       'Ready for Testing' indicates issues which have patches available for

    
   
95
 *       testing by community members or the original reporter which should

    
   
96
 *       resolve the reported issue.

    
   
97
 *

    
   
98
 *       If the patch does not resolve the issue, then it should be placed back

    
   
99
 *       into Confirmed status until an additional patch can be created for

    
   
100
 *       testing.

    
   
101
 *

    
   
102
 *       If the patch resolves the issue, then it should be moved to the Ready

    
   
103
 *       for Review status. 

    
   
104
 *

    
   
105
 * \subsection ReadyForReview Ready for Review

    
   
106
 *       When an issue has a patch that has been tested by a community member and

    
   
107
 *       which resolves the originally reported issue, should then be moved to

    
   
108
 *       the Ready for Review status. Issues marked as Ready for Review should

    
   
109
 *       then either be reviewed by another developer prior to merging (if it is

    
   
110
 *       a non-invasive fix), or the patch should be placed on Reviewboard if it

    
   
111
 *       is a complicated or invasive fix.

    
   
112
 *

    
   
113
 *       If an issue has a reviewboard link, it should be placed in the

    
   
114
 *       Additional Information section of an issue, and the marker [review]

    
   
115
 *       prefixed to the issue title.

    
   
116
 *

    
   
117
 * \subsection Resolved Resolved

    
   
118
 *        The Resolved status is rarely used directly by manual intervention, but

    
   
119
 *       rather is utilized by svnbot and other automated methods prior to an

    
   
120
 *       issue being closed.

    
   
121
 *

    
   
122
 * \subsection Feedback Feedback

    
   
123
 *       Feedback is used when an issue is awaiting information from the original

    
   
124
 *       reporter, or other active members of the community in the issue. Issues

    
   
125
 *       which remain in the feedback state longer than 2 weeks without feedback

    
   
126
 *       from any active participants, and which cannot be moved without, are to

    
   
127
 *       be Closed and marked as suspended.

    
   
128
 *

    
   
129
 * \subsection LicenseRequired License Required

    
   
130
 *       License Required is used when a patch has been attached to an issue, but

    
   
131
 *       which is currently in the License Pending state, or has been rejected

    
   
132
 *       and is awaiting the reporter to resign the license. 

    
   
133
 *

    
   
134
 * \subsection Assigned Assigned

    
   
135
 *        Issues marked as Assigned are the responsibility of the assigned

    
   
136
 *       developer, typically because they contain some sort of special knowledge

    
   
137
 *       required to resolve the issue, or because they have decided to take

    
   
138
 *       responsibility for moving the issue to resolution.

    
   
139
 *

    
   
140
 * \subsection Closed Closed

    
   
141
 *       Issues which have a resolution are marked as Closed. There are several

    
   
142
 *       resolutions that a Closed issue can contain, such as Fixed, Won't Fix,

    
   
143
 *       Duplicate, or Suspended. Issues that have been Closed manually should

    
   
144
 *       have an appropriate resolution set such as Suspended or Won't Fix, along

    
   
145
 *       with a note indicating why the issue was Closed.

    
   
146
 *

    
   
147
 *       If the issue is being closed due to a lack of feedback, the resolution

    
   
148
 *       should be Suspended, and a note indicating the issue was closed due to

    
   
149
 *       a lack of feedback, and that it will be reopened upon request if the

    
   
150
 *       reporter can provide the necessary information to move the issue forward

    
   
151
 *       again.

    
   
152
 *

    
   
153
 * <hr/>

    
   
154
 *

    
   
155
 * \section TypicalWorkflow Typical Workflow

    
   
156
 *

    
   
157
 * The typical workflow of an issue is as follows:

    
   
158
 *

    
   
159
 * \subsection Brief Brief

    
   
160
 *

    
   
161
 * New --> Feedback(*) --> Acknowledged --> Confirmed --> Ready for Testing

    
   
162
 *   --> Ready for Review --> Closed (commited, closed by svnbot)

    
   
163
 *

    
   
164
 * \note (*)Optional status used when not enough information provided to move to

    
   
165
 *          Acknowledged.

    
   
166
 *

    
   
167
 * \subsection Verbose Verbose

    
   
168
 *

    
   
169
 * - Issue is filed by a community member. All issues will start in the status New.

    
   
170
 *

    
   
171
 * - An issue marshal then performs triage on New issues and determined if they are

    
   
172
 *   valid issues (non-support), have been correctly categorized, have the

    
   
173
 *   necessary debugging information, etc...

    
   
174
 *   - Issues without the necessary information are moved to Feedback

    
   
175
 *   - Issues that are support, or feature requests without patches, are Closed

    
   
176
 *   - Issues that have all the necessary debugging information to move forward

    
   
177
 *     are Acknowledged

    
   
178
 *   .

    
   
179
 *

    
   
180
 * - After an issue has been moved to the Acknowledged state, then a developer will

    
   
181
 *   review to determine if the issue exists, and if so, to move it to the

    
   
182
 *   Confirmed state. If additional information is required, the issue may be moved

    
   
183
 *   to Feedback state.

    
   
184
 *

    
   
185
 * - An issue reaches the Confirmed state when the issue has been verified to

    
   
186
 *   exist. Issues that are Confirmed may also contain patches that provide

    
   
187
 *   additional debugging information.

    
   
188
 *

    
   
189
 * - Issues that have patches that require testing and feedback from the community

    
   
190
 *   are then placed in the Ready for Testing status.

    
   
191
 *

    
   
192
 * - Once a patch has been tested and confirmed to resolve the issue, we change the

    
   
193
 *   status to Ready for Review.

    
   
194
 *

    
   
195
 * - An issue that is Ready for Review needs to be looked over by a developer, or

    
   
196
 *   placed on Reviewboard (for larger patches) prior to being commited. Issues

    
   
197
 *   that are in Ready for Review are typically ready, or nearly ready to be

    
   
198
 *   commited.

    
   
199
 *

    
   
200
 * - Once an issue has been commited, svnbot will then Close the issue if the

    
   
201
 *   correct keywords are used in the commit message (see Guidelines for Commit

    
   
202
 *   Messages)

    
   
203
 * .

    
   
204
 * <hr/>

    
   
205
 */

    
   
206

   

    
   
207

   
  1. /trunk/include/asterisk/doxygen/mantisworkflow.h: Loading...

https://reviewboard.asterisk.org/ runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to asteriskteam@digium.com.