Re: Spec organizations and prioritization

Le mardi 20 mars 2012 à 08:19 -0700, Anne van Kesteren a écrit :
> Carefully watering down text to make sure that all implementations are  
> compliant is an expensive exercise. Given the way  
> http://www.w3.org/2005/10/Process-20051014/tr.html#cfr is defined and many  
> specifications that are not fully interoperable (e.g. SVG) went to  
> Recommendation there are definitely other approaches.
> 
> Also, the WebApps WG asked for volunteers in a room of about 100 people  
> when we decided to abandon XMLHttpRequest to see if anyone was interested  
> in doing that watering down and making it happen. Nobody volunteered. I  
> sometimes have the feeling W3C Team members are assigning blame to the  
> person editing and I feel that is inappropriate.

I'm truly sorry if you took my comments as blaming you (or editors in
general); I think the last person that can be blamed in this is the
editors, who already have way too much on their hands.

The point of discussing XMLHttpRequest was not to revisit history or to
assign blame to anyone, but just to look at whether my suggestion could
have helped. I didn't make that suggestion back then (I wouldn't have
known how to formulate it), and I didn't volunteer to do that work, so I
share any blame that would have to be taken if we wanted to do that.

I entirely agree that some of the work that my approach requires is not
work that we should necessarily ask editors (or lead editors) to manage;
and if we can't find people motivated to do the tasks, then it means
that people don't really see the value of getting RF commitments, in
which case my approach won't help. 

But I think that making that approach explicit and clarifying its
consequences to group participants might make it easier to find
volunteers.

> Resources are limited and the process as is (broken) requires lots of  
> them. The math here is really straightforward, it is way easier to fix the  
> process then to find tons of competent people helping us out. It seems  
> better that we realize that than try to change priorities for the one or  
> two years where the current broken process still matters. Then we can  
> collectively focus on fixing it rather than getting sidetracked.

You assume that we can go from "process is broken" to "process is
perfectly suited to our needs" in a couple of years. That assumes we
know exactly what a non-broken process is (which seems hard without
having the said process in place), and that we know how to move from
broken to non-broken in two years. This sounds like XHTML2.

What I'm suggesting is an approach to go from a partially broken process
(or more exactly, set of processes), to an increasing less broken one. I
truly believe that as long as the improvements we make make it faster to
get interoperably deployed features available on an RF basis, we'll be
improving the processes.

Now, the particular solutions that I suggest might have better
alternatives; but I don't think one that starts from "let's wait till we
find the perfect process" is one of those.

Dom

Received on Tuesday, 20 March 2012 15:33:47 UTC