Re: status of phase 1 work items?

On Fri, 21 Jun 2013 02:20:20 +0200, Marcos Caceres <w3c@marcosc.com> wrote:
> On Thursday, 20 June 2013 at 18:08, Dave Raggett wrote:
>> On 20/06/13 17:45, Marcos Caceres wrote:
>> > Hi Dave,
>> >
>> > On Thursday, June 20, 2013 at 5:29 PM, Dave Raggett wrote:
>> > > Several of the specs have been updated since the FPWD was > >  
>> published, and
>> > > are candidates for updated public working drafts. Any suggestions >  
>> > for which ones are ready, or soon will be?
>> >
>> > I would not be in favor of republishing any of the specs until we  
>> feel they are ready for LC (or only to meet the heartbeat requirement).  
>> In the specs we have published so far, we are still dealing with the  
>> feedback from public-script-coord.
>>
>> The usual idea is to update the public Working Draft to mark progress
>> whenever there has been significant round of changes to the editor's  
>> draft.
>
> The problem is that the specs on /TR/ fall out of date too quickly and  
> it's too slow to republish (not your or the W3C's fault, it's just  
> reality). Consider, since Monday, we've made close to 100 changes to the  
> spec and closed numerous bugs - see list of changes:
> https://github.com/sysapps/telephony/commits/noLegacyStyle

I did. It took me about 10 minutes just to skim and see that if any  
substantive changes are in there, I will probably have to spend an hour to  
find them. I see a *lot* of what look like totally editorial changes.  
Making me construct my own map of changes from that is a huge waste of my  
review time.

I would guess you could write a list of the important changes from memory  
in a couple of minutes and I guess that would save me somewhere between 20  
minutes and an hour of trawling through the minutiae. In other words, it  
makes the difference between me wasting my available time, and giving an  
actual review of changes.

It also seems that you spent a few days shuffling stuff around. I expect  
reviewing a random draft in the middle of that to mean I find a pile of  
weird artifacts of being halfway through that process. There is no  
indication that this is happening, so I have no way of knowing if I should  
waste an hour or two trying to mentally reconstruct where your process  
will result, waste half an hour a day for the next week looking at new  
editors' drafts until I find one that seems at least internally  
consistent, or waste a whole day telling you why the document I stumbled  
on doesn't make sense.

Which is why I will not bother asking Yandex people to pick a random  
editor's draft. If there are significant changes since the FPWD I would  
love some way of knowing that doesn't cost me 20 minutes. I am certainly  
not prepared to waste the time of people I might ask to review by  
expecting them to figure out which of 100 changes are meaningful, or  
whether the thing they are looking at is a mess because you haven't  
figured out what you are doing or just because you are in the middle of a  
few days work and wisely committing as you go.

> I think it's better to encourage people to always read the Editor's  
> draft and just use FPWD and LC for IPR commitments (hence the inclusion  
> of the blue bar in the telephony spec).
>
> Last I heard PLH and co. are working to allow Editor's drafts on /TR/
> to overcome the problem above.

Really? Pointer? (I know the topic has been discussed. I didn't know there  
was a move to do this).

> It's why I'm more inclined to only publish for important milestones.

Substantive changes to the spec are generally important milestones.  
Completing a series of editorial reshuffles is also potentially a  
milestone. If you are making very fast progress and have a lot of them,  
you might want to pace out hte milestones to a few weeks apart. But if you  
wait until you think the whole thing is done to publish a milestone, you  
invite comments of the "but this is pretty much unworkable" variety (as  
happened in the case of e.g. Pointer Events, certainly to the immense  
frustration of our developers and I believe to the frustration of the  
Working Group as well).

The amount of work required to publish a new Working Draft to /TR is  
usually measurable in minutes. Write a status section and changelog that  
tells people in a few lines what changed since the last version and what  
you expect next, create a version of the document that meets the  
requirements for publishing. If you don't have a Working Group agreement  
to publish on a reasonably regular schedule or defined trigger, get  
agreement to publish - something that is much easier when publishing is  
regular.

It is typically a lot less than the work of a careful review that you are  
requesting others do. It is an investment in maximising the likelihood  
that reviewers understand how to efficiently review the document, and so  
in getting feedback that is helpful to the Working Group.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Friday, 21 June 2013 18:41:42 UTC