How to track issues that block PR but not Last Call (was Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03)

Focusing this reply on ISSUE-53, since discussion of other issues is  
off-topic.

On Aug 22, 2009, at 3:21 AM, Sam Ruby wrote:

>
> Issue 53, the subject of this email, is an example of an issue that  
> Ian identified as only taking a few hours.

Ian said the drafting work, given the options on the table, would take  
about a day. I beliveve the Working Group decision we need to get to  
that point, will take 2-4 weeks, based on past experience.

>
>> To be more specific about my request to the Chairs, we need to  
>> decide at least some of the following questions soon:
>> 1) Should HTML5's update to the text/html and application/xhtml+xml  
>> MIME types be:
>>    A) Inline in the HTML5 spec, as is the custom for other recent  
>> W3C specifications?
>>        OR
>>    B) Posted as an separate IETF RFC, updating the previous RFC for  
>> this purpose?
>> 2) Do we need to decide the answer to #1 by Last Call?
>
> Please forgive the indirect answer, but what we need by Last Call is  
> a draft that enjoys the consensus of the Working Group.  I  
> personally have no opinion on question #1 (or more precisely: I can  
> live with either), and indeed, I view the proper role of a chair to  
> be to not to make such decisions, but rather to assess the consensus  
> of the group.

The Chair's role is not only to assess consensus, but to also guide a  
decision process when consensus is lacking. On ISSUE-53, we have a  
choice of two options. Julian prefers one, Ian prefers the other. It  
is a completely binary choice, there is no middle ground. Both have  
indicated their willingness to abide by a group decision either way.  
Both have also indicated their unwillingness to take further action  
without a group decision.

>
>> 3) If we need to decide the answer to #1 by Last Call, do we need  
>> to start the relevant IETF action to either update or obsolete the  
>> old HTML content-type RFC?
>> I think it is within the Chair's discretion to say that (2) and/or  
>> (3) do not need to happen by Last Call; they are purely procedural/ 
>> process issues, and not technical issues. If the Chairs so rule,  
>> then we can resolve ISSUE-53, or at least put it in a state where  
>> it doesn't block LC but does block PR. If the Chairs feel that (1)  
>> needs needs to be answered and action must be taken before Last  
>> Call, then the Chairs need to assess consensus, or hold a poll to  
>> determine a decision, or determine that the answer to (1) is within  
>> Chairs' discretion and then tell us what the answer is. Since  
>> contacting the IESG, submitting an Internet-Draft, and getting it  
>> on the right standards track are all matters that, based on past  
>> experience, can take weeks or months to accomplish, the time to  
>> make these decisions is now. Delaying these decisions puts our Last  
>> Call target in jeopardy. This is the action I need from the Chairs.
>
> I'm not going to decide this by fiat, but I would be quite willing  
> to do so via lazy consensus.  See below.

All right, I've posted a lazy consensus request on postponing further  
work on this past Last Call. If lazy consensus fails, I will record  
this issue on my status list as pending action by the Chairs. Any  
suggestions on a deadline for objections? I went ahead and sent it  
without a deadline to avoid further delay.

>
> 2) If you (or anybody) for that matter wishes to propose that any  
> specific issue needs not be closed for Last Call, and were to  
> propose a mechanism to track said issue that the Working Group in  
> general were to agree with and the person who raised the issue in  
> particular were comfortable with, then I am entirely OK with closing  
> the issue.  I've seen you propose closing issues and tracking the  
> continuing progress via bug reports before, and believe this to be a  
> good outcome.

I'd like to ask the Chairs and Team Contacts for a their input on how  
to track issues that should not block Last Call, but should block PR.  
The need for such a status has become clear not only with this issue,  
but also with the issue of "about" registration.

Dan Connolly proposed that issues marked as "Pending Review" can be  
treated as blocking PR but not LC. I don't think that works, given our  
current definition of Pending Review, which is that consensus has not  
yet been assessed (which might well indicate the issue blocks Last  
Call).

My proposal, create a new product in the tracker, "HTML5 spec PR".  
Issues that block PR but not Last Call would be moved to this new  
product. Once we enter CR, we would merge back to a single set of  
issues. I would love to hear other suggetions.

Regards,
Maciej

Received on Sunday, 23 August 2009 04:15:03 UTC