- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 20 Mar 2012 16:33:17 +0100
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-w3process <public-w3process@w3.org>
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