process clarifications

[Marc's email went out while I was editing this note - in some places I hope this addresses his questions, but in others it does not. I'll reply to the list to Marc as well.]

Greetings,

Apparently there are points of confusion around our processes. This message tries to clarify our processes and decision procedures. 

For most people on the mailing list this post will be a review -- feel free to skip or skim if you like. There are no new announcements or procedural changes here. We will also go through a summary of what's below in person in DC before we start work, with time for discussion. If you are new to the TPWG, or returning, I hope you will find this helpful. This post is long, but it covers many questions I have heard from new WG members.

--------------
Background
-------------

W3C is an international standards body founded by Tim Berners-Lee in 1994. Hundreds of billions of dollars of commerce runs on W3C standards, which includes HTML. W3C cannot compel anyone to follow a W3C standard. W3C final publications are termed Recommendations. 

W3C employees a small staff. You may have met Thomas, Rigo, Wendy, and Nick already: they are full- or part-time W3C employees. W3C is a member-driven endeavor. The majority of the work is done by people who work for organizations other than W3C. A new Working Group starts when there is sufficient interest among the membership. Microsoft's member submission in February, 2011 [1] formed the basis of the Tracking Protection Working Group, which was chartered [2] in March, 2011. As some of you have pointed out, the charter's time line is very aggressive. This was understood during chartering time, and necessitates more work more quickly from all of us.

The TPWG is not the start of DNT. Other events directly relevant to the TPWG include a submission to the IETF standards body [3] and W3C's workshop on web tracking and user privacy in April, 2011 in Princeton [4]. Working Group chairs are appointed on behalf of the W3C director, Tim Berners-Lee. The actual decision is made by W3C staff. Chairs select (and can dismiss) editors.

As the TPWG completes our deliverables, text is typically drafted in one of two ways. First, as strawman proposals written by editors, which the WG either agrees to, rejects, or modifies. We've seen that with early drafts of all documents in the TPWG. Second, as text proposals from WG members. Generally, people volunteer to write a specific section, and take an action item to do so. In some cases, chairs specifically request text from a WG member, as I did with a large number of issues at the end of 2011.

-------------
Focus on text
-------------
The chairs (and many participants) have found WG discussions are more productive when we have text in hand. It is easier to modify a draft than to start from scratch, yet hard to write a first draft by committee. To this end, Matthias and I have focused much more on bringing discussions to a close by asking for concrete proposals in writing. We had a few occurrences of issues raised but no longer sustained interest, or action items to write text that dragged on for months. To address that, in Brussels we proposed and the group agreed that if there is an issue but no one is willing to take the action to write a text proposal for it, we will close the issue for lack of interest. We also agreed that if there is only one text proposal, after group review with no additional volunteers to author competing proposals, we will adopt the single proposal. Based on subsequent feedback, we clarified this to (a) the chairs may, not must, close an issue for lack of interest, and (b) a WG member later voicing interest in writing a proposal that was closed for lack of interest is an excellent reason to re-open the issue [8]. To be blunt: we are not trying to rush issues to closed out from under the group. We do want a way to avoid issues malingering when they are not a priority for group members to address. We have a lot of work, and a lot of busy people. One thing that has worked reasonably well is to ask if someone else would care to write a draft if the original action item languishes. I hope by now the group has seen in practice that we are not arbitrarily closing issues, while curtailing "I'm still working on it a few months later" as an inadvertent way for busy people to delay the group's progress. There is some judgement in here as well: the more complicated a proposal the more leeway the chairs are likely to give if a date slips, particularly if there is good progress being made.

-------------
Decisions and consensus
-------------

W3C has a lengthy process document [5] that we follow. In particular, here is an excerpt from a longer section on consensus [6]:
		"Consensus: A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set. Unanimity is the particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains)."

That's the formal definition, with additional (interesting) discussion in the following sections. Here is how I have come to understand consensus:
	- Consensus does not require 100% of the group in agreement. If it did, nothing would get done.
	- As a rough guideline, the chairs should move discussion forward if there is a well-specified alternative that has, in our judgement, broad support and little opposition. You may have heard this expressed informally as about 80% of the group can live with a proposal. This is not a hard and fast rule, and does not refer to a formal vote. You will see differences in chairing styles even within the TPWG, and certainly across WGs. But the basic idea is that if there is a clear direction of where the group largely accepts a proposal, we should resolve the issue and move on.
	- Consensus is not a popularity contest. Under the process we discussed in Brussels, we build a set of proposals, call for objections against them, and choose the one that draws the least strong objections, both on substance and strength. Let's say we're selecting a color to paint a bike shed[7] and we have proposals for red, yellow, and blue. A direct democracy would simply tally the number of people who consider each to be their first choice, and pick a winner. What we do is a little different. We pay very close attention to the proposal that draws the least strong objections. If a small majority most favor yellow, but those who do not like yellow absolutely cannot live with it, yet the yellow supporters could live with blue or red if they needed to, than even though yellow is most popular it is not the consensus decision.
		   
