- From: <chaals@yandex-team.ru>
- Date: Mon, 19 Sep 2016 14:24:04 +0200
- To: Stephen Zilles <szilles@adobe.com>, 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>
Very quick reply - I think we can effectively do a quick revert without a lot of problem. Not today, probably not until Wednesday. cheers 19.09.2016, 12:38, "Stephen Zilles" <szilles@adobe.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 -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 19 September 2016 12:24:36 UTC