SUO: RE: SUOP Topic :> Current Draft Of Procedure Text
See comments below.
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
> -----Original Message-----
> From: Jon Awbrey [mailto:email@example.com]
> Sent: 23 November 2003 03:58
> To: SUO; West, Matthew R SITI-ITPSIE
> Subject: Re: SUOP Topic :> Current Draft Of Procedure Text
> SUOPT :> CDOPT. Note 2
> SUOPT :> CDOPT. http://suo.ieee.org/email/thrd2.html#11706
> Referring to "SUO Procedures Document Draft 3" (19 Nov 2003):
> SUOPT :> CDOPT 01. http://suo.ieee.org/email/msg11706.html
> I am going to look for ways to chunk this draft into smaller pieces --
> to "modularize" it if we need a fancier name -- and maybe eventually
> work out a version tracking system for the more independent sections,
> so we don't have to keep reading through the whole text each time we
> make a change.
MW: Well in case you hadn't guessed I am maintaining a master Document
in MS Word, and as I identify improvements I can make from the various
discussions, I amend this document. I am issuing a new draft about once
per week at the moment, with editorial notes to guide where the most
significant changes occur. This gives people a chance to see whether or
not I have been listening to their comments or missed/ignored them.
MW: I am hoping we are 1-2 drafts away from something that is worth
an initial vote on, but we will see.
> I'll first read through the whole text just
> for small stuff and informational questions.
> I haven't had a chance to go through Tom's
> comments or your replies to them as of yet.
> | Standard Upper Ontology Development Guidelines
> | Version 1.0 D3
> | Status: Stage 2: Draft Material
> | Editor: Matthew West
> | 1. Introduction
> | 1.1. Purpose
> | The purpose of this document is to support the purpose
> | of the Standard Upper Ontology Group, as stated in the
> | Project Authorisation Request  by providing principles
> | and lightweight procedures and templates to enable the
> | efficient and effective development of deliverables for
> | the Standard Upper Ontology Group.
> "lightweight" is awk, colloq, or needs further explanation.
> "effective and efficient" is the more logical order, from
> the general theoretical case to the special pragmatic case.
MW: Agree. Changed.
> | 1.2. Target Audience
> I suggest "Intended Audience". You don't want to give your audience
> the impression that you intend to institute hostilities against them,
> especially if you are.
MW: Well I've used Target Audience for 15 years without objection, but
I have no problem with Intended Audience. So changed.
> | The target audience for this document is the participants
> | in the Standard Upper Ontology Group, noting that they can
> | come from a wide range of backgrounds with a wide range of
> | (and lack of) knowledge and experience.
> This is where the "instituting hostilities" part seems to come in.
> Maybe try:
> > The intended audience of this document is the participants of
> > the IEEE Standard Upper Ontology [Working? Study?] Group, who
> > come from a wide range of disciplinary backgrounds, levels of
> > professional experiences, and areas of expertise.
MW: I make it Working Group, otherwise agreed and done.
> | 1.3. Scope
> | (Editorial note: Inserted in this version) This document applies
> | to all deliverables of the Standard Upper Ontology Workgroup that
> | require approval by the Standard Upper Ontology Workgroup.
> SUOW is bad acronym. Suggest we stick with SUO SG or SUO WG.
MW: As above, from the PAR it looks like the correct name is Standard
Upper Ontology Working Group, so SUO WG, but you will notice I have
avoided using acronyms.
> | This includes:
> | - Ontologies developed under the Standard Upper
> | Ontology Workgroup,
> | - This document.
> | This excludes:
> | - Deliverables of other standards bodies,
> | - Discussions on the Standard Upper Ontology e-mail lists.
> | 2. Process
> | 2.1. Stage 1. 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.
> Sounds like an non-contingent rule.
> Need to distinguish SUO and SUO WG.
> Unnecessary passivism.
> > In order to initiate the process of approving an activity for the
> > Standard Upper Ontology Working Group, henceforward SUO WG, the
> > proposers of the activity shall submitt a motion to the SUO WG
> > defining the objectives of a Work Programme and including an
> > outline of the deliverables of the Work Programme.
MW: OK, but I'm not using the acronym in the document. I will follow
by using Work Programme throughout rather than Project.
> | 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.
> "recognized" is now a technical term lacking any operational or
> procedural definition at this point. "formally recognized" has
> the same property, messing up the freedom to use "recognize" and
> "formal" in, er, non-official capacities. perhaps the use of a
> rare word like "sanctioned" plus the inclusion of a definition,
> er, gloss.
MW: how about a quite ordinary word like "authorised" that has a pretty
clear meaning. I'm changing it to that contingently.
> | 2.2. Stage 2. 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 [may] raise formal issues against it.
> excessive passivism again. 'who' may circulate and develop this?
MW: I will reword.
> | It is good practice to develop and maintain a formal issues log,
> | but at this stage it is not required. Formal issues shall be
> | raised using the pro-forma in Annex A, and sent to the SUO list.
> | The formal issue resolution process is defined below in Clause 3.
> agressive passivism again. 'who' shall raise formal issues?
> why do you say "pro-forma". makes it sound perfunctory.
MW: Changed to form.
> | 2.3. Stage 3. 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.
> who is "project"? the abovesaid proposers?
> how do we know if they are satisfied or not?
> would it make any difference to the process
> if they propose a Draft Standard that they
> were not satisfied with, but just didn't
> tell anybody that?
MW: OK, so how about simply "At their descretion the Work Programme Leader
may submit material for approval as a Draft Deliverable."
MW: I will make this change.
> | A formal vote is taken. The following responses are allowed:
> | - Abstain
> | - Yes
> | - Yes with comments
> | - No with comments
> | Comments are made as formal issues raised as described in Section 3.
> | "Yes with comments" does not require the formal 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 issues.
> | "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 of those voting,
> | vote in favour, the document may pass to the next stage.
> I will break here for now.
> Jon Awbrey