Re: Charters for review

On Tue, 21 Nov 2006, Chris Lilley wrote:
> 
> Thanks, I have fixed these. Please see
> 
> http://www.w3.org/2006/11/HTML-WG-charter.html

Since this charter says that the HTML WG will attempt to liase with the 
WHAT WG, I thought I'd highlight some issues with the charter that would 
probably need to be addressed before such liasons could be successful.

OPENNESS

Going forward, I see four possible outcomes:

 * The HTML WG replaces the WHAT WG
 * The HTML WG and WHAT WG produce competing specifications
 * The HTML WG and WHAT WG work on orthogonal, non-overlapping documents
 * The HTML WG and the WHAT WG work on the same specification

Since the charter says that the HTML WG will liase with the WHAT WG, I 
presume that this means one of the last two options, and since the 
deliverables section of the proposed HTML WG charter reads almost exactly 
like the table of contents of the existing WHAT WG specification, I assume 
the two working groups are not intended to work on orthogonal documents.

This implies that the HTML WG and the WHAT WG are intended to cooperate 
and produce the same specification. I think this is a fine goal.

For this to happen successfully, the two groups would have to work 
together quite closely. From the point of view of the WHAT WG community, 
this means that the HTML WG would have to work in a very open way. Even 
the appearance of a closed process would likely harm such cooperation.

Thus:

 * Regarding technical matters, there shouldn't be a difference
   between being a working group member as a W3C Member Company, a W3C
   Invited Expert, or participating as a non-W3C Member. This should
   be made explicit in the charter; currently the charter implies that
   non-members are not full members of the working group.

 * There should not be any secret mailing lists, even for
   administrative purposes.

 * The public mailing list should be www-html@w3.org, so as to not
   lend the appearance of attempting to ignore the existing community.

 * There should not be teleconferences or face-to-face meetings, as
   most participants could not afford to attend such meetings. There
   could be the option of annual meetings, open to all participants,
   with some of the less well financed working group members being
   sponsored by the other members to attend, but such meetings would
   have to be informal, with no actual decision-making ability, so as
   to prevent the non-attending members from feeling
   disenfranchised. (The existing community numbers in the hundreds;
   teleconferences and face-to-face meetings are unmanageable at such
   numbers anyway.)


DECISION PROCESS

In any venture of this magnitude, it is guarenteed that everyone will need 
to make compromises. However, it is important that in doing so, the 
quality of the work is not also compromised. To ensure that specifications 
maintain a high level of quality, I would suggest assigning each 
deliverable a single editor, who is responsible for taking into account 
everyone's opinions, and integrating them into one coherent whole. Thus I 
propose that the charter explicitly require a single editor per 
deliverable to be responsible for decisions and finding compromises.

Of course, having a single editor leads to the possibility that he will in 
fact ignore feedback and do his own thing. To avoid this, I propose that 
the charter also have an explicit process for overriding the editor.

This would, IMHO, be a much more agile solution than the current proposed 
process, namely requiring the chair to record a resolution and objections 
for each decision. Given the magnitude of this work, having the working 
group explicit make a decision on every small thing would jeapordise the 
entire effort.

I propose the following text to replace the Decision Policy section:

  The Working Group will assign a chairman. The chairman is
  responsible for deciding when to publish snapshots of the
  deliverables (as described under "Expected Milestones" above), and
  for resolving conflicts, as described in this section.

  The Working Group will assign an editor for each deliverable, who
  has editorial control over that deliverable. Editors must base their
  work on the technical feedback of all the Working Group members.

  W3C Member Companies and W3C Invited Experts may request that a
  decision made by one of the editors be reversed. If this occurs, the
  chairman must post an e-mail to the Working Group's mailing list
  asking the other W3C Member Companies and W3C Invited Experts that
  are members of the Working Group to state their opinions. Each W3C
  Member Company and W3C Invited Experts may vote once, by sending an
  e-mail to the list stating their position. If a majority (more than
  half) of the votes collected in the week following the posting are
  in favour of reversing the editor's decision, the editor must make
  the required change or relinquish the editor position.

  This process is not expected to be used often. If it is used, the
  Working Group's charter should be re-examined by the W3C.

The last two paragraphs would consist of the only difference between being 
a W3C Working Group member and a non-W3C Working Group member. Obviously 
if the entire community disagreed with the W3C members this would be very 
noticable; I believe this transparency would be enough to prevent this 
process from being abused.

As it happens, this process matches the WHAT WG process, which has so far 
been quite successful (in fact, the "overriding" clause has never been 
invoked, and the community has done nothing but get stronger). Having a 
similar process for the two groups would also enable the groups to share 
an editor, thus saving significant time and effort. (I would volunteer to 
have that role if the other working group members were happy with this.)


TIMETABLE

The milestones in the charter are somewhat unrealistic. I would suggest 
the following timetable would be far more likely, based on past experience 
with HTML4 (which is still not fully implemented by any two UAs), DOM, and 
CSS2.1 (which is the only large W3C specification to have attempted a 
serious disambiguation period):

    First Working Draft in October 2007.
    Last Call Working Draft in October 2009.
    Call for contributions for the test suite in 2011.
    Candidate Recommendation in 2012.
    First draft of test suite in 2012.
    Second draft of test suite in 2015.
    Final version of test suite in 2019.
    Reissued Last Call Working Draft in 2020.
    Proposed Recommendation in 2022.


TESTING

I also think it is critical that the volume required of the test suite 
deliverable be quantified. The term "comprehensive test suite" is vague at 
best; the working group is likely to steadily reduce its opinion of what 
is "comprehensive" as the work progresses. It is far better, in my 
opinion, to have a very specific goal in place, for example, "an average 
of 2000 tests per chapter". This gives the working group an unambiguous 
goal. The goal is somewhat arbitrary, and, after discussion, could be 
changed by rechartering, but this would require a clear intent, rather 
than it being a subconscious change over time.


CONCLUSION

This latest charter makes big strides towards being the basis of an 
important cornerstone of the Web in the coming years. I hope you will be 
able to take the above feedback to heart. I look forward to taking part in 
this new working group.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 21 November 2006 21:05:52 UTC