Although the CR form shall indicate the details of change, each CR shall have attached the pages of the specification that are affected by the CR, using the latest version of the major version. These pages shall have the proposed modifications clearly marked, by means of the word processor's "revision mode".
In case there are more than one independent CR to the same part of the specification, neither of them should contain the proposed modifications from the other(s), however any potential interaction between the modifications should of course be resolved before presentation.
Entry to the TSG WG:
A proposed CR should be brought to the relevant Group primarily responsible for the specification concerned and discussed there, before presentation to the TSG. If possible it should be distributed, by the source, as soon as possible and prior to the coming Group meeting to the relevant e-mail reflector (with a clear indication of the subject), for the purpose of shortening discussions in meetings and to try at as early a stage as possible to come to a widely acceptable solution. Comments from secondarily responsible TSGs (if any) shall have been sought and comments shall have been taken into account before presentation to the TSG for approval.
To ease the work of the Group and of the Support Team , a proposed CR should be presented in a form suitable for TSG WG agreement and TSG approval. If a CR is not immediately accepted the originator shall update the CR taking into account comments and other guidelines from the relevant groups, including change of reference version if needed, and to re-present it to the Group.
All CRs shall be presented in electronic form.
During the course of its development, a CR may be modified, and the CR's progress shall be indicated by allocation of a revision number: rev. 1, 2, and so on. A given revision of a CR is uniquely defined by
the specification to which it belongs, and
an alphanumeric string (the CR number) and
the revision number (default, i.e. the value if no number is given, is 0, i.e. the original, unrevised, CR).
The CR number shall be allocated by the Support Team.For a given Specification, CR numbers shall be unique and shall never be reused (see clause 4.6.1
). Numbers used for rejected CRs shall not be reused. If a CR is rejected, and the responsible Group considers it useful to bring a modification of the CR to a subsequent TSG for approval, the new CR shall be allocated a new number. That is, it shall not be presented as a revision of the same CR number previously rejected.
Impact on other specifications and Joint CRs:
If the content of the CR is such that, in isolation, it makes the whole set of approved Specifications inconsistent, corresponding CRs shall also be considered and produced. This should be carried out by the originator of the CR (and his colleagues in other Groups) in advance. The Support Team is co-responsible for identifying and communicating cross-TSG and cross-TSG-WG impacts.
In principle, a CR shall not be forwarded to the TSG unless the potential impact on other specifications has been thoroughly examined and concluded, either resulting in a "No impact" statement or in a full and consistent set of corresponding CRs to all affected specifications. Such sets of CRs should be combined into a single document, by the Support Team , before submission to all responsible TSGs and called "Joint CRs". An approval by all primarily responsible TSGs is necessary.
If some of the corresponding CRs are to be considered by other Groups, the Support Team shall be responsible for monitoring the result in those Groups and for submitting the full set, when available, to the TSG. This might mean that in some cases the CRs agreed in the TSG WG are not presented to the immediately following TSG meeting due to outstanding CRs from other Groups.
Other "consequential" CRs, needed for reasons other than direct consistency, may be drafted, presented and agreed independently. This covers typically additions to test specifications and O&M specifications. If a CR causes an inconsistency with an existing/approved test or O&M specification, the corresponding CRs should be presented together with the core specification CR.
Handling of the CR in the TSG:
When the TSG WG has agreed to a CR and comments from secondarily responsible TSGs (WGs) have been taken into account, the Support Team shall ensure that it is correctly formatted and assembled, and shall submit the CR to the primarily responsible TSG for formal approval.
The Support Team shall make available to the TSG summary lists of all CRs presented for decision. This list shall be updated to show the decision reached for each and every CR.
Decisions on CRs, and results:
The TSG shall consider and conclude on each CR independently, except for Joint CRs, which are handled and concluded together; the verdict on each CR shall be one of the values listed in clause 9.2
Control and notification of CR decisions:
At the end of each TSG meeting, the Support Team shall issue lists containing the detailed result of the CRs presented at the meeting, including information about the consequential new version numbers of the concerned specifications. These lists shall form an annex to the meeting report (and hence are part of a permanent document). These lists, being the evidence of which specifications have changed and how, are important management tools for both TSG delegates and the Support Team since it takes some time before the new versions of the specifications can be compiled and released.