Survey 2012

From Community Council Community Group

Notes from 2012 CG/BG survey


  • Olivier: My experience with CG and BGs has been mixed. Some groups have been running like WGs, with an experienced chair and a strong focus, and have been fantastic to be part of. Others seem to convene, not know what to do, and die a slow death. I don't think it is a problem with documentation - the documentation is mostly OK. More of a problem of interaction design and flow, IMHO.
  • Idea: Use the "created" email to get people started more clearly.
  • On "Chair":
    • Idea: when someone is selected as a chair, if that person has never received this message before, trigger a message welcoming the person as new chair with useful information. For example what tools are available.
    • Peter Rushforth: The process for choosing a chair was not well described, perhaps intentionally.
    • Annette Greiner: Choosing a chair with the online poll was pretty easy.
    • Adrian Roselli: If there is some way for a chair to indicate whether discussion should happen on the site or the mailing list, then I'd like to see them use it. That kind of message right on the home page might help.
    • Debbie Dahl: [paraphrasing] avoid monopoly of chairing + editing by one company.
    • Vidhya Gholkar: Company A forms group chooses chairs and whene they move/chnage Company A hires replacement.
  • Idea: One month after group creation, system sends email for getting started as follows:
    • If the group has a chair (or more than one), send the chair an email with info about tools, documentation. let the chair know he/she can forward to the group or use as the basis of a more personalized email.
    • Otherwise, send an email to the group letting them know they need a chair and why, and also with info about tools and that the chair(s) can request additional tools.
  • Idea: review welcome blog post for useful information to convey.
  • Paolo Ciccarese: [...]I wonder if all groups are active. Probably recommending an heavy use of mailing list and wiki would be a good idea.
  • Paolo Ciccarese: As a chair it would be nice to have direct contact with W3C staff for discussing specific technical issues.
  • Annette Greiner: It would help me as the chair to have a better understanding of how to engage the rest of the group. I realize that it was a conscious choice to make the process very flexible, but this leaves me wondering how to invent a process.

Getting information


  • not clear where to look or how to filter. would be nice if i could enter tags indicating interest and get suggestions on which groups to join.
  • If I had to navigate the existing list of arcanely titled groups in search of something interesting, I would probably struggle. That's not going to get any better as time passes and groups pile up.
  • Karl: Categorization might also help to find the group among the 100+ ones.
  • Idea: When group first formed, give big clues about available documentation and toolset.
  • Jan-Christoph Borchardt: sort by popularity or participants, or prioritize by other groups which people of the community groups I am already in are also in.

Tracking / Monitoring

  • would be nice if i could "follow" or "monitor" a group w/o joining to see if it is interesting.
  • Olivier: Would be great to feature list activity on the HP somehow.
  • Veronica Cisneros: I was expecting to receive notification of any activity, but I have not received any emails alerting me of new documents or new comments or anything.

W3C endorsement

  • Milan Young: CGs provide a perceived endorsement from the W3C for unmoderated discussions and specifications. While I understand that there may be some use cases for lightweight discussion forums, I do not believe the material resulting from such forums should be accessible to those outside the group.

Good practices & Operations

  • Once a community group is proposed, there should be a kind of blog post where it is explained why the group is proposed, what are the initial plans etc.
  • Charters are useful
    • (Tobie, Olivier)
    • Dave Pawson: put up an outline process, timescales (if applicable) etc, to let users see what is expected.
    • Art: every CG home page should include a clear (as possible) statement about its scope (and if the scope changes, the statement updated accordingly). The scope should include: why the group was created; the intended audience/participants; enumerate the groups doing related work (e.g. other CGs, other WGs, other SSOs, etc.)
    • Wai Seto: It would be good to have well defined "deliverables" for the WGs.
    • Rob Marchand: We believe that the CG process should more clearly define the transition of deliverables to WG status, and that planning for this transition should be part of the requirements for CG chartering.
  • Need clearer decision-making within groups:
    • Mike Amundsen: just got into this and decision-making is still loose. would be nice if we had some clear guidelines (not rules, just guidelines) that we could adopt, modify, etc.
    • Milan Young: The lack of structure around decision making is the downfall of a CG. Allowing charters to give complete authority to the chair is a recipe for a dictatorship. There must be some irrevocable requirement for seeking consensus.
    • Dave Pawson: More formal structure and expectations, hence easier to fit with the group.
    • Peter Rushforth: Is there some recommended way/tool that the w3c encourages decision making?
    • Adrian Roselli: This is less a function of the group and more about its chair. There should be clear output objectives and a scope. From there it's a matter of a chair to make sure discussion stays in scope and moves toward the objective, other he/she should redirect it.
    • Annette Greiner: Maybe offer some advice on getting a group really going.
    • Art: every CG should document how the group makes decision; what if any role does consensus play
    • Jason Grigsby: It really wasn’t clear to us what we were supposed to be doing. And because the work we were doing on images required browser vendor feedback, it felt like a lot of work we were doing was pointless.
  • Idea: Slide decks for targeted needs:
    • Getting started (chair, setup)
    • Getting to success in your group (developing scope, setting expectations in charter format, motivating participants, working effectively, publishing)
    • Progressing to the standards track (transition)
  • Markus Lanthaler: I'm satisfied even though it often takes longer than expected.
  • Adrian Roselli: Community groups seem to allow interaction on the site as well as on a mailing list. I do not think discussions on the site are as effective (personal preference) and that has thrown me. Seeing some declaration from the group up-front about where discussion will happen, along with reminders from group chairs, might increase participation (if only by reducing confusion).


  • How to publicize creation of groups?
    • Idea: In email reply to people about group creation, suggest that they tell people in their various social networks.
  • Groups not making progress in some cases
    • Idea: Check with chair periodically to see how it's going?
    • Art: I am a member of six CGs. Some of them are doing nothing and should be closed.
    • Wai Seto: May be some kind of progress reviews with the C/BG with the members will help.
  • Meta list for CGs interactions [the council CG has mandate to help groups]
    • Art: There should be mail list to discuss topics that cross CGs e.g. how do other CGs do X; what are other CGs doing to track issues, how can we have a voice conference, etc. (If such a list already exists, please let me know its name.)


  • The acceptance process is too much protracted. It discouraged people to get involved.
  • Colin Snover: Community Groups stall out almost immediately because of the horribly cumbersome process for registering, joining, and posting messages to the mailing list.
  • Lars Gunther: Some tasks seem redundant when you're on more than 1 group
  • Adrian Roselli: A plain-language summary for those of us without legal degrees or spare change to afford someone who has a legal degree.
  • Annette Greiner: Requesting and getting an account was very easy. Dealing with the affiliation info was confusing, in part because it wasn't clear that one needed to sign up as a member if affiliated with a member organization. It was also complicated by changes at my home institution.
  • James Barnett: It's much too easy to join a CG without any real IP commitment. (My company is a W3C member, but I didn't need to go through our AC rep to join.)

