P&P: Procedures document

[jim.s3@juno.com]

Matthew,

        Speaking as a member of SUO P&P, I don't see the need for this
procedure.  IEEE and CS provide plenty of policy and guidance on
standards development and I don't the need to take it down to any finer
grain of detail.  Our starter documents are not progressing because
nobody is submitting any comments, not for lack of a written process.  

        Speaking as SUO-Chair to SUO P&P Chair, Frank has provided a
lengthy list of comments.  Which did you resolve and which  


Frank Farance's Comments:
Matthew-

I am strongly opposed to your procedures document because it re-invents
terminology and parts of the standards process -- and it re-invents them
imprecisely, which is of little good to us.  I believe you are a
participant of ISO TC184, yet I would have expected that your documents
regarding the standards process would have used ISO "standards
terminology" (e.g., ISO/IEC Directives, ISO/IEC Guide 2, etc.) rather
than using the Oxford English Dictionary (<-- good for lay people, poor
for technical definitions).  For example, the terms "conformance",
"defect", "definition", "example", "formal issue", "informative",
"normative", "principle", and "term" are all defined in ISO sources or
have their ISO equivalents (e.g., "formal issue" would be a line-item on
the ISO comment form, which is part of comment resolution, which may be
part of ballot resolution).

Regarding the notion of "principles", standards have a notion of
"provisions" (requirement, recommendation, statement, instruction).  We
should simply use what already exists.  The wording in Clause 4 appears
to be either recommendations or statments -- my guess is that you intend
for "recommendations" since there are no "requirements" in Clause 4.

Regarding Clause 5, the work programme for this working group is clearly
defined: currently, we have 1 PAR (project) outstanding <-- that is our
work programme.  If we want more projects, we need to request them (I
haven't seen any requests for additional projects).

Regarding subclause 5.2 and 5.3, the so-called "deliverable" is what IEEE
calls a "standard", "recommendation", or "guideline" <-- a formal result
of a unit of the work programme (project == unit of work programme).

So I suggest we postpone discussion of your procedures document until you
can tell us how we make progress on the work we a required to do.

Regarding Clause 6, for international and national standards, your
concerns about "an untrue statement, an unclear, ambiguous or misleading
statement, something missing that is necessary" aren't the proper
criteria for issues.  The criteria for issues is: text that causes the
lack of consensus (regardless of reason).  As an example, certain
standards wording is purposely ambiguous (e.g., it permits a range of
implementations) and other kinds of standards wording purposely have
features where "something missing that is necessary" (<- this is known as
"implementation-defined").  So I believe this criteria is incorrect.

Regarding Annex 3, the split between "normative" and "informative" is
inaccurate -- whole clauses and subclauses can be informative.

If your notion of "deliverable" means "project" in the IEEE sense, then
your process has re-invented the IEEE process.  If your notion of
"deliverable" does not mean "project" in the IEEE sense, then it is
unclear how you "devlierable" actually relates to the P1600.01 project
this is established -- i.e., this is all nice discussion, but the purpose
of IEEE Working Groups is to produce standards, not just facilatate
discussion.

As you can see, I believe there are major problems with your document --
and I find the document unnecessary because we already have a document
for the IEEE standards development process.

-FF

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!