Adding a clear incubation process and flow

[AramZS]

This PR intends to alter the charter to include a means to handle incubation for specific in-scope work.

Notable alterations are:

• The addition of a Document Incubation h3 section to cover the means and purpose of the incubation process.
• Added note that Adoption process may or may not take up documents from incubation and in either case still requires a clear group consensus to enter the adoption process.
• Promoted "Feature Work" section to an h2 heading and made modifications to make it clear that the process of migration and discontinuation applies to both Adopted and Incubated documents.
• Made it clear that all incubated documents are covered by the CLA.
• Incubation work does not require the expectation of interoperability, as it is too early in the process to assume a work under incubation would be ready for such an expectation.

Goals of the alteration:

• To acknowledge that PATCG's constituency is different enough from WICG that there is value in having an incubation process within this CG.
• To give us tools to facilitate the work on proposals that we believe--if they reach a viable state for this group to reach consensus on and this group has decided to adopt them--may be strongly within the interests of this CG.
• To better organize work into this space and provide a clear set of tools for work within this space to be properly identified and discussed.
• To create opportunities for such work to use our facilitation and IPR tools in the form of having a repo within this org and the ability to create ad-hoc meetings for PATCG's membership.

There are a number of things we want to make sure that this does not imply:

• This does not intend to imply that all relevant proposals must be within this group or that their incubation process must come through this group's incubation process.
• This does not intend to imply that private ad technology proposals can't be incubated by WICG
• This does not intend to imply that private ad technology proposals must immediately move from another space or from WICG to our process
• This does not intend to imply that every possible private ad tech proposal is best housed within our incubation process.
• Most of all it should be clear that entering the incubation process requires consensus under our existing rules. I do not intend to imply that this process should be a free-for-all.

If you feel this alteration implies any of these things, please point out how it does so we can make alterations for clarity.

This is a draft and I anticipate and hope for feedback and refinement from the group.

Final merging is contingent on consensus from the group.

[darobin]

LGTM but please note that this is HTML, not MD, you need some <p> elements in there!

[AramZS]

LGTM but please note that this is HTML, not MD, you need some <p> elements in there!

I think I have that resolved now!

[AramZS]

I see your feedback and have made made the suggested changes @dmarti and @cwilso ! Thanks!

[appascoe]

lgtm

[bslassey]

I'm very supportive of this change, and the text looks good to me.

[ekr]

I do not believe this is a good idea. Recall that this CG is intended to incubate documents for the WG, so having yet another phase inside this WG seems like it will primarily serve as a source of confusion, as we see routinely in WICG.

Putting that aside, it's not clear to me what the distinction is between those documents which are appropriate for incubation and those which are actually adopted. The primary difference seems to be whether they are intended for a CG report, but the bar for a CG report is quite low. It's hard to see the point of work that isn't intended to result in such a report.

[cwilso]

FWIW, I do agree that it's not clear why an incubation group would have a separate incubation process. However, I disagree about refusing to accept under the group's umbrella any work until it is proven to be entirely functional and agreeable to all involved; that's the end of the incubation stage, not the beginning. This isn't a WG. It's a CG, which effectively only ever CAN be an incubation venue for a WG.

I want to be clear that we are not asking the PATCG to “adopt and support our solution now”; there is a lot of work to be done before anyone could claim (us included!) that they have confidence this is the right solution; we want PATCG to take responsibility for working on this use case, and we want to contribute this proposal to that shared effort.

