- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 20 Jan 2009 08:20:15 -0500
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: www-archive <www-archive@w3.org>
Lachlan Hunt wrote: > Moving process discussion to www-archive > > Sam Ruby wrote: >> You don't have to back up your opinion if you "can live with" something. > > No, people should need to give justifications whether they are for or > against a proposal. If people don't provide any justification for why > some proposal is good, then there's less information available to base a > decision on. The process must not degrade to a simple voting process, > which is how I perceive the can/can't live with model. It doesn't > matter how many people can or can't live with anything. It's the > quality of the arguments that matter, not the quantity of those arguing > one way or another. > > 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. > 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. > 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? - Sam Ruby 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. Tell me what you don't like about doctype-legacy-compat, and I will see what I can do to fix real instances of real problems. 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.
Received on Tuesday, 20 January 2009 13:20:40 UTC