2. The Standards Development Lifecycle

The Standards Development Lifecycle is the set of processes governing development of a document on the standards track from project initiation, through development, formal review, approval, publication, and maintenance.

Figure 2. The Standards Development Lifecycle

Throughout the lifecycle participants must adhere to the guiding principles of The Open Group.

2.1. Initiate Project

Figure 3. Standards Development Lifecycle: Initiate Project

Project initiation to develop a new standard, or revise an existing standard, within a Forum/Work Group must be a consensus decision of the body.

The initiation stage includes consideration of whether the project is a new work item, or a project to revise an existing base document. There must be an agreed project scope/charter describing the purpose, scope of the project, and expected deliverables.

2.1.1. New Work Item

For a new work item, where there is no existing base document, the Forum/Work Group, in cooperation with The Open Group Manager and the Technical Editor, define the process for Draft Development, ensuring that it complies with the governing processes of the Standards Development Lifecycle.

Figure 4. Developing a New Standard

The starting point is one of The Open Group document templates; refer to Resources. The use of an official template is necessary for approval. Material can either be developed or contributed, or both.

2.1.2. Revision to an Existing Standard

Where there is an existing standard, then the Forum/Work Group, in cooperation with The Open Group Manager, must define the detailed scope of the revision to the standard. This could be a limited set of corrections that could be published as a Technical Corrigendum, or a major revision, in which case the whole document would be open for change as per the defined project scope/charter. The starting point for a revision is the existing document.

Figure 5. Revising an Existing Standard

When revising a standard, the project scope/charter must address compatibility, migration, and the impact on the ecosystem around the standard (such as certification). Changes to an existing standard must be framed as Change Requests (either explicitly or as detailed markup to the base document) so as to document the traceability between versions of the standard, and to allow the consensus decision-making process to occur on the proposed changes.

2.2. Draft Development Process

Figure 6. Standards Development Lifecycle: Draft Development Process

When developing a draft standard the Forum/Work Group must use the consensus decision-making process in order to establish consensus on the text being produced.

The process to develop the draft must be open to all eligible participants of the Forum/Work Group and be seen to be open. A high-level overview of the Draft Development Process is defined in Section 3.2.1 of the Standards Process; refer to: www.opengroup.org/standardsprocess). (Note that approval to add to a work program is covered by the previous section of this document – Initiate Project.)

When developing a standard, it is important to use a template and adhere to the style guidance within the template. See also Developing Standards Text.

There must be at least one review within the Forum/Work Group to establish the consensus on the draft document prior to entering the Company Review Process. The process for such a review can take different forms, such as periodic draft development meetings, or a formal Forum/Work Group Review Process with Change Requests; refer to Forum/Work Group Review Process.

The Open Group Manager must manage the review. Forum/Work Group participants and The Open Group Manager should seek the widest possible participation in the review to ensure a broad base for consensus.

At the end of the Draft Development Process a test of consensus to enter the Company Review Process must be taken; see Consensus for Company Review. Tests of consensus that have a low percentage of group participation may be deemed insufficient to demonstrate that consensus has been reached.

Figure 7. The Draft Development Process

2.2.1. Consensus for Company Review

Prior to holding a Company Review for a document, which would involve all members of The Open Group, the Forum/Work Group must make an explicit decision to move into the Company Review Process using the consensus decision-making process.

The Open Group Manager decides how the decision is taken, for example whether a Forum/Work Group Review Process with Change Requests is required to establish consensus, or whether a resolution of the Forum/Work Group will suffice.

2.2.2. Forum/Work Group Review Process

The Forum/Work Group Review Process is an option for establishing consensus on a draft document during the Draft Development Process. It is conducted within the appropriate body developing the document. The process is modeled on the review part of the Company Review Process. It can include the participation of invited experts, such as members of other Forums within The Open Group. The review can include non-members subject to an appropriate invited expert agreement being in place with the individual.

Change Requests are statements of desired changes that the reviewers would like to see applied to the review document to make it acceptable to them.

The Forum/Work Group is responsible for resolving all Change Requests submitted during a Forum/Work Group Review:

  • Resolving Change Requests can include accepting, declining (rejecting), or accepting with modification

  • The defined level of consensus (75% of those voting) is required to resolve Change Requests

The length of a review is dependent on the size of the document, but is typically between two (2) and four (4) weeks.

The review group is usually the membership of the Forum/Work Group, plus other relevant groups and experts.

The review is usually conducted using The Open Group Document Review system. It can also be conducted by email.

The Forum/Work Group is the sponsor of the review. Assuming that the ballot is on proposed resolutions and not original Change Requests, then the sponsor reviews all the Change Requests and formulates proposed resolutions. The formulation of proposed resolutions can take place in a number of ways:

  • At a face-to-face meeting

  • By email

  • By remote conferencing

