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-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.

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.


>
> -----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.
>
>
>
>
>

Received on Thursday, 19 June 2014 01:45:13 UTC