Re: Bug 7034 (was: Possible *third* proposal)

On Mar 19, 2010, at 1:01 PM, Sam Ruby wrote:

> On 03/19/2010 03:52 PM, Maciej Stachowiak wrote:
>> I would expect the cited bug to be NEEDSINFOd unless Sam provides  
>> more
>> information than he has so far.
> [co-chair hat off]
> The title of the bug report is "authoring conformance requirements  
> in the spec should either be removed or replaced".  Given that  
> title, I don't know what more information could possibly be needed.

Let's say Ian wanted to make a spec change to address the the bug. How  
would he know whether a given change addresses it? Based on that title  
alone, it seems impossible to tell if any particular resolution of the  
bug is a FIXED or a WONTFIX. If the title were "All authoring  
conformance requirements in the spec should be removed", then it would  
be very clear whether a resolution counts as FIXED, but I believe that  
is a solution you personally do not agree with, even though it was the  
original intent of the bug. (My guess would be that a bug with that  
title would result in a resolution of WONTFIX with a justification for  
why there are authoring conformance criteria in general, rather than  
detailed individual justification of every one.)

> Just to be clear: what I am seeking is rationale for the current  
> authoring conformance requirements.  If this isn't the process for  
> seeking rationale, please let me know what the process is.

Assuming you don't want the bug to end up as RESOLVED NEEDSINFO, the  
best thing to do would be to ask for specific removals or changes, or  
at least state an unambiguous criterion by which it could be  
determined if a particular change to the spec is satisfactory to you.  
I suggested that you add that information a couple of times in the bug.

> The alternative, as I see it, is to take guesses as to what the  
> intent is for the authoring conformance requirements, then make my  
> own personal assessment as to whether the actual requirements meet  
> my guess as to what the intent is, and then file bugs based on my  
> guesses.

What I'd suggest instead is that you name the conformance criteria  
that you disagree with, or some clear criterion by which it may be  
determined which those are. The intent of the bug process is to get  
changes to the spec that satisfy your objections *or* rationale for  
why the requested change was not made. That doesn't mean that you need  
to go into full detail about the exact change you want, but it should  
be reasonably clear whether a specific change resolves the problem or  

(Note by the way, I'm not picking on you individually, I often ask bug  
reporters to be more specific or split up their bug report.)


Received on Friday, 19 March 2010 20:30:12 UTC