Revised triage [Was Payment Handler issue triage [Was: [Agenda] 4 April Payment Apps Task Force teleconference]]

Hi all,

The Payment Apps Task force today discussed [1] and revised the list of issues going into FPWD for Payment Handler.
I’ve given two milestones to our list for discussion thursday:

 * Mark in FPWD:
   https://github.com/w3c/webpayments-payment-apps-api/milestone/1

 * Close before FPWD:
   https://github.com/w3c/webpayments-payment-apps-api/milestone/2

I believe all the ones to close before FPWD are easy to do and therefore should not be seen as “blockers” other than
the Editors doing the edits.

Ian

[1] https://www.w3.org/2017/04/04-apps-minutes


> On Apr 3, 2017, at 5:25 PM, Ian Jacobs <ij@w3.org> wrote:
> 
> 
>> On Mar 31, 2017, at 10:45 AM, Ian Jacobs <ij@w3.org> wrote:
>> 
>> Participants in the payments app task force,
>> 
>> We meet 4 April at 10am ET. I expect by then to have a proposal for how to 
>> triage issues preparing for FPWD. I’d like to review that proposal at the meeting.
>> (I won’t have it until end of day for me on 3 April.)
>> 
>> I am likely to organize the issues something like this:
> 
> [Snip]
> See proposal below.
> 
> Ian
> 
>> WebEx: 
>> http://www.w3.org/2017/01/paymentapps-2017.ics
> 
> 
> ======
> Here's an initial categorization of issues with First Public Working
> Draft in mind:
> 
> - Substantive to address before FPWD
> - Substantive to address after FPWD (and mark in the spec)
> - Editorial to address before FPWD
> - Editorial to address after
> - Potentially close with no change
> 
> For reference, here's the issues list:
>  https://github.com/w3c/webpayments-payment-apps-api/issues
> 
> Ian
> 
> ==================================
> Substantive to address before FPWD
> 
> 120: Origin should include iframe(s)
>    Rationale: Rouslan has a proposal; can we agree to it?
> 
> 111: `appRequest` attribute should not be a dictionary
>    Rationale: The original suggestion from Rouslan was incorporated;
>    Marcos has an additional proposal; it seems like we could work through
>    this in time for FPWD
>    https://github.com/w3c/webpayments-payment-apps-api/issues/111#issuecomment-287944141
> 
> ==================================
> Substantive to address after FPWD
> 
> 124: Clarify what information user agents forget at various moments
>    Rationale: If the specification evolves a lot (as is likely), the
>    answer to this question will evolve as well. Suggest we add an
>    issue marker in section 8.1 ("information about the user
>    environment").
> 
> 123: Share user data with Payment App
>    Rationale: Include a marker in the spec in order to draw attention
>    to this issue and gather data.
> 
> 119: PaymentRequestEvent incompatible with DOM events
>    Rationale: Marcos raised this. In light of the focus on PR API, I suggest
>    we simply log this to address later.
> 
> 116: Relation between merchant order of payment methods and payment app order of instruments
>    Rationale: There is a related issue on Payment Request API, and that
>    issue may be resolved after FPWD. Therefore, I suggest we leave this
>    one open and in the spec. We should also review 6.1.
> 
> 
> 97, 115: Different approaches to opening windows
>    Rationale: Marcos and Tommy working on this, and working to align
>    with the SW Open Window Algorithm
> 
> 94: Add explicit permission call to allow payment app to handle payments
>    Rationale: We know we want this, and there is already a note and
>    example of one way to do this that can help review.
> 
> 23: Analyse security properties of payment app execution environment
>    Rationale: Continue to ask this question ongoing
> 
> ==================================
> Editorial to address before FPWD
> 
> 122: Clean up respec errors and "tidy" the markup
> 
> 109: Renaming PaymentApp* classes
>    Rationale: This may have been done via an Adam Roach edit. Tommy Thorsen
>    has a few additional suggestions.
>    https://github.com/w3c/webpayments-payment-apps-api/issues/109#issuecomment-287705543
> 
> 
> ==================================
> Editorial to address after FPWD
> 
> 50: Links to terms and common terminology
>    Rationale: As the specification fills out, references will become
>    more precise.
> 
> 49: Pictures would help
>    Rationale: Part of a larger merchant adoption strategy effort
> 
> ==================================
> Potentially close with no change
> 
> 117: Support for Abort() being delegated to Payment Handler
>    Rationale: This seems primarily to be an issue about PR API.
> 
> 105: What is a Payment App?
>   Rationale: The specification scope is narrowed to defining a feature
>   of the Web platform. We answer the question in the specification.
> 
> 84: Recommended payment apps
>   Rationale: The specification no longer speaks about recommended payment
>   apps.
> 
> 69: What does "icon" mean?
>   Rationale: This is addressed by the draft. 
> 
> 5: Display may be subject to user and local policy.
>   Rationale: Issue is underspecified
> 
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
> 
> 
> 
> 

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Tuesday, 4 April 2017 16:29:28 UTC