-
Notifications
You must be signed in to change notification settings - Fork 178
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
Comments
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? |
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. |
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.
I agree we need to know exactly which of the three has multi implementer support and will move. Thanks! |
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 |
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? |
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. |
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. |
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. |
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. |
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. |
Doc looks good to me. I added a few references to other proposals (e.g. cross-device) and use-cases. |
I made some minor edits. Note that we are not members of PATCG, at least not yet. |
Thanks! I plan to create the GitHub issue for the proposal in the PATCG repo toward the end of the day (Pacific time). |
I plan to add a few suggestions today. Will do so before noon (PT) so you can file the issue today, @erik-anderson. |
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
The text was updated successfully, but these errors were encountered: