Re: status of phase 1 work items?

On Sunday, June 23, 2013 at 9:44 PM, Charles McCathie Nevile wrote:  
> On Fri, 21 Jun 2013 21:25:10 +0200, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
>  
> > On Friday, June 21, 2013 at 7:41 PM, Charles McCathie Nevile wrote:
> >  
> > It was intended to show *the number of changes* that can occur to a spec  
> > in a week while we wait for publication.
>  
>  
> Isn't that what branches are for?
No. Branches may gather a set of changes together into a logical set for a period of time, but the branch may be merged in at any time (or changes from a branch can be cherry-picked into the main branch). The branch itself my be discarded.   
>  
> You claim the spec isn't ready for implementation  
That is correct. As one of the Editors and someone working on an implementation, I should know. My implementation, in JS (Chrome only):

http://marcoscaceres.github.io/teleprolly/demo/

The implementation itself has been used to find a ton of issues - a lot of which have not been fixed yet.  
> (which seems like  
> over-simplification to the point of nonsense - first because I believe  
> your *starting point* was an implementation,

*My* (Marcos') starting point was the spec. I have not been involved with Mozilla's implementation of telephony at any point (my implementation doesn't even work in FireFox because FireFox currently lacks support for the Web Audio API, ATM). I wrote *my reference implementation* as the spec is being written and *know* that it's not implementable.  

My starting point is always what is best for the Web - not "oh, lets just standardize what we have". I'm deeply offended that you would suggest otherwise.    
> and second because I believe  
> that implementation and testing are critical to the development process).


Do you honestly think anyone doesn't? The whole point of doing the reference implementation is to verify the spec text and to generate tests (without this actually ending up too early in a *real* browsers). We've been screwed too many times by browser makers shipping half-baked stuff too early on the open Web. I encourage you to read the extensible web manifesto:
  
http://extensiblewebmanifesto.org/
   
> Everyone knows that a snapshot draft is a stabilisation point that may be  
> missing some of the latest and greatest thinking.

A lot of history shows that this is not the case.  Also, even your statement above is absolutely wrong: it's not a "stabilization point" at all - it may completely change tomorrow if there is good reason to do so. The problem is this belief that there are stabilization points - a spec is stable when it stops changing - no sooner. The spec clearly states, from the W3C boilerplate:  

[[
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
]]

The W3C has the sense to understand the reality of the situation.  
> But if you are really  
> producing a revolution in thinking every week, maybe you're not ready to  
> be working on a standard. That sounds more like an interesting research  
> project.

Please stop the trolling rhetoric and using tired old arguments. You haven't being involved _at all_ with the telephony work so I don't see how you are in any position to pass such judgment about the changes the people _actually involved with the work_ are making.   

So, yeah - It would be nice if standards worked like the above. In reality, the world doesn't work that way. For example, Promises only happened in the last few months:

https://github.com/sysapps/telephony/issues/17  
> If you are merely making editorial changes, then it won't matter so much  
> which end of the change the review comes.

We are by no means just making editorial changes. By making editorial changes, we've found all sorts of bugs and made important normative changes, recommendations, and clarifications.  

I know it's boring, but look at the list of bugs in just the last week which resulted from what was supposed to be a purely editorial exercise:  
https://github.com/sysapps/telephony/issues?state=open

> (If they are important to  
> clarify the spec for reviewers and implementors, it is better to do them  
> then publish, if they are for the convenience of the editors it doesn't  
> matter at all).

All changes we make are for the benefit of implementers and reviewers. I am an implementer, reviewer, and (accidentally) editor. In fact, I never intended to become an Editor of the spec - I accidentally fell into it through reviewing the document and writing my prototype implementation.   
> > > 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"?
>  
> No. I don't actually have much time to dedicate to this group (which is  
> why I am spending what I do have for now on trying to make it easier for  
> people like me to contribute more usefully).


We invite you to print out the Editor's draft and send us feedback. That would be really helpful.  

If you are asking us to slow down, then no - that won't happen. We have a great pace and good momentum behind the work.

> > All normative changes will be recorded there. That's already in the
> > Editor's draft.
>  
> Good (I didn't look so carefully at the editor's draft yet. Luckily, since  
> it says "nothing to see here" :) ).

Strange? Where did you get a 404?  
>  
> > > 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.
>  
>  
> Sure. Except that would come at the cost of more important things I have  
> to do.

