Re: Chair review of the issue-200 legend-placement change proposals

On 04/22/2012 12:42 PM, Marat Tanalin | tanalin.com wrote:
> Thank you for the feedback, Sam.
> I've updated my proposal according to it.

Reviewing your update:

1) The details section now contains a single proposal, so thank you for 
that.

2) The details section continues to contain rationale that needs to be 
move out of this section.  This includes the first sentence 
("Currently,... just because...").  This includes the phrase "To make 
browsers' transition to new behavior smoother".  Finally, this also 
includes all text that follows the phrase "Benefit of introducing new 
element" through to the end of the section ("confusing thing to use").

3) The request I made was for a set of edit instructions specific enough 
that they can be applied without ambiguity.  The text starting with "new 
ILEGEND element should be introduced" does not meet this criteria.

Point #2 above can be addressed by moving the identified test from the 
"Details" section to the "Rationale" section.

Point #3 can be addressed by copy/pasting the definitions for Legend 
from the spec and then directly making the edits that you are proposing.

If these comments are not addressed by June 21 we will consider this 
proposal to be withdrawn.

- Sam Ruby

> 17.04.2012, 16:10, "Sam Ruby"<rubys@intertwingly.net>:
>> http://dev.w3.org/html5/status/issue-status.html#ISSUE-200
>>
>> Change Proposals:
>>
>>      * Allow: http://www.w3.org/wiki/User:Mtanalin/legend-placement
>>      * Keep: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-200
>>
>> The Allow proposal has sufficient rationale, but the details section is
>> deficient in that it proposes multiple options and does not propose them
>> as a set of edit instructions, specific enough that they can be applied
>> without ambiguity[1].  In particular, the existing Details section uses
>> terms like "could be" and "Another acceptable (and probably even better)
>> option".
>>
>> All Rationale and use case information needs to be moved out of the
>> Details section.  What should remain should constitute a single
>> proposal.  Should there be a desire to submit multiple proposals, that
>> can be discussed, though the clear preference of the co-chairs would be
>> to have a single proposal.
>>
>> Until this feedback is addressed, the Allow proposal is not accepted.
>>
>> In addition, the rationale section of the Allow proposal is deficient as
>> written. It just states some facts, but does not relate them to a reason
>> for allowing the construct. The first sentence of the Summary section
>> does provide a plausible reason, so perhaps that should be included in
>> Rationale.
>>
>> The Rationale could also be strengthened by providing use cases.
>>
>> The Keep proposal is acceptable as is, but could benefit by addressing
>> the feedback that has already been provided on list[2].
>>
>> - Sam Ruby
>>
>> [1]
>> http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#change-proposal
>> [2] http://lists.w3.org/Archives/Public/public-html/2012Mar/0790.html
>

Received on Thursday, 7 June 2012 18:11:31 UTC