Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move this proposal to the PATCG #262

Closed
csharrison opened this issue Nov 1, 2021 · 14 comments
Closed

Move this proposal to the PATCG #262

csharrison opened this issue Nov 1, 2021 · 14 comments

Comments

@csharrison
Copy link
Collaborator

This is an issue to discuss the transition plan to move this proposal into the PATCG.

This venue will include more folks and its charter fits the proposal very well. Let's use this issue to discuss the nuts and bolts of moving there. One thing that would be good to discuss is what should happen to the current biweekly meetings that we hold today. There is a preference in the PATCG (see this issue: patcg/meetings#4) for longer, less frequent meetings with fewer breakouts and an emphasis on collaboration through github.

I am interested to hear everyone's thoughts on this working style vs. what we currently do today. We can discuss in the upcoming PATCG meeting (Monday, November 8th at 9am Pacific (PST)/12pm Eastern (EST)/5pm London (GMT)) if people have strong feelings one way or another. We would adopt the new structure once the proposal is accepted by the cg and we move the repo over.

cc-ing folks who participated in the discussion on this in today's call: @eriktaubeneck, @erik-anderson @johnivdel @eriktaubeneck

@johnwilander
Copy link

We'd need to figure out "further work is likely to lead to independent interoperable implementations" first, right? https://patcg.github.io/charter.html#adopt Or is that already established?

@martinthomson
Copy link

I'm supportive of moving this[*] to PATCG. This work is directly in their remit, which is far better scoped than WICG.

However, can you clarify what "this proposal" means exactly? There are at least three different designs in this repo. My view is that this work provides valuable input, but I don't know if this exact design (any of those proposed in this repo) is what will work. There is probably a bit of ground work needed in PATCG to determine what the goals need to be before we can answer John's question regarding anything.

@johnwilander
Copy link

I'm supportive of moving this[*] to PATCG. This work is directly in their remit, which is far better scoped than WICG.

Just so I understand, is that Mozilla expressing a position that they'll likely implement? I'm asking because I want to dedicate time and effort to the right proposals given that we have so many and complex ones.

However, can you clarify what "this proposal" means exactly? There are at least three different designs in this repo. My view is that this work provides valuable input, but I don't know if this exact design (any of those proposed in this repo) is what will work. There is probably a bit of ground work needed in PATCG to determine what the goals need to be before we can answer John's question regarding anything.

I agree we need to know exactly which of the three has multi implementer support and will move. Thanks!

@martinthomson
Copy link

is that Mozilla expressing a position that they'll likely implement?

No. We are interested in having a solution to this general class of problem, but we're in no position to support any of these proposals.

Mozilla's view is that we should have a solution (or solutions, in a pinch) for the problems we see in this general area. We also are firmly of the view that the PATCG is the right place to decide what that solution looks like.

What I'd like to see is that $ENTITY (whether that be Google or Apple or Mozilla) propose that PATCG adopt their work. But I'm more interested in $ENTITY committing to working with PATCG on solutions, whatever those solutions end up looking like.

@AramZS
Copy link

AramZS commented Nov 4, 2021

I think this approach sounds reasonable, that we have a more general 'this is the concept we want to handle (conversions) and there are a number of proposals towards that which we'd like to discuss in PATCG in order to reconcile them into a single proposal' with the goal of a reconciled single proposal than making its way to the working group we intend to form; if that makes sense to all participants?

@csharrison
Copy link
Collaborator Author

This seems reasonable to me Aram. I'll raise this to the rest of the folks working on this proposal in our next scheduled meeting (Nov 15) to solicit some more feedback.

@erik-anderson
Copy link

Per the call we had yesterday, I proposed working with interested folks to write a very high-level proposal for PATCG to get conversion-related work started there. @csharrison and @eriktaubeneck expressed interest in helping craft that, but others are welcome as well.

I started a draft doc. Folks that are interested in collaborating-- feel free to make edits directly and/or add comments. I'd like to bias toward starting the conversation over there, so I'd like to have someone (maybe me) create the proposal issue within the next week or so.

@johnwilander
Copy link

johnwilander commented Nov 17, 2021

Is there a path to "a reconciled single proposal" here? I'd love for there to be one.

WebKit has continuously expressed opposition to the cross-site tracking aspects of Attribution Reporting API. We do not want tracking of individual users' activity across websites to become a web standard. That is the reason why we have not seen a path to consolidate Attribution Reporting API with Private Click Measurement.

@erik-anderson
Copy link

My suggestion would be to have a very broad starting point. Folks want to "solve measurement," so let's start with that.

If, as we work through it in the PATCG, it becomes clear there's no path forward for certain aspects in terms of getting something that would be suitable for transferring to a WG, then I would expect those areas to be pruned over time.

I don't think we will get agreement on the appropriate scoping prior to discussing it in the PATCG, though. If that is a prerequisite, then I fear we will be discussing for a long time outside of the PATCG and not leveraging that group to move things forward.

I certainly hope that, over time, that group will be able to collaborate to create a unified proposal.

@csharrison
Copy link
Collaborator Author

I agree with Erik. It makes sense to bring the use-case to PATCG and work from there on a deciding if a reconciled single proposal is possible, rather than deciding that right now.

@csharrison
Copy link
Collaborator Author

I started a draft doc. Folks that are interested in collaborating-- feel free to make edits directly and/or add comments. I'd like to bias toward starting the conversation over there, so I'd like to have someone (maybe me) create the proposal issue within the next week or so.

Doc looks good to me. I added a few references to other proposals (e.g. cross-device) and use-cases.

@johnwilander
Copy link

I made some minor edits. Note that we are not members of PATCG, at least not yet.

@erik-anderson
Copy link

Thanks! I plan to create the GitHub issue for the proposal in the PATCG repo toward the end of the day (Pacific time).

@eriktaubeneck
Copy link

I plan to add a few suggestions today. Will do so before noon (PT) so you can file the issue today, @erik-anderson.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants