Re: Comments on 6 December 2013 Chapter 7 draft

On Mon, 09 Dec 2013 19:03:30 +0400, Ian Jacobs <ij@w3.org> wrote:

> Here are some comments on the draft chapter 7 [1] announced [2] on 6
> December.

Thanks.

> I've sent these comments in one email. Let me know how you wish to
> handle them (whether adding to the process issues list yourself of
> having me do it).

I prefer to get things into issues. I'll raise them from this email,  
because since you did your review I've made a new draft with the content  
re-ordered. I've also noted here the new section numbers (and apologise  
again that the table of contents links are broken).

In future, please feel free to directly raise issues - it saves me a  
little bit of work...

> [1] https://dvcs.w3.org/hg/AB/raw-file/59ee28366bf8/tr.html
> [2]  
> http://lists.w3.org/Archives/Public/public-w3process/2013Dec/0026.html
>
> - General requirements for Technical Reports

Now 7.2.2

>   Because of the patent policy, it is important that readers know
>   whether a group expects a document to become a Recommendation or not.
>   Also, when a group has been chartered to produce a Recommendation
>   but then plans change, it is important that a document state the
>   new expectation.
>
>   The draft says that the status section "should include expectations
>   about next steps, and". I don't think that's strong enough as
>   stated.  I think this should be a MUST to send clear signals relevant
>   to the patent policy.

Raised issue 74 for this. By the way I think the change is a sensible idea.

> - 7.4.1.a First Public Working Draft

Now 7.3.1

>   The draft says: "The Director must announce the publication of a
>   First Public Working Draft publication to other W3C groups and to
>   the public." In practice we do not announce publications to other
>   W3C groups other than via the home page (which is to the public).  I
>   have also not heard requests for a second type of announcement to
>   groups. Therefore, I propose to delete "to other W3C groups and"

Raised issue 7. Note that I disagree, and would like to have mail sent at  
least to chairs@

> - 7.4.1.b Revised Public Working Drafts

Now 7.3.2

>   "If 6 months elapse without significant changes to a specification a
>   Working Group should publish a revised Working Draft, whose status
>   section should indicate reasons for the lack of change."
>
>   If groups are finding it not worth their time to publish, asking
>   them to publish may not have the desired effect. I propose instead
>   that the WG SHOULD send a status update to the webmaster and request
>   that the Webmaster update the most recent draft with the status
>   update.

As far as I know, there is only one way to publish a new draft - but if  
you allow groups to send some edit to the Webmaster and make him or her  
responsible for updating the draft, I don't think that changes anything we  
have done here.

If groups have done nothing, unless they already set expectations that  
nothing would happen in describing next steps as per the issue above, they  
only need to agree to publish a new draft with revised expectations about  
next steps.

I think we can remove the last clause of this requirement. But I think the  
rest of it should stay. And if publishing is really painful, we should fix  
that - it is a critical part of making W3C work, so just telling people  
not to publish seems counter-productive to me.

I haven't raised an issue - if you disagree with me, please raise one.

> - 7.4.1.b Revised Public Working Drafts

Now 7.3.2

>   All the elements in the list of requirements for publishing a
>   revision are of the same "type" except the last one:
>
>      "may request publication of a Working Draft even if its content
>       is considered unstable and does not meet all Working Group
>       requirements."
>
>   Indeed, it sounds much like the first paragraph of the section:
>
>      "A Working Group should publish a Working Draft to the W3C
>      Technical Reports page when there have been significant changes
>      to the document that would benefit from review from beyond the
>      Working Group. "
>
>   Both of them refer to context rather than prerequisites. I recommend
>   moving the last bullet of the list as a sentence of the first
>   paragraph.

This is editorial, but I have actually moved the two requirements that  
apply to all working drafts to the beginning of the section on Working  
Drafts.

> - 7.4.2 Candidate Recommendation

Now 7.4

