Re: Spec organizations and prioritization

Created ISSUE-6 https://www.w3.org/community/w3process/track/issues/6

On Tue, 20 Mar 2012 16:33:17 +0100, Dominique Hazael-Massieux <dom@w3.org>  
wrote:

> 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.

Yes. I think the relevant question is whether it makes sense to consider  
an approach in future where for some cases we are prepared to publish  
specs that don't solve all the problems, as an intermediate step.

>> 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.

Indeed. Like publishing a spec that is known to be imperfect. As I  
understand it, that's similar to what is being proposed by some people who  
say "just make a snapshot for the Patent Policy and call it the  
Recommendation (version today)".

>> 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.

Right. It was clear in the XMLHttpRequest that it was too late.

>> Nobody volunteered. I sometimes have the feeling W3C Team members are
>> assigning blame to the person editing and I feel that is inappropriate.

It would be. But I don't know where you get that feeling - I think many  
people recognise that there are problems, and we should find better ways  
to solve them, which means trying to look at what went "wrong". But that  
doesn't mean it is the fault of the editor, or the group, or anyone else -  
just that if we don't understand it, we will have a hard time talking  
about how to make it better.

> 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.
...
> 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.

I'm with Dom here. I would be surprised if we can fix everything in a  
couple of years, and I don't see that there will be some magic time when  
we can suddenly work on it and do everything really quickly.

To follow the XHR example a bit further (disclaimer, as Anne's manager at  
the time I supported the way he worked on it - and still do), an  
alternative might have been to take on the pieces that were found to be  
interoperable, and publish that before working on the edge cases. Indeed,  
someone like me could have taken over that content when it was *useful*,  
leaving you to continue doing the important work of dealing with those  
cases, just marking them in the version I was working on as issues still  
to be resolved, and going through the mechanics of publishing. (Again, I  
was among the people who didn't volunteer to follow up on XHR1 as it was,  
and I didn't volunteer to do this for XHR1 earlier nor ask Anne to do so).

In principle this could be done without changing the Process. In practice,  
it does mean changing the practice. If I tried to take a spec from Last  
Call to CR today, and it had dozens of known issues and a suspicion that  
there were more unknown issues, I suspect the transition request would be  
turned down...

cheers

Chaals

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 20 March 2012 16:58:54 UTC