What is a good Defect Tracking process

Before we discuss that what are good Defect Tracking process first of all we'll discuss what exactly is a defect itself. If we are to understand, in a nutshell, that what a Defect is then we'll come to know that a defect in a software is usually a term that defines the concept of a failure to conform to specifications of the software package. For example, an incorrect implementation of specification and missing of the specific requirements(s) from the software.
Now after understanding briefly what Software Defects are, we're moving on to our next important topic that is a Good defect tracking process.
Software Quality Assurance engineers work together as a team in departments to effectively implement a good defect tracking process. What have been understood by surveys and analysis of SQA -that a good and effective defect tracking process is one that reduces the project cost to optimum level. And this cost reducing project can be achieved by implementing a decent defect tracking process that is well structured to track process initially by logging the defects, then investigating them, and then providing this structure to resolve them.
A good defect tracking process is the one that doesn't just fulfill formal steps and procedures but strictly ensure that defects are being handled in a well-appropriate and organized manner from the time they are discovered til their resolution. A well planned progress will always have priorities in itself regarding the value of a defect, so normally there are four types of defects:
One that needs to be resolved immediately.

Other high priority defects
Normal priority defects
and Low priority

An incorrect statement in the requirement of the software package or any other serious design flaw in the software is considered to be resolved immediately without any further delay, whereas such minor defects like a font size mismatch may be considered as a low priority defect. One of the most common yet most neglected flaws in a defect tracking process is a lack of or poor communication of the software defects, its status and changes to the members of the development team and all other possible concerned peers. This issue is most often arise when we see that development team is not only working separately within one building but also remotely (i.e. a bunch of coders in one state, whereas others in the other far distant state). In such scenarios, we see atleast 30% flaw in the communication which makes the tracking process to slow down, misinterpret, stay ambiguous, and sometimes (though not often) stops abruptly. So after understanding all these aspects a good defect tracking process is the one which is perfect communication as one of its component.
And finally at the end we're gonna discuss about how a defect reporting is done in an effective defect tracking procedure. These reports are exclusively sent to those people of the department who are responsible for decisions about the resources, cost, and ofcourse the delivery schedules. Many organizations may have a different form for reports but all of 'em have these three basic categories of reporting: