Web Payments Working Group Teleconference

25 Aug 2016


See also: IRC log


Manu, Ian, alyver, DJackson, dlongley, ShaneM, AdrianHB, Roy, Max, DavidEzell, dezell, rouslan, adamR
NickTR, Zach


Draft TPAC agenda

TPAC draft agenda https://github.com/w3c/webpayments/wiki/FTF-Sep2016


<AdrianHB> ian: [talking through agenda]

<AdrianHB> ... will speak to editors in advance about reporting on their work and how it will evolve

<AdrianHB> ... still a wip

<Zakim> ShaneM, you wanted to ask if we anticipate any discussion of the patent stuff?

Issue and pull request triage

AdrianHB: I think it will take me about a day to do the triage. I think the group has evolved to the point where I think we should review our process.
... there are specs where there has not been activity and they don't come up on calls. I would like to delegate some of the triage responsibility to the editors
... this is a question to the editors - how do you feel about taking ownership of issues lists and pull requests, and to the group: do you think this is a good idea?
... do we want editors to be able to define labels and milestones, or to keep consistency?

Shane: I think it's reasonable to ask editors to take on maintenance of issues.
... Are you open to editors delegating?

AdrianHB: Yes
... When we come to meetings, as Chair I am ok to round up what to discuss, but now we have multiple issues lists and that's more complicated.

<ShaneM> multiple specs per repo is an anti-pattern...

AdrianHB: AdrianBateman had proposed at one point a single issues list; I wonder if we should go back to "one repo"

<Roy> +1 not a million repos

manu: +1 to have editors manage their own issues

<Zakim> manu, you wanted to take responsibility for issue lists, but not going to be processing them.

manu: I was a proponent of centralized issues list; but I don't think that will help us now. I think decentralizing management is appropriate and delegation to the editors is fine
... editors can ask for time on a call to address their needs, and chairs make a decision given priorities
... I expect nothing to happen with the http api specs until the group decides they want issues to pop up

<ShaneM> payment app, payment method identifiers, browser payment request, overview?

AdrianHB: My assumption was that anything that's an editors draft is a work in progress that the Editors can work on. Work can continue even if Chairs don't put time on agenda
... and doesn't need to consume group time.
... I definitely don't think we should have a bunch of stagnant repos out there

manu: That's not my understanding of our agreement. We are not processing issues because that would take away participant time.
... My understanding was that we would not do work on HTTP API or pull people away.

<dlongley> we're happy to start processing and discussing those and we have asked to do parallel work

AdrianHB: There's a difference between "getting on with the work" and "pulling people away".
... people who want to get involved can. The concern was taking away time from group meetings.
... each group member can choose how to spend their time.
... but the chair focus is to get the prioritized work to advance

<Zakim> ShaneM, you wanted to clarify what we are doing on HTTP API and messages

shanem: Do HTTP API repos trigger emails to group?

AdrianHB: Yes. But I trust people to manage their email input

<manu> Ian: This is a delicate balance, the Chairs have not put some time for HTTP API on calls. I would not support using the main group mailing list for active discussion on HTTP API.

<adamR> +1 to Ian’s point

<manu> Ian: I don't care if Github sends messages to us, but if now I'm getting a solicitation on the groups' mailing list on the HTTP API, it will take attention away from the group.

<AdrianHB> ian: it's been clear that the chairs have not put much meeting time aside for HTTP API but we're keen to set aside at f2f

<manu> Ian: I've appreciate the opportunity to focus, editors can do work, but let's try to find a balance where it doesn't overwhelm the groups communication channels.

<ShaneM> I reserve the right to send emails to the working group... even on topics that are not at the top of the priority list.

Shane, I didn't ask you not to use the list for the group at all. Only to find a balance wrt priorities.

<manu> Ian: We can turn off automatic notification to the group. I don't mind leaving it on now, but if there is going to be a huge flurry of work, people that want to pay attention, they can pay attention to the repo.

AdrianHB: I would encourage people to work on the specs. If we decide there is too much traffic on the list we can turn off monitoring for example.

Status of pull requests on payment request API etc.


AdrianHB: Editors, can you provide us with some updates?

Roy: The only one I'm aware of is around PMIs...Zach's proposal has not yet been adopted.

IJ: When is your editor sync generally?

Roy: Tuesdays

IJ: Could you check in with the editors on status (e.g., as a one-off with note to the WG, or certainly in time for next call)?

<Zakim> Ian, you wanted to ask roy about push

IJ: Roy, was a dedicated group created to work on this?

Roy: Not yet.
... I hoped to raise during one of the calls.




IJ: Have the editors discussed this?

Roy: We've had a bit but mostly lately focused on PMIs
... I am not hearing much support for the straw man proposal.

<Zakim> manu, you wanted to say we're interested in push payments.

Manu: Our organization is interested in push payments. We did review the PR and have some thoughts on how push payments should be done, different from what is proposed. Are you interested in the deeper discussion, or addressing the specific question of communication failures during payment request API?

