TPTP Development Process

Process documentation
Bugzilla fields

When opening a bugzilla, use the following definitions of severity and priority to categorize the bugzilla
correctly. Typically a high severity means a matching high priority, but it is possible to have a bugzilla
with a high severity and a low priority. For example, if the defect is a problem that blocks use of a
enhancement, but that enhancement is a corner case that has few (if any) users, then that bugzilla
would be high severity but low priority.

Priority Definitions
Priority Definition
P1 Cannot ship without this enhancement
P2 Highly desirable and planned for this release,
but not stop ship
P3 Of interest, but not planned or expected in this
release
P4 Not used by TPTP
P5 Not used by TPTP

Severity Definitions
Severity Definition
blocker Prevents function from being used, no work
around, blocking progress on multiple fronts
critical Prevents function from being used, no work
around
major Prevents function from being used, but a work
around is possible
normal A problem making a function difficult to use but
no special work around is required
minor A problem not affecting the actual function, but
the behavior is not natural
trivial A problem not affecting the actual function, a
typo would be an example

Bugzilla Process

The bugzilla Reporter (a.k.a. "Originator" or "Submitter"), when opening a defect,

1. Sets the severity level of the bugzilla (Severity = anything other than "enhancement").
2. Sets the the Version to the version of TPTP that the originator found the bug in.
3. The reporter does not adjust the Target Milestone of the bugzilla. For defects, the reporter
should indicate in the description what target milestone that they would like the fix to be
delivered in.
4. The reporter does not adjust the Priority of the bugzilla. For defects, the assignee chooses
 the Priority while the reporter chooses the Severity.

The bugzilla Reporter (a.k.a. "Originator" or "Submitter"), when opening an

enhancement,
1. Sets the severity level of the bugzilla (Severity = "enhancement").
2. Sets the Version to the version that the reporter wants the feature done in.
3. Chooses the Priority of the bugzilla only if the bugzilla is for an enhancement. The reporter
should state in the description what priority (P1/P2/P3) that this enhancement is for them,
and the assignee sets the priority field to match. The assignee then negotiates with the
reporter if they disagree with the priority of the enhancement.

Note that the priority level chosen by the reporter is a guideline for TPTP, and may or may
not be changed by the Requirements Group when it's time to create a TPTP plan.
5. The reporter does not adjust the Target Milestone of the bugzilla. Only the assignee may
adjust the Target Milestone of the bugzilla. The Target Milestone of an enhancement may
be set by the assignee to one of the following:

• --- if the enhancement is not triaged or requires triage.

• future if the enhancement is not committed into a TPTP plan.

• <release> [<iteration>] if the enhancement is committed into a TPTP plan based on guidance from
the AG and Project Lead.

The bugzilla Assignee (a.k.a. "Owner" or "Committer"), when processing a bugzilla,

1. Chooses the priority level of defects.
2. Sets the target milestone. The target milestone reflects the release and iteration when:

• The change will be checked into CVS.

• The defect is resolved without a change (e.g. INVALID, WONTFIX, LATER, REMIND,
WORKSFORME and duplicate of another defect).

If the assignee disagrees with the severity, the assignee negotiates with the reporter to adjust.
Likewise, if the reporter disagrees with the priority or target milestone, the reporter will negotiate with
the assignee to adjust. However, typically each will not directly change the others' settings.