Thoughts on Chairing the Harmonization WG

This version:
Previous version:
Joseph Reagle <reagle@w3.org>
Dan Connolly, Philipp Hoschka, and Steve Lucas, as well as general discussions on the W3C WG Chairs list.


This document is part of the The Art of Consensus: A Guidebook for W3C Working Group Chairs and other Collaborators. It is the opinion of a single person and has no formal standing.

This document was written in ~1998 though it has been updated and tweaked given subsequent experiences.


Many of the following concepts I developed during the chairing and editing of the P3P Harmonized Vocabulary Working Group (WG). They are based on prior thought, conversations with colleagues, IETF and W3C process, and some things I've read. Some of this may be typical management knowledge, but given I've had no formal "technology management" training and this was my first Chair, I wanted to capture some of what I learned regardless. The W3C is a unique enough place, that things we learn here probably are not well expounded upon elsewhere.

The W3C's work is focussed on specifications and consensus development between sometimes antagonistic parties, in a contentious domain. The chair has few management carrots or sticks available for ensuring the timely completion of the group's tasks. My experiences here reflect the nature of the Harmonization WG: a working group designing a policy centric XML/RDF schema for P3P. Many participants were policy experts and had a less than typical comfort level of using the Internet for online collaboration. The WG also had many participants representing both privacy regulators and marketers: an interesting mix!

I've written this document to share my  own experience in hopes that others will share theirs with me. Also, like my workstyle, this may be of interest to those that are unlucky enough to be stuck in a WG with me!

  1. Document
    1. Do the charters
    2. Use the list
    3. Show the work flow
    4. Represent contention
  2. Set Expectations!
    1. Consider time
    2. Dig into concepts
    3. Constrain your options
    4. Look-ahead
    5. Have fail-safe-solutions
    6. Set mini-milestones
    7. Stabilize the document
    8. Stick to past decisions
  3. Participation
    1. The Times of Teleconferences
    2. Agendas
  4. Facilitating Consensus
    1. Plug and Play Proposals
    2. Purposeful Discussions
    3. Good Questions
    4. Minority Reports
    5. Implementations
  5. Requirements
  6. Closing (or "Shut it Down!")

Document !

A WG's confidence in its chair and editor is dependent on their confidence that they are part of the decision making process and that their concerns are reflected in the document.

Do the Charters

While a  project's or working group's charter may seem like an annoyance, and it seems to rob the chair of flexibility, a well crafted charter can be immensely useful to a working group chair. While we want to be as open and participatory as possible, sometimes the chair must step on feet; having requirements and expectations documented in the charter is your tool to managing the group and retaining scope as you move forward. If scope, goals, and deliverable are documented beforehand, your decisions are less likely to be seen as whimsical, arbitrary or capricious. Note, there is also danger in creating an overly Machiavellian charter which the group will resent, or will permit others to entangle the WG in process. Consequently:

  1. Do the charter.
  2. If you can't document a specific (such as a date) at least document the requirement (this group must have a deliverable by the time another group starts).
  3. Get buy-in from your group on the charter and timetable.

Use the list

The list archive covers your back! While chairing and diplomacy can be well served by a quick email or phone call, I don't think any technical conversation should be directed to a Chair in private. In XML Signature WG, I actually represented this on the home page:

Chair Responsibilities

Any correspondence to either Chair in that capacity should include both email addresses in the distribution. Any technical question, proposal, or discussion must be distributed to the list. An email to a Chair that does not include the list in the distribution may be considered private correspondence and might not be added to the agenda for WG consideration; we need public records of proposals, consideration, and re-consideration as we move forward in achieving a group consensus.

Email to the list help me because if people challenge me:

  1. I've not been having private conversations that might be relevant to patent concerns.
  2. Any change to a document (even typos) can be justified via a reference to the archive.

Show the work flow

I took great pains to be as explicit as possible about the changes that happened in my group. Over 4 months I created 16 drafts and 13 sets of notes. However, the frequent document churn, the occasional missed call and the lack of collaborative Internet savyness meant that a number of concepts were not properly synchronized in the combined knowledge of the working group. An unfortunate result of this is that as the group nears completion, people may balk and say, "when did this change happen?" Or perhaps as the definition or scope of a concept changes other concepts dependent on that first will be orphaned. Consequently, I recommend:

  1. Showing all versions of the document on the group's page. Show which meeting or set of notes was the basis for the changes made in the document.
  2. Show changes from one document to another in a "diff" color.
  3. When significant conceptual changes are made, document this in a history of the spec included in the working document.

