attachment-0001

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 ---------------------------------------------- <table width=100%> <tr valign=top> <td> <td>"Hastings, Tom N" <hastings@cp10.es.xerox.com> 01/30/2003 02:58 PM <td>                To:        Harry Lewis/Boulder/IBM@IBMUS         cc:        pwg@pwg.org         Subject:        RE: PWG> PWG Process</table> 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@us.ibm.com] Sent: Thursday, January 30, 2003 13:12 To: pwg@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 ----------------------------------------------