W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: Request for editing guidance

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Thu, 10 Jun 2010 14:49:37 -0700
Message-ID: <AANLkTikMTNeocUQUlwViGDMHr42tK3Q8glBB1V5iJXl8@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
On Thu, Jun 10, 2010 at 2:04 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 10 Jun 2010, Sam Ruby wrote:
>> [...]
> So basically you are admitting that the chairs' WG decisions are in fact
> based purely on volume of complaints on a case-by-case basis and not on
> any consistent technical grounds.

I'm not sure you can logically conclude "purely", however IIRC the
chairs have multiple times noted the criteria of "raises the least
objections" as one of the considerations when there are multiple
options being considered. (I don't have a citation - just off the top
of my head from memory from this list - chairs please feel encouraged
to correct me if you feel that statement is inaccurate).

> I will revise my editing style and working group participation
> accordingly.

Ian, I do think there is something to be said to continue to push for:

a) known explicit technical design principles for the spec
b) consistent application of those principles

>From watching most of the change proposals, rarely do they cite
precise design principles from our design principles document.

My guess is that that's mostly due to neither "design" nor "principle"
being mentioned anywhere in the change proposal template:


I'd like to see the group try adding a required subsection to the
existing Rationale section of the Change Proposal Template that lists
something like:

Design Principles

Please list and cite the specific existing design principles from the
design principles document[1], and how those design principles
logically justify the changes in the change proposal.
[1] http://www.w3.org/TR/html-design-principles/

Additional Principles

If additional design principles are necessary to logically justify the
changes being proposed, please list those additional design

WARNING: note that design principles tend to be applied consistently
to an entire specification (not just the part being potentially
changed), and therefore, if your additional design principles are
accepted, be forewarned that applying them may have additional impacts
on other portions of the specification being changed.


I'd like to see us at least *try* to bring to light and emphasize
design principles in Change Proposals before throwing in the towel and
giving in to purely political winds, based on the principle that
design-by-explicit-principles tends to lead to a better (technical,
for users, etc.) specification than design-by-consensus.



Received on Thursday, 10 June 2010 21:50:30 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:20 UTC