Re: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

On Thu, 31 Jul 2008, Sam Ruby wrote:
> 
> This list is but one of a variety of sources of inputs that you accept. 
> Even if a person attempts to follow all of the insane number of lists 
> that you follow, they won't be getting the entire input stream as you 
> undoubtedly meet with people F2F.  It is even possible that some of the 
> input you receive F2F isn't public.

There are indeed several places I get input from that aren't public, e.g. 
I've been accepted as an observer on the "security" lists of various 
browser vendors (and if any other browser vendors would be willing to 
accept me to their list, please let me know), so that I can get ready to 
plug security holes in HTML5 when browsers come across problems, even 
before they mention them in public. I also sometimes receive candid input 
in secret from people and groups who, for political reasons, don't wish to 
be seen publicly holding particular opinions.

Obviously, I try to keep such private input to a minimum, and I try to 
keep as much of it public as possible, but I'm not going to ignore such 
private feedback either. The more information I have, the better decisions 
I can make in the spec.


> So decisions are inevitably made elsewhere.  At times on other lists.  
> At times even, as you recently put it, in your shower.

Indeed. For that matter, there are many decisions that are made that I 
don't really even realise are decisions. For example, consider checkin 
r1302, "Make addCueRange() have an identifier so that people don't have to 
use currying". I decided what order to put the arguments in, what to call 
them, what to call the new callback interface. I decided to not require 
the ID to be unique, I decided not to limit the values to valid XML IDs. I 
decided not to include the current time in the event, nor the start nor 
end times. I decided to not use DOM Events but to use callbacks. I decided 
not to change the way cue ranges are removed.

I based all these decisions on my experience and all the input I received 
on the matter.


> > > Therefore, any decisions made before the formation of a public 
> > > group, were not "open".
> >
> > Actually even before we had an actual mailing list to archive the 
> > discussions, everything was already being written in public. We soon 
> > set up a list, though, I mean, everything's been done really in public 
> > since 2004 already.
> 
> Everything?  You have a shower-cam?  You've never met privately with 
> people from Google, Mozilla, Microsoft, IBM?  And if you did, you have 
> never considered any of their inputs unless it was previously made in 
> public?

Everything has been edited in the public, if you prefer.


> > As I said to Sam, nothing is set in stone. Decisions are regularly 
> > changed in the face of new suggestions, evidence, etc.
> 
> IMO, that's actually your strongest point; particularly if you 
> deemphasize the word new.  And this point is not just words, but there 
> is abundant evidence supporting this claim.

Thank you.


> But one thing that will always remain true is that it will never be the 
> case that everybody agrees with every decision you make.  There will 
> always be cases where somebody believes that they made a strong case 
> with clear evidence and that you decided to go a different path.

Absolutely. Sometimes, I myself am that person, e.g. with the solidus 
thing. :-)


> My opinion is that there one change that would make this process 
> stronger is if there were a clear escallation path for cases such as 
> these.  One that rarely overturned your decisions, but does do so with 
> just barely enough regularity to inspire confidence that the process 
> works.  And if the changes were rare enough, and the people who were 
> responsible for handling the escallation actually offloaded work from 
> you, this would be a net plus. (Note: this is typically a role that WG 
> Chairs fulfill).

The WHATWG has such a mechanism (the "members", as defined by the charter, 
have the authority and responsibility to overrule me if I make bad 
decisions), but I've so far managed to never make a decision that has 
required them to exercise this power.

The W3C has such a mechanism too, known as "formal objections", with Tim 
making the final call after hearing the arguments from both sides. In my 
experience, Tim's decisions can be somewhat arbitrary since he doesn't 
have the same level of experience with the relevant technical details as 
the people who disagree on the decision. (This isn't in any way meant to 
be a slight on Tim. I imagine I would be equally unable to make well- 
informed judgement calls if I was asked to arbitrate an RDF or XML Schema 
decision, for instance.)

I would be happy for the working to have an additional, working-group- 
specific, well-defined process for overruling me, so long as the people 
with the authority to do so are people who really understand the issues, 
e.g. people who have written browser code and who keep a close enough eye 
on the development of HTML5 to really have an informed opinion. (Maciej 
comes to mind as someone with this level of experience.)


> > Just saying "reconsider this decision" doesn't cause the decision to 
> > be reconsidered. It doesn't matter when the decision was made. What 
> > matters is whether new information has come to light.
> 
> "new" is relative and (given the lack of documenation) undefined in this 
> context.  Additionally, if this group wants to be truly inclusive, it 
> needs to be able to find a way to accomodate people who weren't present 
> at the time provisional decisions were made.

How should such accomodation happen?

I agree entirely that people by and large won't know what has been 
considered and what hasn't. I mean, at the extreme, there are things -- 
many, many things -- that I've come up with, considered, and rejected, 
without ever mentioning them anywhere. How can anyone know?

So it's fine for people to raise issues. The point is just that if their 
proposal _has_ already been considered, I don't have the bandwidth to go 
through and rehash the sometimes week-long discussions that such proposals 
deserve to get. So sometimes I (and others) say "we've already considered 
that, but rejected it because..." with some brief description of a 
problem, usually the main problem, rarely the only problem, that affects 
the proposal.

Is that unreasonable?

(Ideally, someone would then document this on a wiki page of "rejected 
ideas" or something, but nobody has volunteered to do that so far.)

To give the specific example of the namespace parsing mechanism that IE 
implements which you have put forward several times: I read the whitepaper 
that Microsoft put forward on the day they announced it, and considered it 
carefully as I was reading it. I also had already considered IE7's parsing 
behaviour, and considered IE8's parsing behaviour as soon as I had IE8 
installed and had gotten the workaround for their attribute DOM handling 
bug sorted out (thanks Philip`). You've since brought it up at least half 
a dozen times, both here and on your blog, and gotten a response each time 
(almost certainly a progressively shorter and shorter response), saying 
that those ideas had already been considered. You have never introduced 
new information, indeed as far as I can tell you haven't actually 
seriously considered what the proposal is and have never shown an actual 
example demonstrating that you truly understand Microsoft's proposal.

What could I change in the way I respond to issues to make you feel like 
your suggestion has been seriously considered, as it indeed has?


> > Nothing is immutable. Any decision can be reversed in the face of 
> > strong reasons and arguments and evidence.
> 
> It doesn't always feel that way.

Changes like this happen all the time. Just yesterday we reversed the 
decision on the issue of the <a> element's content model, an issue so big 
it has its own FAQ entry in the WHATWG FAQ.

How can we make it more obvious?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 31 July 2008 21:01:45 UTC