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.