Re: [Issue-152] Note for Draft Process Document

 > I also believe that the discussion that was held at the AB meeting in 
Tokyo seemed to be saying that we could not adequately define “editorial 
change” so triggering an Exclusion
>period was the simpler thing to do because it was not that costly and 
gave better patent infringement protection

This is not just an issue for errata management.  The difference between 
and editorial and substantive changes also determines whether a 
Candidate REC is published as a Revised Candidate Recommendation and 
goes through another exclusion period or not (Process section 7.4.1).  
We seem to think we can tell the difference when a spec is being 
developed and goes to CR and needs to change again.  We should clarify 
the definition of Editorial Changes (I propose a definition below).

I think the 2 separate classes that make up editorial changes used to be 
treated differently, but not anymore so those separate classes aren't 
needed. Coalescing them makes 3 classes that are treated differently (1. 
editorial changes -> ?; 2. substantive changes that don't add features 
-> CR; 3. substantive changes that do add new features -> FPWD)

Suggestion for Definition of Editorial Changes:
Editorial Changes are modifications that do not affect conformance.  
Reasonable implementers would not interpret these modifications as 
changing architectural or interoperability requirements. If 
implementation requirements were ambiguous and were made clear by a 
modification, then that modification is not considered an Editorial 
Change because it may be viewed as changing requirements. If there is 
any doubt as to whether a modification is an Editorial Change, it should 
not be considered an Editorial Change. Examples of Editorial Changes are 
fixing links, typos or grammatical errors where the change does not 
change implementation requirements.  Other examples include correcting 
non-normative code examples where the code clearly conflicts with 
normative requirements, or clarifying informative use cases or other 
non-normative text that does not define implementation requirements.   
As a rule of thumb, Editorial Changes do not require any code changes in 
reasonably competent implementations.

With a good definition for what the classification is, we could then 
decide who decides on which class modifications to a spec fall into 
(either a CR that changes on the way to REC or a revised REC later).



