Re: HTML Working Group Decision Policy - for discussion

Maciej Stachowiak wrote:
> 
> On Oct 9, 2009, at 8:50 AM, Henri Sivonen wrote:
> 
>> On Oct 8, 2009, at 11:24, Maciej Stachowiak wrote:
>>
>>> On Oct 8, 2009, at 12:26 AM, Henri Sivonen wrote:
>>>
>>>> On Oct 7, 2009, at 12:04, Maciej Stachowiak wrote:
>>>>
>>>>> It's very important for Working Group members to read this document 
>>>>> and give questions or comments. Once we settle on a policy, we're 
>>>>> going to follow the procedures outlined and will expect Working 
>>>>> Group members to be the same. So now is a great time to ask about 
>>>>> things that are unclear, or suggest improvements.
>>>>
>>>> It's unclear to me if issues can be revisited once an endpoint of 
>>>> the escalation process has been reached.
>>>>
>>>> If person A escalates and indicates that (s)he'll produce a Change 
>>>> Proposal but fails and the issue becomes deferred, can person B 
>>>> re-escalate the same issue and undefer it? Can person A re-escalate? 
>>>> (I'd expect it to be out of order if person A re-escalates.)
>>>
>>> I think it would be out of order for anyone to re-escalate an issue 
>>> that has timed out (or a nominally separate but effectively identical 
>>> issue).
>>
>> That kind of rule would make the process vulnerable to attack, as 
>> dbaron already observed.
> 
> I'll discuss the appropriate way to resolve this with my co-chairs. 
> Personally, I am more worried about attack by a persistent person or 
> small group keeping an issue open forever (by repeatedly failing to 
> write a Change Proposal and repeatedly re-raising it) than by a person 
> taking an issue off the table by escalating to the tracker in bad faith 
> and falsely claiming they intend to produce a Change Proposal. But we 
> should try to deal with both possibilities.

At some point, every process has to rely on at least some person or 
persons operating in good faith (otherwise, it it turtles all the way down).

The simplest fix here is that reescalating an issue that has timed out 
requires approval by the co-chairs; and if people are unhappy with the 
co-chairs action (either way: allowing something to be reopened that 
should not be, or blocking something that should be reopened), then the 
chairs can be escalated first to the Interaction Domain Leader then 
ultimately to the Director.

In general, we want to avoid establishing the co-chairs as gate keepers, 
but in cases which are unlikely except in cases where somebody is 
operating in bad faith, having the co-chairs act as gate keepers in just 
those limited situations it is a perfectly acceptable solution.

The standard here should be chairs interposing only in cases where a 
person or group is operating in bad faith, and in general we should give 
the benefit of doubt -- this implies that first requests to reescalate 
are often granted, but subsequent ones are less likely to be granted. 
This practice (i.e., this paragraph) doesn't need to be captured in the 
policy.

>>>> This policy doesn't seem to cover how the WG decides to take on new 
>>>> deliverables. Is that intentional?
>>>
>>> Taking on new deliverables in practice boils down to two publication 
>>> decisions: publishing a First Public Working Draft and going to Last 
>>> Call. I assume once we go to Last Call we likely intend to stick with 
>>> it through REC, but FPWD does not carry any implication that we will 
>>> proceed further on the REC track. We did not document the process for 
>>> these kinds of publication decisions; the policy focuses on decisions 
>>> about spec content. Do you think these steps need to be explicitly 
>>> documented somewhere? Our de facto practice seems to be that a lazy 
>>> consensus resolution or poll is sufficient for FPWD, but there is no 
>>> precedent yet for LC.
>>
>> It seems odd to me to document a process even for responding to other 
>> WGs but not to document the process for taking on new FPWDs. After 
>> all, the W3C Process makes completely disposing of a document 
>> impossible once it has reached FPWD, so it seems like a bad idea to 
>> take on FPWDs too lightly.
>>
>> (It seems that outside the W3C people put more weight on WG Notes than 
>> is appropriate considering how WG Notes are published. I noticed 
>> Wikipedia even referring to WG Notes as "W3C Notes". Thus, it's 
>> probably a good idea to avoid a situation where the WG has to 
>> published Notes it doesn't really endorse at all.)
> 
> We should make sure to include clear text in Notes indicating that they 
> have not been endorsed as a standard by the W3C or the Working Group, 
> and have no normative status.
> 
>> Previously a policy of requiring a certain number of independent (as 
>> determined by the chairs) WG participants who've volunteered to work 
>> on a spec was put forward. Is that policy still in effect and have the 
>> chairs identified the required independent volunteers for the 
>> documents that have recently been put forward for FPWD?
> 
> I think the absolute minimum bar to pass for publishing a First Public 
> Working Draft is a lazy consensus resolution (with a week or so for 
> parties to object). If that does not find consensus, then we take a 
> poll. Note: thinking that a poll is required is a valid reason to object 
> to a CfC. Thinking that even a Note would give a false sense of 
> endorsement to something incredibly bad would also be a valid reason. 
> But no one objected at the time.

I think the wording of your first sentence of this paragraph may not 
mean exactly what you meant.  In all cases, a lazy consensus resolution 
is sufficient.  The actual minimum bar, however, is lower.

The ASF has a bit of experience with attempting to find consensus in 
situations where we are dealing with potentially an unbounded group 
(which I happen to believe is the fundamental difference between this 
group and traditional W3C Working Groups).  You can see some of the 
thinking here:

http://www.apache.org/foundation/voting.html

The key part is "Releases may not be vetoed", as to do otherwise enables 
potential denial of service attack.  The theory is that as long as a 
release has quorum and majority, it should be allowed to proceed.  In 
practice, if something has quorum and those that feel strongly enough 
about the issue, then they can force a release by splitting the group 
(in the ASF this involves creating a new PMC, in the W3C, this would 
involve chartering a new WG).

I'll also note in passing that any rule that the W3C has allowing a note 
to be published does not imply that any portion of the FWPD enjoys 
consensus.  The ultimate note that is published could be a "tombstone", 
and simply state that the working group explored "X", and ultimately 
decided it was a bad idea for the following reasons: X1, X2, X3.

> Previously, Sam stated a requirement of at least three independent 
> contributors (where contribution can include such things as direct 
> editing, making an implementation, commenting on the draft, etc), though 
> this has been applied in a rather informal way. It seems to me that 
> HTML+RDFa has met this standard through the number of people who gave 
> concrete technical feedback that resulted in changes to the draft (even 
> if many of those people would not consider themselves supporters).
> 
> I'll ask my fellow co-chairs about whether we'd like to formalize and 
> document this policy.

Whether or not we formalize that rule, I would prefer that we NOT 
publish something as a product of this Working Group that essentially is 
an individual effort.  That's what Member Submissions are for.

> Regards,
> Maciej

- Sam Ruby

Received on Saturday, 10 October 2009 10:00:55 UTC