W3C

Web Payments Working Group Teleconference

14 Apr 2016

Agenda

See also: IRC log

Attendees

Present
dezell, Ian, ShaneM, nick_s, AdrianHB, dlongley, manu, AndChat|, rouslan, Cyril, zkoch, Daren, CyrilV, shepazu, MattS, VincentK, jyrossi, BrianSullivan
Regrets
NickTR
Chair
Ian
Scribe
manu

Contents


<scribe> scribe: manu

Call for Consensus to publish FPWDs

Ian: Thanks all for feedback

<Ian> https://github.com/w3c/webpayments/wiki/CFC_20140412

Ian: The summary can be found at the link above.
... Based on the feedback, the Chair decision is to publish 3 of the 4 drafts, all but the architecture document.
... There will be an email to make that easy to find in the mailing list archives. We have lots of responses, strong support for 3 of the 4 specs. We'll continue to improve the architecture document.
... We'll return to the publication request once we have more support.

<dlongley> manu: What's the publication date?

Ian: We request that the director approve the transition to FPWD of the 3 docs - we'll request publication for April 21st.

<Ian> https://www.w3.org/2016/03/15-wpwg-blog.txt

<Ian> IJ will update the blog post to appear on w3.org/payments/WG

Ian: We have this blog post for update - linked from that is the FAQ

<Ian> https://github.com/w3c/webpayments/wiki/PaymentRequestFAQ

Ian: I'd like to understand whether there are any objections for publishing this FAQ w/ specs and blog post notice based on final list of specifications. I'll do that.

<Zakim> ShaneM, you wanted to ask about future updates?

Shane: Do we have a plan going forward for how stuff is rev'd over time?

Ian: The next agenda item discusses that.
... There is a separate topic that we'll cover over the next few weeks - what are the next things that will come to our Agenda. Three proposals, another one on messaging, reorganizing the documents, so there are no current plans for architecture, proposals on how to improve it.
... I hear no objections for publishing FAQ to mitigate concerns raised.
... Congratulations to everyone on the first drafts, still more to do, but a valuable milestone.

Decision and publications process after FPWD

Ian: Mike, are you here?
... Since Mike is not here and it's very late in Tokyo - assuming he couldn't make it, I'll try to cover this.
... The high-level observation moving forward, once we've passed monolithic requirement for pushing spec, we can make finer grained updates henceforth. W3C has an automated publishing process to push finer grain updates.
... Today we make it clear that the document doesn't reflect group consensus, the more we push changes that reflect group consensus, the greater the overall consensus on the spec. So, how do we push information?

<Ian> https://github.com/w3c/webpayments/wiki/CFC_20140412

<Ian> https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0012.html

<Ian> w3.org/TR/

Ian: The question is how do we get proposals, consensus for those proposals, and then mechanics for updating editor's draft, and then published version in TR space.
... The text in the agenda says - how do we get proposed changes? Since we're using Github, the recommended way for people is to fork the spec, make changes, then submit pull requests..

<Ian> PROPOSAL TO THE GROUP:

<Ian> The WPWG will use the auto-publish mechanism

<Ian> Adopt decision policy above (Editors can merge proposals with consensus + editorial; others discussed before decision)

<Ian> Adopt publish-TR-on-merge policy.

<Ian> Create a twitter account to build community around the specs (and inform them of key publications)

Ian: So, how do we make progress - where should there be friction to ensure consensus, where should we free up editors?
... We have the tools available to push the Editor's Draft to the TR page automatically as soon as Editor's make commit to Editor's draft. It's mirrored into formal publication space. The W3C has moved into this direction of frequent updates to published document because we don't want them to be stale. In the future we'll want stable snapshots.
... We'll want to push those changes to TR space, which ones get pushed - the Editor's are empowered to merge proposals where there is consensus - or proposals that fix bugs or are editorial. The way consensus is measured - there is explicit decision from Chairs, or obvious consensus in issue tracker.
... Obvious consensus - strong support and no objection.
... three or four people say it's a good idea, no one opposes, we're trying to make life easier on editor's. Where there are challenging topics, bring it to WG agenda - ideally those discussions are about concrete proposals. It doesn't mean that in every case. Adopt that decision policy - we publish TR specs when editor's when they merge PRs.

<Zakim> AdrianHB, you wanted to ask how the editors decide if there is consensus? There are a few PRs that have only supportive comments but have not yet been merged or commented on by

<zkoch> I can respond

<zkoch> as editor

zkoch: I think we have a few PRs waiting to be merged - they're assigned to different editor's - I know I have two assigned, we're actively triaging ones that have obvious consensus.

