- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 10 Feb 2012 11:13:10 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
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