- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 1 Jun 2009 12:19:22 -0500
- To: Leif Halvard Silli <lhs@malform.no>, "Dailey, David P." <david.dailey@sru.edu>, Sam Ruby <rubys@intertwingly.net>
- Cc: HTML WG <public-html@w3.org>
Maciej wrote [1]: > If I understand your position correctly, you're saying any rule that > can't be stated and obeyed in 100% absolute terms is not worth > writing down. Leif answered [2]: > Principles are principles. Stating clear and unambiguous principles is > one thing. Finding, that in reality, you have to break a principle or > two, is another thing. Exactly, Leif. The introduction of the Design Principles doc states: "To make useful progress, we need to have some basic agreement on goals for this group." Smart goals use SMART[3] criteria: * Specific * Measurable * Achievable * Relevant * Time-bound (Drucker, Peter. Collins Business; Revised edition; April 22, 2008) Consensus of SMART goals, definition of terms, and a common set of reviewing questions would have: 1. Aided in communication and understanding. 2. Helped avoid needless arguments and churning of issues. 3. Promoted consistent and fair decision making. 5. Encouraged outcomes that reflect what is important to the working group. 6. Benefited working group progress. David wrote[4]: > If the principles are to be taken seriously then I would want to > undertake a much more systematic study of the nature of principles in > the evolution of policy and in the way that those principles may be > used to introduce bias into the evolution of policies. That would be great, David. Thanks. But it would depend on the answer to the question you asked: > In what way are these design principles vital to the task at hand? In order to apply consistent unbiased decision making throughout the specification, it would have been critical to come to consensus on the design principles. Inconsistent principles can lead to inconsistent, contradictory, and discriminating decision making. As Leif said, principles are principles. As DanC has said, "their main utility is as justification in discussions." [5] In other words they are fundamental value guides used to base decisions. No agreed upon principles, at best result in decisions (e.g. dropping/adding changing elements and attributes) without foundation. At worst they may result in arbitrary, inconsistent, unjust, partial, wrong-headed, and discriminating decisions. TBL said, "design principles very hairy...journey of arriving on consensus valuable; have whole group in on discussion, creates common vocabulary and trust in one another..." [6] The problem is, at this late date, for some working group members trust has gone to ashes [7]. Sam wrote: > Is it fair to observe that a document that purports to describe "a > shared vocabulary to discuss various ideas" would attract weaker > objections than a document that purports to describe "Design > Principles"? I'm not sure that the vocabulary is even shared, Sam. A title of "A Document to Discuss Various Ideas" would be more truthful. The document contains ideas which the working group has discussed at length without coming to a mutual agreement. If it is decided to publish the Working Draft as a note, I previously proposed language for a disclaimer [8]. David has also asked for a suitable disclaimer [9]. I think it was Chaals who suggested that the group should publish a version indicating the document is no longer an active work item. Best Regards, Laura [1] http://lists.w3.org/Archives/Public/public-html/2009May/0653.html [2] http://lists.w3.org/Archives/Public/public-html/2009Jun/0003.html [3] http://en.wikipedia.org/wiki/SMART_(project_management) [4] http://lists.w3.org/Archives/Public/public-html/2009May/0635.html [5] http://krijnhoetmer.nl/irc-logs/html-wg/20070817#l-43 [6] http://www.w3.org/2007/04/26-html-wg-minutes [7] http://lists.w3.org/Archives/Public/public-html/2009May/0092.html [8] http://lists.w3.org/Archives/Public/public-html/2009May/0170.html [9] http://lists.w3.org/Archives/Public/public-html/2009May/0219.html -- Laura L. Carlson
Received on Monday, 1 June 2009 17:20:00 UTC