Technical Committee Procedures (STANDING DOCUMENT)

openURC Document 2013-04-30

This version:
Latest version:
Previous version: (mark changes)

Editor: Gottfried Zimmermann
Copyright 2013, OpenURC Alliance


This openURC Standing Document describes the procedures of the Technical Committee (TC).

Status of this Document

This is a public openURC Standing Document. It is a "living document" which will be updated by the BoD as needed.

Comments on this document should be sent to the editor.

Table of Contents

1. Scope

This OpenURC Alliance document specifies the committee procedures for the openURC Technical Committee.

The main job of the Technical Committee is the development of Technical Reports, see [openURC TC Charter].

2. Definitions and Abbreviations

Approved Technical Report
Board of Directors
Draft Technical Report
Rescinded Technical Report
Technical Committee

3. Introduction

This section is informative.

The work of the openURC Technical Committee (TC) revolves around the standardization of URC related technologies. To accomplish this work, the TC follows processes that promote the development of high-quality standards based on the consensus of the membership. This document describes the process the TC follows in pursuit of its mission.

Here is a general overview of how openURC develops and standardizes its technologies.

  1. Members can indicate interest in a particular technical topic. The TC may organize a Workshop to bring people together to discuss topics that interest the openURC community.
  2. The TC carries out the technical development work. It may assign specific areas of this work to Task Forces.
  3. The TC creates Technical Report Drafts that undergo cycles of revision and review (by Members and the public) as they advance in status.
  4. At the end of the process, the openURC Board of Directors reviews a Draft Technical Report (DTR), and if there is support, publishes it as Approved Technical Report (ATR).
  5. The BoD may rescind a Technical Report, then called a Rescinded Technical Report (RTR).

The Process Document promotes the goals of quality and fairness in technical decisions by en-couraging consensus, requiring reviews (by both Members and public) as part of the Technical Report development process.

4. Technical Report Development Process

The Technical Report development process is designed to reach consensus about the content of a Technical Report, to ensure high technical and editorial quality, to promote consistency among specifications, and to earn endorsement by openURC and the broader community. At the same time, the process is flexible and suited to quickly develop Technical Reports in reaction to market demands.

At any time, a Technical Report has one of the following statuses which must be identified:

In addition to a status indication, a Technical Report must contain a version date.

The following informative figure illustrates the stages of a TR:

Fig. 1: Stages of a TR in the development process

Fig 1 (informative only): Stages of a TR in the development process (textual description).

The corresponding steps of the Technical Report development process are:

  1. Creation of a DTR requires approval by the BoD, as a maintenance action of the [openURC TC Charter]. This includes appointment of the editor(s).
  2. Development of a DTR within the TC, interspersed with public reviews (by the openURC members and the public at the same time). A public review period is at least 3 weeks long. It must be announced by the editor(s) of the DTR in consultation with the TC. The TC may publish as many DTRs for public review as it wants, but at least one. If the TC believes that the DTR is ready to be released as ATR it shall conduct a “last call review”. During any review period, the TC shall solicit comments and respond to questions from the openURC Members, other openURC Committees and the public. The TC shall record all comments received, and should address any substantive comment on a DTR in a timely manner.
  3. After a “last call review” and if no substantive changes have been made to the DTR under review, the TC may request a BoD Review. The TC Chair shall submit the DTR and a record of all received comments and pertaining responses to the BoD. The BoD shall deal with the DTR within 30 days upon receipt of the request by a simple majority vote. If approved, the ATR shall be published on the openURC website. The approval may be conditional to minor technical changes or editorial changes. If not approved, the DTR is remanded to the TC which must address the indicated issues and conduct at least one public review before requesting ATR status again. Work may also cease if the BoD instructs the TC to stop the development of a DTR, or if the TC determines that it cannot productively carry the DTR any further.
  4. An ATR may be rescinded by the BoD by a simple majority vote. A rescinded (or deprecated) Technical Report is not endorsed by openURC anymore. An ATR that has been rescinded gets RTR status, and is conspicuously indicated as “rescinded” on the openURC website.


5. Modifications on this Document

Changes to this document require a simple majority of votes in the BoD.

6. Normative References

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

[openURC TC Charter]
openURC Alliance Technical Committee Charter. Latest version available at:

7. Appendix: Change Log

NOTE: This section is informative.

Changes are listed in reverse chronological order.

2013-04-30 BoD meeting:

2013-04-22 Gottfried: