Re: Process Model [was: ACTION-78: Suggestion text for 1.5.4]

Sam Ruby wrote:
> Lachlan Hunt wrote:
>> e.g. Consider this scenario:
>> * Dozens of people are saying they can live with proposal A, but not B.
>> * 1 or 2 people are saying they strongly prefer proposal B, but they 
>> "can live with" proposal A.
>> * The many people in favour of A are using relatively weak arguments.
>> * The few in favour of B are using relatively strong arguments.
>>
>> Ideally, the result should favour the few over the many: proposal B 
>> should be chosen over A.
> 
> In this scenario, nobody said that they "can't live with" proposal B. If 
> someone did, they would have been asked to provide a strong argument as 
> to why they did so.

Actually, I said "...can live with proposal A, *but not B*", meaning 
"cannot live with" B.  I now see how what I said is slightly ambiguous, 
sorry for the confusion.

>> However, as I understand your consensus driven can/can't live with 
>> model, proposal A would be chosen over B, despite it being suboptimal. 
>> The other model may not be considered consensus, and I suspect you 
>> think that's a problem, but it is a technically superior solution and 
>> that is why I think your model is flawed.
> 
> In the scenario above, as no-one would be able to provide a strong 
> argument against either option, both A and B would be made available as 
> options to the editor.

How does the clarification I gave above change that outcome?

>> I know from experience how consensus driven can/can't-live-with 
>> approaches can result in suboptimal outcomes.  Just look at the 
>> Selectors API method naming issue.  Despite the research and effort I 
>> put into finding the most appropriate name based on evidence and 
>> logical argumentation, the WG went to a vote and forced me to choose a 
>> suboptimal name that no-one was particularly thrilled about but which 
>> everyone "can live with".
> 
> Who is suggesting a vote?

I'm finding it difficult to perceive "can live with" and "can't live 
with" as anything other than a form of vote.  The statement itself isn't 
  an argument, and frankly whether someone can or can't live with 
something doesn't matter in the least.  What matters is just the quality 
of the argument put forth and it should make no difference whether 
someone explicitly says they can or can't live with something.  It's 
also pointless to get people to say it explicitly since it's much easier 
to evaluate someone's position based on the arguments they put forth, 
than relying on an explicit binary statement.

> P.S.  I hate with a passion hypothetical discussions such as these.  The 
> discussion that has occurred recently on issue 54 doctype-legacy-compat 
> is not an example of a vote.  No noses were counted.  Only two people 
> followed instructions.  Those two people provided strong cases.  Those 
> strong arguments made by few made a big difference.

I'm aware the so few people followed instructions, which thankfully made 
the attempt at using the model a benign failure.  Presumably I was one 
of those who didn't follow instructions because I explicitly avoided 
stating whether or not I could live with a solution, and only provided 
logical arguments and evidence for or against each.

But despite your complaints about people not following instructions, 
most people that contributed used a model that really works (i.e. 
presenting evidence and logical arguments), and we ended up with a 
better proposal than those on offer to begin with.

> If your position is that while this may have worked on 
> doctype-legacy-compat, it is unlikely to do so on bigger problems, let's 
> revisit that discussion when we have real instances of real problems.

My position is that, in reality, the can-live-with model wasn't really 
used for the doctype-legacy-compat and can't be used as evidence of it 
working.

My suggestion is that instead of presenting a list of options and asking 
people to say yes or no, it's better to ask them to evaluate each 
alternative.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Tuesday, 20 January 2009 13:56:55 UTC