Re: status of phase 1 work items?

On Fri, 21 Jun 2013 21:25:10 +0200, Marcos Caceres <w3c@marcosc.com> wrote:

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

Oh, OK.

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

You claim the spec isn't ready for implementation (which seems like  
over-simplification to the point of nonsense - first because I believe  
your *starting point* was an implementation, and second because I believe  
that implementation and testing are critical to the development process).

Everyone knows that a snapshot draft is a stabilisation point that may be  
missing some of the latest and greatest thinking. 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.

If you are merely making editorial changes, then it won't matter so much  
which end of the change the review comes. (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).

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

> 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" :) ).

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

Right. But I don't have the time. 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.

> 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. So getting the  
all-important understanding and feedback from people who will develop this  
should be done some other way.

(In particular, it is a great idea to get feedback from people who  
implement *without* following the spec's development closely. Lacking the  
shared assumptions of the editors, they are the ones most likely to  
actually find where undocumented assumptions lead to amibguities - ).

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

OK. I'll look for it in the next milestone release.

>> 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).
[...]
>> 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.

Hmmm. That seems like far too long, but even then I would encourage you to  
publish a TR draft at least every couple of months.

> 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 :)

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

A snapshot for stability can afford to be a few days out of synch. In any  
event it will be as soon as you start editing again. This means you need  
to think a bit about where to tap the snapshots, but it sounds like you're  
trying to do stuff for the that isn't actually necessary.

On the other hand, linking issues to where they are tracked live is really  
helpful, so don't stop that :)

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

cheers

Chaals

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

Received on Sunday, 23 June 2013 20:45:14 UTC