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

Reviewed and ok by me too. Thanks, Tantek

On Mon, Aug 1, 2016 at 11:12 AM, David Singer <singer@apple.com> wrote:
>
> On Jul 31, 2016, at 20:22 , Stephen Zilles <steve@zilles.org> wrote:
>
> All,
> This is a revised draft that incorporates the changes suggested by Jeff
> Jaffe and David Singer.
>
>
> ok by me, good to go. (well, there is a double full-stop "(and
> un-obsoleting)..” but that is minor)
>
>
> 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.
>
>
> Dave Singer
>
> singer@mac.com
>
> David Singer
> Manager, Software Standards, Apple Inc.
>

Received on Monday, 1 August 2016 21:43:46 UTC