I have to disagree with Martin’s assertion (over in patcg/proposals#4 (comment)) that personal repositories are a good place to continually refine proposals; beyond assembling an initial proposal, I believe this is an antipattern. It is very important to us to do work together in public communities - not just “in the open,” but actively seeking others’ involvement and working together with other community members. We are not big fans of a model that encourages any single vendor to go off and work largely on their own on a problem, refining a solution proposal until they think it is complete; in our experience, this tends to create tunnel vision, and makes it all too easy to simply work on a solution until our engineering team believes we're done, then ship it, after which time the community can either adopt it wholesale or not. I hope we are all in agreement that this pattern is a Bad Thing™ for the Web, and that it is a much better pattern to work together in the community to solve problems. (This is all aside from the value of getting CLA/IPR coverage at least committed to by contributors at a basic level.)

In short: I'm not sure what "adopted" means in a CG. I think the PATCG should be adopting use cases, and taking on board proposals for how to address those use cases; that doesn't mean that it stamps "STANDARD" across those proposal, quite the contrary: such proposals should be clearly marked as not-a-standard. Not-a-consensus, even. But we should be working together to reach consensuses on some solutions, not ignoring proposals until an ideal one is offered.

I'm concerned by comparisons to WICG. NOTHING in WICG is anything but an incubation, by definition; nothing there has proven broad support. Nothing there is a "standard". If something has reached the point of broad agreement, we (WICG co-chairs) try to move it out; to another CG with the right community for further incubation, or ideally to a WG that can turn it into a real standard.

The difference here is that WICG is not really a focused community - and we think this use case is clearly in the PATCG’s scope, and this is the right community to look at this problem. It's clear from the comment thread over in patcg/meetings#32, even, that there is broad interest in exploring this use case and attempting to solve this problem. It's clear there are concerns over some details not being determined, and some of the issues being open - that's of course completely natural and expected, because there is still a lot of work to be done (and a lot of other community perspectives to be looked at, and it’s possible some might cause the CG to abandon this work.). That's all fine and normal.

If the PATCG decides not to accept proposals into their space in the near term, I would recommend to our team that we move proposals into the WICG instead (presuming that we pass the bar of "multiple entities are interested in exploring this proposal", which I think there is clear evidence of in case of Topics), and continue to work on it there with whatever part of the community wants to move there to participate. If at some point in time the PATCG wants to take it up, great, we can transfer it (we do this in WICG often as well). I see this as a significantly less attractive option, personally, as I believe this group is the right community to own this use case.

[ekr]

This seems like a topic best discussed at the meeting, so I'm going to keep my responses shortish.

FWIW, I do agree that it's not clear why an incubation group would have a separate incubation process. However, I disagree about refusing to accept under the group's umbrella any work until it is proven to be entirely functional and agreeable to all involved; that's the end of the incubation stage, not the beginning.

This is not the standard I am endorsing. Rather, I believe that the standard ought to be the one in the charter, namely "there is consensus amongst Community Group Participants that the work should be taken on and that the document is a good basis for a Community Group Report. What I'm opposed to is taking on documents where there is not consensus on that point.

I'm concerned by comparisons to WICG. NOTHING in WICG is anything but an incubation, by definition; nothing there has proven broad support. Nothing there is a "standard". If something has reached the point of broad agreement, we (WICG co-chairs) try to move it out; to another CG with the right community for further incubation, or ideally to a WG that can turn it into a real standard.

And yet companies frequently ship specs that are only in WICG and we often get calls to implement those specs.

Re: personal repositories, ISTM that part of the problem is the distinction between a discussion forum (which I agree that the CG should sponsor, even for non-adopted drafts) and for where the drafts live. Github tends to blur those distinctions, but my concern is having documents appear on a piece of real estate which tends to indicate that they are work items of the CG, when they are merely being discussed but have not been adopted.

[martinthomson]

Apologies for being quiet, I've been otherwise occupied and unable to keep up with the volume of text generated on this (and other) discussions.

I don't think that this is the right outcome. Especially if this is used as a pretext to provide resources for any of the current proposals. We need to spend our time picking proposals, not working on them all concurrently. What people do outside of the group - informed by discussions here; to improve or merge their proposals - doesn't need shared resources. We can harness the power of the hyperlink to ensure that nothing relevant is missed and of this platform to ensure that nothing occurs in private where it should not.

I don't want this to be about Topics, but as this discussion started there, it's relevant. It is important that we don't engage on the subject at all until we're further along with the measurement/attribution work. Success on anything here is far from assured and my experience suggests that lack of focus is a very good way to slow things down or even destroy them.

This PR duplicates all of the "adopts" machinery, but doesn't really create any sort of clear distinction between states. If you go this way, the text needs to be factored, heavily.

[AramZS]

I want to note that I am actively reviewing these objections to try and see if there is a clear line towards modification on the PR, and also that I am open to any modifications proposed by this group, if there is a proposed alteration that would fit the idea of "discussion forum for non-adopted draft". I am also still open to the idea of noting that a proposal is officially "of-interest" in some way without bringing the repo into this CG. That said, I do think there are some concerns that without bringing it into a W3C repo the mechanisms used by participants to guarantee coverage under the W3C's CLA and I see those concerns.

Perhaps the compromise is, as suggested, moving such proposals into WICG and then marking them as "of-interest" in some way in the proposals repository--and I think we'd want a clear process for that in either case? That said I do think that the idea that all proposals that have not reached the standards for "adoption" under our or similar CG processes must go to WICG seems counter-intuitive. Having a focused clear venue in which incubation can occur as a side thread without it taking up our active meeting time--beyond the initial agreement to incubate and the potential call to adopt--seems to be very advantageous.

At core, I agree with @cwilso on this:

It is very important to us to do work together in public communities - not just “in the open,” but actively seeking others’ involvement and working together with other community members. We are not big fans of a model that encourages any single vendor to go off and work largely on their own on a problem, refining a solution proposal until they think it is complete; in our experience, this tends to create tunnel vision, and makes it all too easy to simply work on a solution until our engineering team believes we're done, then ship it, after which time the community can either adopt it wholesale or not.

I'd like to see us assure that (EDIT: by which I mean the tunnel vision) is not the process, through whatever this group feels is the best means.

@martinthomson I'm specifically interested in how to create that clear distinction and open to ideas. The concept here is that we reach consensus on entering it into the "incubation" state and must have a separate consensus call to move it to the "adoption" state; with any proposal in the "incubation" state being clearly marked in the README. We can also potentially make it marked in the repo title, but I sense that you're looking for a more complex process. But I'm also assuming that even making clear that a proposal is "of interest" to us should have some sort of process (even if it isn't incubation). I'd be glad to author changes, but I'm not sure what direction would help us all come to acceptance here, and I'm open to ideas.

