Re: HTML Working Group Decision Policy - for discussion

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.

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

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.

Regards,
Maciej

Received on Saturday, 10 October 2009 01:28:19 UTC