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 at sharplabs.com]
Sent: Saturday, February 22, 2003 11:54
To: 'Rick Seeler'; pwg at 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 at adobe.com]
Sent: Saturday, February 22, 2003 12:28 PM
To: pwg at 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 at pwg.org [mailto:owner-pwg at pwg.org] On Behalf Of Harry Lewis
Sent: Friday, February 21, 2003 9:42 PM
To: pwg at 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
----------------------------------------------