When opening a Bugzilla, use the following definitions for various Bugzilla fields to categorize the Bugzilla correctly. For example, typically a high severity means a high priority, but it is possible to have a Bugzilla with a high severity and a low priority when the defect blocks an enhancement but the enhancement is a corner case that has few (if any) users.

Priority Definitions

Priority	Definition
P1	Cannot ship without this Bugzilla
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

Keyword Definitions

The following keyword definitions extend the existing Bugzilla Keyword Descriptions:

Keyword	Definition
plan	Used only during the release planning phase by Project Leads and PMC members to tag the Bugzillas in the release plan.

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. Once the priority of the Bugzilla has been set, the assignee should notify the Project Lead when the priority is decreased.
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.