attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD> <BODY> <DIV>Although there are some interesting ideas here, I think several of the  proposed items are highly undesirable. The existing process is clear that working drafts are informal documents. One uses a working draft to develop  a Charter. One uses a Working Draft to develop each stage of a standard. </DIV> <DIV> </DIV> <DIV>I suggest that the process document is, in effect a PWG standard. If there is a perceived need to change that process, and to develop (as it appears) an distinctly different process, it should be done in an orderly way according to the defined process. This includes first establishing need and developing the requirements.</DIV> <DIV> </DIV> <DIV>I think the need for a new process and the requirements for the new process should first be made clear and agreed upon.</DIV> <DIV> </DIV> William A. Wagner (Bill Wagner) Director of Technology Imaging Division NETsilicon, Inc. 781-398-4588 <BLOCKQUOTE> <DIV class=OutlookMessageHeader dir=ltr align=left>-----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Thursday, January 30, 2003 4:44 PM To: pwg@pwg.org Subject: PWG> Process Changes from SM f2f </DIV> Here is what I think was (partially) agreed to in this morning's call 1. In the diagram at the end of the process document:    a. Change the name of the Formal Document "PWG Proposed Standard" to "PWG Working Draft"      1. There was an alternate proposal to change this to "PWG Proposal" given that the diagram already asserts         that informal "working drafts" support the entire process    b. Change the name of the Formal Document "PWG Draft Standard" to "PWG Proposed Standard"      1. Although this would not be necessary with the alternate approach (a1)    c. Indicate, diagrammatically, that there is iteration within each process step, not just linear progression       and last call rejection.    d. Move the Activity "Prototyping" to the right so that it spans the last call. 2. Appropriately reflect these changes and naming conventions in the prose of the process document 3. A versioning scheme was proposed as follows:        v.01 to v.xx  "PWG Working Draft"    Last Call & Formal Approval    v1.0.0 "PWG Proposed Standard"    If minor changes necessary    v1.0.0 Errata document    If significant changes are necessary    v1.1.0 "PWG Working Draft of a Proposed Standard"    v1.1.1 "PWG Working Draft of a Proposed Standard"    ...    v1.1.x "PWG Working Draft of a Proposed Standard"    Last Call & Formal Approval    v1.1.x "PWG Proposed Standard"    If minor changes necessary    v1.1.x Errata document    Last Call & Formal Approval & (Steering Committee?)    v1.1.x "PWG Standard"    This is where a lot of debate was left unresolved, with some thinking a failed last call Proposed Standard    should recycle completely back to PWG Working Draft and others thinking there is no need to last call    a Proposed Standard except in attempt to elevate it to PWG Standard. 4. An observation was made that we need to define how the above versioning (however it resolves) correlates    with the ISTO document numbering on the PWG web site. 5. We need to understand the ISTO policy w.r.t. publishing PWG standards on the ISTO web site and CD.   ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- </BLOCKQUOTE></BODY></HTML>