W3C home > Mailing lists > Public > public-w3process@w3.org > August 2016

Re: 答复: Revised Draft intro to Process 2016 Document to be sent to

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>  

> Thanks.
> I suggest we can list the major changes in bullets or numbering, which  
> can be more clear.


(Note also that a newHTMLdiff is necessary)


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:40 UTC