PWG> PWG Process

PWG> PWG Process

PWG> PWG Process

Harry Lewis harryl at
Thu Jan 30 17:04:32 EST 2003

Yes... I realized that potential for misinterpreting my statement after I 
mailed it. Of course... a last call can 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>
01/30/2003 02:58 PM
        To:     Harry Lewis/Boulder/IBM at IBMUS
        cc:     pwg at
        Subject:        RE: PWG> PWG Process

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 
You wrote below:
"One of the key elements of the existing process is that there are ONLY 3 
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.
-----Original Message-----
From: Harry Lewis [mailto:harryl at]
Sent: Thursday, January 30, 2003 13:12
To: pwg at
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 

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 

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 reflector 
Harry Lewis 
IBM Printing Systems 
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Pwg mailing list