Represent Contention

People are most concerned when they feel there views are not being respected or discussed. People can be surprisingly flexible if you agree to reflect the fact that there was contention on an issue but that you must move on. Allow them to help you document the contention, but place limits on the how verbose their description is.

Set Expectations!

Often working groups have to work under extremely tight deadlines while facing contentious topics. I've found that a working group does not mind deadlines in principle, but it is hard to achieve it in reality. Members tend to be of a dual mind. While they want a chair who can bring a work item to a timely close, when it comes to closing the item that they care about, couldn't they have one more week? This is a natural tendency. How do you deal with it?

  1. Consider Time: Be pragmatic in your assessment of how long the process will take. How long will the group take to:
    1. Define what it needs to do. (This often can take a significant amount of time.)
    2. Come up with a robust set of issues that are prioritized in terms of importance, and likelihood of successful resolution in your time frame.
    3. Address those issues. (A metric of your progress is to keep track of how many issues open, close, and the severity of the issues as the group progresses.)
    4. Close, how much buffer time will the group need? (I figure on 20-40% of what it at first seems to take barring substantive issues which can easily extend that.)
  2. Dig into Concepts: If you can give a topic enough time, break apart a concept or issue. At some point, it is often useful to dig deep and tease out all of components of a concept. In my working group, one such concept was recipients: who is the data is released to? We started out with ambiguous terms such as transfer, release, and disclose; but these terms are ambiguous and over-loaded. Eventually, we reached a very robust understanding of the concept broken into three parts, 1) who is the data disclosed to, 2) are they using similar practices as the original site that collected the data (such as "for direct marketing") and 3) on whose behalf is the third party using the data (while a site may give information to UPS for shipping a product, UPS can go off and do something completely different with the information, on their own behalf.) However, this left us with an extremely complex matrix of options, but at least we understood what we were talking about.
  3. Constrain your options: In the Harmonization WG, I was perhaps too liberal in spending time on creating a complete conceptual model. My thought was that we would explore everything, then simplify as we went along, and we did manage to do that, but I wish I had made a constraint upfront akin to: "this schema can have no more than 7 variables, with an average of 3 values (and no more than 5) per variable." Another way to constrain your options is to create requirements that features must be implemented by 1 or 2 prototypes for it to be included in the proposed recommendation (IETF style).
  4. Look-ahead: When I try to set scope and constrain my options, I consider two classes of topic. Immediate, those things the WG has been chartered to do, and must be delivered within the time-frame. Look-ahead, those things that are relevant to the work of the immediate, but are not deliverables. I use the second class of topics to help tease out the concepts, and provide a high assurance that the first set of solutions are extensibly complete. However, you do not want to place them in your critical path. If they are important, they will not necessarily get solved any faster by placing them in the immediate deliverables, and it certainly won't advance the other problems any faster. I sometimes explain this as, "muddying the water won't help you navigate to your goal and faster" and "do one thing, and do it well."
  5. Have Fail-safe-solutions: While you may now properly understand a concept or issue, this is no guarantee that you have an adequately simple and complete solution. In the P3P WG I chaired, a number of concepts were introduced late in the process as members joined. The WG members definitely wanted to discuss these issues, but some were quite contentious and we did not have enough time for them to be discussed to the extant necessary.  Having a simple "fail-safe" solution in the document that people are somewhat comfortable with helps you in the future when your time runs out. This should limit the amount of last minute panic associated with a topic. While the fail-safe solution isn't optimal, it doesn't create any "no-go's." Common fail-safe solutions are to make that feature optional, or to merely include an extensible bucket which can be filled in at a later date.
  6. Set mini-milestones: Issue X must be resolved by a given date, if it isn't, document that it wasn't given enough thought, but that document stands where it is; you fall back to your fail-safe.
  7. Stabilize the document: Define a point at which a part of the document, or the document itself is "stable." Meaning there will be no major conceptual shifts or proposals, but that the remaining time needs to be spend clarifying and communicating the concepts that are already there.
  8. Stick to past decisions: On some topics, the group will continue to return to them time and again. A good rule is to be open to proposals that don't conflict with decisions that have already been made. Proposals that conflict with decisions of the WG must be accompanied by new evidence, i.e. evidence that wasn't considered in the WG decision.


