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!
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.
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:
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:
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:
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:
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.
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?
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
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 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.
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.
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."
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
- Those who would propose new features or modify old ones are urged to discuss their ideas with experienced HTML implementors before going public. In any case, the following issues should be addressed in any proposal:
- a statement of the problem as you see it
- a proposed solution
- a demonstration that this solution is globally cost-effective without being locally prohibitive (i.e. the sum of all the effort of deploying this solution is less than the cost of dealing with the problem with existing technology, and yet no one party bears too much of the burden. For example, if you require every information provider to do something, it had better be minimal.)
- a discussion of graceful deployment and interoperability issues.
Your want your WG's calls and meetings to be productive. Three ways in which meetings seem unproductive are:
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:
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.
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:
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.
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.
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]
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. Selby. Microsoft 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.