OMG Specification Process

In OMG Specification Adoption process(http://www.omg.org/gettingstarted/processintro.htm), there are typically two types of actors

1. Voters (http://www.omg.org/gettingstarted/process3-Votes.htm)
2. Submitters

All submitters are voters, but not the other way.

The voters themselves fall in many groups -

1. Technical Committee (Platform and Domain)
2. Architecture Board
3. Task Force
4. Board of Directors

The Specification Adoption process and the adopted specification goes through the following life cycle -

1. Creation
2. Maintenance

OMG standard creation goes through the following phases

1. RFI (Request for Information) Process
2. RFP (Request for Proposal) Process
3. Finalization Process

Request for Information Process
This is an optional step. Typically in this step the Technical committee forms a Task Force and the Task Force issues a "Request for Information" to the industry to collect information. This process involves the following steps -

1. TF creates RFI and votes for acceptance before submitting to its Technical Committee
2. Technical Committee votes the RFI for issuance
3. Technical Committee issues the RFI
4. Submitters can then respond to the RFI. Submitters present their submissions to the TF and may also demonstrate if they have anything worthwhile
5. The TF after their meetings with RFI submitters can then use the information however they want in the forthcoming RFP.

As stated earlier, RFI is an optional step and is not mandatory for an RFP. Since RFP is itself the Requirements specification for the forthcoming specification, RFI may be considered a kind of information gathering.

Request for Proposal Process

RFPs are actually the requirements documentation for the specification in question. The task force formed by the Technical committee is responsible for creation of the RFP. They may take the help of the RFI step to make concrete the requirements, if the requirements are not very clear. RFP, along with he requirements also specifies the time line of action that is to be taken. Typically, it lists the LOI deadline (Letter of Intent) and Submission Date. So, it consists of the following steps

1. TF writes and votes to accept it for forwarding to the Technical Committee
2. The Architecture Board also votes on the created RFP
3. The parent TC of the TF votes to issue the RFP. The RFP by default binds the timeline for Letter of Intent and Initial Submission Date.
4. Companies interested in submissting for the RFP submit their LOI before the deadline.
5. Then, by the Initial Submission Date, they submit their proposals. If they need more time for submission, a revised submission date can be obtained.
6. The submission date typically falls about 3 weeks before an OMG technical meeting. OMG members then read the submissions and if they dont like make comments. In most cases, the submitter needs to get back with a revised submission.
7. When the submission is ready for acceptance, the TF votes to recommend forwarding to the TC.
8. AB then votes.
9. TC then votes to recommend to the BOD.
10. BOD then votes to make the submission "OMG Adopted Specification".

Once the specification gets the BOD nod, though the specification gets a n OMG adopted specification status, it still does not get a release number. This is because, typically the adopted specification has quite a few inconsistencies and bugs that get resolved in later versions. In aknowledgement of this fact, OMG differentiates between Adopted Specification and Available Specification. An Available Specification is typically formed by a Finalization Task Force after the Adopted Specification is released. The following happen from the Adoption stages to making the specification available -

1. On successful creation of an Adopted Specification, the TC forms a Finalization Task Force (FTF) which makes changes to the Adopted Specification based on the issues encountered and reported and creates a first revision of the Adopted Specification.
2. The issues when encountered get reported as "Specification Issues" to OMG, on which the FTF acts.
3. This revision goes through the same voting process as the Adopted Specification and the result is the Available Specification. This available specification may be further edited to produce the Formal Specification.

Specification Maintenance
Once a formal document is created, immediately the TC creates Revision Task Force RTF to cater to any changes or bug fixes needed and also defines two timelines - Comment Deadline and Report Deadline. The Revision task force collects and acts on the Specification Issues submitted and through the voting process as described earlier makes revisions to the specification and releases them. On release, another RTF is automatically created. Following are the steps that are followed in this process

1. On successful Formal document creation, the TC forms a RTF and along with this specifies the Comment deadline and Report deadline.
2. Users and members can then report issues against the formal document as Specification Issues which get logged in a database. Typically, the issues can be categorized as either errors, ambiguities or enhancement requests.
3. RTF acts on the errors and ambiguities recieved before the Comment deadline to work on to produce a document revision. RTF resolves and gets data regarding the issues using emails.
4. In anycase, the RTF needs to have all the issues voted before the Report Deadline. The report deadline indicates the "transactionable" time for the RTF and is considered not contactable after this time. RTF also need to vote the revised to be forwarded to the TC before the report timeline.
5. The revised document (also called report document) is then forwarded to AB and then TC and then BOD to voting.
6. Once BOD approves the document, the changes are incorporated into the original version and new version is created. After this version is created the RTF process continue

Types of Documents
The following types of documents are published. The type really depends on the state of the process at which it was created -

1. Final Adopted Specification - This is the formal adopted specification. The FTF task force is not yet created. These documents are prefixed with "subgroup/". For example subgroup/06-01-09.pdf
2. Proposed Available Specification - This is the FTF report which has been recommended to the TC for approval. The voting process is underway. These documents are prefixed with "dtc/ or ptc/". For example ptc/06-01-09.pdf
3. Available Specification - This is the adopted version of the FTF report.
4. Version 1.0 - The formal document after editorial changes on the FTF report. These documents are prefixed with "formal/". For example formal/06-01-09.pdf
5. Proposed Available Revision - RTF report completed; voting underway. These documents are prefixed with "dtc/ or ptc/". For example ptc/06-01-09.pdf
6. Available Revision - Adopted RTF revision
7. Version x.y - formal revision publication.

zz The