>   In general I find challenging the relationship between the "general
>   requirements for advancement" and the specific requirements for
>   each transition type. At times there are new requirements, at times
>   there are changes from "SHOULD to MUST". I am wondering whether
>   pulling the "general requirements" out is useful at this point.
>
>   In this section, one bullet is:
>
>    "If the document has previously been published as a Candidate
>    Recommendation, must document the changes since the previous
>    Candidate Recommendation, "
>
>   It is not clear to me how this differs from the general requirement:
>
>    "must provide public documentation of all substantive changes to
>    the technical report since the previous publication. The community
>    also appreciates public documentation of minor changes."
>
>   You might have something specific in mind, but as written I can't
>   determine the difference. Or if the difference is "documenting all
>   changes" instead of "documenting substantive changes" then I'm not
>   sure that difference is necessary to justify the specific bullet.
>   If the consensus ends up being that it is necessary, then I think the
>   difference from the general bullet needs to be clearer.

The difference is documentation of *all* changes rather than just  
substantive ones. But I am not sure it is important enough to keep the  
nearly-redundant requirement - and I agree that if we do, it should be  
made clearer what the difference is.

I've raised issue 76.

> - 7.4.3 Publication of a W3C Recommendation

Now 7.5

>   I am not sure I have understood what is supposed to happen here.
>
>   It seems like something happens between publication of a CR
>   and publication of a Recommendation.
>
>   First, there is no rationale to explain why there is an event
>   between publication of CR and publication of a REC.

Raised issue 77.

This is part of the de-emphasis of Proposed Rec as a formal stage, and it  
really does need some more explanation. My assumption is that there is a  
director's call, in general, but not necessarily a new publication. There  
must be an announcement to the AC that there is a deadline for their  
review...

>   Second, if the event involves a publication, it is not clear
>   to me what the label on the document would be.

Right.

>   Finally, I think the mixing of PER and "for all Recommendations" in
>   this section is a source of confusion, especially since some of the
>   bullets in the "for all Recommendations" list actually seem only to
>   apply to PER (e.g., the second and third bullets). I urge you to
>   split the descriptions of "REC after CR" and "REC after PER" in
>   clean sections. It may be a little longer but I think will reduce
>   confusion.

I *think* I already did this in the latest draft - please check (it's now  
section 7.5).

> - 7.4.3 Publication of a W3C Recommendation

Now 7.5

>   The phrase "review period" appears in these bullets although it is not
>   mentioned earlier. The phrase used earlier in the list is "deadline
>   for comments." Given that the word "review" is used in the section
>   "wide review." I would recommend changing "deadline for comments" to
>   "MUST specify a review period".

Seems editorial, but I changed the other way, to use "deadline" more  
consistently, because I think it is clearer what a deadline is than what a  
review period is.

> - 7.5 Publishing a Working Group or Interest Group Note

Now 7.7

>     "W3C must publish any unfinished specifications on the
>      Recommendation track as Working Group Notes. "
>
>  I suggest we change that to SHOULD. The sentence that follows says
>  SHOULD for a different scenario:
>
>    "If a Working group decides, or the Director requires, the Working
>     Group to discontinue work on a technical report before completion,
>     the Working Group should publish the document as a Working Group
>     Note."
>
>  It is not clear to me that the rationale of "closing the group" is
>  materially different from any other piece of rationale the Director
>  might have.

This has been discussed before (in an AB meeting before we made the  
discussion open). The rationale for the difference is that there is no  
effective way to require a Working Group to publish a Note shelving their  
work, especially in the case where they have been told to shut down. But  
it is feasible, and IMHO reasonable, to insist that W3C team do it.

If you want to re-open the discussion, please raise an issue.

> - 7.5 Publishing a Working Group or Interest Group Note

Now 7.7

>   "must record the group's decision to request advancement, and"
>  I tend not to think of "going to Note" as "advancement." Indeed,
>   in some cases it downgrades a specification. While "advancement"
>   might simply mean "moving to the next state of the state machine"
>   I suggest changing the phrase to "to request publication as a Note."

Agreed, and this is editorial. It will be in the next draft.