Ian: A thing that the editor's can do - if they can concretely help synthesize the issues, bring them to the attention of the Chairs that make sense for how the spec should evolve.

<AdrianHB> I am concerned about the rate of progress and feedback from editors (i.e. a signal that says "we're looking at this would be useful")

Ian: There's not action item here - way that the editor's help the group make progress
... Any feedback on transparency on what editor's are doing w/o being a burden?

<AdrianHB> I think we should wait for Thursday call each week before we discuss PRs. Right now it feels like PR's go into a black hole

<AdrianHB> I DON'T THINK we should wait

zkoch: We're in a weird transition point, how we deal w/ PRs about that - we met last week to figure out our process. We can talk about what we're comfortable w/ as editor's. We have other full time jobs so we block off time to work on these things. I think we can bring this up w/ other editors on how we communicate this.

<Zakim> manu, you wanted to refine "obvious consensus"

<Ian> manu: Regarding "obvious consensus"...

<Ian> ...I think the definition (strong support, no objections) is ok at a high level

<Ian> ...but I'm concerned because we don't have a lot of people engaging on the issue tracker

<AdrianHB> +1 - wanted to add that there is a responsibility on the group here too to provide feedback

<Ian> ...frequently at W3C a core contingent deals with the spec day-to-day

<AdrianHB> merge decisions are much easier for editors if the group provides some +1s

<Ian> ...I am ok with 3-4 +1's with no objections....but that doesn't mean that it "clearly reflects consensus"

<Ian> ...what about a policy where we don't push specs until people have a chance to review and give their consensus views

<Ian> ...does anybody else share this concern?

<Zakim> Ian, you wanted to mention link to Arch spec as editor draft

Ian: We will have to adjust references to architecture document - those will still exist as editor's draft - is that straightforward, not time consuming.

zkoch: Yes, we should be able to do that.

<VincentK> quit

<Ian> zkoch: I am reluctant to merge pull requests where we have a sense that people didn't have a chance to comment.

zkoch: I tend to agree, there are more active people - some people might be out. I don't think editor's would want to merge things w/ only a few people participating.

<Ian> ...I think the Editors also have a sense that for big issues discussion would be necessary

zkoch: For example, merging multiple arguments into single argument in payment request - I don't think we'd pull that in w/o discussion on call.

Ian: Controversial issues where there is no clear agreement, that doesn't have consensus. The editor's will act in good faith - if decision is necessary - ask the group - that's a great way to work - trust the editor's to make progress, knowing that people can , after the fact, ask that things be removed. Over time things may change and opinions may change and we can always come back.

<Ian> IJ: +1 to editor judgment

zkoch: I think the key thing here is that Editor's will be using their best judgement.

<AdrianHB> I think the editors should set some expectations for the group around how long they expect it to take for a PR to be merged. If the editors see a PR that they think is going to take a while to assess we need a mechanism to signal this to the group

Ian: Also that there are multiple editor's helps. Staff and Chairs can be called on as well - that should help.

<Zakim> ShaneM, you wanted to talk about periodic consensus review and date space and to ask if we could have somone from another group that has done this before come in and talk about the

<zkoch> Adrian: Yeah, I mentioned that I would take this back to the editors about how to provide more transparency around PRs we’re looking at/considering

Shane: Manu mentioned that we do periodic reviews to signal real consensus - even if we're doing frequest TR space updating - when that happens, those documents go into date space - they get a dated version - so the history is there, we can pick one of those and say "this is a point where we want you to do a consensus review".

<AdrianHB> ZKoch: I think an "Under Review" label or similar would be useful with maybe a milestone that indicates when it will be discussed

Shane: That's a way to do that that doesn't churn underneath the people doing the review. I feel like we're having a conversation that many other WG's have. There must be experience in other WGs, can we talk to those WGs?

Ian: Even if other groups have solved this problem, we want to walk though this w/ this group.

<AdrianHB> +1

<AdrianHB> (to Manu)

<MattS> +1

<ShaneM> +1 to manu

<AdrianHB> I think the issue under discussion is not about publication process anyway it's about merge process

Ian: From time to time - we may be able to do consensus blessing - not sure if that is okay. We may do it gradually, we may also get group consensus. When we advance to CR, that's the real decision.
... We could contemplate other proposals, but the one we have on the table reflects the opinion of a number of folks in W3C.

<Ian> Manu: I haven't heard anything that scares me.

<Ian> PROPOSAL TO THE GROUP:

<Ian> The WPWG will use the auto-publish mechanism

