RE: fixing process regression related to typo fixes

Virginia,
There are actually, see section 6.7.2 Revising a Recommendation [1], two ways to create an Edited Recommendation: without and with Substantive Changes. When Substantive Changes are made, then a CR (and an Exclusion Opportunity) occurs. It is only for Editorial Edited Recommendations that no Exclusion Opportunity occurs.
[1] https://www.w3.org/2015/Process-20150901/#revised-rec


Steve Z

> -----Original Message-----
> From: vfournier@apple.com [mailto:vfournier@apple.com]
> Sent: Tuesday, September 13, 2016 4:25 PM
> To: Stephen Zilles <szilles@adobe.com>
> Cc: Jeff Jaffe <jeff@w3.org>; David Singer <singer@mac.com>; L. David Baron
> <dbaron@dbaron.org>; public-w3process@w3.org; Tantek Çelik
> <tantek@cs.stanford.edu>
> Subject: Re: fixing process regression related to typo fixes
> 
> Hi Steve,
> 
> Thanks very much for taking the first cut at this.  I think this generally looks
> good.  However, I think we should be more clear that an Edited
> Recommendation does not trigger an exclusion opportunity.  We’ll work on
> some language and send it back to you.  Thanks again!
> 
> 
> Best regards,
> 
> Virginia Fournier
> Senior Standards Counsel
>  Apple Inc.
> ☏ 669-227-9595
> ✉︎ vmf@apple.com
> 
> 
> 
> 
> 
> On Sep 13, 2016, at 12:52 PM, Stephen Zilles <szilles@adobe.com> wrote:
> 
> > -----Original Message-----
> > From: Jeff Jaffe [mailto:jeff@w3.org]
> > Sent: Monday, September 12, 2016 4:35 PM
> > To: David Singer <singer@mac.com>
> > Cc: Stephen Zilles <szilles@adobe.com>; L. David Baron
> > <dbaron@dbaron.org>; public-w3process@w3.org; Tantek Çelik
> > <tantek@cs.stanford.edu>
> > Subject: Re: fixing process regression related to typo fixes
> >
> >
> >
> > On 9/12/2016 5:21 PM, David Singer wrote:
> >>> On Sep 12, 2016, at 11:47 , Jeff Jaffe <jeff@w3.org> wrote:
> >>>
> >>>
> >>>> I do believe that the change in the Process 2014 document was a
> > conscious choice and not an accident. The main argument for the change
> > was that can anyone tell (without review) whether an editorial change
> > is truly editorial. That is why the all text changes became
> > reviewable. This argument is stated in more detail in
> >>>>
> >>>> https://lists.w3.org/Archives/Public/public-w3process/2014Oct/0145.

> >>>> h tml from Wayne Carr which is a response to Elika's message that
> >>>> you point to above. Wayne suggests several other ways to get the
> >>>> necessary
> > review, but does not believe that they are improvements.
> >>>>
> >>>> Any change in this area should have wider discussion prior to
> >>>> changing the
> > process.
> >>> I think David's issue is important and I would encourage you to
> >>> entertain
> > such a wider discussion during your TPAC presentation. Let's hear what
> > the Membership has to say!
> >>>
> >> The whole question of how we verify that a change is ‘merely
> >> editorial’ is
> > tricky. People write the dangdest patents (e.g. one I recall being
> > told of only applied if the bits in a structure were in a specific
> > order). Without detailed patent searches for everything, one can never
> > be *sure* that an edit hasn’t changed encumbrances, I fear.
> >>
> >> I wonder how many on the AC will actually open a Proposed Edited Rec
> >> when
> > the changes are believed to be editorial, and check? Are they more or
> > less likely to know than the working group participants?
> >>
> >> Perhaps it’s more important to say that there is a chance for the WG
> > members and their AC Reps to object to a proposed edited rec., and if
> > there is no objection, it’s published? If there IS objection, somehow
> > we’d have to decide as a community whether the edit truly is
> > ‘substantive’, and I am not sure how to do that. Presumably the objector has
> a good reason...
> >>
> >> I am intrigued by Wayne’s suggestion that the license commitment of
> >> an
> > Edited Recommendation be exactly the same as the Recommendation that
> > it edited, as this protects the IPR owners from accidentally
> > introducing a newly licensed thing unintentionally. On the other hand
> > it leaves implementers implementing something which has accidentally
> > incorporated an unlicensed thing. I think that this effect would be,
> > if it happened, worked out in the courts, and I think we’d best be silent about
> it.
> >>
> >> Summary: I would be happy to revert to pre-2014 as long as we discuss it.
> > The reason I am ok with revert is that it’s lighterweight, and we
> > didn’t suffer much under the previous regime.  But only as long as we discuss.
> >
> > I agree with your Summary.
> >
> > For me, there is a known certainty (the last two years) that the
> > current system hurts agility (vignettes from Elika, David, Tantek, and PLH).
> > There is a theoretical corner case that the previous system has a tiny
> > patent exposure.  For me certain agility trumps theoretical tiny patent
> exposure.
> 
> I am detecting, so far, significant support for loosening the requirements on
> "Editorial Changes" (Note this is not just typos; it includes all textual changes
> that are deemed by the Working Group to not affect conformance to the
> specification.)
> 
> It appears to me that the main argument for this is that (1) if the Working
> Group does not believe it changed conformance who is better at doing that
> AND (2) it seems unlikely that people will actually do a patent search against
> editorial changes.
> 
> I, too, liked the idea that Patent Licensing Commitments do not change for
> Edited Recommendations (because there has been no Disclosure Opportunity
> since they did not go through another CR (nor PER).
> 
> To move the discussion to a concrete change proposal, I suggest the following:
> 
> Current:
>   Editorial changes to a Recommendation require no technical review of the
> proposed
>   changes. A Working Group, provided there are no votes against the resolution
> to
>   publish may request publication of a Proposed Recommendation or W3C may
> publish
>   a Proposed Recommendation to make this class of change without passing
> through
>   earlier maturity levels. Such publications may be called a Proposed Edited
> Recommendation
> 
> Replacement:
>   Editorial changes to a Recommendation require no technical review of the
> proposed
>   changes. A Working Group, provided there are no votes against the resolution
> to
>   publish may request publication of an Edited Recommendation or W3C may
> publish
>   an Edited Recommendation to make this class of change without passing
> through
>   earlier maturity levels.
> 
> I have deleted the sentence, " Such publications may be called a Proposed
> Edited Recommendation” as being redundant after the change, especially since
> another suggested change has changed the MAY to an "are".
> 
> I think it would be useful to say that the version number should be updated,
> but since such publications are dated, the new date may suffice to distinguish
> it from prior versions.
> 
>    Note there is a sentence lower in the subsection that the above sentence on
> Editorial changes occurs in that says,
> 
>    When requesting the publication of an edited Recommendation as described
>    in this section, in addition to   meeting the requirements for the relevant
>    maturity level, a Working Group
> 
>       *  must show that the changes to the document have received wide review,
> and
>       *  should address all recorded errata.
> 
> Having had wide review of the Edited Recommendation prior to publication
> seems like a good thing. For an Edited Recommendation that is only doing
> editorial changes, it may not be possible to address all errata since some of
> those may involve substantive changes. Perhaps the second bullet should read,
>      *  should address all recorded errata, or if only Editorial Changes are made,
>          all errata that can be address by an Editorial Change.
> 
> Steve Z

Received on Wednesday, 14 September 2016 00:58:53 UTC