Purpose
Incubation is a way of exploring some new aspect of the Open Web Platform when the best way forward is unclear, when feasibility, compatibility, or developer interest is not yet established, or when early development would benefit from a wide variety of informed points of view before Standards-track work commences.
It enables exploration of novel work, without overly diffusing the effort of a Working Group or expending a lot of resources on work that is ultimately abandoned.
One possible result of incubation is the transfer of work to a Working Group, for Standards-track development. Work might also be forwarded to another group in liaison with W3C. Another possible result is the conclusion that this is a promising area of work, but that a number of prerequisites exist which should be solved first. Finally, incubators might conclude that no Standards-track work should be done in the area. This is still a valuable result, as it can reduce the effort expended on unfruitful options.
Venues for incubation
Incubation can be done in several places; the correct choice depends very much on such factors as:
- the specific work area
- the existence of already established communities, at W3C or elsewhere
- the estimated likelihood of success
- developer interest
- desirability of early IP protection
Web Platform Incubator Community Group (WICG)
Established specifically to incubate potential new work for the Open Web Platform, this venue has the merit of a large critical mass of knowledgeable developers. A huge number of proposals pass through WICG. This has the benefit that it is very easy to suggest a new one, and the drawback that a particular proposal may easily be overlooked unless effort is made to socialize the benefits and encourage review and comment.
Mature proposals are made and tracked on the WICG Proposals Repo, while early explorations and less formed ideas should start on Discourse.
A Community Group
Starting a new, topic-specific Community Group is a little more effort than proposing an idea to WICG but can have the advantage of review by a more focused group of people with shared interests or topic-specific knowledge. It is a good option when one or more external communities already exist, but are not necessarily made up of W3C Members.
There is a list of existing CGs. Check whether a suitable one already exists before creating a new one.
An emerging pattern is, when chartering a Working Group, to use a CG to handle incubation for topics related tothe Working Group. Regular joint meetings between WG and the associated CG provide opportunities for progress reports demonstrations, and discussions on moving particular items to the WG. Note: depending on the chartered scope of the WG, adding a new Standards-track work item may require rechartering the WG.
Member Submission
If work has already been explored by one or more W3C Members, a Member Submission can be an effective way to bring the work to wider review. Like other incubation methods, a Submission is not a guarantee that Standards-track work will take place in the area. The likelihood of success is increased if there is already developer interest, and if royalty-free commitments to known patents are made along with the submission.
W3C Workshop
A W3C Workshop can be a good way to bring a new community together and, if consensus is reached on some new area, the workshop report may suggest next steps including creation of a CG, or even passing the work to a new or existing Working Group.
A Working Group
In some cases, incubation can be done directly in a Working Group. For best results, the chartered scope should be broad enough to permit this, the proposed work should be closely related to existing work items, and the chairs should ensure that discussion on incubated work does not interfere with progress on Standards-track items. For example, a separate call or a separate GitHub repo, or use of GitHub issues and labels, can keep the incubation and Standards-track items somewhat separate.
If the community of interest is wider than the existing WG, a tandem CG is probably a better choice.
Getting Review
Early review of a new proposal is crucial to success (whether success means further development, or early identification of unsuitable areas of work which should be dropped).
Create an Explainer
Since the incubated work is by definition novel, it is important to explain what it is, what benefits it would bring, and how it would fit in with the rest of the Open Web Platform. This is the job of an explainer document. A good explainer balances conciseness with detail, has many examples, and ideally links to a prototype of the proposed work.
TAG review
Once some discussion has taken place, and an explainer exists, and the proposed work is agreed to be promising, then before moving the work to a Working Group, it is good practice to request review by the Technical Architecture Group (TAG).
Next Steps
If it is concluded that work should not be further developed, update the explainer to document that fact and list the reasons that development ceased. This will help people in the future who may have the same or similar ideas; perhaps some of the factors (such as developer interest) change in the future.
TODO
- IPR commitments
- deciding to stop work
- liaison with external groups
- when to do early horizontal review
- prototyping, extensibility points
- splitting work into current and future versions