Re: Request for editing guidance

On Wed, Jun 9, 2010 at 11:28 AM, John Foliot <jfoliot@stanford.edu> wrote:
> Tab Atkins Jr. wrote:
>>
>>
>> I was on the "winning" side of several of the most recent issue
>> decisions.  However, I'm still fairly unhappy with the result.  While
>> I *still* haven't gotten a straight answer about it, it appears that
>> the decision method was "whatever seems to have the lowest chance of
>> causing a Formal Objection later on".  This is far removed from
>> "whatever seems to be the best choice for users, authors,
>> implementors, and the web in general".  If this is indeed the decision
>> process used, then it's a glorified straw poll, and we should admit
>> such rather than wasting frankly ridiculous amounts of time and effort
>> pretending that technical arguments actually matter.
>
> Hi Tab,
>
> I'd like to examine something you said here, and work through it a bit
> further.
>
> 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
>
> Now it is no longer a binary choice, and further, the best technical
> solution does not serve all the other constituents equally.  Here, sadly, it
> is the lowest common denominator (choice 3) that must be chosen as it is the
> best over-all solution, and not necessarily the *best* technical solution
> from an engineering perspective.

The order of constituencies has been defined for a long time - users
first, then authors, then implementors, then theoretical purity.
Additionally, implementors get a de facto veto if they have
marketshare above some handwaved cutoff (somewhere around 1%, if past
comments on the matter can be trusted).

In this case it's pretty clear that #1 is best as long as implementors
are willing to do it, but if they veto it then we fall to #3.  #2
fails on multiple counts.


> 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.
>
> There is no disagreement that, as we are talking about technology, the
> technological solutions should be as sound and robust as we can make them,
> and the input of the engineers in the over-all discussion is critical.
> However, it is critical to also understand that theirs is not the only
> voice, nor community affected. And while I do appreciate that the engineers
> *do* try very hard to understand those other perspectives, they can miss
> subtleties as much as the non-engineers might miss out subtle engineering
> perspectives. That's just life.

While all theoretically true, I don't believe any of this is relevant
to what I or Hixie are talking about.  Taking the input of
non-engineers into account is of course important (they're the first
and/or second constituency), and that happens in the normal iterative
process of writing the spec.

That's separate and different from making decisions based on,
literally, who is most likely to complain the loudest.


>> At this point I'm wondering if just threating an FO on every decision
>> I disagree with would be a better use of my time.  It would certainly
>> be easier than actually gathering arguments and attempting to cogently
>> present them.
>
> I think personally that this would make very little actual difference,
> because even at the FO stage, the best technical solution will still likely
> be weighed against other factors beyond technology. It has to be, because
> (and I know this rankles the engineers) this *is* a political process as
> well: with billions of dollars at stake, and impacts that are truly global
> in scope to stakeholders with varying agendas, (plus not everyone is an
> engineer), and so for whatever reason if another stake holder disagrees with
> a solution for whatever reason, no matter if it is the best technical
> solution or not, that stakeholder can also issue a FO based on legitimate
> factors outside of engineering. So yes, finding solutions that are least
> likely to attract a Formal Objection later is the only prudent path to
> follow.

When stakeholders with billions of dollars at stake object, they'll be
listened to.  That's roughly equivalent to the implementor veto - if
authors (where "authors" includes major companies) aren't going to use
something, then it's a bad technology.

The problem with the stated path of "avoid Formal Objections" is that
it's a trivially hackable process.  I'll just threaten formal
objections at every point if that's a successful way to influence a
decision.

~TJ

Received on Wednesday, 9 June 2010 19:36:58 UTC