Sometimes a Chair's biggest challenge can be in getting members to participate in a constructive manner. Lots of participation is an indicator of a healthy WG, if the Chair is doing all the work, its management is sub-optimal.  I recommend the following

  1. Encourage proposals, if someone agrees to write up a proposal, document that as an action item with a due date.
  2. Create deadlines for proposals, particularly proposals that will be discussed at a face-to-face. By allowing your working group to participate in and provide buy-in on deadlines (in the timetable, charter, or action item), they will feel more committed to the timetable than if you set the deadlines yourself.
  3. Optionally, publish statistics on posts to the list as an indication of participation. Use this at some point to determine who will be listed as a contributor.

My understanding of the W3C process is that you cannot exclude or limit membership to a working group, however I think this can be problematic. I believe the benefits of limiting membership is some instances can include:

I also believe that many working groups should be public, benefits can include:

However, when your work is complete, it is good to show that your work enjoys support from as many members as possible. Some members may only wish to lurk and make a small comment every once in a while, and this is a perfectly legitimate role.

The Times of Teleconferences

The W3C is a global organization. Consequently you are going to have to be sensitive to the concerns of people calling in from around the world. Furthermore, when a group starts, it can be very difficult to pin down a time that is best for everyone. There is rarely a solution that works for everyone, but I find that if you do your best, and have calls at a consistent time, people can schedule around you, and after a while, that time become a fixed part of calendar in which participants won't schedule conflicts.


An agenda for a call or meeting is essential. It acts as the guide by which you measure whether you are achieving what you need to do to make the call productive. It

At the W3C, people often like to set the agenda by 1) issues not closed from the last meeting and 2) new things raised on the mailing list. The relationship of setting the agenda with the mailing list is important, it encouraging participation throughout the week, rather than ad-hoc and last minute concerns being raised during the meetings. You may even wish to allocate time to the topics, making it clear that if people do want to raise an issue, they will have to raise it on the list first.

Facilitating Consensus

Consensus is a significant enough issue that it bears repeating from the Process Document:

Integral to the W3C process is the notion of consensus. The W3C process requires those who are considering an issue to address all participants' views and objections and strive to resolve them. Consensus is established when substantial agreement has been reached by the participants. Substantial agreement means more than a simple majority, but not necessarily unanimity. In some circumstances, consensus is achieved when the minority no longer wishes to articulate its objections. When disagreement is strong, the opinions of the minority should be recorded alongside those of the majority.

Groups strive to reach consensus in order to provide a single solution acceptable to the market at large. If a group makes a decision that causes the market to fragment -- despite consensus by those participating in the decision -- the decision does not reflect a single market and therefore the group has failed to reach true consensus.

Section "1.3 W3C's consensus policy" W3C Process

I've written further about the meaning of consensus and why I like working with the IETF and W3C in "Why The Internet is Good: Community: Governance That Works Well."

Plug and Play Proposals

I am a big believer in put-up or shut-up. If people are arguing over something in your current working draft without resolution, ask the people to make specific proposals that change the document at hand; this allows an issue to be easily focussed, and limits uninformed rants and kibitzing on previously resolved issues. Consider the following text taken from http://www.w3.org/MarkUp/HTML-WG/:

Proposing New Features

Purposeful Discussions

Your want your WG's calls and meetings to be productive. Three ways in which meetings seem unproductive are:

  1. hesitation: dead air on the telephone, or a chair who can't determine or keep a consistent protocol for allowing people to speak around the table. Let people know what the protocol is (left to right, raised hands on IRC channel) and the group will do the work of self enforcing it.
  2. rambling: on telephones -- without the context of body language or eye contact -- people are often frightfully unaware of how uninterested the group is in what they are saying or of how long they have been talking. Some exhibit this in face-to-face meeting even! As a chair you have to minimize rambling. Even set time-outs, "ok, everybody give me their one minute on this issue." A IRC channel is a useful device for out-of-band issue queuing.
  3. purposeless: sometimes you may have a meeting in which everyone had a good time talking, or they were bored, but in either case, nothing got done. Have a goal in mind for what you want to achieve in the group, and hopefully at the end of the meeting there is a good set of action items.

Good Questions

Way to avoid the above pitfalls is to structure conversations with good questions. Long meetings and teleconferences are particularly prone to going off topic. Structure the conversations with constructive questions. In P3P, there was the issue of whether there was consensus on whether a concept like "access" should be included. I broke this into three questions and did a quick pole:

  1. Is this concept an important one and one people want to spend time on? [poll members around the phone.]
  2. Is this concept defined well, do we offer a good solution? [poll members around the phone.]
  3. Should this be required or optional? [poll members around the phone.]

