Re: status of phase 1 work items?

On Friday, June 21, 2013 at 7:41 PM, Charles McCathie Nevile wrote:

> On Fri, 21 Jun 2013 02:20:20 +0200, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> > On Thursday, 20 June 2013 at 18:08, Dave Raggett wrote:
> > > On 20/06/13 17:45, Marcos Caceres wrote:
> >  
> >  
> > 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.

Oh, I wasn't intending for you to go an have a look at the actual content of the commits. Sorry you wasted your time.   

It was intended to show *the number of changes* that can occur to a spec in a week while we wait for publication.  
> 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.

Argh, did you not see the email about the "Changes section"? All normative changes will be recorded there. That's already in the Editor's draft.  
> In other words, it  
> makes the difference between me wasting my available time, and giving an  
> actual review of changes.

Sure, that's why the Editor's draft has the Changes section:
http://telephony.sysapps.org/#Changes

As you can see, no normative changes have been recorded yet … and there is a good reason for that :) The Editor's are working hard on Github addressing bugs in a separate branch (the one you looked at above).   
> It also seems that you spent a few days shuffling stuff around.  

Yes. Please see the "Transition to `noLegacyStyle`" milestone:  
https://github.com/sysapps/telephony/issues/milestones  

And see also:
https://github.com/sysapps/telephony/issues/113

It would really help if you were tracking bugs on GH and participating in closing them.  

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

You got it :)   
> 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.

It would help if you were following on GitHub. It's all there and those involved don't have a problem with the process. Between the Editor's we are actually kicking some serious ass and making some awesome progress filing and closing bugs.      
> Which is why I will not bother asking Yandex people to pick a random  
> editor's draft.  

That's a shame. We are extremely careful about when and how we update Editor's drafts. All changes are thoroughly reviewed before integrated.   
> If there are significant changes since the FPWD I would  
> love some way of knowing that doesn't cost me 20 minutes.

Yes, the "Changes" section is what you want.   
> 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.

Absolutely, which is why it's on a separate branch … so to avoid exactly what you said above. Sorry again about the confusion ^_^    
> > 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).

This thread:   
http://lists.w3.org/Archives/Public/spec-prod/2013AprJun/0024.html
> > 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).


Yeah, it's why I put the BIG BLUE WARNING into the spec. I'm ok to republish every so often, but note that I waste about 1 day preparing a draft for publication. That's time I could be spending actually working on the spec.  

If you really want to publish every so often, I'm happy for you to take over that task. It would really help me out and I can focus on Editing.   
  
> The amount of work required to publish a new Working Draft to /TR is  
> usually measurable in minutes.  

Man, you obviously work much faster than me. Here is the record of how long it took to publish the FPWD:  

https://github.com/sysapps/telephony/commits/First-Public-Working-Draft

It took well over a week to get the spec in order - and a ton of commits keeping it all in sync. See, in particular, the stuff that was done on the 11th of June.  

Granted, next time it won't be sooooo bad (and some of the fixes benefitted the Editor's draft, like broken links, pointing to the correct IPR pages, etc.).
> 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.

Happy for you to take over publishing. It would really help me out and allow me to focus on editing!  
> 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.
>  

I'm happy either way, so long as we can publish often and quickly. I would love it if we could publish bi-weekly or weekly (or hourly;)).   

Kind regards,
Marcos

Received on Friday, 21 June 2013 19:25:39 UTC