Old W3C/WHATWG peace proposal

kadesh.md

A few years ago, the W3C reached out to the WHATWG in order to put an end to the continuous bickering, stop work duplication, end the confusion that developers (and many others) feel due to the split, etc. The proposal was made in private to avoid the acrimonious politics that it would draw and in the hope of eventually surfacing it as a bilateral proposal rather than an olive branch from just one protagonist. (This may have been a mistake.)

The founding principle of the proposal was that in a world of computers and automated publishing, the living standard versus snapshot divide is stupid: you can have both, with one generated from the other. There is no need to convince others that your view is best. There is certainly no need to condescend to Web developers because they may not behave the way you wish they did. You only need to make it clear which is which and what each is for.

This proposal came after the Web Platform Test Project, which was a continuous and extremely friendly collaboration between the W3C and WHATWG, and may therefore have been overly optimistic (especially since it required approval from people not involved in WPT).

Either way, it was rejected by the WHATWG after long discussions. (Note that it was not formally accepted by the W3C either since that would have been a pointless exercise after the rejection).

It was known informally as the “Kadesh Proposal”, named after the Treaty of Kadesh. It also featured a prototype example implementation, but that no longer really works today, notably it no longer has the WHATWG logo, due to a bunch of third-party resources having been moved and other such bitrot.

I leave it below should anyone be interested.

• Both the title and h1 clearly mark snapshot documents as such.
• Snapshot documents make use of meta robots noindex so as to never show up in search engines.
• Snapshots of documents developed in collaboration by the two peer organisations are co-branded: both W3C and WHATWG logos, and if applicable the spec-specific logo.
• The “Usage of this Document” section clearly spells out what snapshots and live documents are for, which one you want to use for different purposes (in a non-judgemental manner), which is the default if you don't know, and a clear link. The proposed text which was derived from a previous discussion is included below.
• Banner: when you scroll anywhere in the snapshot past the "Usage of this Document" section a banner sticks to the top pointing out that it's a snapshot, and linking to the usage description and live document (the test implementation one was ugly as hell, this could of course be made nice).
• Style override. The same style override used to make Rescinded Recommendations look less like standards is applied (it's all pretty drab and black).
• There is a clear link to the live version from the snapshot (actually several).
• In snapshots, the subtitle further indicates the snapshot status.
• In most cases I would anticipate that a snapshot is just a version of the live document at a given moment in time. If however for whatever reason a trimmed-down snapshot is required (eg. because the live version has too far-fetched proposals, very detached from reality as can happen with some editors) and someone other than the live editor(s) made that change, that person is marked as “Publishing Editor”, without any change to the original editors' list.

Usage of this Document

Web standards are available in two flavours: snapshots, which are immutable versions made at a point in time and guaranteed never to change, and live versions which capture as much as possible the latest state of the technology and are intended to be continuously maintained and kept up to date.

Which version you should rely on and reference depends on your needs. If your specific situation demands am unchanging document, understanding that it is likely to contain defects that have been addressed elsewhere, then you will want to use the snapshot. If however you require a document that is as up-to-date as possible, then the live version is for you. If in doubt, we recommend you rely on the live document.

This document is a snapshot document. For the live version, please visit https://yadda yadda some link.

Yeah this failed for the same reason "compromises" with the W3C always fail: it doesn't address the fundamental reasons for the WHATWG to exist. For example, it continues to push for the existence of out-of-date copies of documents that look important and that people will reference.

The only reason for snapshots to exist is legal (patent protection), and so documents that exist for that purpose should be labeled as such. No blog posts about how "HTML 5.2 released!" and such other nonsense. No need for any branding at all (the fact that you even care about the branding on such documents shows that you want people to look at them).

Plus this does nothing to resolve the many, many other problems with the W3C. I've made lists of those over the years. Here's a copy of one of the times I made a proposal:

IDEAS FOR THE W3C

SHORT TERM: A PROPOSAL FOR HOW A WORKING GROUP SHOULD WORK

Here is a description of the work environment that I propose we use to
develop technologies in a W3C context. I present this merely as a
starting point for discussion; I am very open to negotiation. I
haven't included detailed rationales for many of them, since I hope
they are self- evident, but if they are not please do feel free to ask
me about them.

• the group is open to anyone, not just people who are employed by
  members (employees of members are required to go through their
  employer; also I understand there are some complications with
  employees of certain companies like Yahoo!, and this is not meant
  to in any way affect that).

• the WG does not have recurring teleconferences or face-to-face
  meetings. (These are highly unfair to group members who do not have
  an employer backing their participation, as well as being generally
  extremely unproductive ways of making progress.) Individual members
  of the group are naturally welcome to meet as they wish, and are
  encouraged to present the fruits of such focused meetings to the
  group by e-mail.

• tentative decisions are first made by the editor by editing the
  draft in response to feedback, and then fixed in response to
  further feedback; the chair can then override such decisions if the
  editor's decision is clearly wrong in terms of what the
  implementors will implement (see above; the implementor have
  ultimate authority).

• no decisions are made in adhoc teleconference or face-to-face
  meeting -- all technical input must be considered, whether it be
  from someone in Africa who can't afford to travel to their next
  village or from someone like us who can afford to rush to another
  country on a whim. In particular, this means that "well we decided
  at the foobar meeting that..." is never a valid argument.

• editorial (non-normative) issues are left entirely to the editor,
  the WG's time is not wasted dealing with issues such as what colour
  an example should be. (The chair and the editor are encouraged to
  discuss topics like this, of course, and the chair can always assign
  another editor if the editor continually makes poor decisions.)

• arguments are generally to be grounded in reason and data, not
  unfounded assertions or "expert" opinions. (An "expert" is someone
  who can present good rationales and knows the relevant data, not
  someone with strong opinions.)

• the TAG and a11y groups don't get treated as any more privileged
  sources of feedback than any random person on the web. They need to
  provide rationales and data just like everybody else.

• the group is encouraged to seek out feedback from other groups such
  as the TAG and a11y groups, but also from bloggers, community sites
  that discuss the specs like A List Apart, discussion forums like
  reddit, etc.

• stability of the spec is decided by what is interoperably implemented,
  not by a statement of the working group. It doesn't matter if the
  editor thinks that a section of the spec is perfect; if it isn't
  implemented, or doesn't match implementations, it's still not done.

• the implementors with the majority of the likely resulting user
  base must have absolute decision authority, not Tim, not the WG
  chair, not me, not the accessibility community. They vote by writing
  code and shipping it.

• the WG's work product's authoritative version would be the most up
  to date draft (either on dev.w3.org, or somewhere that immediately
  mirrors dev.w3.org, or some other location that the spec editor's
  changes go to). This is what press releases, etc, must point to,
  not the TR page (unless the TR page is the location that is
  continually updated to match the most recent changes, which would
  be fine too, but is presumably even more radical).

• the WG's work product must be licensed under the MIT license (under
  W3C copyright, presumably), or another license that allows
  unrestricted forking, reuse, editing, embedding in works with any
  other license, whether itself free or proprietary, etc.

