WICG: Evolving the Web from the ground up

We are super excited to announce the launch of the W3C's Web Platform Incubator Community Group (WICG). Despite the funny name ("the Why-See-Gee, really?"), this is a great new initiative that seeks to make it easier for developers to propose new platform features for standardization.

What we want to achieve

The purpose of the WICG:

• Make it as easy as possible for developers to propose new platform features, in the spirit of the Extensible Web Manifesto.
• Provide a space where developers and implementers can discuss new platform features.
• Incubate those ideas by providing guidance and a supportive and inclusive environment to those who have never contributed to standards (and even to those that have!:D); Ultimately transitioning those ideas to a W3C Working Group for formal standardization (i.e., making a "W3C Recommendation").
• Modernize how we do standardization of platform features (yay! no mailing lists... unless you really want one).
• Provide a legal framework that keeps all contributions free and open.

In short, we want to be a support group for aspiring standardistas. We want to provide you with all the help you would need in order to take your idea or proposal to the next level.

What we are not

We are not planning on being the new powers-that-be. You don't have to convince us that your idea is any good; and even if you do, that might not help you much. What we would give you though is feedback on your ideas formulation, and help you iterate on them to improve the chances of them getting some traction once presented to the appropriate group.

Are browser makers involved?

Yes! Absolutely. Microsoft, Apple, Google, and Mozilla are fully supporting this effort. Inspired by what the RICG achieved, the browser vendors want to make it easier to have a dialog about new features in a space that provides the required legal framework with minimal red-tape. However, we require people to join the community group to participate. Having early buy-in from browser vendors is critical for getting something supported across browsers. Because all the browser vendors are involved in this effort, ideas can be quickly vetted from both a developer and browser vendor's viewpoint. By working together, we can create features that are fit for their purpose and, hopefully, a pleasure to use—all while solving real-world problems!

How we hope to make things easier...

In short: GitHub + tooling + a supportive community. The elves at the W3C have been busy making sure we have the tools in place to make participation as simple as possible. We will develop specs/use case documents like we develop any open source software.

What's the process?

Roughly, we want to follow the process already established by the RICG, though we will adapt as we go. It will go something like:

1. State the problem: Write a description of a limitation with the Web platform and either post it to Discourse, spin up a GitHub repo, or just publish it somewhere (e.g., blog post, gist, whatever you like). This should be something you believe is missing in the platform and would make the lives of developers significantly easier if it were added. It can also be something you've noticed is a recurring development pattern which would benefit from standardization.
2. Join the group: Before bringing the above to the group's attention, join the community group, which means you agree with the terms of the W3C's Community Contributor License Agreement (CLA). It's critical if you first join the group or else key members won't be able to review or discuss your proposal. Don't worry if you forget, the Chairs will remind you and hound you till you do :)
3. Evaluation: As a community, we will evaluate if the problem can't be solved already using Web tech. We will also look at how many users of the Web might be affected. This will require collecting data, real world usage examples, etc.
4. Use cases: If need be, we will formalize the above into a use cases document. Such a document can help prove to the community that there is indeed a need for a solution that needs standardization (see the Use Cases and Requirements for Standardizing Responsive Images, for example).
5. Advocate: We circulate this with browser vendors and the community at large—we pitch it to anyone who will listen. Getting everyone on-board and in our corner is critical.
6. Specify it: Once we have buy-in from browser vendors and the community, we put together some rough proposals (e.g., a new HTML element, API, or HTTP header...) and we do an "intent to migrate": where we move the spec to a W3C Working group to seek royalty free licensing commitments from W3C members (you know, the "free" in "free and open").
7. (Bonus points) Implementation: Help turn the ideas from words on paper into working features in modern browsers.

(If you are interested in the formal process, take a look at the Web Platform Incubator Community Group Charter)

Support

We won't sugar coat it: standardization is hard (just ask anyone who survived the RICG:)). The bar to add new things to the Web is going to remain high: We might need to raise money. Or bring everyone together in a room, like we once did in Paris. Or pitch ideas at conferences to get more developer interest and get momentum behind a feature. However, anyone who chooses to participate will be well supported. We have some extremely experienced browser/standards engineers participating who are here to help. If you don't know where to start, or don't know your RFC2119 from your WebIDL, don't worry. We got your back!

Collaboration with the RICG

So what's the relationship between this group and the RICG ? Since we share members and acronym parts with it, we thought it's worth explaining. The RICG is focused primarily on pushing essential responsive features into standards and browsers, as well as getting more developers involved in the standards process. The WICG will focus mostly on that second bit: incubation of new platform features. We will help you take your idea of something that is missing in the platform and help you grow it until it is ready to be sent off to the appropriate group. This might even include pushing something into the RICG. The RICG will continue to handle all things "responsive", tackling the specific issues that have matured from a gleam in someone's eye into ready-for-prime-time proposals.

What about other Community Groups?

Other Community Groups continue to function as normal. However, the WICG provides a one-stop-shop for features specifically targeted at web browsers. Sometimes, new CGs might be spun off from this one to work on a particular feature.

Got Questions?

You can find the chairs on Twitter:

• Marcos Caceres
• Yoav Weiss
• Chris Wilson