[IJ: +1 to addressing the immediate concern for payment request API]

Manu: We are also looking at push payments in HTTP API context.

Roy: Welcome to the focus group!
... The direction I have in mind is failure modes.

AdrianHB: To recap - the idea is to avoid fragmentation in how we deal with push payments.
... I think push payments are quite important...most non-card payments are push

<dezell> NACS/Conexxus are extremely interested in push payments.

Max: We are also interested in exploring what we can do about push payments

<ShaneM> +1 that paypal / alipay are examples of "push"

AdrianHB: I think we should start by looking at the issues logged against the straw man and revise it; I think it's important to sort out on these calls.

<scribe> ACTION: Roy to prepare a "state of affairs", due 2016-09-01 [recorded in http://www.w3.org/2016/08/25-wpwg-minutes.html#action01]

<trackbot> Created ACTION-28 - Prepare a "state of affairs", due 2016-09-01 [on Roy McElmurry - due 2016-09-01].

<Roy> +1

AdrianHB: I am happy to put this on our tpac agenda

<ShaneM> +1 to putting it on the agenxda

<ShaneM> at TPAC

testing plan

Mike: I've filed some pull requests based on testing needs.
... there are some missing normative requirements that make it hard to test (and thus use)
... once we start to do more testing I'm sure we will start to find more cases
... I hope that we can work out something with the editors so that we can iterate quickly
... to update the spec and make it more precise

<manu> +1 to note that requirements on users of the API are problematic.

Shane: We have some requirements in the spec today on "users" of the app (e.g., "one or more payment request URI")....
... Do we want to be rigorous in the spec about error handling?

<manu> We should re-cast as throwing an error

<dlongley> i think the spec should say an error must be thrown

IJ: I was going to ask implementers what they are doing

<Zakim> manu, you wanted to give some thoughts.

manu: we should not suggest to people that if you do the wrong thing it will still work

<manu> Agreed, stuff that is not testable is throw-away text (if there are MAY, etc.)

[Discussion of notes v. normative]

<manu> Agreed, we should not use RFC terms if it's optional stuff that demonstrates that we thought about it and decided not to do something.

Shane: Can talk about requirements on optional features

AdamR: Not sure I agree; let's discuss offline

Shane: How do we exercise payment request API in the absence of a payment app.
... how do we test flow of messages?

<manu> Shane is asking a deeper question, adrianhb

<Zakim> AdrianHB, you wanted to say I disagree slightly :)

<AdrianHB> ack

IJ: Right now we don't have payment apps in payment request API so that I don't know what to test.

<Zakim> manu, you wanted to note that Shane's asking a more nuanced set of questions. It's about test suite design and how we're going to do it.

<Zakim> ShaneM, you wanted to say that we *could* have a testing requirement that there is a mediator supplied payment method so that we can test

AdrianHB: Is the assumption that browsers must have basic card supported natively out of the box?

AdamR: If we made it explicitly required for testing, that is probably reasonable but I want to hear from other browser vendors

<ShaneM> ACTION: ShaneM to ask the list about implementors and what they can support for an extant payment method for testing purposes. [recorded in http://www.w3.org/2016/08/25-wpwg-minutes.html#action02]

<trackbot> Created ACTION-29 - Ask the list about implementors and what they can support for an extant payment method for testing purposes. [on Shane McCarron - due 2016-09-01].

<adrianba> we've tested things like this before - we don't necessarily need to rely on one specific method

<ShaneM> adrianba: cool

<adrianba> for example, we've tested media elements where not all implementations support the same formats

Issue and pull request triage

APA request


IJ: Please review that email and comment on the list

Shane: I authored the text (within the APA)

AdrianHB: +1 to the editors of the specs looking at it.

<ShaneM> non-normative text

IJ: I am a bit cautious about "the implementation must ensure that the interface

for those interactions is exposed to the platform accessibility API."

ShaneM: That's not an rfc2119 must

IJ: I think it's appropriate to draw attention to guidelines; may not need a whole paragraph.

<Zakim> ShaneM, you wanted to talk to the APA guidance briefly

On the overview document

AdrianHB: I have shared with some people who have found it useful; some editing in order...I think it would be a valuable tool to be able to share with people.

<manu> Ian: I have also shared the Overview document, I offer that the next revision of it should follow TPAC. It should reflect our understanding of the world after TPAC.

<ShaneM> Note that there is a publication moratorium starting on 15 September.


1 September

Summary of Action Items

[NEW] ACTION: Roy to prepare a "state of affairs", due 2016-09-01 [recorded in http://www.w3.org/2016/08/25-wpwg-minutes.html#action01]
[NEW] ACTION: ShaneM to ask the list about implementors and what they can support for an extant payment method for testing purposes. [recorded in http://www.w3.org/2016/08/25-wpwg-minutes.html#action02]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/09/01 16:02:21 $