Resolve Open Change Requests

You resolve open change requests by following the steps below. Before you start working on a change request, be aware of any processes required by your team. For example:

  • Your company might require that the change request Status be changed to In Progress.
  • You might be required to link open change requests to the associated file or files that need to be changed. If this is the case, when you check in a file or group of files, you can indicate the change requests that are being fixed by the files. Doing this saves the time it would take to change the status of each change request.
  1. To locate change requests that need to be resolved, select a folder in the Server Explorer or in one of the Eclipse views and then open the Change Request view.
  2. Click Link with Selection.
  3. Double-click the change request. The Change Request <number, revision #> dialog box opens.
  4. Change the Status of the change request to one of the resolved statuses: Fixed, Documented, or Cannot Reproduce. Alternatively, you might use Is Duplicate or As Designed, if either of these is appropriate.

    When you select a resolved status, StarTeam automatically makes the following changes to the change request:

    • Places the name of the person who submitted the change request in the Responsibility field. The assumption is that the person who submitted the change request will want to know about, verify, or perhaps challenge the change in status.
    • Changes the setting for the Addressed in build field to Next Build (if the status has changed to Fixed or Documented). When the next build label is created, Next Build changes to the name of the build label. The assumption is that the person who verifies that the change request has been implemented should test the correct build of the product.
  5. If you choose Fixed or Documented as the new status, select the Solution tab and type the appropriate information in the Work Around and/or Fix text boxes.

    Often a change request suggests one or more fixes for a problem, and none of these suggestions are implemented. To avoid confusion, the fix that is implemented must be described in precise detail. Testers and writers rely heavily on this information.

  6. Click OK.
Tip: Although the application makes these automatic changes immediately, you can change the Responsibility or Addressed in build setting before you click OK (or Apply, if appropriate). In this way, you can bypass the automatic workflow and route the change request as your team requires.