Re: Split Issue 30?

On 2/10/2012 10:57 AM, Maciej Stachowiak wrote:
> On Feb 10, 2012, at 8:23 AM, Laura Carlson wrote:
>
>> Hi Sam,
>>
>>> I dislike this characterization and the innuendo that people may be playing
>>> tricks.
>> I am sorry you dislike it. But re-ordering issues to strengthen one
>> proposal over another is not equitable.
> I think that the key consideration for the Working Group should be to ensure that every issue and every proposal gets fair consideration. This needs to take priority over considerations of which proposal benefits.
>
> It seems to me that your argument is purely based on giving a tactical advantage to the "Instate Longdesc" Change Proposal, not on making sure that *all* proposals  get a fair hearing, with all possible information on the table. I can understand why you would feel that way; it's natural to want to advocate for your preferred proposal. But I think it is unlikely that the Chairs would give a lot of weight to that type of argument, because our job is to ensure that the process is fair to everyone, not to help a particular side win.
>
> While the Chairs rarely order issues for the sake of dependencies, I have to agree with Sam that the last thing we want is for ISSUE-30 to get reopened yet another time.

Laura has repeatedly addressed the other two change proposals, as well 
as thoroughly documenting her reasons for asking that longdesc be 
maintained as a web standard.

Jonas, the author of one of the proposals has stated that his proposal 
is not directly intended for longdesc. But, he is hoping that it can 
eventually lead to longdesc being obsoleted.

This is not an issue of tactical advantage. It's an issue of simply 
going in circles.

It seems to be well established now that there is not a present, working 
replacement for longdesc. The issue was whether longdesc should be 
maintained.

The change proposals looking to obsolete longdesc are grasping for new 
semantics, and new features, so that, in the future, longdesc can be 
obsoleted.

While that's all well and good, those seem like items that ought to be 
in their own change proposal. They are general items, they are not 
"let's replace longdesc with this, because it works", they are "let's 
add on these new features, and then maybe we won't need longdesc". They 
deserve a full analysis and consideration. But they deserve it on their 
own merits, as enhancements to what currently exists. Instead they are 
being examined as usable replacements for longdesc.


-Charles

Received on Friday, 10 February 2012 19:13:38 UTC