W3C Outposts Proposal

W3C Member-Only Document 09 March 2010

Robin Berjon, Robineko
Dan Appelquist, Vodafone


During the November 2009 TPAC meeting, the suggestion that W3C should do more to provide support for standards development at the lighter-weight end of the spectrum was raised. This document proposes a mechanism for doing so.

Status of This Document

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.

Table of Contents

1. W3C Outposts

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.

1.1 A Separate Website

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).

1.2 How To Start an Outpost

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.

1.3 High-Quality Tooling

W3C Outposts would have access to the following excellent tools which we have grown to worship the SysTeam for:

Mailing lists
These would be DB-backed. Signing up for an Outpost list would require accepting terms that cover not only public archival (as is the case for other W3C lists) but also an RF commitment to the group. Essentially, the mailing list membership is the Outpost's membership. The Chairs and Watchers should be granted basic administrative rights. Note that there are potential issues with RF commitments that should be discussed, but it is the authors' opinion that one of the big advantages of an Outpost over other options would precisely be this, and therefore that enforcing such a commitment brings value superior to the hurdles that it creates.
Public archives
The same archival system used for W3C lists.
A public IRC server with bots for logging and other common tasks. This may be made available on a different port from the 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).
Outposts are expected to track action items and issues in the same way as groups. This requires using the list of participants from the same DB as for the mailing list.
Public web space for the group
The group needs to be able to publish a variety of documents about its status. The list of committers may be shorter than that of members, maintained by Chairs and Watchers. A wiki may be used, but if avoidable shouldn't be the only option.
A publication zone
Outposts need to be able to publish their reports (in draft or final forms) in a specially dedicated area that groups them all, akin to /TR/ but not /TR/. Note that we use "Outpost Report" in the same meaning as it has in "Technical Report" in W3C, i.e. an account concerning a specific topic, not a list of what happened over time within the group.
A VCS server
Groups will need to maintain editors' copies of documents, and possibly to toy with implementations (which will be required to be produced under the W3C open source license), and it is possible that they would develop test suites. This requires a VCS server — either built on W3C's CVS architecture or (better) using something more modern such as git. Chairs and Watchers need the ability to add committers. It is possible and even desirable that this and the public space would be the same repository.

1.4 The Outposts Trust

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.

1.5 Watchers

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.

1.6 Process

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.

1.7 Publishing

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.

1.8 Activity Requirements

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.

1.9 Outposts Outreach

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.

1.10 Life After the Outpost

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).

2. Advanced Outposts

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.

A. Acknowledgements

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.

B. References

B.1 Normative references

No normative references.

B.2 Informative references

No informative references.