• static copies of the WG's work product published by the W3C, e.g.
  when a draft snapshot is published to the TR page, must be clearly
  marked as being obsolete snapshots when published. For example,
  either the document could have an always-visible warning, or the
  document's title could be "Patent Policy Snapshot for WebSRT -
  August", or some such.

• the WG's work product must regularly (e.g. every six months or
  every year) go through the entire patent policy cycle (i.e.
  FPWD/LC/REC). This is to avoid coupling the patent policy
  commitments (which are generally desired quickly and which
  certainly need to apply as soon as implementations start appearing)
  to the stability commitments (which are generally tied to proving
  interoperability, something which only happens years after
  implementations are well-established in the market). There should
  not be any interpretation of "REC" in this context as being related
  to stability, however.

• the WG must be able to publish without fighting about pubrules
  every time. For example:

  • if the document has a link to some third-party site (e.g.
    oreilly.com) in some example, that link doesn't get removed
    because of some obscure pubrules.

  • the document's styles don't have to match W3C styles if there is
    a good reason to differ from W3C styles. (Naturally, this
    doesn't apply just to change for change's sake.)

  • the document can use the latest version of HTML or other
    technologies.

• any timetable associated with the work is actually realistic, not a
  hopefully optimistic fantasy designed to make the AC members happy.

• the WG only has a public mailing list.

• the WG only has one chair.

• the WG chair assigns responsibilities like editorship, who runs
  official group blogs, twitter accounts, wikis, etc.

