See also: IRC log
<scribe> scribe: Ian
Nick: Thanks, manu, for starting the conversation
<nicktr> https://github.com/w3c/webpayments/issues/89
<Zakim> manu, you wanted to note AdrianB's issue.
manu: Chatted with AdrianBA
yesterday
... he has one to add
... We should do technical things first (before strategic or
operations)
... I agree with Zach we should deal with the hard issues where
nuance is important
... first issue is are we doing low level, or both low and
higher level?
... there's also a question around shipping address...I think
that there is agreement among editors to support the shipping
use case.
... question around payment app registration. What is an app?
How are they installed?
... answering that question will then help us answer question
about how to communicate with payment apps.
... Question "5" will be about "how will we do things like
feature detection" in API (e.g., does it support billing
address)?
... question 6 is about use of events/promises...what is the
interaction pattern (if we do a checkout API)
<Zakim> AdrianHB, you wanted to discuss Zach's comment as a first step
AdrianHB: We should order these
questions so we can build on them
... manu said "there is consensus among editors to support
shipping." So I think we should put that to the group and move
on from there, accepting that as a requirement.
... I think we need to put pins in some requirements
... I think we have a spectrum of options (from "just payment"
to checkout)...and in the middle we have "everything in one API
but with some additional features"
... let's nail down the requirements and then answer some of
the questions on the back of that
IJ: Let's tease out requirements as AHB has started to do
<Zakim> manu, you wanted to note AdrianB's concerns about having discussions at too high of a level.
IJ: e.g., developer usability
Manu: I agree that some conversations are happening at "too high a level"...
<adrianba> i'm fine with making sure we agree on what problems we want to try to solve
manu: It may be hard for us to come to ground on requirements quickly at FTF meeting
<adrianba> my criticism was more about arguments about the type of technology we might use
Manu: The specs have developer code we can look at
(as far as comparing code as a way to pick most dev-friendly design)
<AdrianHB> +1 to getting agreement on the goals/requirements up front (and quickly if we can)
IJ: You need to articulate the requirement (e.g,. "performance") before making some design decisions.
<Zakim> AdrianHB, you wanted to request that we see some example developer code
AdrianHB: Regarding developer
code, one of the requirements we should consider in how we look
at our approaches is: what will it look like when a developer
writes a site that uses this API?
... we should take common use cases and write the code that a
developer would have to write to use the APIs...and compare
them
... this suggestion from W3C staff
... it would be good to have such examples going into the
meeting...or can choose them on day one
... On the question of "what is a payment app"...I think that
we are not all in agreement about how an app will
materialize...
... e.g., is it a native app on mobile?
... or a native app on desktop or iframe or browser extension
or service worker?
... we should talk about what that thing is going to be
<Zakim> manu, you wanted to ask if he should try restating the questions as questions around goals?
Manu: we could frame questions about goals
Some ideas:
<dlongley> https://github.com/w3c/webpayments/issues/89#issuecomment-185819392 <-- i put some suggestions here for high-level goals w/respect to APIs
Nick: Helpful for people to express what they think the goals are
adrianhb: I think chairs need to
structure discussion (which you've touched on on your
thread)
... we need to do more work
... I expect we will need to iterate
... It hasn't been mentioned yet, but we will need to go back
and look at horizontal review stuff
... we should iterate through those requirements quickly
(security, privacy, accessibility)
... and how our design decisions to date reflect those
requirements
... e.g., not sharing payment method information with
merchant
<mountainhippo> ack
IJ: Personally I think that those topics are really important but our decisions right now seem unrelated; but later let's absolutely add sections to the spec on various considerations.
<Zakim> manu, you wanted to agree with Ian, we may want to cover this stuff if we start having awkward silences on day 2
(e.g., privacy, security, i18n, accessibility)
+1 to not "forgetting" to do these things
[Strategic questions]
Manu: What data do we have to study in order to see if the APIs will meet their goals?
[IJ thinks we will not get some data until later]
Manu: Another topic is how to extend API without breaking implementations?
nick: Flows help us ground discussion in real payments
<Zakim> manu, you wanted to note that we may want to have a spec update at the beginning of the meeting.
manu: I would like the editors to
frame "where we our with specs" when we start meeting.
... some people may not be able to read specs before
meeting
IJ: I would rather use time for looking at code side-by-side rather than edit history
nick: We will have new
participatns
... although I am not advocating a full edit history, I think
there is value in:
* Reiterating how to prepare for the meeting (which materials available)
* Introducing people to the specs
nick: so I support a (not long) contextualization
<Zakim> manu, you wanted to not that we don't have demos for some of this stuff, only spec code examples and to note that he only meant introducing people to the specs.
(IJ still feels it would be important to look at code as a better way to understand the specs)
manu: I did not mean edit history...I meant intro to the spec
<mountainhippo> +1 to manu's suggestion
manu: we are talking about 3 specs
IJ: I can live with 15 mins to intro 3 specs
adrianHB: Manu and Ian surfaced something we should clarify
<Zakim> AdrianHB, you wanted to clarify the focus for the f2f
adrianHB: that we will focus on
the browser API
... we will consider then how that work affects other specs
we've talked about doing
... but the focus for this FTF is to get us to a FPWD of
browser spec
<Zakim> manu, you wanted to say he's not comfortable, but doesn't feel there is support to look at other specs.
manu: I am not comfortable that we are pushing off other specs but understand people want to focus on browser API
<ShaneM> +1 to getting something done. whatever that something is. We need "points on the board"
manu: if we have extra time we can talk about HTTP API and others
<Zakim> mountainhippo, you wanted to note that he is going to bring a short demo of HTTP api use case and some docs
nick: I will bring a short demo
of an HTTP API
... something that might be useful for HTTP API discussions to
come
<AdrianHB> +1 to other API discussions if we have time (even if the editors break out for a short session)
[Operational topics]
+1 to CG discussion at AC meeting as AHB suggested
Manu: I think that there are
questions like who the editors are and mechanics of getting
specs into repo
... I am concerns about transparency in this group
-1 to CG discussion at our FTF meeting
<VincentK> * VincentK has to leave for another meeting
I *totally* agree technical work needs to be done in public.
And having access to all the information avoids silos of understanding
nick: I take Manu's concerns seriously.
<manu> +1 to that - we all want the same thing
<dlongley> +1
<manu> we haven't been executing in that way.
Totally ready to blame NickTR to speed things up
<manu> https://github.com/w3c/webpayments/issues/89#issuecomment-185171992
would like to add either to the agenda or as an issue the following;
Adoption/Transition of the API
a. Finding the relevant payment application
b. If merchant can prefer one payment app over another if there are multiple apps that can perform the same method
b. Fall-back methods when no such app exists (or the shopper doesn't want to sign-up to the terms & conditions)
c. What our expectation is for situations where the merchant wants to override the 1.0 implementations to better control the flow
<manu> +1 this is an important point to discuss
<AdrianHB> +1
matt: We have too many places where agenda is being developed
(Yes, we need to consolidate)
<manu> +1 to consolidate
<manu> (someone needs to take an action on that)
(I hear AHB will drive that)
Shane: With my test czar hat on...very important but haven't done anything yet since nothing to test yet.
<Zakim> ShaneM, you wanted to mention that we need to start making progress on testing too
<Zakim> zkoch, you wanted to mention some quick logistical things about FTF at google
Zach: Remember elevator story ... get there before 9am or you will need to check in
shepazu: Parking?
zkoch: Nothing special; public parking