Another interesting facet about consensus is that, ideally, we are able to work through issues to reach agreements we can all (or most nearly all) live with. It is partly a journey as well as a decision. This is one of the reasons I stress civility as being so important: we need to work together to try to find common ground. This particularly makes sense given the voluntary nature of Recommendations.

There are several ways to get an informal sense of where WG participants stand on an issue. Ones we've used  to determine a direction for next steps during a given discussion include:
	- Discussions, by email, phone, IRC, and in person; this often fails to reach beyond a handful of people
	- A hum
	- A strawpoll
	- Asking participants on conference calls to +1 or -1 options over IRC

I have heard some confusion between these informal measures and voting. Voting is a formal and rare process in W3C; the TPWG has never held a vote. Voting would require written options, and written responses.

We heard concerns about voting during the first months of the group: results depend on who happens to be in the room at a given time; a vote does not find the path of least objection that our consensus process sets out to identify; issues can become very divisive. With something as voluntary as a Recommendation, that is problematic. These are reasons the W3C staff and chairs do not like holding votes. In addition, a member of the business community raised concerns and requested we not hold votes. With this feedback in mind, the following day we suggested an alternative path to determining consensus, which Matthias presented and the group accepted. Again see the write up [8], which includes Matthias' slides.

Rather than vote, we will gather competing text proposals (as above) and discuss them fully. When the chairs believe we have completed constructive discussion, and refined the proposals as well as possible, we will then poll the WG members for their objections to each proposal. A process with the same basic approach is used by the HTML WG, so if you are curious, you can see examples from their work [9]. To pick a straight-forward example for the sake of looking at the process, here the chairs provided links to a proposal, and a no change proposal, for handling backslashes in a particular case and requested any strong objections to either proposal [10]. The chairs reviewed the objections in detail [11] to find the proposal that has the least strong objection to it. 

Note well: this does not mean the fewest people who object. This is about the strength and substance of the objections raised, not the number of "me too" notes, nor the tone of the objection. In that regard, this process does depend on some judgement from the chairs while weighing where there is consensus for the issue. Also note the inputs to the decision all come from the group. This is not an exercise in "let's talk about things for four months, submit two proposals, and let the chairs choose one." Quite to the contrary. This is a process to surface where the group view is, not where the chairs' view is. The end result could very well be something one or both of the chairs detest, since this is a process to discover the group consensus.

-------------
Final thoughts
-------------

A few final thoughts that came up in Brussels as we discussed this. First, by selecting proposals with the least strong objections raised, we encourage submission of proposals that are most likely to get the most broad ability to live with the proposal in the first place. Contrast to a real estate transaction where one party starts high, another starts low, and they battle to drag the mid point their way. That rewards extreme proposals. Here, in contrast, the best approach is to propose something moderate in the first place. This should help. Second, once we have the best proposals we think we will get, we can establish a known timeline, with a known end date for a decision. We have discussed some issues for months and are seeing limited benefit to continuing to discuss them. Here is one way to close them. 

The chairs have incentive to avoid this process and try to work out a group resolution without needing to poll the group formally for objections. Dissecting each objection and then the chairs needing to discuss and agree on responses to all of them sounds like an excruciating way to spend time. We are not looking to use this process unless the group does not appear to be making progress toward resolution of an issue.

Finally, if you substantively disagree with a decision of the group or the process used to obtain it, you can file a formal objection [12].  Note that chairs can move forward despite a pending formal objection; however, these objections will be reviewed.  Formal objections are subject to a number of requirements, including being public, having a proposed remedy, and a rationale for the objection.

-------------
Feedback
-------------

As with the process to rely more heavily on text proposals, if you have refinements or suggestions to finding consensus via surveying members for their objections, please do share them. We are not looking to spend endless discussions on how to end having endless discussions. That said, we know getting the process right is important, and we are open to ideas and modifications for how to do things better. 

If there is any place in this message where I lost you, please let me know where so I can try to do better in person.

	Aleecia, with Matthias

[1] http://www.w3.org/Submission/web-tracking-protection/
[2] http://www.w3.org/2011/tracking-protection/charter
[3] http://tools.ietf.org/html/draft-mayer-do-not-track-00
[4] http://www.w3.org/2011/track-privacy/
[5] http://www.w3.org/2005/10/Process-20051014/cover.html#toc
[6] http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus
[7] The bike shed example that keeps coming up is originally from
http://bikeshed.com/ which is in no way required reading, but is amusing
[8] http://www.w3.org/2011/tracking-protection/decision-policy.html
[9] http://www.w3.org/html/wg/wiki/Surveys
[10] http://www.w3.org/2002/09/wbs/40318/issue-126-objection-poll/results
[11] http://lists.w3.org/Archives/Public/public-html/2011Mar/0573.html
[12] http://www.w3.org/2005/10/Process-20051014/policies.html#FormalObjection