Comments on 6 December 2013 Chapter 7 draft

Hi Charles,

Here are some comments on the draft chapter 7 [1] announced [2] on 6
December. It's great to see things coming along.

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

Ian

[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

  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.

- 7.4.1.a First Public Working Draft

  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"

- 7.4.1.b Revised Public Working Drafts

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

- 7.4.1.b Revised Public Working Drafts

  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.

- 7.4.2 Candidate Recommendation 

  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.

- 7.4.3 Publication of a W3C Recommendation

  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.

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

  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.

- 7.4.3 Publication of a W3C Recommendation

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

- 7.5 Publishing a Working Group or Interest Group Note

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

- 7.5 Publishing a Working Group or Interest Group Note

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

- 7.5 Publishing a Working Group or Interest Group Note

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

- 7.6.1 Errata Management

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

- 7.7 Rescinding a W3C Recommendation

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

- 7.7 Rescinding a W3C Recommendation

 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.

  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.

 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.
     
 That should eliminate the need to say "a Working Group or the
 Director" since only WGs "request" and only the Director "proposes".

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

 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.
 

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                                          +1 718 260 9447

Received on Monday, 9 December 2013 15:03:38 UTC