Welcome!

Congratulations on the creation of your new Community Group and joing a Community Group. This is a guide for getting started. If you have any suggestions for this guide, please send an email to public-council@w3.org. This is a community-maintained guide, please add information that you think will help other people find their way around Community Groups.

Community Groups: What are they?

The Community Group give developers a light-weight and easy-to-use infrastructure for encouraging innovation and maturing possible future new Web standards. Unlike W3C Working Groups, Community Groups do not require W3C membership and are completely open to any participant who can agree with the intellectual property constraints of the Community Group. Community Groups have a brief description of their interest and no pre-determined time limit. W3C Community Groups can produce reports which, while not being W3C Recommendations, can serve as prototype for future W3C Working Groups. Unlike the more structured W3C Working Group process, W3C Community Groups have no pre-determined process and so communities are free to create their own around their own styles of work. The point is to get innovative work done fast, while providing a clear bridge to protections and benefits of standardization if and when the W3C Community Group feels its work is mature enough.

W3C Forum

This is an open and public forum for hashing out ideas related to new Community Groups or suggestions for the overall process. @@MORE DETAILS

Creating a New Group

Proposing a Group

@@TODO

Group Acceptance

@@TODO

Chairing a Group

In Community Groups, the chair is by default the proposer of the group, although this can change. The role of the chair is to organize the Community Group life, and so it is a key role. In particular, the Chair organizes meetings and may in some groups mediate debates on technical issues in the report.

The chair will have to organize the agenda and the meetings, make sure to have the minutes recorded and delivered in time, to ensure that the work is moving forward. This requires helping elicit the kinds of work needed to be done and making sure its assigned to the correct people. You will have to maintain the Community Group Home page as well, which is a tool not only for the Community Group but also for the rest of W3C Members.

In debates, often the more neutral you are, the more it will be easier for you to get the things done by participants of the Group. When there is a conflict, step back. When there is an issue, clarify each point of the issue to the group participants. Make sure that everyone agrees with the facets of the issue. Then you can start to organize a sane debate. However, also sometimes technical leadership is required.

Here are some useful rules of thumb:

Do not command, but encourage.
Do not impose, but suggest.
Encourage everyone to contribute.
Make sure that all opinions are expressed and recorded.
If decisions are made, make sure that each decision is recorded.

Adding and Changing Chairs

@@Do we have this working yet?

Breaking The Ice

Starting the work in a group is sometimes difficult. People may be shy, people are not sure how they will work and what is appropriate to say or not to say. Then, your role as a chair is to “break the ice!”

Invite each person to introduce him/herself whith the name, the company, what are their interests for the work.
Keep the introductions short, very short.
Ask people what they would like to do in the group in terms of practical work (editing, testing, graphics, reviewing, etc.)
Open discussions, do not close doors
Discuss strategies of development and working methods

Dealing with Disruptive Group Members or Spammers

@@TODO

Making Decisions

The W3C does not give Community Groups a particular structure. Instead, Community Groups are welcome to define their own structure for making decisions. However, groups can follow W3C Process on making decisions by consensus, a method we have found to be very useful for W3C working groups in general.

Running Meetings

Meetings are often the best way to keep a Community Group on track to produce draft specifications and other work. If you host meetings (which are optional for Community Groups), its important to have a scribe. A scribe is someone that takes minutes of the meting. Scribing is a very important task for the group life and for recording everything which has been said during the meeting. It is not only about scribing the meeting but also being sure that every individual action items have been recorded, each opinions have been rightfully transcribed in accordance of his/her author and finally to write an abstract of each discussion. This last part is often forgotten unfortunately. Think that the minutes of the group meetings have to be readable by someone outside of the group and be readable after 2 or 3 months when the context has started to be less obvious.

Prepare the meeting

Send an agenda to the mailing-list at least two (working) days before the meeting date.

Join the IRC channel 5 minutes before the meeting, it will give you time to prepare.
Set the topic of IRC Channel: /topic Meeting FooCG
Invite Zakim to join the IRC channel: /invite zakim
Invite RRSAgent to join the IRC channel: /invite RRSAgent
RRSAgent will create an URI where the log will be kept. Example: http://www.w3.org/2006/05/01-xg-guide-irc
Set the Meeting title: Meeting: FooCG Teleconference - 1 May 2012
Set the Chair name: Chair: Pedro
Give the Agenda URI (mailing-list): Agenda: http://lists.w3.org/Archives/Member/public-foo-xg/2012May/0007
Set Scribe name: Scribe: John
Set Scribe nickname: ScribeNick: johnny

You are ready to start the meeting.

Manage the meeting

First of all, read this W3C IRC guide which goes through all the commands for recording the minutes and share with the potential scribes.

Having a regular meeting on phone is not necessary obvious for many people. At the first face to face, you should make a demo of the way it is working. It will help people to understand how to use it. Invite all participants to login on IRC and to use IRC, specifically to take their turn in discussion. IRC is also an effective tool for participants to clarify what they said if they think the scribe has made a mistake or has forgottent an important point.

Very important! When the scribe is writing an action item, be sure that the action item has

an owner
all information necessary to be understood out of context
a deadline

