F2F scheduling and WG time lines

All --

Introduction
====================

With the implementors, we have had some (private) discussions about 
implementation plans.  The timing of a F2F is critically dependent on 
*initial* implementation attempts and test-case writing.  In this message, 
I want to try to pull together all the pieces.  We need to see the 
alternative detailed time lines associated with the various options that 
people have discussed, so I have tried to project some.

Within the WebCGM TC, we had some discussions about November versus 
later.  The majority seem to support November, cautiously (because of the 
dependence on test writers and implementors meeting their due 
dates).  Since that choice (Option 1 below) was not unanimous, I'd like to 
discuss once more in the Thursday WG telecon.

Details follow...

Charter
====================
Here is what the Charter says:
http://www.w3.org/2007/10/webcgm-charter.html#milestones

·       WecCGM WG starts -- Aug 2008
·       Publish FP&LC Working Draft ( and start 4-week Last Call Working 
Draft Review) -- September 2008
·       Collect and write test cases -- November 2008
·       Process LC comments, resolve, negotiate resolution -- December 2008
·       Produce Disposition of Last Call comments -- February 2009
·       Publish CR -- March 2009

[...etc...I have cut the milestones list at March CR...]

Background facts:
====================

1.) *any* technical (substantive) change after LC requires that there be 
another LC.

2.) it is possible, however, at CR stage to declare a feature "at risk", 
and pull it from the spec if there is insufficient implementation support 
(but can't *change* the feature without causing another review).

3a.) for WebCGM 2.0, by the time the WG started we already had several 
(about 5) months of experience with the OASIS CS text and with 
implementations.  We had 23 queued technical changes that the WG approved 
and rolled into the spec before the LC ballot started (about 6 months after 
CS approval)

3b.) this time, we are looking at LC start about 3 months after CS approval 
-- the LC spec is basically the same as the CS spec -- and implementations 
are also behind where 2.0 was.

4.) in the past, the majority of defects in the WebCGM specs, and comments 
for change, have come from the early implementation efforts and from 
writing the test cases.

5.) the functionality of 2.1 is very much smaller than the functionality of 
2.0 (which was all of Ch.4 and Ch.5, plus some).

6.) [Conjecture]  Unless we postpone or extend the (first) LC for a few 
months, there is very likely to be a 2nd LC required.  (And that could 
*still* happen with a postponed LC, if unexpected non-WG comments  lead to 
changes)

Options:
====================

Here are some options that allow us to converge on CR in March, per the 
Charter, via different detailed timelines.

Option 1:  LC now and November F2F
----------

(sep-oct-nov) 1st LC review
(sep-oct-nov) finish test writing
(sep-oct-nov) preliminary implementation of all features
... Nov. f2f -- process output of the above
...... (dec) produce LC response doc & negotiate
...... (dec-jan) WG internal work on WDs, integrate broader impl. feedback
..........(late jan - early feb) 2nd LC (3 weeks)
.............(feb-mar) 2nd LC response (NO TECH CHANGES!)
................(mar-apr) CR --> PR

Option 2:  LC now, F2F in Jan-Feb
----------

(sep-oct-nov) 1st LC review
(sep-oct-nov) finish test writing
(sep-oct-nov) preliminary implementation of all features
...... (dec-jan) broader implementations all features
...... (nov-dec) produce LC response doc by telecon & email; negotiate
...... (nov-dec-jan) WG internal work on WDs, integrate more impl. feedback
..........(late jan- early feb) 2nd LC (3 weeks)
.............(feb-mar) 2nd LC response (NO TECH CHANGES!)
................(mar-apr) CR --> PR

Option 3:  Postpone (1st) LC, F2F later
----------

(sep-oct-nov) finish test writing
(sep-oct-nov) preliminary implementation of all features
...... (dec-jan) broader implementations all features
...... (nov-dec-jan) WG internal work on WDs, integrate more impl. feedback
..........(jan) 1st LC (3 weeks)
.............(early feb)  F2F for 1st LC response, CR 2-pass preparations
.............(feb-mar) possible 2nd LC cycle (NO TECH CHANGES!)
................(mar-apr-may) CR --> PR
(Note.  possibility of 2nd LC cycle introduces an uncertainty in this option.)

Option 4:  Extend the (1st) LC
----------

(This looks a lot like Option 3, except LC is running from Sept into 
January -- I don't see any advantage over Option 3).

Option 5:  F2F in March during CR
----------

(I haven't developed this one.  Reason.  If we need a f2f, I think it will 
be earlier when the substantive issues with the spec flushed out, not later 
when we're trying to achieve 2-pass on each feature.  If you disagree, feel 
free to send a fleshed out time line for this option)


Discussion
==========
Please feel free to add more -- this is my preliminary summary of pros/cons 
that have popped up in prior discussion.

con 1:  slippage of implementors and test writers from their agreed 
schedules could risk F2F productivity.
pro 1:  everyone (almost) could make it in Nov, including non-WG 
implementors and our Invited Expert.
pro 1:  declared plans (and private pledges) indicate sufficient 
implementation attempts for the needed spec-comment generation.
con 1: not uniform implementation effort (vendors across functionality) by 
Nov.;
con 2-4:  early indications hint at some possible scheduling/availability 
issues in Jan/Feb
pro 2-4:  more implementation experience
con 3:  given that the TC is presently leading in the test-writing, and WG 
in spec advancement (like the 2.0 division of responsibility), what would 
WG do from now thru January?
pro 1, 2:  any serious comments/issues from other W3C WGs will be known early.
con 3:  we have already gotten permission and pre-announced Sept. LC, and 
Charter calls for it.
con 1 (pro 2,3): "too aggressive" (quote)
pro 1:  aggressive goal encourages progress.

More?

Assessment
====================
(This is opinion.)

In my opinion, the contenders are Options 1 and 2.  Option 3 is basically, 
"stop the process while test suites and implementations catch up", and I'd 
rather keep the process moving forward.  (In-line I gave my opinions of 
Options 4 & 5, in lieu of expanding their possible time lines.)

Regards,
-Lofton.