Re: HTML5-warnings - request to publish as next heartbeat WD

On Aug 10, 2009, at 9:29 PM, Manu Sporny wrote:

> Maciej Stachowiak wrote:
>>> Here is a subset of my standards:
>>> For a section to be determined controversial:
>>>
>>> - It must have been discussed at length (for at least 2 months)  
>>> without
>>> an agreeable solution being integrated into the specification.
>>
>> I'd agree this can be defined as a "controversial" issue.
>
> Good.

Glad we agree on something!


> The issue becomes controversial by willfully violating another  
> standard.
> If we are carefully writing the HTML5 standard so that it provides
> browser interoperability and some other working group willfully  
> violates
> parts of the HTML5 standard, I would expect that we would take issue
> with that. To do otherwise would seem contradictory.
>
> However, perhaps the proper approach is to ask those groups if they
> would like to raise an issue with HTML WG or change their  
> specification
> to match HTML5.

I believe that is the proper approach to such conflicts. I would add  
that it doesn't have to be the group raising the issue - an HTML WG  
member who is concerned about the conflict could raise it.

> Minor concern: What happens if the WG that created the spec doesn't
> exist in an official capacity anymore?

Then we need to do one of the following:

(a) Work towards a renewed effort that would create a successor spec.
(b) Live with the conflict (many are, frankly, not harmful in  
practice), or, equivalently, consider ourselves to be writing a  
successor spec.
(c) Match what the old unmaintained spec says.

> What I don't want us to do is sit by and let the language blind-side  
> the
> other working group or not allow anyone to raise the issue. I believe
> that we should be rigorous in seeking feedback and gaining consensus
> (both inside and outside the HTML5 community).

I totally agree with you on this. But I think HTML WG members are  
doing just fine at raising these issues. I don't think we have to go  
out of our way to label conflicts as "controversial" if no one has  
spoken up about the issue. If no one at all speaks up, that would mean  
the conflict is not, in fact, controversial.

>> As a representative of a UA manufacturer, I would not want my  
>> objections
>> to implementing something to result in this kind of issue marker
>> automatically. Perhaps if the editor refuses to take that feedback  
>> into
>> account after some time, then there might be a controversy. But in  
>> fact,
>> "we can't/won't implement this" type feedback is common and seems  
>> to be
>> resolved in a satisfactory way. Nor have I seen any other UA  
>> vendors ask
>> for these kinds of markers for their issues. Thus, I don't think  
>> issues
>> like this that fail to meet condition 1 should be specially marked.
>
> Fair enough, I retract that requirement (more on this below).

Cool.

>
>> I don't entirely agree, but it's better than nothing. Here's what I
>> would propose:
>>
>> 1) The issue was raised at least two months ago, by one of email,
>> bugzilla or the issue tracker.
>>      AND
>> 2) There has been no mutually satisfactory satisfactory outcome.
>>      AND
>> 3) There is an open issue in the issue tracker indicating this.
>
> I've noted that you've compromised to 4 months with Ian. I also note
> that we have less than 3 months to LC -- a time when a great number of
> people start raising issues and concerns related to the specification.

As far as I can tell, we are not on track to LC in 3 months. To reach  
LC, we have to resolve all our controversial issues, and so far we  
have not been doing so. That being said, I think we should consider  
shortening the time horizon as we approach LC, if we ever actually  
start approaching it.

> Since LC is a time for the public to review the spec, your criteria
> doesn't allow any new sections of the spec to be marked with warnings.

As I understand it, these markers are for issues that are  
controversial within the WG itself. To publish a Last Call Working  
Draft, we must resolve all such issues within the Working Group. Last  
Call comments from outside the WG may raise new issues - the Working  
Group has an obligation to formally reply to all such comments.

>
> How are we supposed to convey which sections of the document are most
> problematic to the public with the approach you list above?

All issues, whether marked in the spec or not, must be resolved within  
the Working Group in order to publish a Last Call Working Draft. For  
any issues raised after Last Call, the Working Group can't change the  
Last Call Working Draft until the review period is over, but is  
required to formally address all comments. So once we go into Last  
Call, the issue is moot.


>
> I think we need another criteria in addition to the list you have  
> above.
> The goal of this criteria is to allow rapid detection and public
> reporting of a long standing issue that has been ignored/undetected/ 
> not
> discussed for whatever reason. This is a suggestion and may not be the
> most ideal way forward:
>
> OR
> 4) There are at least 8 people that assert a particular section as
> problematic. (8 is arbitrary - whatever number it is, it should be  
> high
> enough so that people cannot vote in blocks, but low enough so that it
> isn't a herculean effort to place warning text beside a section that
> does not enjoy consensus).

I believe that the right way to proceed with rapid detection of a new  
issue is to post it on the mailing list and raise an issue in the  
issue tracker. After all, it's impossible to tell if it's  
controversial until we have some discussion. Frankly, I am dubious of  
the value of markers in the spec in the first place. Ultimately we  
have to actually resolve the issue, and stating that an issue is open  
in the spec does not directly do anything to resolve it. So if we must  
have them, I'd rather have it be based on reasonably objective  
criteria, rather than voting. That way, we can minimize the amount of  
time spent thinking about what to declare controversial, and spend  
more time thinking about how to resolve the controversy. I also note  
that the markers will not serve a useful purpose once we go into Last  
Call, since they all have to go away before LC and once LC is  
published we can't add any to the TR copy of the document.

Regards,
Maciej

Received on Tuesday, 11 August 2009 05:15:29 UTC