SUO: Starter Procedures Document
Dear Colleagues,
Jon requested a plain text version of my starter document for the
procedures project. So here it is.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
Standard Upper Ontology Development Guidelines
Version 1.0 D1
Editor: Matthew West
1. Introduction
The purpose of these guidelines is to set out the process and deliverables for Work
Programme within the Standard Upper Ontology Group.
2. Process
2.1. Stage 0 - Activity Approval
A proposal shall be submitted as a motion to the Standard Upper Ontology Group (SUO)
defining the objectives of a Work Programme and include an outline of the deliverables of the
Work Programme. The motion shall also include the nomination of a Project Manager for the
Work Programme.
The motion may include reference to initial material, or deliverable material for any later
stages of the process.
The motion may include the nomination of additional roles within the work programme, e.g.
deliverable editor.
If the motion is passed the Work Programme becomes a recognised part of the Standard
Upper Ontology activity.
2.2. Stage 1 - Draft Material Development
Draft Material may be developed towards or in support of the project deliverables. This may
be circulated for comment at the discretion of the Project Manager. No formal vote on this
Draft Material is taken, but interested parties can raise issues against it. It is good practice to
develop and maintain a formal issues log, but at this stage it is not required.
Issues shall be raised using the pro-forma in Annex A, and sent to the SUO list. The issue
resolution process is defined below in Clause 3.
2.3. Stage 2 - Draft Standard Proposal
When the project is satisfied that they have the material in a form that constitutes a
technically complete Standard, they may propose it as a Draft Standard. A formal vote is
taken. The following responses are allowed:
- Abstain
- Yes
- Yes with comments
- No with comments
"Yes with comments" does not require the issues raised to be resolved before the document is
accepted as a Standard. This might be appropriate when there are editorial issues, or perhaps
minor technical ones. "No with comments" means that the document is not considered fit for
purpose as a standard, i.e. there are major technical issues that need to be resolved. It does not
mean that the voter does not support the intent of the standard. That is decided when the work
Programme is approved.
Following the result of the vote, if the majority vote in favour, the document may pass to the
next stage.
2.4. Stage 3 - Standard Proposal
The project should attempt to resolve any issues raised as a result of the Draft Standard ballot
and then when the Project Leader is satisfied that as many issues as possible have been
resolved, then the document can be submitted for vote as a Standard.
The voting is as for a Draft Standard. The standard is passed if a majority vote for it, but in
the event that there are any "no with comments" votes, the Project Leader should consider
resolving the issues and resubmitting the document for a further vote.
2.5. Stage 4 - Revision
A Standard may have issues raised against it. A log of these issues shall be maintained by the
SUO Chair. A Project to resolve one or more issues against a Standard may be proposed.
3. Issue Resolution Process
Any voting member of the Standard Upper Ontology Group may raise an issue against a
document. An issue has an importance level that is one of the following values:
Editorial A defect that does not affect the technical performance of the
document and do not affect its understandability. Examples include
spelling, grammar, or layout.
Minor Technical A defect that is technical in nature, but is easy to fix. Examples
include errors in construction of formal language statements.
Major Technical A defect where the scale and impact of the defect may require
significant thought and work. Examples include axioms stated in
such a way that they do not have the intended effect, and missing
material.
The project shall maintain an issue log for all issues raised against the document that has
reached Draft Standard level or beyond. The issue log shall be publicly available.
An issue is resolved when the project and the issue raiser agree that it is.
The status of an issue has one of the following values:
Raised The issue has been raised, but the project has not yet responded to the
issue.
Accepted The issue has been accepted as valid by the project, but no resolution
has been identified and agreed with the issue raiser.
Rejected The issue has not been accepted by the Project. A reason must be
given.
Withdrawn The issue has been withdrawn by the issue raiser.
Resolved The resolution to the issue has been agreed in principle by the issue
raiser and the project. The resolution is documented in the issue log,
but has not yet been reflected in the document.
Completed The resolution of the issue is reflected in the document to which it
refers.
An issue is considered outstanding unless it is either completed or withdrawn.
Annex 1 Issue Pro Forma
Issue Raiser:
Date Raised:
Status:
Issue level:
Title:
Clause:
Issue:
Proposed Resolution (optional):
Discussion:
Agreed Resolution (project and issue raiser):
Completion Date: