Ian Hickson wrote:
On Thu, 19 Feb 2009, Sam Ruby wrote:
For starters, there is an interesting gap between 100% and 50.000001%.
I wasn't specifically meaning 50%; there are as you say a number of ways
of achieving "consensus" without achieving "unanimous consensus", ranging
from everyone-except-people-who-disagree-with-everything-on-principle down
all the ways past 50% to a mere plurality. If our goal is to aim for one
of these levels, it would be helpful to know which level we are aiming for
since it would affect the way one would approach the goal of publishing a
last call draft.
At the IETF, there is a mantra of "rough consensus and running code".
As I read your proposed milestones, I see Last Call first preceding
running code in a number of instances. Am I misreading this?
While it is possible to gain consensus without running code, it isn't
obvious to me that it is desirable to do so. Rob's approach is to start
from running code.
To the extent that the document you are editing accepts input from
places other than the public-html mailing list, the concern about the
"inordinate amount of bureaucracy" doesn't fully apply.
Not to the content of the spec, but it might to the decision of whether we
have consensus within the group (since that might not represent consensus
amongst the wider Web community).
To the extent that people like you are hooked into the wider web
community, it is worth noting that it would be virtually impossible to
have consensus on anything in this smaller group that would not reflect
the wishes of the wider Web community.
I will also note that the wider Web community is is like the proverbial
elephant[1]. In particular, this I see a quite different view of the
very same web reflected here:
http://www.w3.org/2001/tag/2008/09/f2fkc-agenda
I don't know yet how to reconcile these different views.
I'll come back to the "inordinate amount of bureaucracy" later in this
email.
What bar will you be looking for when I say "ok there is no
outstanding feedback, let's publish a Last Call draft"?
I don't have the full answer for that question, but let me start with
this: no, I do not believe that votes are something we should employ
except as a last resort.
Ok. I think it would be helpful to have a firm idea of how we want to
approach this problem sooner rather than later, if we are to not slip past
October.
It would be helpful if we had a firm idea of how we want to approach the
problem of section 1.5.4 sooner rather than later, if we are to not slip
past October. This is not an issue that where implementors "vote with
your feet". What bar are you looking for?
You question the viability of the W3C published dates. Permit me the
same with respect to your October date.
The part of the process dealing with assessing consensus is not amenable
to algorithmic description. Some examples from which you might be able
to generalize: We have rough consensus on legacy-compat. We have rough
consensus on Karl and Henri's license use cases. We have rough
consensus on canvas being in scope. The first two I cited did not take
very long to achieve. And I believe that if similar processes were
followed, this group could get more efficient on processing issues.
Even more complicated ones.
Giving the smaller surface area, and the backing of running code for
everything in Rob's draft, I am considerably more optimistic about the
prospects of attaining W3C consensus for a draft with his scope to
proceed onto Last Call in 2010. Given my past experience with Rob, it
would not surprise me if it made 2009. Perhaps even October.
In particular, I will note that section 1.5.4 is simply not an issue
with Rob's draft.
For the near term the low hanging fruit is as follows: [...] for you to
consider Rob's approach to @summary, @profile, and @alt.
Could you elaborate on this? I'm not sure what approach you mean.
Rob's statements on this matter:
https://bugzilla.mozilla.org/show_bug.cgi?id=478665#c3
http://lists.w3.org/Archives/Public/public-html/2009Feb/0128.html
Related example from the same editor:
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1
As a concrete example, let's explore "summary". To the extent that I
understand it, your position is that the summary attribute is
non-conforming, and people who wish it to be so must provide a what
appears to be an unspecified amount of supporting data if they wish this
to be changed.
My read is that Rob would simply say that summary is a part of the
grammar and would prepare an even-toned cautionary note directed at
consumers. Others would be welcome to draft alternative wordings for
the cautionary note for consideration.
Same issue. Same W3C. Two different approaches. One involves an
"inordinate amount of" people documenting issues to be tracked and
working groups to document official positions.
- Sam Ruby
[1] http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