WG / CG comparison

  • Christophe Gueret: I don't really see the difference. I opened a community group (DLD) because that was the less constraining of the two but it seems to me that at the end you get the same thing. I suggest merging the two types of groups into one.
  • Lars Gunther: WGs tend to be more formal, and indeed should be. Other groups are very varied and their worth will be proven over time.
  • Markus Lanthaler: Well, Working Groups can produce official standards but CGs can not. The disadvantage of WGs is that one usually has to be an employee of a company with W3C membership.
  • Vidhya Gholkar: CG could be a good place to do the ground work to improve or produce new technical specifications. But frankly the linkage between the Core Mob CG and the WG is tenuous.
  • Teotonio Simoes: I think that a WG with a well defined aim has a better change to succeed.
  • Wai Seto: The major differences that I can see are IPR policy between WG and C/BG. It seems that C/BG has less restrictions to start the discussions. That is a positive thing I believe.
  • James Barnett: Community Groups should be abolished as soon as possible. Their existence (and total lack of due process) undermines the whole purpose of a standards organization. I can't think of a better way for the W3C to go out of business than to promote CGs to the detriment of real Working Groups.
  • Rob Marchand: We believe that if a CG wishes to publish their output, they should be allowed to do so only as the input to a full Working Group.


  • Conference call facilities would be useful, but seems outside of the W3C's scope.
  • Melvin Carvalho: Or a WebID login.
  • Style, ergonomics:
    • Dave Pawson: Needs reviewing wrt ergonomics? I found it confusing at times, hard to navigate.
    • Lars Gunther: Better visual design is needed!
    • Wai Seto: The CG wiki seems very different than the homepage and dashboard.
  • Renato (+ Paolo Ciccarese): We need to better control the front page. The centre column should be in our total editorial control, not dominated by the posts.
  • Silvia Pfeiffer: I would have liked to join as an individual, but any joining requires me to use the one registered account.
  • Jan-Christoph Borchardt:
    • The most annoying thing is the limit on username length, which forces me to use a completely different username from anywhere also and hence also leads to log in problems sometimes when I forget how exactly I spelled it.
    • We use a mailing list – a Google Group outside of W3C though. It’s easier to sign up for that and it has a way better web interface to enable more people to participate.
  • Art: Template items for homepage should include:
    • a. Participants' Expectations - every CG should document the roles and expectations of the group's "leaders" (e.g. Chair(s), document Editors, etc.) as well as the participation expectations for CG participants.
    • Work Mode - every CG should document the group's "work mode". For example, the group is mail list only, the group will have f2f meetings, the group will have IRC meetings, etc.
    • Decision Making - every CG should document how the group makes decision; what if any role does consensus play
    • Milestones, Schedule & Plans - every CG should document what it expects to "deliver" and when
    • Are We Done Yet? Requirement - every CG should document its life expectancy plan. Leaving a CG open when it is no longer active is a bit remiss and the CG's "leader(s)" (or the CG's creators if no leaders emerge) should close the CG when it is done or no longer active. (IOW, the group's leader(s) should periodically run the "if this CG closes, will anyone notice?" test.)
  • Jason Grigsby: There is a blog, but you don’t get notifications when someone adds a comment to the blog.
  • Create a media wiki template for specs


  • more promotion of CG deliverables (e.g., to members, newsletter, tweeting publications)


  • Lucinda Lewis: If business processes developed within the community could be tested within the community, the results could be even more powerful.