I really can't help you with your time management and priorities, Charles. I really value your opinion and want this to work for you and everyone else. Help us find ways of helping you, but we need to do this in a way that doesn't affect the momentum we already have.
> > > 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.
>  
>  
> Right. But I don't have the time.
Then you have to trust that we are doing the right thing. I also can't track everything that, for instance, is happening with Promises, Nav Controller, or ES6 - but I trust that those that are doing the work are capable human beings working to the best of their ability to produce something good.  
> Asking an engineer who drops to about  
> 25-50% efficiency if s/he has to work in english to follow the process  
> live is more like an effective DoS than a way to help us.


The working language of the W3C is, for better or worst, English. If you have suggestions about what can help there, I'm all ears.  
  
>  
> > Between the Editor's we are actually kicking some serious ass and making
> > some awesome progress filing and closing bugs.
>  
>  
> Excellent. That's why you are the editors, so I am glad to hear you're  
> doing a good job. It seems redundant to have everyone in the world  
> following over your shoulder like a bunch of micromanagers.

I agree.  Everyone has the option to op-in or out of the following development. And it's why we have the Changes section now.  
> So getting the  
> all-important understanding and feedback from people who will develop this  
> should be done some other way.

Again, I'm all ears. We've never provided more ways for people to get involved.

1. Github.
2. Editor's drafts  
3. TR drafts  
   
> (In particular, it is a great idea to get feedback from people who  
> implement *without* following the spec's development closely.

Yes, but we also don't want to waste those people's time. The process we decided on was that we publish a FPWD and we send the specs to public-script-coord to review (i.e., to idiomatically rip to shreds). So there is a right time to involve the right people. For telephony, that time is not now and the Editors are the ones on the best position to make that call, IMO.  

> Lacking the  
> shared assumptions of the editors, they are the ones most likely to  
> actually find where undocumented assumptions lead to amibguities - ).

I think the Editors are very much aware of that. But it's the Editors that need to make the call when the spec is ready for wider implementer review.  
  
> > 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.
>  
> No, I *really* don't - although I note Dave offered :)


I'll set something up with Dave. Will try to publish bi-weekly when it makes sense.  
  
> On the other hand, linking issues to where they are tracked live is really  
> helpful, so don't stop that :)

Filed bug on Respec:
https://github.com/darobin/respec/issues/241

Will try to work on that before the F2F.  

> > 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;)).
>  
>  
> I think bi-weekly is as fast as you want to get. It takes time to schedule  
> a review. The people you want to do the reviewing aren't going to look at  
> it every day, and that's a Good Thing™.

> They might spend 1/2 a day or more  
> on a review. That's valuable time that you can't have as often as you can  
> get 10 minutes from a WG member for a particular point, or a quick IRC  
> chat with a developer you happen to know well.
>  
> This is the difference between making a good spec for the people you are  
> working with directly, and making a good standard. In the latter case,  
> your key audience must include people who you never know, and if you do it  
> well enough they never need to look at the inner workings of the group  
> developing the spec. A good handful of careful reviews along the way are a  
> good proxy for real knowledge abut how this audience will react (and by  
> definition it is very very difficult to get real knowledge). I'm not  
> trying to slow down your editor's drafts - the fact that they evolve  
> rapdily is great. But there needs to be a slower-moving channel for  
> review.  

I agree that reviewers should not have to follow the goings on in the group (though things work better when interested parties are highly involved), but I don't agree that snapshots matter. I think it's fine to pick up the version that is up online at any given instance and review it.  
> This can be faster than the "lawyers review" channel of  
> FPWD/LC/Rec, unless that is fast, because the target is "dark  
> implementors" (in the sense that they are effectively unseen by the  
> Working Group) - and making them "only-mostly-dark". Note that a big  
> reason for them to be dark is that they are working in translation - and  
> in that case wanting them to follow the group on an hourly or even daily  
> basis is likely to be a very inefficient use of time.
>  

I think you are characterizing this as being a more extreme situation than it actually is. Reviewing either a printed version or a version that is on the screen for some period of time (e.g., 48 hours or even a week) is fine. Using "oh, it may change in that time" is not a good excuse for not doing a review. Also, a reviewer who is actually intending to give feedback could simply email the group or the Editor's asking them when would be a good time to do a review and if any foreseen changes are coming up. The potential changes to the spec are all documented in the issue tracker, usually days to a week in advance (e.g., evaluating the use of promises has been open for two months).  

Anyway, I'm happy to continue to work towards improving the process for everyone. If your (or anyone's) reviewers in particular are having issues, I'm happy to make myself available in whatever way I can to help them with reviewing or keeping up with changes.   

Kind regards,
Marcos

Received on Monday, 24 June 2013 13:08:41 UTC