Very often, without splitting these questions out, the conversation will take a lot of time without arriving at any answer. Sometimes, members may say, "yes, this concept is important and that is why it must be specified as required in this particular way." Use discipline and say, "ok, I take that as a yes, we'll deal with the issue of requirements shortly." I actually formalized this somewhat in a prioritization exercise, asking people to prioritize and choose one proposal over another. Prior to a call or meeting, it is always good to have a sense of what issues you want addressed, what questions need to be asked, and even what answers you'd like to see considered. The WG will often come up with something better than what you thought of, but if you have something in mind, at least you have a set of options and semi-consistent result.

Minority Reports

Sometimes you will not be able to achieve unanimity. However, if you've developed a good culture and clearly document dissention members will often be more than obliging since they trust the process and they are looking forward to the final deliverable as much as anyone else. And keep in mind, as TimBl states, "a minority in a WG might represent a majority in the world at large."

Unfortunately, the greatest and most common danger is moving on without realizing a point of opposition: you've moved on thinking that you addressed all concerns, and someone is still waiting since they haven't heard a proper response: heads will knock later on.

Because of this, when I'm processing issues (and I think the thread is coming to an end), I try to close my emails with, "I hope this answers your question and I'll note this issue closed unless I've misunderstood or you have further concerns."


While no one in my group was writing code, I did want to see how the vocabulary could be used in practice, and see who was willing to step up to the plate and do some real thinking. Consequently, I asked the group to write up their own privacy statements in the language we were developing. This was really quite useful. I had planned to do this, but had forgotten to and hadn't looked at my calendar in a while, fortunately a member had the same idea independent of me. Place implementation milestones and exercises on your timetable so others can remind you! In more technical WGs implementation feedback is absolutely critical.


Requirements capture many of the issues above, requirements:

  1. Document the status of an issue in a group, particularly its importance.
  2. Set expectations about what exactly the group is doing.
  3. Help facilitate a consensus, rather than arguing whether a concept should be addressed at all, turning the conversation to whether the concept should be optional or required gives you some wiggle room for negotiation.

Explain to your group what the requirements are expressed over and give people a sense of what "consensus" means.  Since P3P enables data to be collected in a way that can be abused, requirements in my group were expressed over policy: which concepts must to disclosed in order to request data? Even though I initiated the concept of (required | optional) for diplomatic purposes, I am still uncomfortable with the result and believe that usually requirements should be expressed over characteristics likely to effect interoperability.

Closing (or "Shut it Down!")

The point of this whole document is to enable the WG to deliver upon their commitments on time, and then allow everyone to go on to do new and improved things. Those things might have been discovered during the course of the chartered work, and if you have a successful WG culture hopefully folks will like working with each other. However, I don't believe in scope, feature, or deliverable creap. Just as your current deliverables were served well by a focussed charter and requierments document under which WG members committed, so would any new deliverables.

Appendix: Reading List

How to do it.

Ian Jacobs. World Wide Web Consortium Process Document. W3C. November 1998. [Reference updated to $1.63$]

S. Bradner. RFC2418: IETF Working Group Guidelines and Procedures. IETF BCP 25. September 1998. ftp://ftp.isi.edu/in-notes/rfc2418.txt [Reference updated from RFC1603]

How to do it well

Frederick P. Brooks Jr. The Mythical Man-Month : Essays on Software Engineering. Published by Addison-Wesley Pub Co. July 1, 1995. [A classic in project management.]

Michael A. Cusumano, Richard W. SelbyMicrosoft Secrets : How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People. Published by Free Press. October 1, 1995. [Surprisingly appropriate to the W3C, particularly chapters 4, 5, and 6.]

David Isenberg. RISE OF THE STUPID NETWORK Why the Intelligent Network was once a good idea, but isn't anymore. One telephone company nerd's odd perspective on the changing value proposition. [A bit off topic but interesting along the lines of simplicity in design.]

Russ Mitchell speaking with Eric Schmidt. How to Manage Geeks.

Managing Software Engineers. by Philip Greenspun. [Interesting extension from Brooks though I'm not personally keen on the resulting "80-hours is not enough" conclusion.]

Fisher, Ury, Patton (ed). Getting to Yes : Negotiating Agreement Without Giving In. [A classic in arguing for interests instead of from position and coming to mutually beneficial agreements.]

Eric S. Raymond. The Cathedral and the Bazaar. [More good "simplicity in design" principles.]

"The Consensus Building Handbook A comprehensive guide to reaching agreement" eds. Lawrence Susskind, Sarah McKearnan, Jennifer Thomas-Larmer. The Consensus Building Institute. Sage Publications. 1999.