<Ian> Adopt decision policy above (Editors can merge proposals with consensus + editorial; others discussed before decision)

<Ian> Adopt publish-TR-on-merge policy.

+1

<dezell> +1

<zkoch> +1

<AdrianHB> I propose that we continue to use gh-pages branch for editors drafts and create a new branch that is exclusively used for auto-publishing to TR space

<dlongley> +1

manu: +1

<rouslan> +1

<maheshk> +1

<AdrianHB> +1

<MattS> +1

<CyrilV> +1

<ShaneM> +1

<Ian> SO RESOLVED

<zkoch> :|

<Zakim> manu, you wanted to move to adopt the proposal and move on (we can always change it if it doesn't work out)

Extensibility

<Ian> https://github.com/w3c/webpayments/wiki/Extensibility_Notes

Ian: I wrote down a compendium of extensibility - we have talked on a number of occasions about extensibility and how we imagine the system to be extensible.
... I don't know if we'll get to any resolutions today - let's look at topics side-by-side - we may reach a better understanding about how we'll meet these things in all of their forms.
... Ultimately, if we can reach consensus on requirements, it'll make it easier to design specs.
... To introduce this briefly - we have a number of components in the system, including API itself, different aspects of extensibility, there are payment apps, payment mediators, payment method identifiers, I'm happy to look through these quickly, but what I want to ask people to do, group participants have write access.
... We may want to make sure that we capture the most important considerations so we can build the specs accordingly and meet peoples needs.
... Some of these around payment method identifiers, those are the four requirements we discussed in San Francisco. Those appear in FPWD.
... Those may look the most familiar - for payment apps, we have talked about the need for mediators to communicate w/ payment apps. We have talked about the update problem (if I update my payment app and register a new instrument, mediators need to be aware of that). We've also talked about whether mediators should expose registration information w/ other mediators.
... There are some open issues about the need to support custom data for different payment methods. We have talked about payment mediator extensibility - should we be able to have different payment mediators.
... Matt suggested mediator role - here I've indicated that a browser not support 3rd party mediator functionality as far as browser expectations - payment applications can fill that role. Interoperability to swap in different mediators - 3rd party payment apps should provide those choices.
... Real quick walkthrough - I'm not looking for consensus on requirements. We want to make sure it includes requirements that people have.

MattS: Because this is a wiki, I wonder if we should be editing it or raising issues? Then update the document?
... We don't have PRs to moderate this.

Ian: For a while, people can add to the document just to flesh it out
... That's not what we'd claim consensus on, though... once we have a draft, freeze it, then discuss that
... This is just a prompt to get people to contribute to it.

MattS: Ok, append-only to wiki

Ian: I like it when people put down notes - like "I disagree for reason X"
... Asynchronous collaborative editing.
... We could ask for people to make changes to this by April 21st, then we can start to look at consensus.

<Ian> Manu: General +1 for the approach I think.

<Ian> ...I feel like we've labeled a lot of things under the extensibility banner that may not be extensibility topics.

<Ian> ...one is around functionality detection

<Ian> ..can we identify the extensibility chunks and then focus on that one.

<Ian> ...e.g., message extensibility with a concrete proposal

Ian: I put them in the same document because we use extensibility to mean "all of them"

<MattS> and I also lablled issues associated "Extensibility/Verisoning"

Ian: If you're saying "Can we prioritize?" I'm fine with that.
... Sounded like I wanted a decision after 21st, that may not be desirable/achievable - want to prompt people to contribute with a timeline of a week.
... If people want to focus on a specific spec, then that's fine too - but there are multiple extensbility topics so we're not talking past one another.
... So, if you have extensibility in one place, you MAY not need it as much in another.
... One thing that would be really nice is to get commitments from people to review this - we feel more confident when we know if multiple people have looked at this.

<MattS> I will

<Ian> ACTION: MattS to review the extensibility wiki by 21 April [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action01]

<trackbot> Error finding 'MattS'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

<ShaneM> I will too

<scribe> ACTION: Manu to review extensibility wiki by April 20th. [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action03]

<trackbot> Created ACTION-18 - Review extensibility wiki by april 20th. [on Manu Sporny - due 2016-04-21].

FTF meeting agenda update

Ian: That's the extensibility topic - the goal is to have consensus to guide the next steps there.

<Ian> No update!

Ian: My understanding is that we're getting close to talk about Blockchain workshop - Nick has been traveling, no updates really - apologies for that.
... We'll try to work w/ this group for ideal scheduling, whether it's with or in parallel.

Doug: There has been a little bit of backchannel discussion on this - sorry for the conflicts - we're going ahead w/ the workshop at MIT at end of June. There is a question on whether or not MIT could also host face-to-face meeting. It may be possible. There would be some costs that would have to be covered, we think we could get the rooms.
... If people are interested in attending both things and want to come to Boston to do that, want to know who is interested in co-located thing?

MANU IS VERY INTERESTED IN CO-LOCATING WPWG F2F and BLOCKCHAIN WORKSHOP

Doug: Hope that some of you are interested in Blockchain workshop, let us know if you are.

MattS: Have you had a chat w/ WorldPay on that - wait on that before you make a formal proposal to the group.

<MattS> Im a +1 for that then!

Doug: Nick suggested that we may want to host in Boston - we haven't had a chance to talk yet
... I don't want to conflict w/ whatever he has going forward there.

MattS: If Nick's happy w/ Boston, I'm happy w/ Boston.

Doug: I've been chatting with him on it. Apologies that we don't have more information on it - working hard to get this information to you.

Ian: We will know more next week.

Doug: If you're interested in attending, let us know - who is interested in attending, what right course is going forward, etc.

<AdrianHB> In lieu of being able to discuss PR 133 would appreciate feedback from the editors on the PR as it addresses a lot of issues

<Ian> https://github.com/w3c/browser-payment-api/pull/133

Ian: Now that we've gotten through FPWD, I expect WG's agenda to become more focused on issues. One of the things that stood out for me was Adrian has put together a proposal - PR133 - addresses 4 open issues.
... That's noteworthy enough that we should discuss in the group - notably, what do the editor's thing? No changes happen before FPWD, but this is for subsequent edits.
... Do the editor's have any feedback on this?

<zkoch> looking

<Ian> zkoch: Not yet

zkoch: We haven't had a chance to look at it in depth - will do so tomorrow.

<ShaneM> ACTION: ShaneM to review the extensibility wiki by 21 April [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action05]

<trackbot> Created ACTION-19 - Review the extensibility wiki by 21 april [on Shane McCarron - due 2016-04-21].

Ian: We urge others to take a look at that proposal - that's a helpful way to make progress rapidly.

<AdrianHB> Wants to re-emphasize that the group needs to GET INVOLVED! Even just a +1 or -1 helps us understand the general feeling

<zkoch> Yep

<zkoch> :)