My concern is that whatever way we'd indicate that a proposal is "of interest" it has no clear rules around how we'd further discuss or talk about it. Indeed, as we've seen elsewhere, even linking to a proposal can be taken as an implication of active work, akin to bringing it into the GitHub org unchanged, by people with less knowledge of the process. A formal method for handling proposals "of interest" and their potential travel through the W3C process seems that it would be very useful to keep things running smoothly and also to make the different states of any proposals as clear as possible.

[martinthomson]

The problem here is more that we have O(N) solutions for the same class of problem where we want O(1). Until we pick a winner, which seems a way off, we will have exactly the problem you describe, no matter what label is attached to a proposal. People will just not bother to sink the massive effort required to make useful contributions to a design when they have no good idea that the design will be chosen. We see that with WICG. We also see the "WICG" label being interpreted as something more than it really is.

[cwilso]

This is not the standard I am endorsing. Rather, I believe that the standard ought to be the one in the charter, namely "there is consensus amongst Community Group Participants that the work should be taken on and that the document is a good basis for a Community Group Report. What I'm opposed to is taking on documents where there is not consensus on that point.

Perhaps, then, our disagreement is on the meaning of the word "basis". Because I think something that is a good start, but may not graduate to actually BEING a CGR (if subsequent incubation proves it is not a good idea), meets that bar. It SHOULD be made clear that's not the same as the CG making a statement (like a CGR does) that "this is what the CG thinks is the right solution".

And yet companies frequently ship specs that are only in WICG and we often get calls to implement those specs.

