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

RE: fixing process regression related to typo fixes

From: Stephen Zilles <szilles@adobe.com>
Date: Mon, 19 Sep 2016 10:37:22 +0000
To: David Singer <singer@mac.com>
CC: Jeff Jaffe <jeff@w3.org>, "L. David Baron" <dbaron@dbaron.org>, "public-w3process@w3.org" <public-w3process@w3.org>, Tantek Çelik <tantek@cs.stanford.edu>
Message-ID: <BY1PR02MB111410F6E772DD63C8110D54AEF40@BY1PR02MB1114.namprd02.prod.outlook.com>


> -----Original Message-----
> From: David Singer [mailto:singer@mac.com]
> Sent: Wednesday, September 14, 2016 4:59 PM
> To: Stephen Zilles <szilles@adobe.com>
> Cc: Jeff Jaffe <jeff@w3.org>; 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
> 
> Steve
> 
> I think we should look at a simple revert as the first course, rather than
> writing new text, as new text may have new unintended effects.  Is it not
> possible to ‘revert and think harder’ as suggested?

Unfortunately, a simple revert is not possible because the paragraph in question has changed significantly over the various versions of the Process Document

In the 2005 document it says,
"The first two classes of change require no technical review of the proposed changes, although a Working Group MAY issue a Call for Review. The modified Recommendation is published according to the Team's requirements, including Publication Rules [PUB31]."

The "first two classes" were split in Process 2014 and the Editorial Change paragraph became,
"Editorial changes to a Recommendation require no technical review of the proposed changes. A Working Group 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 are may be called a Proposed Edited Recommendation."

This is when the (objected to) requirement to go to PR instead of directly to "modified REC" was introduced. This paragraph was further modified in Process 2015 to,
"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."

That is, the provision, " provided there are no votes against the resolution" was added to help insure that only non-substantive changes were being made, at least from the viewpoint of the Working Group.

For these reasons, the suggested edit below seemed the most direct way to implement the intent of the proposed "regression".

Steve Z
> 
> > On Sep 13, 2016, at 12:52 , 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
> 
> Dave Singer
> 
> singer@mac.com

Received on Monday, 19 September 2016 10:37:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 September 2016 10:37:56 UTC