Ian: Zach may be saying - let's not do detailed issues yet until we've given editor's some breathing space.

Encouraging contributions

manu: +1 to AdrianHB - more people need to start weighing in.

<AdrianHB> I propose we dedicate next week to issue resolution

Ian: We want people to make proposals - Cyril wrote up a draft around SEPA, I've been reaching out to other participants in the group as well.
... General request to the group to do payment method specs. People may not be comfortable using Github - open question, do we need to be using WebIDL?
... Do people want tutorials on WebIDL, ReSpec, Github, put stuff into a form that's consumable by the group? We can find people to help w/ that.

<Ian> Manu: Sending comments by email is fine, too.

<Ian> IJ: Agreed. This is an invitation to get people more into github

Ian: If you do want to do the more authorly things - but feel there are technology barriers, we can help - let us know.

<Mike5> e-mail is a barrier to some people actually

<MattS> Also, there is some confusion about how easy it is to use GitHub, so understanding how to use the Web UI rather than GitHub Desktop or Shell

<MattS> in terms of reducing technology, not knowledge barrier!

<Mike5> some contributors really dislike dealing with our old-school mailing-list culture

Ian: Doug has proposed a publicly consumable quarterly report...

manu: Mike5 - yes, but some people don't know how to use ReSpec, Github, etc and don't have time to learn it - but they do know email... I'm just suggesting we take input any way we can.

Ian: We want to see if there are signs of interest for regular updates - snapshots are nice.

<zkoch> +1 to taking input the way we can

Next meeting

Ian: Next meeting is 21st of April - we'll be discussing whether to take up three proposals in this week's agenda.
... Come to the meeting informed.

<AdrianHB> Thanks

<zkoch> seeya!

<Ian> scribe: Manu

Summary of Action Items

[NEW] ACTION: Manu to review extensibility wiki by April 20th. [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action03]
[NEW] ACTION: MattS to review the extensibility wiki by 21 April [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action01]
[NEW] ACTION: ShaneM to review the extensibility wiki by 21 April [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action05]
 

Summary of Resolutions

<Ian> The WPWG will use the auto-publish mechanism

<Ian> Adopt decision policy above (Editors can merge proposals with consensus + editorial; others discussed before decision)

<Ian> Adopt publish-TR-on-merge policy.


Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/04/14 17:18:00 $