See also: IRC log
TPAC draft agenda https://github.com/w3c/webpayments/wiki/FTF-Sep2016
https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login
<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?
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.
https://github.com/w3c/browser-payment-api/pulls
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.
https://github.com/w3c/browser-payment-api/pull/223
https://github.com/w3c/browser-payment-api/pull/223
https://github.com/w3c/browser-payment-api/issues/224
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
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
https://lists.w3.org/Archives/Public/public-apa/2016Aug/0086.html
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
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