Most of the problem here is, I think, one of terminology, or perhaps more accurately, a lack thereof.
In the good old days when CM was a discipline that covered the product from Requirements to Archiving, there were numerous CR's. That is to say, CR was a generic term. I think the practice of thinking of it as "the" form came from a view internal to the software developer team, because by the time it gets to them, it's simply a request to change the software..
In any event, here are a few of the more specific terms:
1. Engineering Change Proposal (ECP) or Configuration Change Proposal (CCP):
ECP is typically the top level form of a CR and may require the most time and effort. An ECP is the vehicle to propose requested changes to functionality or product changes due to external changes in available technology. For example, an ECP would be submitted if a customer identifies a need/desire to have the system automatically generate an email when event X happens. In a robust CM program, the customer might want to know up front how much it will cost, how long it will take, will new equipment be required, etc. For the other example (technology change), if a new operating system won't support the old software, an ECP might propose staying with the old system or upgrading the system and creating new software.
Assuming approval in either case above, everything has to be changed -- requirements documenation, design documentation, system/subsystem specifications, etc. Identification of all these elements would be revealed on the ECP form. Depending upon the complexity of the product, the actual changes might be listed or the ECP might spawn multiple child ECPs to address the items listed. When all of the children are closed, then the parent can be closed.
By the time an ECP gets to the programming team, they will probably view it as, wait for it, darn! you guessed it, "a CR."
2. The Test Problem Report (TPR) - provides feedback to the development team and says essentially, "This is an instance where the result differs from the expected result." In other words, fix this. Depending upon the nature of the problem, the "fix" might require a change in requirements or technology, which will require an ECP (and the TPR can't be closed until that ECP is closed).
3. The Test Incident Report (TIR) - Not really a change document, but a notification that something in the testing environment is or went amiss. A TIR could cause initiation of an ECP if the solutin to the TIR was to modify the test environment. For example, the program was created to run on OS2 but the testing environment is still running OS1, an ECP might be generated to upgrade the OS.
4. Defect Report (DR) -- Usually arises from a review of some kind (visual scan, formal stage gateway review, field usage, etc.) rather than software testing. I don't recall using a DR in the software environment very much if at all. However, an example might be one icon on-screen but another in the user manual. In hardware a DR could be used to report physical flaws or deviations from material specifications.
5. Discrepancy Report (DSCR) -- Sometimes used on documentation. For example, an abbreviation "1B1" that appears in one place and "B1B" appears in another. Are they supposed to be the same? If so, which is correct? The resulting change might be a simple correction, but to the CM world, the DSCR provides the traceability from one version to the other. If the change would affect functionality or design, then the DSCR could spawn an ECP.
6. Help Desk Ticket or Trouble Ticket (TT) - Obviously originated by the Help Desk. In my experience, you probably won't see these unless the problem is NOT NORMAL. The one's you see are those that have been escalated to Tier 3. As a suggestion, I wouldn't pass the TT to the fix-it shop. Rather, generate one of the above other types and cross-reference the two. (The two usually use different change document tracking systems; for example, Remedy for help and something else for CM change documents.) One way this might operate is give the Help Desk "origination" rights on the CM system. Then, if they need to escalate, they submit a change request (probably a DR) referencing the TT. On the TT, they reference the DR. Then as a policy, they keep the TT open until the DR has been satisfied.
(Thus, the Help Desk can track progress for the user. Also be aware that the DR might spawn an ECP which must be closed before the DR can be closed, which is required before the TT can be closed. Now, trust me on this one -- getting the Help Desk to buy in on this one is going to be a tough sell. All that time for a DR then an ECP and possibly the resulting TPRs will ruin Help Desk resolution numbers. They love to claim TT resolutions within some timeframe, like "no TT open longer than X hours, to that point that some of them will open a second ticket and close the first at X-1 minute just so they can claim goal achievement.)
But back to your post, again I think your conflict is a matter of terminology. In a sense, you are both wrong. Why? Because you both imply that a CR is a specific term.
