Yes... I realized that potential for misinterpreting my statement after I
mailed it. Of course... a last call can FAIL...so there are more than 3
last calls... but only 3 points in the process where last call was
invoked. The point I was trying to make (and what confounded me on the
call) is that while there is iteration WITHIN any process stage... there
are only last calls to TRANSITION from one stage to another. Some were
suggesting a whole subculture of last calling during the iterative process
within a stage. Our current process does not call for this and I feel this
was intentional to try and put more emphasis on collaborating within a
stage to move the ball forward to the transition point as a focused goal.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Hastings, Tom N" <hastings at cp10.es.xerox.com>
01/30/2003 02:58 PM
To: Harry Lewis/Boulder/IBM at IBMUS
cc: pwg at pwg.org
Subject: RE: PWG> PWG Process
Harry,
Don't feel discouraged. I thought that the discussion was very helpful
and showed that we need to try to improve on the written form of our
process. Most of the confusion is what do we call things. We've been
doing a pretty good job at following the steps. But sometimes we have
different ideas of how far along the steps we are and what we call each
step.
You wrote below:
"One of the key elements of the existing process is that there are ONLY 3
LAST CALLS."
I'd like to claify that the current document had 3 *TYPES* OF LAST CALLS
for a standard's track document. There can certainly be more than "3 LAST
CALLS" for a standards track document. Certainly, the feedback loop in
the diagram on page 13 anticipated that some LAST CALL votes would fail
and new versions of the document would have to be produced and another
LAST CALL attempted, etc.
I also think there was a lot of consensus of geting rid of the middle TYPE
of LAST CALL, so that a document would transition from Proposed Standard
to (Final) Standard.
Something that needs to get added to the process flow is the idea that a
Proposed Standard (after Last Call) could be decided later based on actual
product usage in the field to be revised to become another Proposed
Standard with another Last Call, rather than being progressed to (Final)
standad with no changes following a Last Call. Thus a standard could
cycle through a series of Proposed Standards over time as experience with
deployed products occurs. This path is very similar to what happend with
IPP, where we had a V1.0 and a V1.1, both of which were Last Called and
both of which had interopeaability events before their Last Calls.
Tom
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Thursday, January 30, 2003 13:12
To: pwg at pwg.org
Subject: PWG> PWG Process
The SM f2f discussion of PWG Process was quite painful. It is obvious
there are a multitude of varying perspectives on how to conduct the
progression of a standards specification. We opened the process topic
because we realized some conflicting information and need for
clarification in our document. I don't have a problem citing other
organizations in search of "best practice" but I would like us to consider
applying newfound reason to clarify our process, not redefine it!
Our existing process distinguishes the key stages of Chartering,
Proposing, Specifying, Implementing and Maintaining an industry standard.
It recognizes supporting documents for this activity such as White Papers,
Working Drafts and Standards. It also acknowledges activities such as
Brainstorming, Requirements gathering, prototyping, implementing and
testing.
The process, as written, is an attempt to organize these activities and
supporting documents in such a way that streamlines the progression from
concept to final standard... something we hadn't seen in other venues. One
of the key elements of the existing process is that there are ONLY 3 LAST
CALLS. Each last call (if passed) makes a distinct transition to a more
stable level of the standard. This is signified by the STATUS (reflected
in the name) of the standard... not the version. Versioning was not
discussed in the current PWG process (which is a flaw) but was assumed to
be a linear progression on the working drafts that supported the standard
progression.
Several ideas for updating our process were floated in the phone
conference today. I am not opposed to updating the process... if one thing
was proven by today's call it is that there is very little agreement on
how the standard should be interpreted. I do feel compelled to remind that
a great deal of similar discussion went into creation of the current
process. I do wonder how much effort we are likely to expend only to come
up with a process with new naming and versioning that diagrams out to
nearly what we have, today.
I recommend anyone who has a proposal which they were trying to hash out
in the call but who feels like, perhaps, their point did not get
assimilated or would like to expose their concepts to a wider audience, go
ahead and describe your idea here, for discussion on the PWG.org reflector
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/pwg/attachments/20030130/dbd4e559/attachment-0001.html