PWG Mail Archive: RE: PWG> PWG Process update [comment on th

RE: PWG> PWG Process update [comment on the diagram]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Mar 03 2003 - 16:43:28 EST

  • Next message: McDonald, Ira: "RE: PWG> PWG Process update [comment on file naming scheme]"

    Hi Tom,

    As I noted before, the diagram is clipped on the right in the MS Word
    source itself. The PDF faithfully follows that clipping.

    I agree that a portrait diagram is highly desirable.

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, March 03, 2003 12:16 PM
    To: pwg@pwg.org
    Subject: RE: PWG> PWG Process update [comment on the diagram]

    Harry and Dennis,

    Thanks for adding the diagram.

    For some reason the diagram is clipped on the right by PDF. Perhaps, PDF
    doesn't support inserting a landscape page in a portrait document? Since
    the diagram lettering is so large, perhaps you can just reduce it and keep
    it portrait?

    Also the bar across the middle should be changed from "Draft Development" to
    "Working Draft Development", to use the new terminology.

    Thanks,
    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, February 24, 2003 13:26
    To: pwg@pwg.org
    Subject: RE: PWG> PWG Process update

    I liked Rick's "flow chart" listing of the steps as a way to be really
    concrete about each of the steps. He wrote:

    I saw the process as this:

    1) Write the Requirements.
    2) Vote on the Charter.
    3) Write/modify the Specification. Once it seems solid...
    4) Vote on the spec.
    5) If the vote fails, go back to step 3.
    6) If the vote passes, it's now a "Candidate Standard".
    7) Find companies willing to do prototype work.
    8) Create/modify prototypes.
    9) If problems with spec are found, go to step 3 or create/modify an errata
    document and go to step 8.
    10) Do interop testing. If it fails, go back to step 8.
    11) if interop passes, vote.
    12) if the vote fails, go back to step 3 or create/modify an errata document
    and go to step 11.
    13) If vote passes - it's now a "Standard".
    14) Celebrate

    But the consensus seems to be that some prototyping has to come before Last
    Call voting to make a Working Draft into a Candidate Standard. So how about
    revising his flow chart slightly as:

    1) Write the Requirements.
    2) Vote on the Charter.
    3) Write/modify the Specification.
    4) Review the specification at face to face meetings and telecons
    5) If changes, clarification, additions are needed, go back to step 3
    7) When the specification is worth protyping, find companies willing to do
    prototype work.
    8) Create/modify prototypes.
    9) Feedback results from prototyping to the WG
    10) If needed (usually the case), go back to step 3
    11) Vote (WG Last Call) on the spec.
    12) If the vote fails, go back to step 3.
    13) If the vote passes, it's now a "Candidate Standard".
    15) Do interop testing.
    16) If problems with spec are found, go to step 3 or create/modify an errata
    document and go to step 8.
    17) if interop passes, vote.
    17) if the vote (PWG Last Call) fails, go back to step 3.
    18) If vote passes - it's now a "Standard".
    19) Celebrate

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Saturday, February 22, 2003 11:54
    To: 'Rick Seeler'; pwg@pwg.org
    Subject: RE: PWG> PWG Process update

    Hi Rick,

    I understand your concern, but the process really is intended to have
    prototyping (preferably by more than one company although not necessarily,
    in the case of an open source prototype) BEFORE voting to promote to
    Candidate Standard.

    Historically, PWG developed standards (Job MIB and IPP) have always
    been prototyped during the working draft stage by one or more
    vendors and their results have driven the specification stage.

    In the IETF/W3C processes, a later Working Draft is deemed complete
    enough by email concensus on a Working Group's mailing list to be
    prototyped - it has NO official status outside the Working Group.
    In order to actually be moved forward to IETF Proposed Standard
    or W3C Candidate Recommendation, viable prototypes are strongly
    recommended to have been completed and results published.

    The PWG Process 2.0 shortens the IETF process to align with the
    W3C, ISO, and many other standards organizations who have some
    official "Candidate" phase followed by "Standard".

    The need you're articulating is covered in the ISO process
    which has the following steps:

    TN - Technical Note (our PWG Working Draft)
    CD - Committee Draft (passed WG 'last call' but NOT a formal vote)
    DIS - Draft Int'l Std (our PWG Candidate Standard)
    IS - Int'l Std (our PWG Standard)

    Using 'CD' wouldn't be good for PWG (conflicts in meaning with 'CS').

    And really we want prototyping long BEFORE a working group would
    'last call' their SD (Stable Draft) or whatever.

    Cheers,
    - Ira McDonald
      High North Inc

    -----Original Message-----
    From: Rick Seeler [mailto:rseeler@adobe.com]
    Sent: Saturday, February 22, 2003 12:28 PM
    To: pwg@pwg.org
    Subject: RE: PWG> PWG Process update

    One question about the new process:

    How does one know that the specification is at a stable enough state to
    begin developing prototypes? I believe it may be hard to convince any
    company to invest in prototype development when there's no guarantee (or
    voting process) to keep the standard from changing wildly in the interim.
    If that step is "Candidate Standard", then the prototyping should come after
    voting to go to "Candidate Standard" and not before.

    Maybe that was the intent and it's just not stated properly. If the
    statement "A Candidate Standard should not be approved unless it is
    supported by prototypes and thought to be ready for implementation." were
    moved out of section 4.5 and into section 4.6 (and the word "Candidate" were
    removed), I'd withdraw my objection.

    I saw the process as this:

    1) Write the Requirements.
    2) Vote on the Charter.
    3) Write/modify the Specification. Once it seems solid...
    4) Vote on the spec.
    5) If the vote fails, go back to step 3.
    6) If the vote passes, it's now a "Candidate Standard".
    7) Find companies willing to do prototype work.
    8) Create/modify prototypes.
    9) If problems with spec are found, go to step 3 or create/modify an errata
    document and go to step 8.
    10) Do interop testing. If it fails, go back to step 8.
    11) if interop passes, vote.
    12) if the vote fails, go back to step 3 or create/modify an errata document
    and go to step 11.
    13) If vote passes - it's now a "Standard".
    14) Celebrate!

    Does this not seem reasonable?

    (I'm sure there will be no shortage or responses to this question. ;-)

    -Rick
    -----Original Message-----
    From: owner-pwg@pwg.org [mailto:owner-pwg@pwg.org] On Behalf Of Harry Lewis
    Sent: Friday, February 21, 2003 9:42 PM
    To: pwg@pwg.org
    Subject: PWG> PWG Process update

    An update has been posted. Thanks to Dennis for adding some corrections,
    observations and pointing out some issues (yellow). We've also added a
    diagram like we had in the old process. Hope it is helpful.
    ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process20-20030221.doc
    ----------------------------------------------
    Harry Lewis
    IBM Printing Systems
    ----------------------------------------------



    This archive was generated by hypermail 2b29 : Mon Mar 03 2003 - 16:47:20 EST