Speaking as the person who put this change in the process…
11.11.2014, 01:03, "Ian Melven" <ian.melven@gmail.com>:
i agree with your assessment of the positive value of Last Call and would support maintaining it informally
+1
On Mon, Nov 10, 2014 at 1:54 PM, Brad Hill
<hillbrad@fb.com> wrote:
The W3C has a new, more streamlined process for Recommendation Track documents:
There is no longer an explicit "Last Call" stage required.
With my hat on as chair, I feel that Last Call is a useful phase of the process. Our group works asynchronously, our features have impact on features defined by other WGs, and historically a Last Call announcement has been very fruitful for us in terms of receiving input from the broader community. It is a signal to someone with limited time to devote to review that new features are not planned and things are approaching their final shape.
What do other members (and especially editors think)? Should we abandon the Last Call in WebAppSec, or maintain it informally as part of our group's culture?
The point of a "last call" is to say that as far as we can tell, we're done. If we missed something, you'd better tell us now.
But we shouldn't have missed something. If we publish regular drafts, clarify what we are doing and point to the pieces we have done at each "stage" by putting out Working Drafts with a request for review of the things that are new, we *should* ave got comments as we went.
By the time things get to last call, if we have been getting implementation testing as we go, the cost of a change is already pretty high. (Like make, where the story is that the developer refused to fix a perceived bug because it would upset the existing users. All 12 of them).
Last Call had a specific meaning for the Patent Policy, which meant if you changed anything substantive you had to return to Last Call. Even if it was obvious to everyone n the group that the change made sense, and came after a long CR and multiple implementations.
informally, a "last call" is useful - to the point that groups did a "last call before we go to Last Call". ideally, you get testing as you develop the spec, and when you get to Last Call there are no big surprises. So informally, nothing much changes - you tell the community where you are at, they review and test, and you go through in a straight line.
The difference in the new process is that you don't go back a step in the process. If your CR produced real issues, you fix them and make a new CR. If there aree lots, you hadn't done a very good job when you asked to go to CR. If you did do a good job, you just continue on.
cheers
Chaals
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at
http://yandex.com