- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Tue, 02 Aug 2016 13:29:06 +0200
- To: "'Stephen Zilles'" <steve@zilles.org>, ab@w3.org, 茱滴 <hongru.zhr@alibaba-inc.com>
- Cc: "'Revising W3C Process Community Group'" <public-w3process@w3.org>
- Message-ID: <op.ylkfisb1s7agh9@widsith.local>
On Mon, 01 Aug 2016 16:10:14 +0200, 茱滴 <hongru.zhr@alibaba-inc.com> wrote: > > Thanks. > I suggest we can list the major changes in bullets or numbering, which > can be more clear. Agreed. (Note also that a newHTMLdiff is necessary) cheers > > >> Judy > > > 发件人: Stephen Zilles [mailto:steve@zilles.org]发送时间: 2016年8月1日 > 11:22 > 收件人: ab@w3.org > 抄送: 'Revising W3C Process Community Group' > 主题: Revised Draft intro to Process 2016 Document to be sent to > > > All, > > This is a revised draft that incorporates the changes suggested by Jeff > Jaffe and David Singer. > > Steve Z > > > =========Draft Letter ======== > > All, > > The Advisory Board is forwarding a proposed Process 2016 draft [1], [2] > and [3] to the Advisory Committee for consideration and comment. The > plan is that, >based on the received comments, a revised draft will be > sent to the Advisory Committee for formal Review prior to the September > TPAC meeting and that >there will be time for questions and comments on > the proposed Review document at the TPAC meeting. > [1] https://dvcs.w3.org/hg/AB/raw-file/default/cover.html > > [2] https://www.w3.org/2016/07/28-Process2016-diff.html (HTML Diff > version) > > [3] https://dvcs.w3.org/hg/AB/ (Detailed Diffs) > > > Please send comments to public-w3process@w3.org (Mailing list archive, > publicly available) or to process-issues@w3.org (Member-only archive). A > >Public Issue Tracker and detailed changelogs are available online. You > may discuss your comments on any other list, such as > w3c-ac-forum@w3.org, as >long as you send the comments to one of the > W3process lists above and copy that list in the discussion. > > > The major changes in this document and their rationale are outlined > below: > > Renumber - 5.2.8, it becomes 5.2.7 (there was no section 5.2.7 in > Process 2015) > > > Added a process to make a Recommendation Obsolete and consolidate it > with Rescinding a Recommendation - 6.9 > > The AB observed that there are some Recommendations that have (mostly) > outlived their usefulness and should no longer be implemented in new > >software. This class of Recommendations, called Obsolete > Recommendations, is different from the class of Rescinded > Recommendations. Rescinding is >an existing process that has an effect > on patent licensing commitments (see section 5 of the patent policy). > This change only adds obsoleting (and un->obsoleting).. A Recommendation > that is Obsoleted remains a Recommendation, it still has patent > licensing commitments and it can be referenced >Normatively, but > implementation of that Recommendation is discouraged. > > > Section 6.9 of the Process Document has been changed to add (to the > process to Rescind a Recommendation) a specification of the processes to > >Obsolete and to un-Obsolete a Recommendation. The details of the > process are similar in each case, but the effect is different. For a few > reasons — to >streamline the process, because it’s a simple yes/no > question (that is, the content of the affected Recommendation, except > for the Status section, does not >change), and because we would only > obsolete when we don’t know of anyone to contact to ask for wide review > — Wide Review prior to the AC (and >Public) Review is not required or > necessary. > > > Anyone can request one of these actions. If the Working Group that > produced the specification is still extant (or exists as a re-chartered > group) then that >Working Group acts to recommend that the requested > action take place. If there is no such Working Group, the TAG acts to do > a technical assessment of >the requested action. If proceeding is > recommended or the AC appeals a rejection, then an AC Review and the > Director’s Decision determine the result. >See 6.9 for the exact details. > > > Changed the voting for AB and TAG elections to Single Transferable Vote > - 2.5.2 > > The W3C Membership recommended that W3C experiment with different voting > mechanisms for TAG and AB elections. After analysis of the 2-year > >experiment that occurred as a result of that recommendation, the > Membership supported the adoption of an Single Transferable Vote > tabulation system for >TAG and AB elections with the expectation that it > will be more representative of the Membership's will. > > > The text that is in the proposed Process document was designed with the > following goals in mind: > The tabulation system description (and choice of specific tabulation > system) should be independent of the process document text.The > tabulation system should be described independent of specific voting > operations (e.g., the forms that members fill out).The tabulation system > should be described independent of any software we use to compute > results (that is: we should not rely on a single piece >of software for > implementation). > > > The Team currently believes that the Meek STV tabulation system is the > best fit for the TAG and AB elections. Details on why and how are at > https://>www.w3.org/community/w3process/wiki/Voting2016. > > > Simplify and Rationalize Appeals, so they can occur whether there was > dissent or not, and in a broader range of cases – see especially 6.4, > 6.6, 6.9, 7, >7.2, 7.3, 10, 10.4, 11 > > Toward the end of the process of creating Process 2015, a number of > issues related to "appeals" in the W3C process surfaced. At that time, > there seemed >to be too little time to appropriately address the issues > with the care that seemed to be needed. These issues (and ones which > have arisen since then) are >addressed in the proposed Process 2016. > > These changes made the following clarifications: > > A. Which of the three types of appeal is to be used MUST be > explicitly identified. The three types are: > > i. Group Decision Appeal > > ii. Submission Appeal > > iii. Advisory Committee Appeal > > B. Who can initiate the appeal MUST be identified (whether it is an > individual or an AC Representative) > > C. What is being appealed, what "decision" and who (chair, > Director, W3C or Team) made it MUST be identified. > > D. There should be a specification of what DOCUMENTATION should > accompany each type of appeal. This is specified for a Group Decision > Appeal. > > > Note: Formal Objections are not strictly an "appeal". They are > "registered" not "initiated" and they follow the document to which they > apply. A separate step, >the Group Decision Appeal, that asks the > Director to "confirm or deny a decision" (of the group) is the appeal > mechanism. Any individual may register a >Formal Objection, but only > group participants may issue a Group Decision Appeal and if they belong > to a Member organization then they must do so >through their AC > Representative. > > > Finally, the rules for what decisions are appealable were simplified to > be uniform across each class of decisions. > > > Clarified the rights and obligations of Member Consortia and their > representatives - 2.1.2 > The Problems: > When we introduced the Introductory Industry Membership level [4, 5] we > imposed limitations on the rights and privileges of this category of > Member. The proposed change eliminates the disagreement between the > current terms of an Introductory Industry Member per their Member > Agreement and this section of the Process which implies such Members may > participate in (all) Working Groups and Interest Groups. >[4] http://www.w3.org/Consortium/fees?showall=1 > [5] http://www.w3.org/2014/08/intromem >In looking at the way we define the entitlements of Member Organizations > that are also a Consortium in nature, there are a couple of issues that > need to be addressed. They arise from the fact that we allow these > Members to appoint four (or more) people to represent them within W3C. > While we say they are there to represent the Consortium we have been > experiencing cases where these designated representatives are in fact > representing their own interests. This opens an IP exposure for W3C > because we don't have commitments from their employers, just from the > Consortium. It also offers a "back door" for large corporations to > participate without joining themselves. The proposed changes, in > section 2.1.2, attempt to close those loopholes. > > Clarified the process for continuing work on a specification initially > developed under another charter - 5.2.3, 5.2.4, 5.2.6, 6.2.2. > > When the W3C Patent Policy and Process Documents were drafted, some > Members may have assumed that work on a W3C Recommendation would be >the > product of work under a single Working Group charter; instead, Working > Drafts often evolve through multiple Working Group charters. The major > >uncertainty has often been phrased as "When do Working Groups end?", > but in fact concerns the situation where a Recommendation is developed > under >more than one Working Group Charter. Many specifications take > more than one charter period to move from First Public Working Draft to > >Recommendation. There is a longstanding practice of adopting a Working > Draft that was published under a previous charter, and continuing to > develop it in >a Working Group with a newer charter. > > > The changes apply to Working Drafts that have had a full exclusion > opportunity under a Working Group pursuant to the Patent Policy (i.e., > Reference Draft >(RD) issued within 90 days of a First Public Working > Draft (FPWD) and a Candidate Recommendation (CR) (called Last Call > Working Draft (LCWD) in the >Patent Policy). > > > The changes in this draft cover: > > a) A change in the W3C Process Document to clarify how work can > continue under a new Working Group charter on a Working Draft that has > already >had a full exclusion opportunity; and > > b) Suggested improvements in practice to improve the ability to trace > the origin of Working Drafts, and their associated Reference Drafts and > Candidate >Recommendations. > > > The most relevant text, currently in section 5.2.6 Working Group and > Interest Group Charters, is: > > “For every Recommendation Track deliverable that continues work on a > Working Draft (WD) published under any other Charter (including a > predecessor group >of the same name), for which there is an existing > Reference Draft or Candidate Recommendation, the description of that > deliverable in the proposed charter of >the adopting Working Group must > provide the following information: > The title, stable URL, and publication date of the Adopted Working Draft > which 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 which 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. > > The Reference Draft is the latest Working Draft published within 90 days > of the First Public Working Draft, and is the draft against which > exclusions are be >made, as per section 4.1 of the W3C Patent Policy > [PUB33]. > > The Adopted Working Draft and the most recent Reference Draft or > Candidate Recommendation must each be adopted in their entirety and > without any >modification. The proposed charter must state that the most > recent Reference Draft or Candidate Recommendation is deemd to be the > Reference Draft or >Candidate Recommendation in the adopting Working > Group, and that the Exclusion Opportunity that arose as a consequence of > publishing a First Public >Working Draft or Candidate Recommendation has > finished, meaning any exclusions against those drafts must be made on > joining the group, as per section 4.3 >of the W3C Patent Policy [PUB33] > > The Director must not issue a call for participation less than 60 days > after the beginning of an Advisory Committee Review for a charter that > continues work on >a Reference Draft or Candidate for which an Exclusion > Opportunity has occurred.” > > Other changes are in 5.2.3, 5.2.4, 6.2.2 > > Note: Except for Section 3.1 of the Patent Policy, there is no explicit > statement in the > Patent Policy that commitments made under the Patent Policy ever expire. -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Tuesday, 2 August 2016 11:29:46 UTC