Thoughts from the P3P Harmonization WG

Joseph Reagle (reagle@w3.org)
16 March 1998

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, W3C process, and some things I've read over the past couple of months. Some of this may be typical management knowledge, but given I've had no "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 RDF schema for P3P. Half of the roster members of the group are invited experts from outside the US, with little technical knowledge and a less than the typical W3C ability for collaborative Internet work.

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 a major pain, and it seems to rob you 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 apiori, 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 having real sticklers who will hold you to points in the charter you'd rather ignore for the moment. 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.

Show the flow of the work

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. (I wonder what the metrics of other groups are?). However, the frequent document churn, the occasional missed call and the lack of collaborative Internet saviness 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.

Representing 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. 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 seems to take, but don't necessarily advertise the buffer to your members.)
  2. 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. 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 P3P, 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.
  5. 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.
  6. 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.

Participation

Sometimes a Chair's biggest challenge can be in getting member 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 the timetable and charter, 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 process is that you cannot exclude or limit membership to a working group, however I think this is problematic. I believe the benefits of limiting membership 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. In the Harmonization WG I actually did close membership before a face-to-face near the end of its work, and elsewhere in P3P a small/quick working group was chartered and in its charter it was limited to people who could meet certain requirements including participation in a previous group. We've since relaxed that requirement (a person agreed to come up to speed with the help of someone else), but it is my opinion that restrictions should be allowed if  they are documented in the charter and they should then be handled very diplomatically and flexibly by the Chair. (I also appreciate the problems this can cause if the chair is not W3C staff.)

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 their calendar in which they won't schedule conflicts.

Agendas

[based on discussion with Steve Lucas, Matchlogic]

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.

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 and the conversation seems to be going no where, ask the people to make specific proposals that change the document at hand; this limits unformed rants and tele-kibitzing.

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) 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 unaware that they've lost the interest of others; this can happen in a face-to-face meeting even. As a chair you have to minimize rambling. Even set time-outs, "ok, everybody give me there one minute on this issue."
  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 the group to arrive at. They will often come up with something better than what you thought of, but if you have something in mind, at least you can steer the group.

Implementations

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.

Requirements

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 if appropriate. (Sometimes ambiguity can be a useful tool too.) 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.

 

Reading List

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.]

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

[article] Russ Mitchell speaking with Eric Schmidt. How to Manage Geeks