Submitters of Change Requests are strongly encouraged to participate in the discussion of proposed resolutions to their own Change Requests and should be prepared to advocate for their position.

The consensus decision-making process must be used when formulating proposed resolutions. This is because the objective is to formulate proposed resolutions that are:

  • Supported by a consensus of members of the Forum/Work Group

  • Not strongly opposed by a sufficient subset of the members to cause the proposed resolution to be revisited

See the Handbook for the Consensus Decision-Making Process (I121); refer to: www.opengroup.org/library/i121.

The Forum/Work Group votes on the proposed resolutions to the Change Requests submitted. Voting is undertaken electronically open to all voting members of the Forum/Work Group. When voting, 75% in favor of a Change Request is decisive. Issues not having 75% are subject to further issue resolution.

The following sections provide information on a Forum/Work Group Review using Change Requests.

See also Guidance for Reviews for additional guidance on reviews. Example: Draft Development Process for a New Standard

An example process for a Forum/Work Group Review for a new standard is shown in The Draft Development Process for a New Standard.

Figure 8. The Draft Development Process for a New Standard

In this example the draft standard is created using a standard template. The “Reach Consensus on Change Requests” process is shown with its sub-processes. Example: Draft Development Process for a Major Revision

An example process for a Forum/Work Group Review for a major revision to an existing standard is shown in The Draft Development Process for Revising a Standard via a Requirements List.

Figure 9. The Draft Development Process for Revising a Standard via a Requirements List

In this example, one of the initial inputs is an agreed Requirements List developed by the Forum/Work Group that documents the requirements for changes to be applied to the existing standard. The proposed draft that is created using this Requirements List must highlight what is changed from the existing standard together with linkage to the associated requirement for change.

Another example Draft Development Process for a major revision to an existing standard is shown in The Draft Development Process for Revising a Standard via Change Requests.

Figure 10. The Draft Development Process for Revising a Standard via Change Requests

In this example new material and corrections to defect reports against the existing standard are being submitted via Change Requests. The creation of the review copy and the review process must adhere to the agreed requirements for the revision documented in the project scope/charter. In general, revisions must explicitly consider all received defect reports and comments on the previous version to ensure openness and quality. Example: Draft Development Process for a Technical Corrigendum

An example process for a Forum/Work Group Review for a minor revision to an existing standard that produces a Technical Corrigendum is shown in The Draft Development Process for a Technical Corrigendum.

Figure 11. The Draft Development Process for a Technical Corrigendum

2.3. Company Review Process

Figure 12. Standards Development Lifecycle: Company Review Process

The Company Review Process is the formal process by which The Open Group measures consensus around a document in order to become a standard.

See Section 3.2.2 of the Standards Process. See also Guidance for Reviews for additional guidance on reviews.

Figure 13. The Company Review Process

Prior to a document entering Company Review, it must be reviewed and approved by the Vice-President responsible for the work area, and the Director of Standards. See Section 3.3.8 of the Standards Process. This includes consideration of proper usage of trademarks, brand positioning, correct application of the document template, suitable content, the avoidance of any negative comments regarding other standards or organizations, and quality concerns.

2.3.1. Narrowing Down Rules

During a recirculation review, the scope of what is open to comment becomes limited – so-called “narrowing down rules” apply, as per Section of the Standards Process:

“Objections are restricted to unresolved issues remaining from the previous review cycle and any changes introduced since the previous review round (or the impact of such changes elsewhere in the document).”

This is to ensure that the draft becomes more stable as the process continues.

2.4. Approvals Process

Figure 14. Standards Development Lifecycle: Approvals Process

Once the final text of a draft standard is complete, it can be submitted for approval. The Open Group Manager is responsible for leading this process in conjunction with The Open Group Legal Counsel.

See Section 3.2.3 of the Standards Process.

Figure 15. The Approvals Process

Approvals occur at the quarterly meetings of The Open Group Governing Board. The Open Group Manager may also request an email approval occur between the quarterly Governing Board meetings.

2.5. Publications Process

Figure 16. Standards Development Lifecycle: Publications Process

For all of The Open Group publication tracks the final stage is for the document to complete an internal review by The Open Group Executive Management.

See Section 3.2.4 of the Standards Process.

Figure 17. The Publications Process

2.6. Maintenance Process

Figure 18. Standards Development Lifecycle: Maintenance Process

Once a standard has been published it moves into the Maintenance Process. This can include collecting defect reports and comments against the standard.

When defect reports are collected, it is recommended that a project be established to review them and make recommendations. The output of such a process could then lead to creation of an errata document or initiation of a project to create a Technical Corrigendum.