Document Number: AUSTIN/SD/6 Title: Committee Maintenance Procedures for the Approved Standard Revision Date: 2012-04-12 Source: Andrew Josey, Chair Action: for information Change History: 112r1: Initial updates after review. 112r2: Minor updates to remove references to WG15. 112r3: Updates to switch defect reporting to using Mantis/ 112r4: Updates to describe procedure for reopening a Mantis bug, and document changed to SD/6 (April 2012) Purpose The purpose of this document is to describe the operational procedures for the Austin Group's maintenance of its set of consensus specifications. This includes how defect reports are generated and accepted, production of responses to defect reports, including production of technical corrigenda, interpretations and a policy on new work items proposed for a future revision. This document does not define how the participating organizations will ballot any resulting corrigenda or publish interpretations/defect reports. The intent is that the outputs will be suitable for entering into the formal process (the Joint Procedures Committee document should be consulted for further information). ----------------------------------------------------------------------- Part 1 - Defect Reporting Procedures 1. PARTICIPATION IS ELECTRONIC. THERE IS NO PAPER. 2. The final standard can be obtained from sponsoring organizations in electronic format. There is also a html version freely available on the world wide web. Proposed technical corrigenda, when available, will be available with line numbers for the purpose of review. 3. Defect reporting is online using a Mantis defect tracker at http://www.austingroupbugs.net For advice on defect reporting please see http://www.opengroup.org/austin/mantis.html 4. All members of the review group for defect reports should be on the main Austin Group reflector. All inbound defect reports are sent to the main reflector. Please keep primary discussion of issues concerning the Specifications on the Mail List. Add notes to a defect report only for cogent and specific information. 5. All defect reports shall be submitted electronically using the defect tracker at http://www.austingroupbugs.net Select an appropriate "Project" for the bug report. Defect reports must refer to a final approved standard, or proposed technical corrigenda (when available). If you feel there is a problem with the defect tracker select the project "Aardvark Bugs" The approved standard includes line numbers which should be used when submitting defect reports. In the absence of the line numbers, for example if using the html version, exact URLs and a description of the paragraph number within a subsection are needed to identify the problem. All review comments are made publically available at the Austin Group defect tracker as they come in. Reviewers should ensure that they are familiar with the detailed scope of the project when submitting comments. 6. A review resolution meeting shall occur periodically to review the defect reports. For those who submit comments you are urged to attend the review resolution meeting or to be available via email and/or telephone during a meeting to respond to any queries related to your review comments. [Note that this means that meeting hosts should be willing to provide telephone connectivity for voice and data communications] The meeting shall review each defect comment and record a disposition Accepted Accepted As Marked Duplicate Rejected A rationale is recorded with each defect report for rejected or partial changes. 7. During a review meeting, updates are made in the defect tracker to record the decisions made in the meeting. The defect tracker sends details of these changes to the main Austin Group reflector. 8. It is the responsibility of individual reviewers to check the updated defect reports (or query the defect tracker system) to find out the disposition of their individual review comments. If a reviewer disagrees with the proposed resolution of an open bug (defect tracker system state for the bug is not Closed and is not Resolved) he or she should (1) submit an additional comment into the defect tracker system, (2) raise the issue on the main Austin Group reflector, (3) raise the issue during the next Austin Group meeting, or (4) raise the issue with his or her Organizational Representative. When a bug within the defect tracker system moves to the Closed or Resolved state it becomes read only. If a reviewer feels that a Closed or Resolved bug should be reopened for further discussion, he or she should choose one of the last three options in the previous paragraph to propose further changes and explain why the bug should be reopened. If discussion on the main reflector or during an Austin Group meeting convinces a majority of the Organizational Representatives that further changes are needed, a working group member with defect tracker system Manager status will reopen the bug. ----------------------------------------------------------------------- Part 2 - Defect Reporting Response Everything starts out as a defect report, unless raised during a plenary session when the ORs are present. There are four possible outcomes to a defect report : 1.The committee agrees with the defect report and is proposing a change for inclusion in a technical corrigenda. 2.The committee agrees with the defect report and is proposing to enter the report and response into the interpretations process. 3. This appears to be a new work item and is thus out of scope of maintenance, and cannot be addressed through technical corrigenda or interpretation. The response to the defect report should be the "Future Enhancement" resolution 4.No action arising , the response to the defect report closes this item. The rest of this section describes the criteria for technical corrigenda, the interpretations process, and recommendations for how new work items are addressed. Technical Corrigenda A technical corrigenda item can change the meaning of the standard, as such all technical corrigenda require formal approval by the sponsoring organizations (usually through a formal ballot process). The following are the criteria for a Technical Corrigenda (TC) item: a. It has to be in the scope of the original Austin Group project. (see http://www.opengroup.org/austin/docs/austin_9r6.txt) b. It should be non-controversial ( a TC is intended to pass ballot at the first attempt) c. It contains no new APIs (functions/utilities), however it may add enumeration symbol and non-function #defines and reserve additional namespaces. d. Typically a TC is used to fix contradictions between different parts of the standard, add consistency between the standard and overriding standards, and to fix security-related problems. Interpretations Interpretation processing occurs concurrently as part of processing defect reports. It is important to make sure that any interpretation has received the concurrence of a balance of interests. For this reason, the Austin Group is not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. An interpretation does not change the meaning of the standard. Notes to the editor (not part of the formal interpretation) are expected to be considered in the next revision of the standard. An interpretation may be controversial. Interpretation requests are reviewed and evaluated by an official interpretations group (the Austin Group reflector). The following set of guidelines are provided to ensure requests are processed appropriately. There are three over-riding rules related to interpretations: Rule 1) THE STANDARD IS WHAT IT SAYS. The words actually approved by the balloting group reflect the requirements set forth by that document. If the words are substantively wrong, then corrective action can be taken via the technical corrigenda process with the full backing of the consensus process. Interpretations must be a comment on what the standard actually does say, not what it should say, nor what it says incorrectly. These are mechanisms for quick revision of the standard (TC), and these must be used to make changes to "how things should be". Rule 2) If THERE IS AMBIGUITY in what the standard calls for; then interpretations must favour a looser conformance requirement rather than a more restrictive one. This will allow some "weirdnix" implementations to conform to a current standard. Again, corrective action can be taken via the technical corrigenda process and eliminate this ambiguity with the full backing of the consensus process. Rule 3) If THERE IS A CONTRADICTION between two sections of the standard, and there is reason to believe that one part is correct, then the rationale should be elucidated and the technical corrigenda process applied. Pro-forma responses In order to follow the guidelines, interpretations make use of the following pro-forma responses to guarantee uniformity of the process. Note, stating the conformance implications is important, and offers a way to distinguish between requirements placed on implementations, applications, and test methods. 1.THE UNAMBIGUOUS SITUATION: "The standard clearly states....,and conforming implementations must conform to this" 2.THE "DEFECT" SITUATION (i.e. the balloting group appears to have gotten it wrong): "The standard states..., and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor." 3.THE AMBIGUOUS SITUATION: "The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor." 4.THE UNADDRESSED ISSUE: "The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor." 5.CONDITIONAL INTERPRETATION BASED ON OTHER STANDARD(S): "The required behaviour of this xxx standard is dependent on the requirements of the yyy standard. If yyy requires aaa then xxx requires bbb, whereas if yyy requires ccc then xxx requires ddd. A request for interpretation of the yyy standard is being forwarded to the yyy committee." 6.SUBSTANTIALLY IDENTICAL TO PREVIOUS INTERPRETATION: "This request is substantially identical to interpretation #aaa, and the resolution of that interpretation applies in this case." 7.SUBSTANTIALLY IDENTICAL TO PRIOR REQUEST, BUT WITH CRITICAL NEW PERSPECTIVE: "This request is substantially identical to interpretation #aaa, however in considering it appears that the previous interpretation should be superseded. The current interpretation for this situation, (which does affect the previous conclusion) is...". In this case an attempt should be made to notify the previous requester. 8.REQUEST FOR INTERPRETATION OF A DIFFERENT DOCUMENT (draft..): "This request is for interpretation of xxx, the approved standard is yyy, the requester is asked to re-submit this request if the question(s) are still pertinate to the approved standard." 9.REQUEST IS UNCLEAR : "This request is not sufficiently clear to permit an appropriate interpretation. The Requester is asked to submit a rephrased or more specific request." New Work Items From time to time, a defect report may propose new work items that are outside the scope of maintenance of the Austin Group specifications. This section addresses how these are handled. The Austin Group is not a development body for new material apart from integration issues arising from the merger of the approved standards that were the Base documents into the revision. The Austin Group expects to take a similar approach for a future revision. Thus if a defect report raises the possibility of new interfaces for inclusion, the standard response will be that it is out of scope for either a TC or Interpretation, and that if the new material were to meet the some criteria it may be considered for inclusion in a future revision subject to the agreed scope determined at that time, although there is no guarantee. The recommended criteria for development of new interfaces to enable them to be considered for inclusion in a future revision are as follows: 1.There must be a written specification that has undergone a formal consensus based approval process and is suitable for inclusion. Parties interested in submitting new work items through one of the three organizations within the Austin Group (The Open Group, IEEE, ISO/IEC) should contact the appropriate Organizational Representative for further information and advice on how each organization handles new work items. Submissions from other organizations will also be considered. Items 2 through 4 below apply to all submissions regardless of origin. 2.There must be an implementation, preferably a reference implementation. 3.The specification must be "sponsored" by one of three organizations (The Open Group, IEEE, ISO/IEC) within the Austin Group, i.e. they would support and champion its inclusion. 4.Submitters must provide an outline plan of the editing instructions to merge the document with the Austin Group specifications, and assistance to the Austin Group editors as required to complete the merger. For an example, see https://collaboration.opengroup.org/platform/single_unix_specification/protected/mailarch.php?soph=N&action=show&archive=austin-group-l&num=434 [^] or https://collaboration.opengroup.org/sophocles/mailarch.php?soph=Y&action=show&archive=austin-group-l&num=434 [^]