On 2015-03-02 20:40, Stephen Zilles wrote:
>
> Wayne,
>
> I believe the essence of your point is that we can adequately define 
> “editorial change” (and that we should fix the current circularity 
> anyway).
>
> I also believe that the discussion that was held at the AB meeting in 
> Tokyo seemed to be saying that we could not adequately define 
> “editorial change” so triggering an Exclusion period was the simpler 
> thing to do because it was not that costly and gave better patent 
> infringement protection.
>
> This brings us to Mike Champion’s point that we have to decide if (in 
> this case) some definition of “editorial change” sufficiently protects 
> us from making a patent infringement mistake that we should opt for 
> the simpler process and live with handling any mistakes that are made.
>
> I believe that the definition of “editorial change” is key to deciding 
> who can say a change is “editorial”. That is necessary to being able 
> to implement a process simpler than having an Exclusion period.
>
> Steve Z
>
> *From:*Wayne Carr [mailto:wayne.carr@linux.intel.com]
> *Sent:* Monday, March 02, 2015 1:03 PM
> *To:* Michael Champion (MS OPEN TECH); Stephen Zilles; David Singer; 
> public-w3process@w3.org
> *Subject:* Re: [Issue-152] Note for Draft Process Document
>
> I think we may be making this too complex by not focusing on the 
> definitions. We're talking about Editorial changes 
> <http://www.w3.org/2014/Process-20140801/#editorial-change>  as 
> defined (recursively by accident I assume) in the Process as:
>
> "The first two classes of change are considered editorial changes"
>
> and the classes referred to are:
> [[
> 1. No changes to text content
>
> These changes include fixing broken links, style sheets or invalid markup.
>
> 2. Corrections that do not affect conformance
>
> Editorial changes or clarifications that do not change the technical 
> content of the specification.
>
> ]]
>
> I'd add to the "Corrections that do not affect conformance" section: 
> "If reasonable readers could differ in their understanding of 
> implementation requirements and a proposed clarification corrects 
> that, then conformance requirements where not clear and those 
> clarifications would not be in this category."
>
> If a spec is vague and good faith implementers could have understood a 
> requirement in various ways, then clarifying that could change 
> implementations.  Those people in fulfilling their disclosure 
> obligations and responding to exclusion periods may not have 
> understood what the requirements were - so they didn't really have 
> proper exclusion periods or disclosure requirements.  In that case, it 
> needs to be treated as a substantive change so there is another 
> exclusion period.
>
> Whoever is deciding if a change is editorial, doesn't have to know 
> anything about any particular patents.  The test is whether reasonable 
> implementers could have different interpretations of the change in 
> text that would change what they think are the implementation 
> requirements. Fixing a typo or grammar or code example that is clearly 
> wrong, are editorial changes.  Clarifying a requirement that 
> implementers understood and implemented in various ways would not be 
> editorial.  Knowing whether there are patents reading on the change 
> isn't necessary.  It's whether it is possible that there could be.
>
>
> Proposal:
> 1) WG judges that it is editorial (reasonable implementers would not 
> have misunderstood implementation requirements) and asks Director to 
> publish revised REC;
> 2) AC and public are informed of request by Director as soon as 
> possible (the public announce list and the AC list);
> 3) Any AC rep objection or Director objection within 14 days of 
> Director notice of the request and it must go through the process for 
> substantive changes (CR).
> 4) If no objections, is published as revised REC
>
> That takes 14 days to do it.  That doesn't seem bad.  It gives the 
> general and the AC public the opportunity to say the spec changes 
> implementations.
>
> On 2015-03-02 11:46, Michael Champion (MS OPEN TECH) wrote:
>
>           The catch is that it depends on an AC member knowing enough to trigger an exclusion
>
>     That problem is built into the W3C process and has been for 20 years.  But it's a problem for members, not the W3C process.  An AC rep of a member with a significant IP portfolio has to do a lot of due diligence for the process to be effective, and the actual work has to be done by people who understand patent law and the member's portfolio.  That's expensive, but has to be weighed against the expected cost/benefits of the portfolio.
>
>       
>
>       
>
>           It seems safer to just have the exclusion period which would provide greater patent protection because expiration of the
>
>         exclusion period would require any patent owned by a group Member to have a royalty free license in the future
>
>       
>
>     This  discussion echoes debates across the software industry as agile methodologies take hold:  There's a tradeoff between responding quickly to opportunities and ensuring that nothing gets broken.  Finding the right balance is hard, and best practices very much a work in progress.
>
>       
>
>     So which is worse:  Continuing to publish a Recommendation with known bugs, or risking that fixes to those bugs could inadvertently break interoperability or create IPR issues?  And if we lean too far in one direction, will that undermine the value of the result?
>
>       
>
>     The Process CG is not the right place to finalize this conversation.  All we can do is identify the issues, collect as much information as possible on the real world risks, and delegate answering these questions to the AC.
>
>       
>
>       
>
>     -----Original Message-----
>
>     From: Stephen Zilles [mailto:szilles@adobe.com]
>
>     Sent: Monday, March 2, 2015 11:23 AM
>
>     To: David Singer;public-w3process@w3.org  <mailto:public-w3process@w3.org>
>
>     Subject: RE: [Issue-152] Note for Draft Process Document
>
>       
>
>     Comments in-line below
>
>     Steve Z
>
>       
>
>         -----Original Message-----
>
>         From: David Singer [mailto:singer@apple.com]
>
>         Sent: Monday, March 02, 2015 9:49 AM
>
>         To:public-w3process@w3.org  <mailto:public-w3process@w3.org>
>
>         Cc: Stephen Zilles
>
>         Subject: Re: [Issue-152] Note for Draft Process Document
>
>           
>
>         We discussed a two-step process: allow the WG to assert that changes
>
>         are purely editorial, and then have a (short) period for any AC member
>
>         to object, whereupon an exclusion period would automatically start.
>
>         IF an exclusion period happens, this takes longer, of course, and only
>
>         if the ‘short’ period is significantly shorter than an exclusion period do we win at all.
>
>           
>
>         Other ideas are welcome.
>
>     [SZ] I recall this discussion. The catch is that it depends on an AC member knowing enough to trigger an exclusion. I have worked for companies that active discourage knowledge of patents by their employees. That would mean that an AC rep for such a company would not have the knowledge to trigger an exclusion period. It seems safer to just have the exclusion period which would provide greater patent protection because expiration of the exclusion period would require any patent owned by a group Member to have a royalty free license in the future. That is why I think the issue reduces down to (a) require exclusion period or (b) do not require exclusion period.
>
>           
>
>           
>
>             On Mar 1, 2015, at 19:14 , Stephen Zilles<szilles@adobe.com>  <mailto:szilles@adobe.com>  wrote:
>
>               
>
>             Wayne,
>
>             Thank you for pointing out that I forgot to say that the note is to
>
>             explain an
>
>         open issue (152) and would be removed as soon as the issue is resolved.
>
>         Hence, it would go in the next draft, but would disappear before the
>
>         final draft of Process2015.
>
>               
>
>             Steve Z
>
>               
>
>             From: Wayne Carr [mailto:wayne.carr@linux.intel.com]
>
>             Sent: Sunday, March 01, 2015 3:15 PM
>
>             To: Stephen Zilles;public-w3process@w3.org  <mailto:public-w3process@w3.org>
>
>             Subject: Re: [Issue-152] Note for Draft Process Document
>
>               
>
>             I'm not sure I understand what is meant by "attachment".  Is it to
>
>             put all that
>
>         text in the Note below in the Process Document?  If so, that doesn't
>
>         seem good.  Way too much text for a fairly obscure subject.
>
>               
>
>             Wherever that Note would be published, I think there's a problem
>
>             with the
>
>         text.  The proposed Note seems to be stating conclusions about whether
>
>         there would have been infringement in the examples.  We shouldn't have
>
>         a note implying whether anything  would have infringed or not.  i.e.
>
>         don't have text like "patent infringement was avoid" or "thus avoiding a patent infringement".
>
>         There can be multiple different reasons why something isn't a concern.
>
>         Sometimes there is a trivial change that makes it so you don't have to
>
>         bother explaining the dozen other reasons it isn't a concern. Changes
>
>         like the examples don't necessarily mean anything infringed - they
>
>         could be just the simplest reason it isn't a problem.  Future versions
>
>         of specs may want to go back in the same area so Notes shouldn't be
>
>         stating conclusions about infringement.
>
>               
>
>             Another approach to the Note could be: "The purpose of returning to
>
>         Proposed Recommendation and an Advisory Committee Review is to draw
>
>         attention to the proposed changes before they become part of the
>
>         Recommendation. A particular focus of that review would be to detect
>
>         instances where changes were misclassified as not affecting
>
>         conformance, in which case the result of AC Review should be to return
>
>         it to Candidate Review and a patent exclusion period."
>
>               
>
>               
>
>               
>
>             On 2015-02-28 15:58, Stephen Zilles wrote:
>
>             Per the request of the Advisory Board, the following note is
>
>             proposed for
>
>         attachment to the second paragraph of section 7.7.2 Revising a
>
>         Recommendation to explain the only open issue on the current draft of
>
>         Process2015. [The proposed text has been hyperlinked inline to make it
>
>         easier to copy.]
>
>               
>
>             Steve Z
>
>               
>
>             ======NOTE=======
>
>             Note: It has been asserted that Process2014 has made the publication
>
>             of
>
>         Edited Recommendations more difficult in the case when they only have
>
>         corrections that do not affect conformance and that this change was
>
>         un- intended. This is Issue-152 on the Revising the W3C Process
>
>         Community Group Tracker. For this kind of change, Process2005 does not
>
>         require any “technical review of the proposed changes.” This also
>
>         holds for Process2014, but an additional step, publication as a Proposed Recommendation, has been added.
>
>               
>
>             The essence of the discussion has been around whether it is possible
>
>             to
>
>         reliably identify “corrections that do not affect conformance.” It
>
>         seems that a Working Group should be able to perform this assessment
>
>         (and has been responsible for doing so in the past). However, several
>
>         recent Patent Advisory Groups (PAGs) have shown that subtle changes in
>
>         a text can have significant Patent implications. The Touch Events
>
>         Specification PAG noted that the Touch Events Specification does not
>
>         fit an ellipse (as required by the patent
>
>         considered) to touched pixels, relying only on a single coordinate
>
>         point (thus avoiding a patent infringement). In a similar analysis, a
>
>         patent infringement was avoid by changing the name of a method being
>
>         used. These examples show the slippery slope of editorial changes.
>
>               
>
>             Based on these examples, a number of people felt that any textual
>
>             changes
>
>         should have an associated exclusion announcement on the changed text.
>
>         That puts the onus of checking whether any of the changes might
>
>         trigger a patent problem on owner of the possibly infringed patents.
>
>         Any reviewer other than the patent holder may not have sufficient
>
>         information to recognize the problem. If the 60 day review period
>
>         passes without any exclusions that is good, and, if an exclusion
>
>         occurred, then the change could certainly affect conformance. The
>
>         essence of the argument is that getting a better Patent assessment
>
>         prior to re-publishing a Recommendation is worth the added delay of an Exclusion period.
>
>               
>
>             This does, however, elongate the process of updating a
>
>             Recommendation
>
>         with purely editorial changes. It has been suggested that it would
>
>         suffice to have the Team Contact (as a disinterested expert in the
>
>         group) review the changes prior to re-publication as a Recommendation,
>
>         thus speeding up editorial updates.
>
>               
>
>             No clear consensus position between these two positions has yet emerged.
>
>             =====END NOTE========
>
>               
>
>           
>
>         David Singer
>
>         Manager, Software Standards, Apple Inc.
>
>       
>