Almost two weeks ago the W3C launched Community Groups (CG) and they're already receiving a decent amount of uptake.

In a recent interview for a .net magazine article I said the following:

W3C's new Community Groups are a huge step forward for W3C. A few key new things are that all it takes is four people to start a W3C Community Group, and they are also free to adopt additional licenses like Creative Commons CC0 and the Open Web Foundation's OWFa 1.0 agreements. W3C has provided a nice simple interface at their website http://w3.org/community. I think W3C Community Groups provide an excellent opportunity for implementing known best practices for open web standards development.

Related disclosures: I've been a contributor to W3C since 1998 (currently active in the CSS and HTML Working Groups and a few incubator groups), I'm on the board of the Open Web Foundation (OWF), as well as a founder/admin of the microformats.org standards community.

Upon reflection since their launch, I'm still as optimistic, and I'm very glad that W3C launched Community Groups as they did. They've clearly listened to a lot of input from a broad variety of other standards communities, and incorporated many suggestions from over the years.

Opportunities

If you're starting a new web standards effort, consider creating/joining a W3C Community Group to do it. I think W3C has set up a good amount of infrastructure that should empower small teams to get up and running quickly. I myself haven't participated in (or created) a CG yet, but I expect I will in the future.

If you're thinking of creating a new CG:

1. Use OWFa and CC0 in addition. Require that your CG also contribute its work with OWFa and CC0. In particular, require that contributors also agree to the OWFa 1.0 CLA, and contribute their work with CC0. I think using both of these will allow maximum portability of open standards ideas, concepts, features, and that's something we should encourage.
2. Establish a culture of working on the wiki first, irc second, and email third. A wiki can be a much more readable (easily consumable) than an email list (which might have endless delta threads you have to read through to figure something out). Wikis also force contributors to better prepare/gather/edit their thoughts as compared to email, where there is the frequent anti-pattern of contributors writing multiple long rambling emails on a single subject. See Wiki is better than email for more.
3. Prefer IRC to email for coordination. Since most of your contributions will be on the wiki, quickly sharing URLs on IRC, and conducting conversations in real time will help facilitate efficient collaboration (much more so than wading through seemingly never-ending email threads).

Keep in mind that W3C Community Groups are quite new and there will be odd bits here and there to work out. CGs are an excellent "1.0" release and everyone who worked on them, W3C staff, etc. deserve our kudos. I'm glad they didin't wait to perfect CGs and instead shipped it when it got to the level it did.

Suggestions

However, now that CGs 1.0 has shipped, here are few suggested improvements I'd like to see W3C consider:

1. Explicitly permit multi-licensing. E.g. it would be great if W3C added an entry to the Community Groups FAQ about using MIT/CC0 licenses like:

   Q: May I create a community group that licenses its work with another license in addition to W3C's licenses?

   A: Yes, as long as community group materials are made available under W3C license, and the citation requirement (that anything from a W3C CG specification must cite the name and date of the spec at a minimum) is kept, your CG may use additional licenses, e.g. CC0 or MIT.

2. Allow additional "sign-up" agreements when creating a CG. This is the counterpart to explicitly allowing multi-licensing, and that is to implement agreements to such licenses in the sign-up process. It would be great if a creator of a Community Group could list additional agreements, non-asserts, licenses that they want the CG to use via a web form, which would then ask others joining the CG to agree to them e.g. OWFa 1.0 CLA and CC0 contributions.

3. Don't require a W3C username and password. W3C should allow logins using various open/federated systems, and then create accounts tied to the identifiers from those systems, where people can check that they agree to the various agreements etc. Provide support for federated identity systems starting with the most used ones and incrementally adding from there:

   1. OpenID - most used federated identity system today
   2. RelMeAuth - tons of people have personal sites that rel=me link to OAuth providers like Twitter, there's an open source PHP library, etc.
   3. BrowserID - up and coming, implemented in a browser plugin.

   W3C should be setting the example here, using these "web-like" identity systems rather than requiring a centralized W3C identity/password to take part in W3C conversations.

Much of the above is from or related to my previous post on open web standards development, but condensed down to a few essentials for W3C Community Groups in particular.

Challenges

While I'm quite hopeful about W3C Community Groups, there is one big area of challenges they, and you (assuming you participate in or create a CG) will face: negative people (sometimes trolls).

For now, just be aware that it is an issue you will have to deal with. Both look out for negative behaviors and do your best to set a positive example. The subject is deserving of its own post.

I have a feeling another challenge will be coordination. What happens when two community groups are created which discuss nearly the same thing? How should community groups coordinate (if at all) with existing working groups in areas of overlap? Is there some way of suggesting that two community groups be merged into one because their efforts seem similar?

I think it's good that W3C is providing the freedom for such groups to exist and communities to form accordingly. I think coordination across or among groups is best done on a case-by-case basis. Thus to some degree this is both a challenge, and a opportunity for community groups to evolve their own processes.

And that's really what I think community groups are about - an opportunity for a more distributed evolution of how different sets of folks approach and develop open web standards. I'm looking forward to seeing what kind of techniques each group uses, and what processes/rules they put in place to make the groups as effective as possible.