A bad example of action item would be: Pedro to send the agenda

A good example of action item is: Pedro to send to yoyo-public@w3.org the agenda for the June F2F in Berlin. Deadline: 2012-05-14

Finish the Meeting

As a chair, you should be in charge of closing the meeting, which means generating the minutes, setting the access level, saying bye to the bots and remind the scribe to send the minutes as soon as possible. For example,

Logout zakim bot: zakim, bye
Make the logs visible to members only: rrsagent, make logs member-visible
Ask for drafting the minutes in an HTML file: rrsagent, draft minutes
Logout rrsagent bot: rrsagent, bye

Moving Your Work to a Standard

@@TODO, note the Final CLA and option of W3C Project Review and other standards bodies like IETF

Closing a Group

@@TODO - needs to be figured out

Being Part of a Community Group

Get The Things Done inside the Community Group

You have many tools to support your work, some of which are familiar open-source tools and others of which are more specific to the W3C. You can conduct discussions via email (the XG gets two lists by default), Web (the chair gets access to part of w3.org), the Zakim IRC Teleconference Agent, and meetings (telephone and face-to-face).

Tools

Homepage
Mailing Lists
Chat (IRC)
Wiki (Mediawiki)
Issue tracking (Tracker)

Homepage

W3C uses WordPress, a popular open-source blogging platform, for running Community Group homepages. These homepages show the members of the group, important links to work, and a stream of news available as RSS. In order to keep a consistent look-and-feel across W3C Community Groups, the groups have only a limited ability to customize their homepage.

Customizing the Homepage

@@TODO - can we do this yet?

Mailing Lists

W3C provides the group with by default four mailing lists. The two lists that you will use most are the "public-GROUPNAME" list for public discussion, and the "public-GROUPNAME-contrib" list, where contributions to reports should be copied (via cc). The public list is for wide discussion and review, and may have people on it that have not signed the Community Group Agreement and thus whose rights to intellectual property could prevent the Community Group report from being the basis of a future open standard. The public-groupname-contrib lists helps make sure that group members who contribute have a clear record, as this is necessary to ensure the report is open as regards intellectual property.

While this may seem excessive, it is necessary to have member lists for reasons relating to intellectual property. However, we expect the majority of the work to be done in the public lists, with the "internal" lists only needed if members of the Community Group have problems with intellectual property. As one of the major value propositions of Community Groups (and the W3C as a whole) is to get diverse stake-holders to commit their intellectual property to the greater benefit of the Web, we expect the "contrib" lists to be helpful in that, as many players will not be able due to organizational policy to even reveal intellectual property on public lists.

Chat

Chat can be used for all sorts of purposes, from discussion to bug reports to hosting meetings. Chat is usually done over W3C IRC (although some groups may want to use alternatives such as Jabber or even Skype). We recommend W3C IRC as we have a set of IRC "bots" (or automated assistants) for running meeting. See Zakim, RRSAgent, etc. @@@TODO

Wiki

W3C Community Groups use Mediawiki, which is a standard wiki that most people should be familiar with. For more information about Mediawiki, please use Mediawiki's page @@TODO

Issue Tracking

Tracker is an issue, action and resolution tracking tool for W3C Working Groups, with Web, IRC and email interfaces. The most important design goal was to be as simple as possible in order to let the Working Groups concentrate on what they do best: the creation of long and boring specifications! Tracker has a long list of features. See Tracker's homepage to have them explained in greater detail.

Rules for Success

These are some simple rules for success. While each Community Group may be different, these can help with the nature of the distributed work of Web-based organizations like Community Groups.

Give Deadlines and Clear Responsible Parties

This is often called the "somebody or nobody" rule. If a particular action does not have a person or two attached to it to "bottom-line" the work, it is highly unlikely the work will ever get done. Also, if work does not have a clear deadline, then it will always slip behind and never get done.

Think light

The wish to achieve everything and solve all issues is one of the most common mistakes. In general, stick to basics for the technology and prioritize implementation over other concerns. You learn a lot by trying to actually implement something! Overloading any the specification with features will delay the work. A good way of avoiding the “technobesity” is to keep a simple rule of work. Each member of the group proposing a new feature must give

the prose of the feature
an example of the feature (for example mark-up)
the test case for it (or test cases if more complex)
show how it is implemented

If one of the four criterion is not met, you just do not add the feature to the things to discuss. People want it, people do the work for it.

Think Organized Content

Sometimes, a Community Group member might have difficulties to fully describe a feature and write the prose for it. At the start of the group life, create a template for features with the appropriate question. Then members do not have to think about the writing style and layout but just about the technical issues.

Think Small and Modular

If something seems to be too big to write, to handle, just break it down. Make it smaller. Think in terms of self-contained modules.

Think Short Deadlines

When giving an action item as chair or accepting an action item, always have short deadlines. If it seems not doable in the given time, it means that the action item, the task to do is too big or too complex. Then back to Think Small.

Think in Pairs

Working by pair helps to achieve quality and put a bit more pressure in achieving the task. It's not necessary for two persons to code or wirte the same thing, but one is writing, and another one is reviewing. The reviewing process should be part of the work before after the completion deadline.