> - 7.5 Publishing a Working Group or Interest Group Note

Now 7.7

>   Editorial: For brevity change the last paragraph of 7.5 to:
>
>   "The W3C Patent Policy [PUB33] does not specify any licensing
>   requirements or commitments for Working Group Notes, only for W3C
>   Recommendations."

Agreed, and this is editorial. It will be in the next draft.

> - 7.6.1 Errata Management

Still 7.6.1 (!)

>  "Working Groups MUST track errata on an "errata page."
>
>  Please delete "MUST". It is not clear to me that there are any
>  consequences in practice, or any monitoring. I think it is more
>  appropriate here to say that "Working Groups track errata on an
>  errata page." I suggest indicating that the errata page is public.
>
> - "A Working Group must report errata page changes to interested
>   parties,". I suggest SHOULD here as well. It is not clear to me that
>   WGs track all the interested parties and therefore we have no way of
>   knowing whether they have satisfied the requirement. If you want to
>   add that they should contact parties outside the WG that reported
>   the erratum, that's good practice as well.

Raised an Issue. Both of these come from the existing process, but I agree  
that the requirement is unenforceable (especially when the Working Group  
has been disbanded...)

> - 7.7 Rescinding a W3C Recommendation

Now 7.8

>   Editorial: Change
>
>   "To deprecate part of a Recommendation, W3C follows the process for
>   modifying a Recommendation."
>
>   to
>
>   "W3C only rescinds entire specifications. To remove part of a
>   Recommendation, W3C follows the process for modifying a
>   Recommendation."

Agreed, and this is editorial. It will be in the next draft.

> - 7.7 Rescinding a W3C Recommendation

Now 7.8

>  I understand the process this way:
>
>   1) Public discussion about a spec happens. The result of public
>      discussion is that we realize the spec should be rescinded.
>  2) A WG REQUESTS that a spec be rescinded.

That step is optional. It may be, for example, that there isn't a Working  
Group to make the request. Hence the "or"

>   3) The Director elects (either on his own or based on a request) to
>      PROPOSE that the spec be rescinded, after which there is a
>      "review period."
>
>   4) At the end we announce the result.
>
>
>  There is confusion in this section about requests and proposals. For  
> example,
>  the document says:
>
>    "In addition a Working Group proposing to rescind
>      must show that the request to rescind has received wide review"
>
>  What wide review are we talking about? Does this mean that there
>  needs to have been some discussion BEFORE the group requests that the
>  spec be rescinded? If so then the second bullet, which says "the
>  request to rescind is based on public comment" covers that. If "wide  
>  review" refers to the review period about to start, then I don't
>  understand.

It is the former. I raised issue 77, but I propose to delete the second  
bullet, not the first.

>  I suggest this section be adjusted so use this language:
>
>    * A WG REQUESTS that a spec be rescinded
>    * The Director PROPOSES (to the community) that the spec be rescinded.

Yep, Editorial and it shall be done.

> That should eliminate the need to say "a Working Group or the
>  Director" since only WGs "request" and only the Director "proposes".

Hmmm. Since a WG can request on their own, *or* the director can proposed  
without a WG request, we stil need an or there. But I'll try to clarify  
the language a bit more.

> - 7.7 Rescinding a W3C Recommendation
>
>    "specify the deadline for review comments, which must be at least
>     four weeks after publication"
>
>  I don't think there is (or should be) any publication as part of the
>  process for proposing to rescind. Please change this text to:
>
>    "specify the deadline for review comments, which must be at least
>     four weeks after the proposal to rescind."

Yeah, I think this might be a copy/pasta error, and is editorial. I'll  
make the change.

>  After the decision to rescind, we might publish a "stub"
>  specification or we might just include a status update. I don't know
>  if the process document needs to say in more detail HOW the
>  information that a spec has been rescinded is communicated.

Agreed.

Thanks for your review.

cheers

Chaals

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

Received on Thursday, 12 December 2013 10:50:57 UTC