Re: Request for editing guidance

On Wed, Jun 9, 2010 at 2:28 PM, John Foliot <jfoliot@stanford.edu> wrote:
> You said "the best choice for users, authors, implementors, and the web in
> general"
>
> What if we had multiple solutions to a "problem" that worked out like this:
>
>        Users - excellent solution/outcome
>        Authors = workable solution
>        Implementors = costly and technically complicated solution
>
> ...versus
>
>        Users - average solution/outcome
>        Authors = complex, difficult and confusing solution
>        Implementors = great technical solution
>
> ...versus
>
>        Users - good solution/outcome
>        Authors = workable solution
>        Implementors = achievable but tricky solution

This is resolved by the priority of constituencies:

http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

The first priority (implicitly) is that nothing can be in the spec if
it won't be implemented.  Following that, we favor "users over authors
over implementors over specifiers over theoretical purity".  In this
case, the first solution would be preferred, followed by the third,
followed by second, based on what implementers are willing to
implement.

The real trick is figuring out what's best for users.

> The problem we have is when decisions are
> made at WHATWG (in what we must honestly agree is a mono-culture setting -
> engineers talking to engineers) that misunderstands or mis-interprets the
> needs/impact on the other groups. It is further compounded by the autocratic
> decision process that is employed at WHATWG.

I'd say the opposite.  The WHATWG is dominated by implementers.
Implementers are uniquely qualified to evaluate the needs of the web
as a whole.  There are only a few browsers, and each browser is used
by a pretty representative slice of all web users.  In contrast,
authors, users, and spec writers tend to see only a tiny and utterly
non-representative part of the web in the course of their day-to-day
life.  They have a correspondingly unrealistic view of the web,
overemphasizing the importance of their own small slice.  The WHATWG
operates by everyone presenting their needs, and the browser
implementers deciding on their importance based on their perspective
of the whole web.

Pragmatically, this is what happens anyway.  Implementers are the
gatekeepers, and if they don't think something is sensible, they'll
just ignore it.  Trying to force things on implementers, rather than
writing specs that all implementers agree with from the beginning, is
what gets us specs that don't reflect reality.  Better a spec that
will be used to interoperably implement *something*, than a spec with
parts that are ignored in practice.

On Wed, Jun 9, 2010 at 3:02 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Jonas - sorry - this is really nonsense.
>
> ...repeating what I said before: it makes a big difference when something
> has been in HTML 4.01 forever, and is in wide use. Microdata is the contrary
> of that.

If I understand Ian correctly, he'd be fine if things like that were a
clearly-stated generally-applicable rule.  His objection is that the
general rules are not stated clearly and officially.  I think this
disagreement could be rectified by a procedure change that encourages
the chairs to set out detailed general principles and try to follow
them closely, rather than making decisions on a purely case-by-case
basis.  This seems like a reasonable request.

What several responses have done instead is give case-by-case
reasoning for why various decisions are justified, and declare that
reasoning to be obvious.  This isn't particularly helpful, since the
editor has said he doesn't find the reasoning obvious.  I don't see
anyone actually addressing the suggestion that the chairs start making
more general, less case-by-case decision.

I'd suggest that everyone here remember that on technical lists, some
people will inevitably be undiplomatic.  Computer skills and people
skills often don't occur together.  Let's all make an effort to focus
on the issues raised, and avoid getting distracted by the tone.

Received on Wednesday, 9 June 2010 19:45:38 UTC