W3C Outposts Proposal
W3C Member-Only Document 09 March 2010
- Editors:
- Robin Berjon, Robineko
- Dan Appelquist, Vodafone
Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document is merely a W3C-internal member-confidential document. It has no official standing of any kind and does not represent consensus of the W3C Membership.
The goal of the W3C Outposts proposal is to provide a lightweight framework for the development of experimental or vertical specifications in the web domain that can bring together a community of members and non-members alike without the overhead of creating a new working group, or even an incubator group. The primary objective is to create stronger links between W3C and the large, innovative web community that produces new technology. Some Outpost products may enter Recommendation Track, but it is quite possible that in some instances simply producing the Outpost Report or associated documents and closing down would be considered sufficient.
No payment would be required from participants. If an Outpost produces a specification that is brought on to W3C for standardisation, solutions will have to be found, either through new membership or through the invited expert mechanism, to establish continuity with the membership of the outpost. It is also possible that this could tie into a scheme for individual membership if such a scheme should be developed.
The name "outposts" is intended to convey the idea of something lighter-weight and somewhat in advance of the mainstream.
Conflict between the deliverables of an Outpost and that of a W3C WG should be flagged but should not be considered a major issue — it is quite possible that the exploration of alternative routes would provide invaluable feedback to existing W3C efforts. Furthermore, Outposts should have licence to reuse parts of and even fork existing W3C specifications, provided that this is clearly indicated. The spirit is that they should be unimpeded in tinkering with web technology, and this right would additionally bring value to the creation of an Outpost over doing the same work elsewhere.
In order to clearly distinguish between W3C's official standards and the reports produced by Outposts, the latter would need their own website with its own branding. Nothing fancy is required — just different. Whether to use an entirely different domain, or a subdomain like outpost.w3.org is a matter for discussion.
The Outposts website should not make use of dated space. It needs to be straightforward and human-friendly.
The Outposts website could carry advertising as a way to help pay for itself (and to provide an experimental ground for potentially doing the same on non-TR W3C pages).
In order to create an Outpost, one must first write a charter detailing its goals and deliverables. The charter need not be complex, or as detailed as some working group charters are, but it needs to state a clear goal and its rough position within the web ecosystem. The requirements should be similar to those presiding over the creation of Task Forces.
The charter must also list who the Outpost Chair (or Chairs) is, and must refer to at least one Watcher.
Ideally the maximum turn-around on the creation of an Outpost should be one week. Outpost reviews would be performed by the Outposts Trust. Inside of a week if three members of the Trust second the Outpost creation and no objections are made it is created (the Trust should have the liberty of evolving these rules over time).
Outposts have no expiry date, but they do have Activity Requirements, and participants in the ad hoc review group as well as Watchers and Outpost Chairs can call for an Outpost's charter to be reviewed.
W3C Outposts would have access to the following excellent tools which we have grown to worship the SysTeam for:
6665 one that is used for regular
W3C groups. It needs to be possible to administer the bots without intervention from
the team (at the very least they need to respond to /invite and have
usable defaults, for instance they should publish documents with world-privileges).
The Outposts Trust is a member-only W3C group that in most ways functions like a regular WG, except that it has no deliverables. Its task is to manage the life-cycle of Outposts. The Trust:
The goal is that the Team's involvement in the Trust can be minimal so as to save costs. Much of the day to day activities should be shouldered by a group of member representatives and trusted invited experts. Outpost Chairs and Watchers should be ex officio members of the Trust.
In terms of resources, the Trust should require only mailing lists and a space in which to publish information. On rare occasions phone conferences may be held, but the expectation is that these would be exceptionally rare.
Every Outpost must have at least one Watcher. Watchers are either Team members or members of the community at large whose understanding of the W3C process and tools has been recognised by the Team. Essentially they act as a manner of informal Team Contact for the Outpost, facilitating discussion, making sure that all is in order, helping out with the tools.
If a Watcher steps down from following a group (or is obviously not tracking it closely enough) then the Trust must either find a replacement promptly, or disband the Outpost.
The Outpost process is essentially a simplified variant of the one that applies to existing groups, with all references to Team intervention replaced with interventions from the Watcher, and a publication process based on Notes.
Outpost Reports should follow a set of common guidelines, but in the interest of celerity they should not have to bear the full weight of PubRules. I would suggest that something straightforward that provides a simple upgrade path to PubRules compliance should be used, perhaps based on ReSpec. Only Watchers need be granted rights to put content there — arguably this could be the sole area for which intervention by the actual Team may be preferable.
Outposts can publish draft reports as often as they wish, on a variety of topics that meet their charters. At times, they may wish to declare a report final, and freeze its development with the assumption that any further work will be produced as a clearly identified different version, with a different short-name, or will move on to W3C.
Outposts are required to maintain a minimal amount of activity, which is largely left to be appraised by the Trust. Every six months a Trust member is expected to review existing Outposts: if there has been little or no activity in the past six months an Outpost is marked as dormant (which is notified to its participants and shown in the list of Outposts); and if a dormant Outpost does not revive itself within another six months, it is closed down.
A closed Outpost sees its content and list frozen, and cannot be restarted. If one wishes to revive an Outpost, one has to start a new one to take over that content, and produce convincing justification as to why it will work this time around.
Outposts may release news about their activities, and can be represented at public events. A selection of such news and events should be relayed by W3C (when it makes sense) in its general news section and in its list of talks.
Naturally Outposts must never claim that their position is representative of the W3C in any way.
Once an Outpost reaches consensus on the fact that it has addressed its deliverables (or in some cases, if it still has deliverables but one or more are found to be ripe for standardisation) it has the option of making its Outpost Report(s) available to W3C through an Outpost Submission.
W3C may then decide to escalate the Submission to a Recommendation Track document, which will require chartering a proper group. If it does, and the Outpost considers itself to be done, then the Outpost is closed down (or put into maintenance mode, if applicable).
This section is an additional proposal, and should be considered simply as a potential outgrowth of the general Outpost idea.
In order to quell (and benefit from) the industry's tendency to form vertical fora willy-nilly, we could envision a form of "Advanced Outpost" that would be similar to normal Outposts except that they would be membership-based, and their work would be largely conducted in private.
They would benefit from the same tooling, with the addition of access to Zakim, and perhaps N% FTE of a Team member instead of a Watcher. The fee would be much lower than that for Membership, and W3C Members would get a strong discount (but would nevertheless have to pay to join, though not to peruse the content).
The expected outcome would be similar: that the final report be submitted and fed into the regular W3C process — at which point participants would have to join. The goal is largely to compete with vertical industry fora that do pretty much exactly that, and through that to get some of the money that flows in that direction.
Many thanks to Tim Berners-Lee, Ralph Swick, Ann Bassetti, Daniel Glazman, and Marcos Càceres for their constructive input.
Special thanks to Mohamed Zergaoui (Innovimax) who was instrumental in bringing this discussion up.
No normative references.
No informative references.