- From: David Singer <singer@apple.com>
- Date: Thu, 19 Jun 2014 14:00:16 -0700
- To: "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>
- Cc: Wayne Carr <wayne.carr@linux.intel.com>, "public-w3process@w3.org" <public-w3process@w3.org>
On Jun 19, 2014, at 12:55 , Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com> wrote: > >How does someone "take it back into a CG" if they don't have copyright > >permission for the changes that happened in the WG? > > Right, so lets fix that while we're revising the Process. > I can't think of any reason why even the people who have been reluctant to liberalize the document license on Recommendations would oppose publishing Notes under CC-BY or the equivalent. Right, we could do that. But Wayne, there are two cases here: those that contributed the changed material want to see it published, whereupon they can contribute it again to the CG, or they don’t whereupon the question is moot. If they don’t want to see it published, they probably won’t grant a license either, so making a W3C note with no IPR status doesn’t help. > From: Wayne Carr > Sent: ý6/ý19/ý2014 12:43 PM > To: public-w3process@w3.org > Subject: Re: incubation in CGs and W3C Notes when a WG drops work on a spec - was: Re: Comments on https://dvcs.w3.org/hg/AB/raw-file/5508dec95a6a/tr.html > > > On 2014-06-19 10:27, David Singer wrote: > > On Jun 18, 2014, at 18:44 , Wayne Carr <wayne.carr@linux.intel.com> wrote: > > > >> On 2014-06-18 16:53, Michael Champion (MS OPEN TECH) wrote: > >>> Obviously not for this revision of the process document, but if we were to insist/encourage that specs be incubated in Community Groups under its IPR policy before going to the Rec Track, we would at least have RF commitments from the folks that contributed an idea to the CG. Ideally a good set of people would have signed the Final Specification Agreement, giving specs that lose traction and end up as Notes IPR standing. > >> We're off the topic of the comments on this proposed chapter 7 change now, so i changed the subject. > >> > >> Whenever this comes up about using CGs as incubators for WGs, I always am cautious because unlike WGs, CGs do not have to operate by consensus. There is a charter template that doesn't have that problem, but CGs don't have to use that or use any charter at all. Without a charter, the chair can just do what they like. If it became some sort of requirement to use CGs as incubators, that shouldn't be a path around having to seek consensus. > > Yes, but this doesn’t affect the IPR status; if contributors sign the CLA and a reasonable crowd sign the FSA, then there is some IPR coverage. Whether the spec is worth publishing, represents consensus, or anything, is quite a different question. > > It's relevant to the suggestion above to "to insist/encourage that specs > be incubated in Community Groups". > > > > >> About your point about ending up as notes and having been in a CG first -- that doesn't resolve the problem unless the model you're proposing is to do virtually all technical work in a CG and only bring it into a WG when all but done. What looks like a pretty good spec from some external source goes into a WG, the WG makes significant improvements and then it turns out there aren't 2 implementations and it is abandoned and published as a Note. If that's to go back to an open source project that uses CC By for instance, that's a problem because they may lose all the changes because they don't have copyright permission to use it. > >> > >> I proposed a couple of years ago that drafts that have significant work on them and then are dropped be published as Notes under the CC By license so they can be taken up again by the initial source or someone else. > > That’s a different question — copyright status — from the initial one, which was IPR status. If the WG added stuff, take it back into a CG and try to get all the contributors to join and sign the FSA. > > How does someone "take it back into a CG" if they don't have copyright > permission for the changes that happened in the WG? They can lose the > changes the WG made and start where they left off, but that isn't what > was suggested above. > > >> > >>> -----Original Message----- > >>> From: David Singer [mailto:singer@apple.com] > >>> Sent: Wednesday, June 18, 2014 4:23 PM > >>> To: Charles McCathie Nevile > >>> Cc: public-w3process > >>> Subject: Re: Comments on https://dvcs.w3.org/hg/AB/raw-file/5508dec95a6a/tr.html > >>> > >>> Thanks Charles > >>> > >>> a few comments below > >>> > >>> On Jun 18, 2014, at 15:25 , Charles McCathie Nevile <chaals@yandex-team.ru> wrote: > >>> > >>>>>> 5. WG Notes are mentioned many times, and there should be a note on the first mention that they have no standing under the IPR Policy. > >>>> ISSUE-102 > >>>> > >>>> I propose instead to note that IPR commitments *only* cover Recommendations, in the Maturity levels section. > >>>> > >>>> The only mention of Notes before this points out they have no formal standing as a recommendation of W3C, which I think is enough in the context. > >>> I think many readers will think (correctly) that the document process and the IPR policy are distinct, and therefore be unclear as to which of them your phrase 'no formal standing' applies to. Clarification (it's both/all) would be harmless, wouldn't it? > >>> > >>>>>> 18. 7.4.1 please rewrite the phrase on at-risk features, to match the earlier text "for a feature to be formally at-risk, it MUST be documented..." > >>>> This is editorial. > >>>> > >>>> W3C style, for ease of translation and comprehension, is to prefer the active voice. > >>> Fine, but the phrase as given implies (incorrectly) that a feature at risk may be documented...some re-phrasing would help; the 'may' applies to the existence of at-risk features, not to whether an at-risk feature has to be documented. > >>> > >>>>> Minor, perhaps only editorial: > >>>>> > >>>>>> 2. For each call for a formal review, please be clear what the question being asked is. > >>>> This would be new, but I think it is a useful, editorial suggestion. Advisory committee review is formally defined elsewhere in the process, but I think we can sensibly clarify in this chapter that the review is to determine whether the document is suitable to adopt as a W3C recommendation. > >>> I am suggesting every time 'review' occurs we make sure that the question is clear (public review, AC review, and so on). > >>> > >>>>>> 3. It is practice, but nowhere written, that a PR transition will not happen while an exclusion opportunity remains open. Please consider documenting that. > >>>> ISSUE-100 > >>>> > >>>> There are use cases for not having the extra delaying step. They are generally rare, and the normal practice is to check if an exclusion period is open before granting a transition. I'll carry on discussion in a separate thread. > >>> The case of haste is covered by issuing a poll and asking people to respond whether or not they intend to exclude. Apparently it's been tried in the past (but never worked - they never got 100% response). > >>> > >>>>>> 17. The rules for what is a decision are very unclear, and as chairs need to refer to this clause when trying to publish, please clarify. If unanimity isn't required, or consensus, what is? > >>>> Working Group decisions are described in Chapter 3. I don't propose to address the question, since the AB has decided that this revision should only be of Chapter 7, but feel free to raise an issue - or to request that the AB change its earlier decision. > >>>> > >>> We've had huge arguments in two groups over this, and people really need to be able to quote the rules. Perhaps a heartbeat or WD publication decision is basically made not even by the chair, but by the process, and the only question that the chair can ask is "are there specific changes you would like to the document, that the group can agree to, before publication?" (and that change might be the insertion of a note saying that the question is not yet resolved, for example). Chairs are suffering now, please come to their aid somehow. > >>> > >>> > >>> David Singer > >>> Manager, Software Standards, Apple Inc. > >>> > >>> > >>> > >>> > >>> > > David Singer > > Manager, Software Standards, Apple Inc. > > > > > > > > David Singer Manager, Software Standards, Apple Inc.
Received on Thursday, 19 June 2014 21:01:08 UTC