SEP Confidential

05/17/2016

Code Review Issues Log

Review Content
Review Date
Start Time
Review Duration
Review Location

Project Code
Project Lead
Primary Owner
Moderator

Contributors
Name

Contributors

Form Version: 07/2004

Initials

Attended

Total Prep Time

Prep. Time

Role

1 of 12

Code Under Review

Location
File

New Version

Previous Version

Change Type

0 Total Files

Code Review Action Items

#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

File Name

First Line

Last Line

Action Item Description

Total Items

Approved
Items

Unresolved Items

Source

Disposition

Assigned To

Severity

Resolution Notes

Close Date

70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144

145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219

220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294

295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369

370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400

Summary of procedure
1
2

3
4
5
6
7
8

10

Code owner requests a review and a moderator is

chosen.
The moderator prepares this log, filling out all available
information on the cover sheet and listing the material.
The moderator distributes this log to all invited
individuals.
Each individual compiles (in this log) a list of issues
found when reviewing the listed materials.
Each individual submits the issue log back to the
moderator/
The moderator combines all the issues into a master
issues log and brings it to the review meeting.
The group examines each issue during the meeting and
determines the appropriate disposition.
The moderator submits the completed review log to the
appropriate location after the meeting. This location will
vary by project.
The owner makes the approved changes from the
review log, making an appropriate resolution for each
one.
When there are no unresolved issues, the code review
changes are considered completed.

Roles
Role
Owner

Moderator

Reviewer

Approver

Description
An individual responsible for the code under review.
This is typically either the author or maintainer of the
code.

Attendance
Required at review except in specific circumstanced
approved by the project lead.

The individual responsible for managing the code

review activity. This individual will schedule the review,
moderate the meeting, and distribute the results
appropriately.

Required at review.

An individual responsible for reviewing the code and

reporting detailed descriptions of any issues found.
The individual with the authority to verify the completion
and acceptability of the code review. This individual is
responsible for the final approval of the results.

Not required at review, but attendance is encouraged.

Not required at review.

Dispositions
Disposition

Description
Indicates that a proposed issue has been approved and
needs to be resolved.

Resolution Requirements
The issue must be fixed and the resolution noted and
dated in this log. Alternately, the issue may be later
changed to transferred. If the issue was overcome by
events, mark the resolution as such and close the
issue.

Indicates that a proposed issue was not approved.

Indicates that a proposed issue will be discussed
outside the review context and revisited with an
appropriate disposition following the further research.

No further action is required.

The issue must be revisited and the appropriate
disposition selected based on discussion.

Indicates that an issue has been moved to another

tracking mechanism.

The new tracking system should be noted in the

resolution notes and the closed on date set to the
submission date of the other tracking system.

Indicates that a proposed issue was describing the

same problem as another proposed issue.
Indicates that an issue has yet to be evaluated by the
review group. This is the initial disposition for all issues.

No further action is required.

Accepted

Rejected
Deferred

Transferred
Duplicate
Proposed

All proposed issues must be examined before the end

of the review meeting. No issue may remain in the
proposed state.

Severities
Disposition

Description

Resolution Implications

Severity 1

Identifies a critical failing of the software that is

identified in the code. Problems of this nature are
apparent to the user in the form of invalid data,
improper procedural results, or inappropriate/incorrect
messages.

Severity one issues must be resolved immediately, and

software should not be released with outstanding
severity one issues except in extraordinary
circumstances.

Severity 2

Identifies a serious flaw in the code. These problems,

while not apparent to the user (see above), impact the
correctness and maintainability of the code. They may
also indicate program performance problems which are
not apparent to the user.

Severity two issues should usually be resolved before

any release to a customer. If these issues are not
fixed, they should be individually evaluated by the
project lead before the software is released.

Severity 3

Identifies a minor flaw in the code. These problems will

not impact maintenance or the user, but are identified
issues that should be resolved where possible.

Severity three issues should be resolved where

possible. However, releases may occur as they do not
impact the user or strongly impact future development.

Field Name

Description

Cover Sheet Fields

Review Content

Describes the content that is the focus of this review.

Review Date
Start Time
Review Duration

The date on which the review meeting is to occur.

The time at which the review meeting is to begin.
The scheduled duration for the review meeting, in
minutes.
The location where the review meeting will occur.
The project code that is to cover the time spent
preparing review issues and attending the review.
The lead of the project referenced above.
The single individual that is primarily responsible for the
code to be reviewed.
The single individual serving as moderator for this code
review.
The name of the individual participating in the review.

