Re: HTML Working Group Decision Policy - for discussion

Wow, you've got some tough questions.

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). The process described does not currently give any way to re- 
escalate. But if someone actually puts forward a well-formed Change  
Proposal after that period, then perhaps we should have some way to  
still give it consideration. Perhaps only at the discretion of the  
Chairs, to avoid being delayed by last-minute Change Proposals. I  
welcome further input on this point.

> If an issue has been resolved by consensus or vote (0, 5.a. or 6),  
> can a person who was a participant of the WG at the time escalate  
> the same or very similar issue? (I'd expect this to be out of  
> order.) What about a person who wasn't a participant of the WG at  
> the time of the consensus call or vote? (I think this wouldn't be  
> out of order per se but would be disruptive to allow.)

If an issue that's already been decided is re-raised by anyone, the  
prior decision stands, unless new information is provided. That's  
standard per W3C Process. I don't think this is allowed by the policy  
as written (except perhaps by filing a new bug and refusing to accept  
that it is a duplicate; I assume we'd act to stop such activity).

> Does anything above change if new information comes to light? Would  
> an implementor trying to implement and finding flaws count as new  
> information?

Yes and yes. Perhaps we should spell this out. There's no provision  
right now to move a bug out of CLOSED state, but a new bug could be  
filed including the new information.

> I gather that any feature that doesn't have two interoperable  
> implementations will get dropped before REC even if the WG has voted  
> to have the feature. Correct?

That would depend on our CR exit criteria. I'm assuming our exit  
criteria will require two interoperable implementations of every  
feature, and that we would mark features "at risk" if there is a  
substantial chance of this not happening. In that case, the "at risk"  
feature could be dropped. If this happened with a feature not marked  
"at risk", we would have to go back to Working Draft to drop it, or be  
blocked indefinitely from getting to REC. For this reason, I would say  
any feature that doesn't have even a single implementation at Last  
Call time (conforming or not) should be marked as "at risk" in our CR  
exit criteria. All of this is somewhat outside the scope of the policy.

> Is an accepted Change Proposal effectively an invariant section from  
> there on? Or may the editor make editorial changes to the text?

I think textual changes that maintain the spirit and intent of the  
Summary in the Change Proposal should be allowed.

> In any case, it seems to me that Change Proposals should come with a  
> copyright waiver, assignment or license that makes the Change  
> Proposal (if incorporated to a draft) not add restrictions to either  
> how the WHATWG licenses spec or how the W3C licenses specs.

We did not think of that. The W3C Process document does not seem to  
cover copyright assignment or waiver. I am hoping someone from the W3C  
Team can advise on what is appropriate here.

> Can a person who isn't a participant in the WG submit a Change  
> Proposal? If yes, does the person have to accept the PP to be  
> allowed to submit a proposal?

I think we should say "yes" and "yes". The policy should be updated to  
say this explicitly.

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

Regards,
Maciej

Received on Thursday, 8 October 2009 08:25:01 UTC