RE: Action-140: Obsoleting a recommendation, one more minor fix

David,
I accept your arguments below and agree that two separate calls for review are not needed in the case of a binary (yes/no) decision

Steve Z

From: singer@apple.com [mailto:singer@apple.com]
Sent: Friday, June 24, 2016 5:27 AM
To: Stephen Zilles <szilles@adobe.com>; Revising W3C Process Community Group <public-w3process@w3.org>
Subject: Re: Action-140: Obsoleting a recommendation, one more minor fix


On Jun 24, 2016, at 6:21 , Stephen Zilles <szilles@adobe.com<mailto:szilles@adobe.com>> wrote:


Yes, I also do not like the serialization of wide review followed by a publicly visible vote (and opportunity for public comment). We should do enough homework that the formal step can be run all at once.

SZ: this violates a basic principle of the REC track process (and really of the W3C); that is, doing a public call for comments prior to an AC Reivew. For most REC Track processes, you cannot get to an AC Reivew without wide Public review having been accomplished.

This is wide review of a binary decision, not of a complex specification. We are also trying to do things more agilely; running the internal review and the external review in parallel should be perfectly do-able.

It’s not a “basic principle” at all. The basic principle is that we make informed decisions.


The point of this is to allow response to the comments to be created and (hopefully) accepted prior to an AC Review.

Why prior?


What good is an AC Review the processes a document that receives comments that totally change the Review. It is better to separate the Call for Comments and the AC Review.

We are talking about a binary decision here; yes or no. If the Director receives external evidence that obsoleting is a mistake, or the reasons to rescind are wrong, or even if he thinks that it’s no longer clear cut, he can say “no”, and we’re exactly where we were, and we can think again. I doubt anyone outside the W3C is going to notice a proposal to obsolete anyway; the whole point is that as far as we can tell, no-one uses or cares about this spec., so sending notices to all those who care will necessarily be an empty set.


There is clearly no need to rush Obsoleting or Rescinding a REC.

There is a need for simplicity. Make it complicated enough and it’ll never happen, which is not what we want.


Separating Chairs and Public review from AC Review would avoid having to repeat the AC Review when comments that require a change to the proposal are received.

I can’t imagine what change one can make to a proposal to obsolete.


I would agree that proposals to Obsolete or Rescind a REC (where the REC is known and has not varied since adoption) have less scope for comments than a proposal to create a REC (in which almost anything could trigger a comment). But, if no comments are received in the Public review, then you have only added 4 weeks to the Process of Rescinding/Obsoleting a REC.

And the need to do a separate public review, and document that you have done it.


I would prefer that the text say,

“The Director must announce the proposal to retire a W3C Recommendation to other W3C groups using at least the mailing list for all chairs and the public. The announcement:
… [ all the caveats, including a deadline at least 4 weeks hence]
“Upon completion of this review and after all comments have been processed, The Director must announce the proposal to retire a W3C Recommendation to other W3C groups and to the public, and must begin an Advisory Committee Review on the question of whether the specification should be retired.”

[The last text was created from text for 6.4 Candidate Recommendation by replacing  “the publication of a Candidate Recommendation” with “the proposal to retire a W3C Recommendation” and replacing “the specification is appropriate to publish as a W3C Recommendation” with “the specification should be retired”. ]
“


For the part about if there’s dissent the Director has to respond publicly.  Isn’t that the same for every Director Decision after an Advisory Committee Review?  If so, all those cases should refer to a section that says that.

That would be good.

SZ: and that is what my proposed revision [1] to 7.2  as modified to address Daniel Glazman’s concerns [2] and related paragraphs would do
[1] https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0016.html

[2] https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0061.html





This has the line about the AC can appeal.  If the other proposal to say the AC always can appeal, then it doesn’t need to be repeated in all these separate sections.

Agreed, I would support an overall process change that
* said all formal Director decisions can be appealed
* defined the appeal procedure
* removed mention of appeals where they are spattered around the document now

This would simplify.
SZ: It would not simplify at this point in time. That is because we would have to go through the Process Document and identify “formal Director’s decisions”. The effort to identify “W3C Decisions” has already been taken and, therefore, it is simpler if we are to have a vote on Process changes in 2016 to stay with that text. Note also that there are three kinds of “appeals” [3] (Group Decisions, Submission and Advisory Committee), one of which the Director “formally” decides. It does not make sense to appeal these decisions.
[3] https://lists.w3.org/Archives/Public/public-w3process/2015Jul/0027.html




Actually, there can be a section on Director’s judgment of consensus after AC Reviews and that section could include the part about if there is dissent and also more generally the AC can appeal any decision. All of that applies to all Director Decisions after Review.
SZ: This is what [1] and [2] above attempt to do.

From: singer@apple.com<mailto:singer@apple.com> [mailto:singer@apple.com]
Sent: Thursday, 23 June, 2016 05:01
To: W3C Advisory Board <ab@w3.org<mailto:ab@w3.org>>; Revising W3C Process Community Group <public-w3process@w3.org<mailto:public-w3process@w3.org>>
Subject: Action-140: Obsoleting a recommendation, one more minor fix

The AB realized that we might, just possibly, make a mistake and obsolete something that we weren’t aware is actively used; or we might obsolete something and then later it starts getting traction and being used. It should be possible to reverse obsoletion, though we hope and expect that this will be rare.

The attached is a revision which adds the sentence:

"Obsoletion may be reversed, using the same process as for obsoleting a Recommendation. “

and then at the start of the two options, add that, viz.:

"The announcement:

must indicate that this is a Proposal to Rescind, or a proposal to Obsolete, or a proposal to reverse Obsoletion of, a Recommendation;”

Yes, I am aware that other parts of the text could be made more complex and more explicit about reversal, but I don’t think it’s worth it: we can surely work out what the intent of the text is in the rare case of reversal.

Yes, I am aware that we might end up with a case where, with the new knowledge, a decision to Obsolete would not pass, but the decision to reverse obsoletion also does not pass.  However, I think making the reversal process “reversal happens if it can be shown that obsoletion would have failed” is too complex to describe easily. I hope the community ‘does the right thing’ and we don’t get into this case.


David Singer
Manager, Software Standards, Apple Inc.

David Singer
Manager, Software Standards, Apple Inc.


David Singer
Manager, Software Standards, Apple Inc.

Received on Saturday, 25 June 2016 00:18:00 UTC