Indeed, and companies frequently ship specs that are not even in WICG (e.g. https://blog.mozilla.org/netpolicy/2021/10/28/implementing-global-privacy-control/), and we get calls to implement such specs also.

It is definitely the case that we should encourage open community-driven design, and I certainly agree that it should be made clear that such items are proposals for discussion, not adopted consensus specifications - or "the chosen solution". (Though again, anything in a CG does not have "official standards standing".)

Re: personal repositories, ISTM that part of the problem is the distinction between a discussion forum (which I agree that the CG should sponsor, even for non-adopted drafts) and for where the drafts live. Github tends to blur those distinctions, but my concern is having documents appear on a piece of real estate which tends to indicate that they are work items of the CG, when they are merely being discussed but have not been adopted.

My concern is that asking for engagement and contributions to a document that does not have clear IP commitments is a Bad Idea; this is one of the reasons WHY we try to move out from personal repos asap. If the guidance from this discussion is that THIS CG wants to hold them at arm's length until they reach some finish line of acceptability, that's the CG's prerogative, but that doesn't change that we will need to put them somewhere that is not just a personal repo. (That's likely to be WICG as a placeholder - again, presuming such proposals pass the WICG bar of having some other entity agree it's worth incubating).

Martin, to build on what you said, people will not bother to sink ANY effort into a design when the CG isn't even agreeing to look at it. WICG is a very different beast in this regard, as WICG is EXPLICITLY not trying to reduce solutions to O(1); it is to give an IP-regimented space to have discussions, and hopefully figure it out to the point it can go somewhere official (that is, explicitly, a WG or WHATWG or the like).

If there are places you're still seeing "WICG label interpreted as something more than it is", then please point me (and the other WICG co-chairs) at them, because we have been trying to make this clearer and clearer.

[ekr]

Perhaps, then, our disagreement is on the meaning of the word
"basis". Because I think something that is a good start, but may not
graduate to actually BEING a CGR (if subsequent incubation proves it
is not a good idea), meets that bar. It SHOULD be made clear that's
not the same as the CG making a statement (like a CGR does) that "this
is what the CG thinks is the right solution".

This is the situation for any document that has not yet become a CGR.
Hence I don't see the need for a separate incubation stage.

And yet companies frequently ship specs that are only in WICG and we often get calls to implement those specs.

Indeed, and companies frequently ship specs that are not even in WICG (e.g. https://blog.mozilla.org/netpolicy/2021/10/28/implementing-global-privacy-control/), and we get calls to implement such specs also.

Note that we do not expose any UI for this feature, and you have to enable
it in about:config, in large part because GPC does not have any standards status.
shipped any WICG-only features behind chrome:flags that seems like it would go
a long way towards addressing this concern.

My concern is that asking for engagement and contributions to a
document that does not have clear IP commitments is a Bad Idea; this
is one of the reasons WHY we try to move out from personal repos
asap. If the guidance from this discussion is that THIS CG wants to
hold them at arm's length until they reach some finish line of
acceptability, that's the CG's prerogative, but that doesn't change
that we will need to put them somewhere that is not just a personal
repo. (That's likely to be WICG as a placeholder - again, presuming
such proposals pass the WICG bar of having some other entity agree
it's worth incubating).

Yes, I understand this need, and I'd be open to some creative
thinking here. Perhaps some kind of patcg-individual-drafts
organization that had no access control, like IETF individual
submissions.

[AramZS]

Yeah, I do think we have a specific use case here that is different from WICG, in that we have multiple proposals in the space trying to solve the same problem and would presumably like to pull things from at least some of them as we build a final solution.

[AramZS]

Ok, I have made a number of alterations here to try and incorporate requirements and objections stated on this thread and acknowledge that this may be too much process. It may make sense to remove lines 275 through 312 and not deal with any question of deciding what is in or out of scope, except I would like to preserve some mechanism to remove irrelevant proposals from even a basic space.

The new changes aim to do as follows:

• Create an open space in the form of a GitHub organization (as suggested by @ekr) that any author can bring a document for coverage by IPR protections that the W3C provides that would generally be considered an "incubation" space for relevant proposals.
• Create a mechanism where the community group may consider these proposals and list them in the proposals repository as being in scope of our work.
• Create a mechanism where the community group may eject a proposal as being irrelevant to the work of the community group.
• Make it clear that proposals in that space are not in any way blessed by the community group or its participants. (Towards @martinthomson's concerns.)
• Create a clear distinguishing set of features in that: it is not clear that the work is likely to lead to independent interoperable implementations; that it may not provide an acceptable web experience for users; and that it may not even follow our group or W3C principles. (Towards @martinthomson's concerns.)
• Make it clear that incubation is not a guarantee that a proposal will be raised to adoption.

Clear options for alteration:

• Remove the "in scope / ejection" process
• Add a step where a proposal must be supported by at least one member of the group belonging to an organization different from that proposal's author (similar to WICG)

I agree that this will require some discussion by the group in the upcoming call, but do the participants on this thread believe that this new process has moved the PR towards a state that could be acceptable?

Please feel free to bring forward suggested changes or corrections.

[ekr]

This seems like it creates a lot of unnecessary process.

As far as I can tell, the basic ask here is to have a venue where
people can people can publish their individual proposals and discuss
them under the W3C IPR rules. This seems like it can be solved
quite simply just by:

1. Create a new patcg-individual-drafts org and let anyone have a
   repo there as long as their draft appears to contain any on-topic
   content (i.e., is not just spam).

2. Allow people to have meeting time -- as prioritization permits --
   for drafts that have not yet been adopted.

This doesn't need to be "incubation" and we don't need any new
formal process around it other than the above. Rather, drafts
in the individual drafts repo can just be adopted like any other
draft in another repo upon group consensus with the existing
process?

If people think more is needed, can they explain what problems
this proposal does not solve?

[dmarti]

@ekr This makes sense, except that we would probably be safer all around if the criteria for entry for the new venue were somehow higher than just not being spam. The W3C CLA "sets forth the terms under which I will participate in and contribute to the development of the Specification, if any, created by the Project." If a proposal is not likely to become part of a specification (or even get on a meeting agenda), it doesn't seem like we can count on being able to extend the CLA over it just by moving it to a different GitHub organization.

[ekr]

It's not clear to me how much being on the meeting agenda matters if no specification is ultimately created. This seems like a topic on which we could get W3C legal advice for the minimum bar.

[cwilso]

I want to lead with "I think anything in a CG is ultimately merely an incubation, and I think we're splitting hairs here."

That set aside - something akin to ekr's proposal above (#7 (comment)) would probably be fine. We do need to be careful that ANYTHING submitted into the group should be considered a "Specification", whether it's "accepted" by the CG as a "work item" or not; if this is not true, the CLA would likely not apply (IANAL, TINLA), and then we'd be better off again incubating work in WICG (or any other CG that would consider it a Specification).

I am perfectly fine labelling things the CG hasn't accepted in a way that makes it clear they are "Unaccepted Work Items", "non-Consensus Drafts", "Submitted Proposals", whatever. My point is not to be able to publicly laud these as "THIS IS SOMETHING THE CG IS WORKING ON RIGHT NOW!!" for PR purposes. But we do 1) need to get IPR locked in early (that's one of the major points of doing work in a CG), and 2) need a clear process to follow, or the answer reduces down (in terms of guidance I can give the Chrome team, e.g.) to "just throw things in your personal Github and hope the CG takes them up sometime."

[dmarti]

@cwilso Yes, the standard for acceptance into "incubation" or "patcg-individual-drafts" just needs to be higher than "not spam". A proposal or specification should be some kind of good-faith effort that is aligned with the purpose of the CG.

[seanturner]

@ekr I think I understand what you are are proposing and by new org you mean just that not a repo under patcg.

[ekr]

Right. I am proposing that:

1. We create a new org called patcg-unofficial-drafts-really-we-mean it (or whatever)
2. Anyone can get a new repo under that org

This is effectively copying the IETF I-D policy but making repos so that they can be used for discussion.

[dmarti]

It doesn't look like we can directly copy the IETF policy for Internet Drafts. rfc-editor.org/rfc/rfc8179.txt, "Intellectual Property Rights in IETF Technology", covers "any statement made within the context of an IETF activity, in each case that is intended to affect the IETF Standards Process or that is related to the activity of an Alternate Stream that has adopted this policy" which is much broader than the W3C Community Contributor License Agreement (CLA) | Community and Business Groups which covers "any original work of authorship, including any modifications or additions to an existing work, that I intentionally submit for inclusion in the Specification, and which Contribution is actually included in the Specification." Not every repo that gets moved into the W3C org is necessarily going to fall under that. The way that the policy is written indicates that there is going to need to be more gatekeeping than just a spam filter.

[eriktaubeneck]

@ekr I think I understand what you are are proposing and by new org you mean just that not a repo under patcg.

@seanturner I believe @ekr is referring to the Github concept of an org, as this PATCG org is a collection of repos. So creating a new org such as github.com/patcg-unofficial-drafts.

[ekr]

I don't see gatekeeping helps here.

As I read the text @dmarti provides, there are things that make it into a specification, which are covered, and things which do not, which are not. And by definition, things which make it into a specification are aligned.

[AramZS]

I guess my main concern here is that there are absolutely proposals floating out there that we don't want to think about or need in our orbit and, to the extent that having this other GitHub organization is useful I worry that these proposals coming into a space with no gatekeeping and no method to object will be used as leverage to create activity that we are then forced to moderate in the CG. I fundamentally agree that having a seperate GitHub Org works. I've changed that in this process and proposed an org name to handle it:

<p>Individuals or entities may bring relevant proposals to PATCG for incubation.
PATCG will set up and maintain <a
href="https://github.com/patcg-individual-drafts">a separate space</a> with <a
href="https://github.com/patcg/proposals" title="PATCG Proposals
Repository">name and instructions defined in the proposals repository</a>. Any
individual W3C or PATCG member may bring a proposal to that space with the
understanding it will be governed by W3C rules and the <a
href=https://www.w3.org/community/about/agreements/cla/>W3C Community
Contributor License Agreement (CLA)</a>.

and

Documents may enter this space without <a href=#consensus>consensus</a> from the group.</p>

I think this fulfills the process that you are looking for here @ekr?

Is part of the problem calling it "Incubation"? We can call this section "Individual Draft Management" if that works better for people.

I also think we have a problem managing the view that non-technical press has of proposals that would even enter that space and I think that having a clear requirement for marking the proposals is the best way to resolve that we have right now. So:

The proposal should also have a notice
on the `README.md` file at its base or on the document itself which clearly
states "This document is a draft proposal not currently on track to become a
standard and does not represent an output of the Private Advertising Technology
Community or Working Group."

I also think that having some way to eject proposals is useful. I dislike the idea of a zero-moderation space and I think that is ripe for abuse of our time and focus. Being able to define a proposal as in-scope or out-of-scope on the suggested guidelines and adding it to the proposals repo is a good way to moderate the space and our focus without preventing authors from collaborating in the space. Until such a decision is made, any proposal is free to enter the GitHub Org, be collaborated on under the CLA, and continue work.

But I do think that where a proposal cannot meet the very low bar of

<li>address a genuine need for web users, for creators of
 advertising-supported websites, for advertisers, or to support an existing need that may
 be impaired by advancing privacy properties;
<li>provides or could provide acceptable privacy properties for users;
<li>provides or could provide an acceptable web experience for users;

I think it makes sense to have an action available, otherwise we would have no grounds to reject a repository even if the space was being used for something out of scope or outright abusive.

I strongly feel that a mechanism by which we might eject a repository from this space is needed and since any such ejection has a chance of being objected to, we need to have a process in place for it. I think that's reasonable? If the process itself is at fault I'd rather refine it then remove it.

[eriktaubeneck]

I strongly feel that a mechanism by which we might eject a repository from this space is needed...

I second this suggestion. I would even propose updating your language to include

Documents may enter this space without <a href=#consensus>consensus</a> from the group, however the group can remove documents by consensus.</p>

[AramZS]

@eriktaubeneck Done.

I've also made some small changes to remove the word "incubation" and make the document, as a whole, clearer about the separate status of that space.

[ekr]

This still seems way too complicated. Here's a revised, much smaller, PR. #15

[AramZS]

Resolved in #15