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

Defer Contact Picker API position #266

Merged
merged 2 commits into from Feb 13, 2020
Merged

Defer Contact Picker API position #266

merged 2 commits into from Feb 13, 2020

Conversation

@tantek
Copy link
Member

tantek commented Feb 8, 2020

Closes #153.

Closes #153.
@tantek tantek requested a review from dbaron Feb 8, 2020
Copy link
Collaborator

marcoscaceres left a comment

Couple of suggestions.... take 'em of leave 'em. I don't mind :)

@@ -35,6 +35,18 @@
"title": "BigInt",
"url": "https://tc39.github.io/proposal-bigint"
},
{
"ciuName": null,
"description": "This proposal adds an API for prompting and querying the user’s contacts for one or more items with a handful of contact properties.",

This comment has been minimized.

Copy link
@marcoscaceres

marcoscaceres Feb 10, 2020

Collaborator
Suggested change
"description": "This proposal adds an API for prompting and querying the user’s contacts for one or more items with a handful of contact properties.",
"description": "This proposal adds an API for prompting and querying the user’s contacts for one or more items with a handful of contact properties. The API improves privacy over several previous Contacts APIs, but uses different properties than HTML autofill field names",
"id": "contact-picker",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "This API innnovates in some ways beyond several previous Contacts APIs, though leaves their source unspecified, and uses different properties than HTML autofill field names.",

This comment has been minimized.

Copy link
@marcoscaceres

marcoscaceres Feb 10, 2020

Collaborator

The current text states facts about the API, but don't really relate to the position. How about:

Suggested change
"mozPositionDetail": "This API innnovates in some ways beyond several previous Contacts APIs, though leaves their source unspecified, and uses different properties than HTML autofill field names.",
"mozPositionDetail": "Although we see this API as a non-harmful addition to the Web, Mozilla defers working directly on this API at this time. We encourage the WICG community to continue to iterate on a data model that is well-suited for representing contacts in a manner that is both privacy preserving and OS independent.",

This comment has been minimized.

Copy link
@adamroach

adamroach Feb 10, 2020

Collaborator

Two quick comments -- (1) My understanding is that "defer" indicates that we are deferring stating a position pending additional data or other developments. Your proposal takes it to mean something subtly different (deferring standards work, which is related but not exactly the same thing). (2) While I understand where you're coming from with the phrasing "working directly on this API," it's easy to see how external parties my read "working" as "implementing" rather than "contributing to its specification." I believe phrasing like "...working directly on this API specification..." would make this less likely.

This comment has been minimized.

Copy link
@marcoscaceres

marcoscaceres Feb 10, 2020

Collaborator

Good suggestion re: 2.. and also good points about 1. "Defer" is indeed, "Mozilla does not intend to look at this specification at all in the near future." I guess I got confused because we did look at it, but now we won't be investing any more time looking at it at all. I'm indeed biased as WICG Chair, as I do duck in an out of a lot of WICG specs as part of my day to day work.

This comment has been minimized.

Copy link
@dbaron

dbaron Feb 11, 2020

Member

Yeah, I think Marcos's suggestion doesn't fit with a "defer" position. I'd be OK with the part about moving it into the description, though. That would leave the "detail" part almost blank -- though Tantek has a "leaves their source unspecified" that Marcos didn't copy, and I'm also not sure what that means. @tantek should we drop or move that part as well?

This comment has been minimized.

Copy link
@marcoscaceres

marcoscaceres Feb 12, 2020

Collaborator

Yeah, I think Marcos's suggestion doesn't fit with a "defer" position.

Re-checked my assumptions there. We should maybe clarify that a bit in the README where "defer" is defined... if I got it wrong, then likely others internally and externally folks are interpreting it incorrectly.

There still needs to be something that says "we think this is in good hands, even though we don't have the resources to participate right now." Or is that not a thing?

Tantek has a "leaves their source unspecified" .. I'm also not sure what that means

I wasn't sure either... I was guessing that means the OS or app (e.g., Contact.app)? Revealing that would be weird tho. @tantek?

@tantek

This comment has been minimized.

Copy link
Member Author

tantek commented Feb 12, 2020

I agree with @dbaron about Marcos’s suggestion doesn’t fit with a "defer" position.

I also strongly disagree with even hinting that we might think this API is "non-harmful" when that hasn’t even been mentioned in #153 — in fact quite the opposite, I noted explicitly there that "I’m leaning towards expecting an eventual 'harmful' evaluation."

So I’m not ok with moving it into the description, and that is unnecessary for a defer position. I’d like us to be able to actually defer rather than debate more details in the description.

Re: "leaves their source unspecified", I’m ok with dropping that from the description, it’s not really an actionable criticism outside of a thorough evaluation. I’ll update the PR accordingly.

(Originally published at: https://tantek.com/2020/042/t3/)

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

marcoscaceres commented Feb 12, 2020

I noted explicitly there that "I’m leaning towards expecting an eventual 'harmful' evaluation."

Why? It does a reasonable job at being privacy preserving - or did I miss something?

@tantek

This comment has been minimized.

Copy link
Member Author

tantek commented Feb 12, 2020

> Why? It does a reasonable job at being privacy preserving - or did I miss something?

Please ask follow-up questions of a potential eventual "harmful" evaluation like that on #153, rather than asking here on a pull request to "defer".

I’m also requesting "us to be able to actually defer rather than debate" a specific eventual evaluation.

(Originally published at: https://tantek.com/2020/042/t4/)

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

marcoscaceres commented Feb 12, 2020

Will follow up in the bug if need be. Thanks again @tantek for putting this together!

dropped unactionable criticism of "leaves their source unspecified"
@dbaron dbaron merged commit 4684979 into mozilla:master Feb 13, 2020
@dbaron

This comment has been minimized.

Copy link
Member

dbaron commented Feb 13, 2020

I merged this as-is. On thinking further about description versus mozPositionDetail I realized we've generally used the description straight from the spec's own abstract when that text was appropriate (it's what activities.py does by default), so I think leaving the slight bit of editorializing in the detail seemed like the right thing.

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

Successfully merging this pull request may close these issues.

4 participants
You can’t perform that action at this time.