- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Sun, 07 Aug 2016 12:09:11 +0200
- To: "Ian Jacobs" <ij@w3.org>
- Cc: public-w3process@w3.org
Hi Ian, On Sat, 06 Aug 2016 00:46:08 +0200, Ian Jacobs <ij@w3.org> wrote: > Chaals, > > I read Process 2016 (3 Aug draft [1]) and have some suggestions. Thanks for these. Please see my initial reactions - where I have said something seems reasonable, I am likely to do it unless subsequent discussion suggests otherwise, or I change my mind - in which case I wil explain something. > Sorry for the length; the Proc Doc is also long. :) Not as long as it was, but I am still looking at places to trim… :) > [1] https://dvcs.w3.org/hg/AB/raw-file/cfef536bff0d/cover.html > > ================ > 1 Introduction > > -------- > "the W3C equivalent of a Web standard." This struck me as odd on > this read; equivalent to what? > > Proposed: "the W3C expression of a Web standard." That seems equally awkward. I don't think this is a critical sentence, so I'll wait to see what happens in the general review before I think about this change. > -------- > "(e.g., Web services)". This feels like a dated example. > > Proposed: delete the parenthetical. Agree. It's purely editorial. > ================ > 2.1.2 Membership Consortia and related Members > > "who have individual persons" and > "who have organizations as Members" > > Proposed: s/who/that Agreed. It's editorial and in line with common W3C style to the extent such a thing exists. > =============== > 2.1.3.2 Advisory Committee Meetings > > "The number of Full and Affiliate W3C Members." There are new > Membership levels, so this feels a bit off. > > Proposed: "Number and profile of W3C Members" I think there should be some clearer wording, but in principle I agree that this should change to reflect reality. > =============== > 2.4.1 Technical Architecture Group Participation > > "Appointees are not required to be on the W3C Team." This was surely > written long ago and doesn't really speak to actual practice. I do > not recall a Team appointee, and I also think the Director in > practice wants to populate the TAG with non-Team. > > Proposed: "Appointees SHOULD NOT be from the W3C Team." I recall a number of team appointees. And this is a substantive change. And the director should be free t appoint whomever he likes - if W3C can't find a way to make a Team member available, when the director considers that person best-qualified for the place, I think that's a problem. If anything I would suggest that the change be the other way - the restriction on not nominating a Team Member without W3M approval should be removed. If the membership think that a particular team member is one of the (typically two or three in any given year) best people to represent them on the TAG I find it galling that W3C would not work out how to respect that request from the membership. > =============== > 2.5.3 Advisory Board and Technical Architecture Group Vacated Seats > > "the Chair asks the participant to resign." I think this is a bug. > Because these people are elected, I don't believe this should be > a "TAG Chair" right but rather a "Director" right. > > Proposed: "the Director removes the participant from their seat." I support the proposed change, but I think it should be given a wider airing. Also, I don't think it's ever been used once a person has got into the TAG. I'd be in favour of the TAG and AB applying some "good standing" requirements. > =============== > 3.1.1 Conflict of Interest Policy > > "clearly a function of the individual's affiliations". This sounded > more editorial than necessary. I believe this came from the previous editor, but I think it is an accurate statement. > Proposed sentence replacement: > > "The ability of an individual to fulfill a role within a group > without risking a conflict of interest depends significantly on the > individual's affiliations." I don't think so. I think it is a function of the individual's interests. But I don't particularly object to changing this text. > ================ > 4 Dissemination Policies > > "maintains a calendar [MEM3]" > > That calendar is deprecated in favor of a public calendar. That is: the > W3C staff no longer maintains a "member only" calendar. > > Proposal: > - Delete MEM3 in 12.2 > - Add a new reference to the public calendar in the public > resources and update all references from MEM3 to the new one. > Public calendar: http://www.w3.org/participate/eventscal OK. > ================ > 5.1 Requirements for All Working and Interest Groups > > "Existing charters that are not yet public must be made public when > next revised or extended (with attention to changing confidentiality > level)." I believe there are no more such charters and never will be. > > Proposed: Delete the sentence. I wondered about that when I was reviewing. I agree with the proposal, but I would request that the Team actually *check* whether there are any such charters before making the change. > ================ > 5.2.4 Call for Participation in a Working Group or Interest Group > > -------- > "After a Call for Participation, any Member representatives and > Invited Experts must be designated (or re-designated)." > > I believe Team practice is slightly different: > > a) If the charter involves no new Rec-track deliverables (and thus > there are no new patent obligations), participants are informed > of the new charter but are not required to rejoin. > > Otherwise, Members are asked to rejoin. > > b) Regarding Invited Experts, I don't exactly know what happens, > including whether they must re-apply to participate. > > Therefore, I believe this sentence needs review. I believe Team practice is in fact to follow the Process. If not, since this hasn't changed in over a decade, I suggest that it is Team Practice that should be reviewed, unless there is explicit pressure to make a change to the Process. > -------- > "If a charter includes deliverables that continue work on a > document" > > This is the first time this concept appears in the document and it > is introduced with no explanation. The concept is developed in > 5.2.6 (see my comments about that section). The sentence in 5.2.4 > is repeated in section 5.2.6. I think 5.2.4 can be simplified to > just include a reference. > > Proposed: Replace > > "If a charter includes deliverables that continue work > on a document for which a Reference Draft or Candidate > Recommendation has previously been published (i.e there has > been an Exclusion Opportunity per section 4.1 of the W3C Patent > Policy [PUB33]), the Director must not issue a Call for > Participation less than 60 days after the beginning of the > Advisory Committee Review of the charter." > > with: > > "See section 5.2.6.1 for information about a Call for > Participation in a Working Group that has taken up a > specification from another group." I disagree. It is spelled out here because this is the first time someone reading in order will come across it. If anything I would make the reference *backward*, but I believe it is reasonable to keep the two statements. On the other hand, others have expressed opinions on both sides of that question so let's see what comes out of the review overall and do that. > ================ > 5.2.6 Working Group and Interest Group Charters > > --------------- > "Intellectual property information. What are the intellectual > property (including patents and copyright) considerations affecting > the success of the Group? In particular, is there any reason to > believe that it will be difficult to meet the Royalty-Free > licensing goals of section 2 of the W3C Patent Policy [PUB33]?" > > This text is disconnected from reality. Our charters include > boilerplate text about the Patent Policy and, on occasion, > document licensing information. I believe the questions quoted > above, while they may be considered while discussing the work, > never result information actually included in the charter (which > is what this bullet list is about). > > Proposed: Replace the bullet with: > > * Intellectual property information. Include information about > the governing patent policy and document license. I disagree. The point of putting this into the requirements was so that charters would provide information to members, instead of them being asked to commit to something, unaware that e.g. some important rights-holding organisation has privately insisted this work be structured to make it easier for them to avoid participating. Failure to inform members of the relevant information - even at the level of "we believe there are organisations who *claim* to hold patents in this area" - seems at best irresponsible. > --------------- > The new text about a group that takes up work from another > group is introduced without explanation. It is also sufficiently > long that it deserves its own subsection. I think that a lot of this section should be rewritten, but it took a lot of discussion to get to any kind of agreement, and I am loath to mess with it until people have seen it in place for a while. So I'm going to pass on this for now, but would like further suggestions on making the whole chapter clearer. > Proposed: > > - Create a new subsection 5.2.6.1 with title: > "When a Working Group takes up a Specification Initiated Under > Another Charter" > > - The section should start with "For every Recommendation Track > deliverable...." and end with "The Director must not issue a > call for participation less than 60 days..." > > - The section should be moved to the bottom of 5.2.6. That means > that the text "See also the charter requirements of section 2 > and section 3 of the W3C Patent Policy [PUB33]." would be > followed immediately by "An Interest Group charter may include > provisions regarding participation,..." and the rest of the > text of section 5.2.6. Then insert 5.2.6.1. > > - The following are editorial suggestions for the text of the > future 5.2.6.1: > > * Start by explaining what this section covers. Proposed: > > "From time to time, a W3C Working Group takes up work that > was initiated but not completed by another Working Group. > This section of the process document describes how W3C > ensures that the hand-off occurs in a manner consistent > with the W3C Patent Policy, and with minimal disruption > to the work." > > * "For every Recommendation Track deliverable that continues > work". I find it awkward to speak of a deliverable > continuing work. Proposed: > > <blockquote> > When the Director proposes that a Working Group take up a > Recommendation Track deliverable initially published under > any other Charter (including a predecessor group of the > same name) the charter MUST include the following > information for each deliverable: > > - The title, stable URL, and publication date of any > Adopted Working Draft that will serve as the basis > for work on the deliverable > > - The title, stable URL, and publication date of the > most recent Reference Draft or Candidate > Recommendation that triggered an Exclusion > Opportunity per the Patent Process > > - The stable URL of the Working Group charter under > which the most recent Reference Draft or Candidate > Recommendation was published. > </blockquote> > > ================ > 6.1.2 Maturity Levels > > "Rescinded Recommendation" is defined but "Obsoleted > Recommendation" is not. Meanwhile, 6.9 includes a definition of > Rescinded Recommendation that may not align exactly with what is > written here. > > Proposed: 6.1.2 include definitions for both terms, with enough > explanation so one can see here how they differ. That may reduce > what needs to be said in 6.9. I'm happy to provide a suggestion > if you'd like. Makes sense. I'm happy to propose a definition. > ================ > 6.2 General requirements and definitions > > "Please note that publishing as used in this document refers to > producing a version which is listed as a W3C Technical Report on > its Technical Reports page https://www.w3.org/TR [PUB11]." > > That sentence is a repeat of the first sentence in 6.1. > > Proposed: Delete the sentence in 6.2. I know I said it twice. But it's important, so the second one is to remind you that you should have paid attention. I prefer to have it in both places, but not strongly. I'll wait for more feedback, and see what we get. > ================ > 6.2.1 General requirements for Technical Reports > > "An editor must be a participant, as a Member representative, Team > representative, or Invited Expert". I'm not sure of the value > of spelling out the types of participant. > > Proposed: "An editor must be a participant (see section 5.2.1) in > the Group responsible for the document(s) being edited." Agreed. > ================ > 6.2.5 Classes of Changes > > s/Examples of changes in this class are/Examples of changes in this > class include:/ > > s/such changes do not belong to this class../such changes do not fall > into this class./ > > For the second edit note that: > - the first sentence of bullet 2 uses the phrase "fall into this > class" > which I suggest repeating here. > - double period => single period Seems reasonable. > ================ > 6.6 W3C Recommendation > > "The decision to advance a document to Recommendation is a W3C > Decision." This sentence is the only one of its kind in the document. > Section 7 defines W3C decision: > > "A W3C decision is one where the Director (or the Director's > delegate) has exercised the role of assessing consensus after an > Advisory Committee review." > > And if you follow the link to AC review you see a list of things: > > > * new and modified Working and Interest Groups, > * Proposed Recommendations, Proposed Edited Recommendations, > Proposal to Rescind a Recommendation, and > * Proposed changes to the W3C process. > > None of the other corresponding sections of the document have an > outright statement that "this is a W3C decision" other than 6.6. > > Proposed: Delete "The decision to advance a document to > Recommendation is a W3C Decision." as redundant. I'm more inclined to try to formalise the notion of decisions in the Process. One of my frustrations is that while it talks about decisions, it is rare that it describes what constitutes a decision being made - in particular, there is nothing that says what is a valid working group decision, although those are required for various reasons in different parts of the process. In the meantime, I'm opposed to your proposed change. > ================ > 6.7.2 Revising a Recommendation > > "Such publications may be called a Proposed Edited Recommendation." > > I am not aware that we call them anything else. Furthermore, I think > it would create confusion if we called the same thing by different > names, especially after a tradition of calling them PERs. > > Proposed: Change to: > > "Such publications are called Proposed Edited Recommendations." In some cases I believe they are called Proposed Recommendations. I'm not terribly concerned about this, but I will seek the advice of the Comms team - if they are or promise to become consistent, your proposal seems OK. > ================ > 6.8 Publishing a Working Group or Interest Group Note > > ------------ > "Working Groups and Interest Groups publish material that is not a > formal specification as Notes. ... as well as specifications ..." > > This paragraph includes mildly self-contradictory statements. > > Proposed: Change the paragraph (with new bulleted list) to: > > "Working Groups and Interest Groups MAY publish Notes for a > variety of reasons, including: > > * supporting documentation for a specification such as > explanations of design principles or use cases and requirements, > * non-normative guides to good practices, and > * specifications where work has been stopped and there is no > longer consensus for publishing them as Recommendations." Seems reasonable. > ------------ > "may remain a Working Group Note indefinitely" > > This section is about both WG and IG Notes. > > Proposed: Delete "Working Group" Yes. > ================ > 6.9 Obsoleting or Rescinding a W3C Recommendation > > ------------- > I think some of the terminology could be simplified. > > * I suggest using the word "Restore" when referring to undoing > a previous decision to rescind or obsolete a Rec. > * I suggest avoiding "obsoletion" and "rescindment"; see > concrete suggestions below. > > ------------- > "W3C may rescind a Recommendation, for example ..." > "W3C may obsolete a Recommendation, for example " > > Please start with an introductory sentence to frame the > discussion. > > Proposed: > > "From time to time, W3C may find it necessary to undo a > Recommendation. W3C uses a similar process but different > terminology to distinguish the severity of new advice > > - "Rescinded Recommendation": W3C no longer recommends > this technology and is extremely unlikely to restore it. > > - "Obsoleted Recommendation": W3C no longer recommends > this technology but there is a reasonable chance W3C > could restore it. > > W3C might rescind a Recommendation when: > > * W3C concludes it contains many errors that conflict with a later > version, or > * W3C discovers burdensome patent claims that affect implementers > and cannot be resolved; see the W3C Patent Policy [PUB33] and > in particular section 5 (bullet 10) and section 7.5. > > W3C might obsolete a Recommendation when: > > * W3C concludes it no longer represents best practices, or > * Industry has not adopted the technology and future > adoption seems unlikely." > > ------------- > Proposed: Change > > "Obsoletion may be reversed, using the same process as for > obsoleting a Recommendation, if for example a specification > is later more broadly adopted." > > to: > > "W3C uses the same process for obsoleting or restoring a > Recommendation." > > Note that you don't need to talk about the scenario since that's > already listed earlier. > > ------------- > Proposed: Change > > "The Director must begin a review of a proposal to obsolete, > un-obsolete or rescind a Recommendation when requested to do > so by any of the following:" > > to: > > "The Director MUST begin a review of a proposal to obsolete, > rescind, or restore a Recommendation when requested to do so > by any of the following:" > > ------------- > Proposed: Change > > "Any individual who made a request to the relevant Working > Group as described above, or the TAG if such a group does not > exist, to consider a Recommendation for obsoletion or > rescindment, whose request was not answered within 90 days" > > to: > > "Any individual who made a request to the relevant Working > Group as described above, or to the TAG if no such group > exists, to obsolete or rescind a Recommendation, > whose request was not answered within 90 days" > > ------------- > Proposed: Change > > "indicate that this is a proposal to Rescind, Obsolete, or > reverse the Obsoletion of, a Recommendation" > > to: > > "indicate that this is a proposal to Rescind, Obsolete, or > Restore a Recommendation" > > ------------- > Proposed: Change > > "For any review of a proposal to obsolete or rescind a > Recommendation the Director must:" > > to: > > "For any review of a proposal to obsolete, rescind, or > restore a Recommendation the Director must:" > > ------------- > Proposed: Change > > "publish a rationale for rescinding the Recommendation." > > to: > > "publish rationale for the proposal" > > (Since this process could be about obsolete and restore, too) Up to here I agree with you and would like to make changes along those lines. > ------------- > It should be possible for the Director restore a Rescinded > Recommendation. We cannot predict the future. Suppose the > Director rescinded a Recommendation because of a patent issue > but then that patent is invalidated. We might want to restore > the Recommendation. The Patent Policy says: > > "If the Recommendation is rescinded by W3C, then no new licenses > need be granted but any licenses granted before the Recommendation > was rescinded shall remain in effect." > > I believe that allows room to restore a Rescinded Recommendation > and get new licenses. I agree here too, although it *feels* different. But the process is in all cases the same - an AC review, and subsequent Director's decision. I wanted to call that out, before people reacted to the different feeling and suggested this was a different thing in practice. > ------------- > Proposed: Change > > "Note: the original Recommendation document will continue to > be available at its version-specific URL." > > to: > > "Note: W3C strives to ensure that any > Recommendation -- even obsoleted or rescinded -- > remains available at its original address with > a status update." > > (Notes: I've modified the text for consistency with similar text > in 6.2.1. The concept of "version-specific URL" is not defined > in the Process Document. Also, I think we should make > clear that we do intend to provide a status update.) Seems OK. > ================ > 7.1.1 Start of a Review Period > > "review form" > > This feels like an implementation detail to me. > > Proposed: s/The review form/The Call for Review/ Sounds reasonable. > ================ > 8 Workshops and Symposia > > According to the archives of W3C Workshops: > https://www.w3.org/2003/08/Workshops/archive > > There has been exactly one event in 21 years with the word > "Symposium" in the title. > > The Process Document does not indicate any material difference > between the two. > > Proposed: > * Remove the concept of Symposium from the Process Document > > Note that nothing prevents someone from organizing a W3C > Workshop with "Symposium" in the title. I hope to revise the various bits of content around meetings, symposia, workshops, conferences, and so on, next year. This isn't a high priority for now, so unless people scream I'll probably leave it alone and do it all at once. And in the meantime, you're tempting me to organise a W3C symposium… > ================ > 12.1 Public Resources > > * PUB25: The link is 404. Should be: > https://www.w3.org/2004/10/27-tag-charter.html Thanks. > ================ > 12.2 Member-only Resources > > * MEM3: See earlier comment; this has been deprecated > * MEM4: Now called "Process, Patent Policy, Finances Guide" > Meanwhile, there is a different resource called > "Member Intro and FAQ" https://www.w3.org/Member/faq.html > Perhaps MEM4 should be updated to point there (with the > current title) > * MEM9: This resource is now public and should be moved up to 12.1 Thanks. > ================ > OTHER COMMENTS: > > * I expected to see mention of the Code of Ethics and Professional > Conduct: https://www.w3.org/Consortium/cepc/ > > One place to include it: 3.1 Individual Participation Criteria. I think we can blame that on the editor's unprofessional conduct. You get what you pay for :) Yes, I think it is trivial to add a reference to it, and that it would be a good idea. > * Minor editorial: > > 6.1: s/member review/Member review > 6.1.2: s/as per/per > 6.1.2: s/review which begins/review that begins/ > 6.7.1: s/Working groups may/Working Groups may/ yup. -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Sunday, 7 August 2016 10:10:05 UTC