Review Location
Project Code
Project Lead
Primary Owner
Moderator
Name

Initials
Attended
Prep Time
Role

Field Name

Guideline
Should be a reasonably short description of the
content that serves to generally identify it to members
of the project.

All required invitees should be listed, even if they fail to

provide an issues list or attend the review meeting.
Optional invitees should be listed if they agree to
participate.

The (unique) initials of the individual.

Yes if the individual attends the review meeting, no
otherwise.
The amount of time, in minutes, that each individual
spent preparing for the review.
One or more role titles describing in what capacity an
individual is participating.

Description

This should only represent the time spent outside the

review meeting.
Simple comma separated list of roles. It is allowable to
expand or add roles if needed, such as "Quality Team
Representative" instead of just "Approver"

Material Sheet Fields

Guideline

Location

A description of where to find the files to be reviewed.

For files available on the network, this should be the

fully-qualified path pointing to the lowest folder that is
common to all files being reviewed. If the material is
under ClearCase source control, the path should be of
the format "{vobname}\source\...\MyProject"

File

The description of the specific file to be reviewed.

This should be a fully qualified path relative to the

location provided at the top of the sheet. In the simple
case, it will just be a filename if all files are in the same
directory. If further entries are needed, please insert
rows into the (middle of) the table.

Version

The version of the file that should be reviewed.

If appropriate, the ClearCase version of the file to be

reviewed. Can be of the form /main/4 or /main/latest

Previous Version

The original version of the file to be reviewed.

This should version identifier formatted as above. If

provided, this indicates that reviewers should review
the changes between the two versions, not the entire
files. This is mutually exclusive to providing a range of
line numbers.

Lines

Line numbers within the file to be reviewed.

If provided, this range of lines is all that should be

reviewed. This is mutually exclusive to providing a
previous version.

Field Name
Total Actions

Description

Action Item Sheet Fields

Guideline

An indicator of the total number of action items listed in

the sheet.
An indicator of the number of actions that have been
approved for further action, either transferred,
approved, or deferred.

Read only, this is automatically calculated.

Read only, this is automatically calculated.

File Name

An indicator of the number of approved actions that

have not been resolved.
The name of the file prompting the action item, or "All"

First Line

The line number where the issue can be found.

Last Line

The last line number of the range containing an issue.

Action Item Description

A complete description of why this is an issue, and

possibly a recommendation of how to resolve it.

Source

An indicator of who initiated the issue.

This should be an individual's initials from the list of

participants on the front page. The individual should fill
this out when submitting issues.

Disposition

Describes the disposition of the action item.

One of the items defined in the disposition list,

provided above. Please view that table for an
understanding of how this field should be used. When
submitting the individual issue logs to the moderator,
this should be set to "Proposed" for all issues.

Assigned To

An indicator of who is responsible for resolving the

issue.

This should be an individual's initials from the list of

participants on the front page. It will be filled out
during the review meeting. If assigning to an individual
not participating, add them to the participant list with no
role assigned.

Severity

Describes the severity of the action item.

Resolution Notes

Any notes associated with the resolution of this item.

This should be filled out during the review. It refers to

one of the severity levels listed in the table above.
Describe the changes or actions taken to resolve this
issue. If the change is simple and consistent with the
described issue then "Code Changed" or "Comment
removed" is appropriate. If the item is transferred, this
should describe the new location of the item. If the
item is rejected, this should say why.

Close Date

The date on which the resolution occurs.

Approved Actions

Unresolved Actions

Read only, this is automatically calculated.

This should be an entry from the list provided in the

materials list.
If multiple lines are part of the same issue, this should
be the first line of that range. If the lines are not
contiguous, separate issues should be generated.
If provided, indicates that the issue is with a block of
code, and not a single line.
This should be sufficient to understand what's wrong
with the code and what is required to fix it. Avoid
vague statements of the nature "Remove comment" if
possible, although "Remove empty comment" is quite
appropriate. Examples: "Comment regarding iteration
count is redundant with loop declaration. Please
Remove." and "The failure to release the interface
pointer on line 234 will cause a memory leak. Ensure
all pointers are released before being reassigned in
loops." Avoid open-ended issues, such as "This needs
refactored" and provide specific recommendations that
can be evaluated for disposition.

This item is only appropriate for items with dispositions

"Transferred" or "Accepted". The spreadsheet will
indicate an error otherwise.