XGuide The missing guide for
Incubator Groups

Welcome

Congratulations on the creation of your new Incubator Group. This is a guide
for getting started. You will also want to familiarize yourself with The Art of Consensus [requires a W3C Member account], the Guidebook W3C
Working Group Chairs and other Collaborators.

Incubator Group Life

The Incubator Group fosters rapid development. It focuses on new Web-related
concepts and has to finish work on a time scale of a year or less. The group
has to keep in mind that one year is really short for writing a document. It is
not a W3C Recommendation, though it could become the prototype
for future comprehensive W3C work.

Chair Role

Stating the obvious, the role of the chair is to organize the Group life. It
is then a key role for everything. 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.

You 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. You will have to maintain the Group Home page as well, which is a
tool not only for the Group but also for the rest of W3C
Members.

Do not command, but encourage.

Do not impose, but suggest.

Encourage everyone to contribute.

Make sure that all opinions are expressed and recorded.

Make sure that each decision is recorded.

Chair Role references

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!”

Have a first face to face meeting as early as possible, if not the first
thing to do!

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.

Bonus: 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

Get The Things Done inside your XG

You have many tools to support your work. 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

For WBS, the chairs can create polls using:
http://www.w3.org/2002/09/wbs/showwb

Think light

The wish to achieve everything and solve all issues is one of the most
common mistakes. Invite the group to stick to basics for the technology.
Overloading 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)

If one of the three criterias 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 grouper 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 techincal
issues. Do not spend more than 1 hour on writing the content for a feature.
Let's say your group is dealing with an XML markup language, then a template
could be:

Name of the element

List of attributes: give a list of attributes and their values and/or the
reference to their definitions

Purpose: A short explanation of the purpose of the attributes.

Example: Give a markup example of the element use

Test Assertions: Be sure to have well and unambiguous description of the
feature

Test Case: Write the test case (better if you have a template for this
too)

Class of Product: Think about who and what will implement this. Does it
have the same behaviour in an consumer (ex: browser, search engine) and a
producer (ex: authoring tool).

Think Small and Modular

If something seems to be too big to write, to handle, just break it down. Make it
smaller. Think about modules.

Think Short Deadlines

When giving an action item, put 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 Pair

Working by pair helps to achieve quality and put a bit more pressure in
achieving the task. Not necessary two persons to write the same thing, but one
is writing, and another one is reviewing. The reviewing process must not be
more than one day after the completion deadline.

Zen and the Art of Teleconferences at W3C

The group has decided to have teleconferences on weekly basis. You have
already sent an email to the W3C Administrative Staff to book your
weekly teleconference meeting [Member + Chair access] You can verify that
your slot has been put in the teleconference
calendar [Member-only] so you can send a link to the participants of your group.

Create a list of scribes and be sure that the scribe will be available for
the next teleconference. Here there are two choices that you have to decide
with the Group:

rotating list of scribes

2 or 3 persons dedicated to scribing

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 a nice 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.

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-xg@w3.org the agenda for the June F2F in Berlin. Deadline:
2006-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

Issues List: Why, When and How?

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.