• people of practical importance in the working group (specifically,
  the implementors) have significant impact on the selection of the
  chair; the chair is not just opaquely appointed by W3C staff.

• the WG chair gets the complete authority and technical ability to
  ban anyone from that mailing list when they are disruptive, whether
  that be through being rude, or through process trolling, or through
  drowning the WG in minutiae, or through incompetence, at the WG
  chair's discretion, even if that person is W3C staff, or me, or a
  representative of a member company.

• the W3C staff doesn't try to apply pressure on the chairs to get
  things done quickly, or done in a particular way, etc. Reaching REC
  is not a goal; interoperability is the only goal.

LONG TERM: A PROPOSAL FOR HOW THE W3C SHOULD WORK

At a high level, I think the organisation that develops the Web's
standards could consist of no more than:

• one unpaid CEO, with the following responsibilities:
  hire and fire power over the following two people
  moderator power over the mailing lists mentioned later
• one tech person, with the following responsibilities:
  keep the servers running
  keep the software up to date
• one people person, with the following responsibilities:
  fielding press
  organising the meeting mentioned later
  convincing one or two companies to make donations to
  pay for the tech, the people person, the hardware,
  and the meeting mentioned later
• a small number of mailing lists, namely:
  a list for authors to get authoring help
  a list for css, svg, and other presentation-level tech
  a list for webidl, dom core, and other core-level tech
  a list for html, apis, and other semantic-level tech
• a web site with specs, each with a test suite, each with
  an editor with exclusive editing authority, and each
  licensed such that anyone who wants to try to write a
  competing version of the spec can do so
• a system whereby anyone can volunteer to start writing a
  new spec or a fork of an existing one
• a system whereby anyone can contribute to the test suites
• a face-to-face meeting organised once every two years,
  with part of the meeting being unconference-style with
  rooms no bigger than ten people, and the other part
  being a group activity like a trip to a tech museum,
  skiing, white-water rafting, a trip to the beach...
• a system whereby the specs get snapshotted every year
  so that companies can volunteer to grant their patents,
  much like the W3C CG FSA
• a system whereby whenever a spec goes a year without any
  updates it gets a big warning at the top of the document
  warning that the document is likely obsolete
• a blog, open to everyone
• a wiki, open to everyone

There's a zillion other ways it could be set up, I'm not saying the
above is the only way, or even the best way.

SOME PROBLEMS

Here are some problems I've described in the past:

I think more fundamentally I would just phrase it as "there is too much
bureaucracy". For example, a spec's editor shouldn't have to go through a
multiyear process to explain why the document should be self-hosting (e.g.
why HTML4 should use an HTML4 DOCTYPE or XHTML1 should use an XHTML1
DOCTYPE). That's absurd. And yet it's par for the course -- despite years
of asking to be allowed to do so, the HTML working group has still been
barred by W3C staff from publishing the HTML5 spec using HTML5.

Similarly, the whole TR/REC process is out of touch with reality. In
practice, while it's useful for some government, contractual, and patent
protection purposes to have frozen snapshots that can be unambiguously
referenced, the majority of the Web is best served by directly referencing
the latest updates. As a concrete example, the latest HTML5 editor's draft
is a better reference for implementors and Web authors than the HTML4 REC.
And tomorrow's editor's draft will be a better reference than today's. Yet
the W3C TR/REC process makes the snapshot have higher visibility than the
"editor's draft" -- there's required warnings on drafts that say how
they're useless documents that nobody should look at, the w3.org home page
proudly points to obsolete documents like DOM2 Events and HTML4, etc.

This problem also exists (in an even less justifiable form) between
working drafts and editor's drafts, where the W3C site is organised to
give old obsolete working drafts (which really are no more than arbitrary
snapshots of the editors' drafts) more prominence than the editors'
drafts. This is a very real problem; I regularly see people referencing
old known-buggy drafts of HTML5 when implementing the spec. Even the big
warning we have on the spec now hasn't made sufficient impact.

The big warning reads "This is a work in progress! For the latest updates
from the HTML WG, possibly including important bug fixes, please look at
the editor's draft instead. [...]". This is yet another example of
bureaucracy -- what I wanted it to say is "This document is obsolete",
but, despite being true, W3C staff wouldn't agree to putting that message
up, and instead we had to settle on the ineffective message we have now.

It's funny how when you build bridges there'll be someone to move in under them!

What does that even mean