Re: snapshots in CfC Re: CfC: Publish a FPWD of "Requirements for Powerful Features"

Thanks for the feedback.  I'm inclined to err more on the side of "active" consensus on editorial matters for an FPWD or WD transition, so long as for an FPWD changes don't introduce significant changes that would expand the scope of the Call for Exclusions.


From: "<>" <<>>
Date: Friday, November 28, 2014 at 8:18 AM
To: Mike West <<>>
Cc: John Kemp <<>>, Bradley Hill <<>>, Mark Nottingham <<>>, "<>" <<>>
Subject: Re: snapshots in CfC Re: CfC: Publish a FPWD of "Requirements for Powerful Features"

28.11.2014, 14:28, "Mike West" <<>>:
I take the general point; CfCs should be tied to specific documents, not whatever happens to be the last thing I uploaded. I'll ensure that happens next time I poke a the list for a formal measurement of consensus.

Yeah, that's great. Meanwhile let's make a mountain out of this molehill…

That said, tip-of-tree has some nice improvements over Monday's document, based on feedback from both you and Brad. I'm happy to put up a snapshot from Monday, but I'd prefer to publish a snapshot from today.

Works for me.


Perhaps we can chat about what makes sense on Monday's call.


Mike West <<>>
Google+:<>, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Tue, Nov 25, 2014 at 5:54 PM, <<>> wrote:

25.11.2014, 18:13, "John Kemp" <<>>:
> Hi Chaals,
> On 11/25/2014 06:54 AM,<> wrote:
>>  TL;DR: Please go ahead.
>>  24.11.2014, 23:20, "Mike West" <<>>:
>>>  On Mon, Nov 24, 2014 at 9:00 PM, Brad Hill <<>
>>>  <<>>> wrote:
>>>      I've made a pull request to formalize the tone a bit.  Pending that or
>>>      similar updates by the editor, I support the publication of this
>>>      draft.
>>>  Thank you! I accepted the pull, cleaned up a few bits, and
>>>  republished:<>
>>  It is really helpful in a call for consensus to have a URL to a
>>  snapshot.
> FWIW, you can review the commits made, individually if you so desire, by
> going to

Sure. I did that and in this case it seems fine to me. But given a change of a few dozen lines, it is not always clear what a "consensus" is if it is determined by statements made about different documents at different times - it's generally easier to agree on something if everyone is agreeing on the same thing. For people on a differenc

>>  Consensus to publish "whatever was there when I looked" is
>>  actually seriously weakened if you can change what is there (this is
>>  security 101, right?).
> One thing that might improve the process is even for the spec editors to
> work in branches and issue Git pull requests back to master. The pull
> requests can be reviewed as a whole, or by looking at individual
> commits, prior to the reviewed pull request being merged to master.

It's simpler than that - in general, people can follow the entire history if they want to see each commit, or look at review drafts if they don't have that kind of time.

It's just a case of not mixing the two…


> - johnk
>>  That said, I think the changes I saw (up until about 15 minutes before I
>>  sent this mail) were helpful, and support publishing either way.
>>>  <<>><<>>
>>>  Regarding the issue #2 you added, 'blob:' has an origin, as does
>>>  'data:'. What clarification do you think is necessary in the algorithm
>>>  in order to resolve the issue?
>>  cheers
>>  Chaals
>>  --
>>  Charles McCathie Nevile - web standards - CTO Office, Yandex
>><> - - - Find more at<>

Charles McCathie Nevile - web standards - CTO Office, Yandex<> - - - Find more at<>

Charles McCathie Nevile - web standards - CTO Office, Yandex<> - - - Find more at<>

Received on Monday, 1 December 2014 17:21:14 UTC