RE: Progress rapidification (was Re: Labels and Milestones on GitHub)

I am certainly in favour of more frequent calls. Our original intent was to meet weekly but alternating between “Americas” friendly times and “Asia Pacific” friendly times. However, I note that despite having run the questionnaire twice, we only have responses from two people, only one of whom is in the AP region. https://www.w3.org/2002/09/wbs/83744/WGconfschedule_eastern/results


I would therefore second a move to weekly conference calls in our current time slot, with the chairs running a biweekly “catch up” session at an AP friendly time if desired. (sorry Mountie)

I want to talk about the design issues – and about the realities of implementations. Adrian and I are both very open to suggestions or requests for agenda items for the calls – particularly where the request comes with an offer to propose a recommendation that we can either form a consensus upon (or not, as the case may be). I like the idea of tagging in git hub to this effect, as Adrian has proposed.

I am heartened by the recent work on the Flows – I remain convinced that they are an excellent lens with which to examine the proposals and I would urge the group to examine them and think about the specs in those contexts.

Nick
--
Nick Telford-Reed
e: nick.telford-reed@worldpay.com<mailto:nick.telford-reed@worldpay.com> | m: +447799473854 | t: +44 203 664 5069

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
Sent: 12 January 2016 11:11
To: Manu Sporny
Cc: Payments WG
Subject: Re: Progress rapidification (was Re: Labels and Milestones on GitHub)

Hi Manu,
Thanks for taking the time to put this together.
I would certainly be in favor of more regular telecons if this will help us to progress faster.
The process we went through to have the WG charter approved meant that we committed to taking input to the group in the form of incubated spec proposals.
As you know there are now a number of proposals on the table but these are still being iterated over.

The proposals have made it easy for us to surface the design issues you are eager for us to solve, as opposed to trying to discuss these in a vacuum or purely theoretically.
To date there are a large number of these questions in the WG issue list some of which reference one or more of the proposals and others which don't.
A number of group members have voiced their views on these discussions.
Are we ready to come consensus on a resolution to any of these?
I don't believe we are yet.
I'm not sure what value it will have if the group is forced to make a resolution around one of these questions and then when the proposal editors go off and try to implement the group's decision find it is not workable or impractical or that the decision taken in isolation was ill-informed.
Example:
You're suggesting we should choose between JSON or JSON-LD as a data model but there is still an outstanding question about whether the request should be an Object with some defined behaviour/methods or just data.
https://github.com/w3c/webpayments/issues/36

One proposal uses just data and the other uses an Object with defined methods and events so we have two specs that illustrate the two points of view.
There is also discussions about what data needs to be in the request. Does it include shipping data or line item details?
https://github.com/w3c/webpayments/issues/38


However, these discussions are linked to another discussion around the need to calculate shipping charges on the fly (or more generically adjust the request based on user input).
There is further discussion about whether or not this is required at all that surfaced in this discussion:
https://github.com/w3c/webpayments/issues/41


This is further linked to the observation from the browser vendors, that many browsers already keep data about the available shipping addresses a user commonly uses, and that this could be used to improve the UX
Contrast this with other opinions that this could be done in a separate flow:
https://github.com/w3c/webpayments/issues/39


Then, the editors of the paymentRequest spec proposal have requested an opportunity to write up a number of other proposals that address some of the issues logged to date:
https://github.com/WICG/paymentrequest/labels/action

i.e. There are a number of issues and they are all linked together in a way that is best understood when seeing them documented in a spec and a number of actions that have not been completed that we expect to shed light on the discussion.

Rather than being a way to get consensus, I see the questions as a way to gauge the direction the group is going and a guide for the proposal editors for each new iteration of their proposals.
Using a draft spec is a very effective way to illustrate why a particular proposal or position on one of these questions should be considered.
Eventually the editors of the specs will feel they can make no further changes to assuage the views of the group and we'll be able to come to a resolution with two solid specs as examples of how each question may be addressed.
During that time I'd expect each spec to iterate and update based on the requirements and ideas that are surfaced in the discussion.
As an example, I see an opportunity for the Web Payments CG to update their proposal to illustrate how shipping address might be captured on their API (or some other API) and still leverage the fact that browsers will have this data readily available and have expressed a desire to use it.

At this stage I would also not discourage members that feel neither spec fulfills their position from forking one and making changes or even submitting PRs against it if they can persuade the authors to accept their ideas.

I recognise that we need to ensure the iteration cycles on these proposals don't hold us back and you will have to trust that the chairs and staff are trying to ensure that this is not the case by engaging the authors regularly.
We have to balance this desire to have a FPWD out by March with a need to give the design process the time it requires to be done with due diligence.

As I have suggested in previous emails we are trying out some mechanisms using our tooling to organize these discussions and provide ways for the group to suggest issues for deeper discussion on a call.
I took an action to document this on the wiki and will do so and send a follow up email later today when I am done.
I think it is a mistake to interpret the low number of participants in the issue discussion as a failure to engage the group. To date the issues have been discussions (not proposals) and not everyone feels compelled to put forward an opinion (especially if their position is shared by other group members that have).
Next Steps:
Update "How we work"
I will update this to include the processes I have sent to the mailing list over the last week.

Putting issues on the agenda for calls
To date there has been no call to action from the group on any of these issues, just exchanging of ideas.
By this I mean there is no issue that has been identified by a group member as important to resolve and proposed for the agenda of a call along with a solid proposal for resolution.
If you feel there is some urgency in resolving any questions currently on the list I would suggest calling for this to be discussed on the next call by logging a solid proposal for resolution.
If there is no objection from the group we'll put the proposal on the agenda for the next call.
Call regularity
I will propose that we increase our call regularity to weekly until the F2F in February and we'll see what the group thinks of this proposal.

Spec iterations
The chairs will continue to push spec authors to either update their specs to address issues or engage the group directly on issues to defend their proposal.
Anyone in the group that feels their ideas are not reflected in one of the proposed specs should submit their own or persuade the authors to accept a PR from them that illustrates it.

Adrian


On 12 January 2016 at 07:26, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
On 01/08/2016 10:06 AM, Manu wrote:
I don't think we're on a healthy trajectory wrt. the specs at the
moment. I'll put together an email to the group with a proposal to
attempt to address these issues next.

Apologies for the delay in getting these proposals out to the group.

Proposal #1: Have weekly WPWG telecons.
Proposal #2: Spend at least 45 minutes per call on fundamental design
             issues.

Regarding proposal #1: Have weekly WPWG telecons.

Most every WG that I've been a part of that has made rapid progress has
either 1) been run by a "benevolent dictator/editor" (HTML5) or 2)
scheduled long/regular weekly telecons focused on issue discussion
(JSON-LD). Neither approach is a guaranteed recipe for success, but with
the right group, I've seen them work before. I'm suggesting we do the
latter (#2) in this group. The issues aren't being surfaced to enough
people on a frequent basis.

I've chatted a bit with Ian and a few others about it. I think the
general feeling is that I'm prematurely worrying about the conversations
that we have not had yet. I can see a very large gap between where we
want to be by FPWD and where we are today. The group isn't coming up to
speed fast enough w/ the various options on the table (IMHO). We're
focusing on easy issues / low hanging fruit.

For example, the registry of short names for payment method identifiers
has gotten quite a bit of attention lately. We seem to be coming to
consensus on a few things in that thread. That's good, but it ignores
the fact that we still haven't made any decisions on the fundamental
data model we'll be using. Is it JSON (like in paymentRequest)? JSON-LD
(like in the Web Payments CG specs)? If we had been focusing on that, we
might have found that the short names registry discussion would've been
solved by the data model decision. We need to be more deliberate in the
way that we go about addressing these issues.

wrt. Data model, at this point, I'm unconvinced that many of the folks
in the group know what the design trade-offs are to a level where a
consensus decision could be made. This is just one of the issues that
makes FPWD a pipe-dream until we address it. It takes a long time to
determine the best path forward for a WG with a fundamental design issue
like this, and frankly, we're just not putting in the telecon time (or
issue tracker time) to come to a conclusion on this any time soon.

That's one of the reasons for proposal #2 - we need to increase the
amount of time we spend discussing issues, even if there is no clear
consensus decision to be made (we can't even get to proposals until
folks understand the difference between JSON and JSON-LD, for instance).

I believe that there is a way of organizing issue discussion that helps
us move through the issues in a more educated/efficient manner (rather
than the random walk we're doing now). This leads me to the third proposal:

Proposal #3: Order the issue discussion in a way that tackles
fundamental design issues first, followed by less fundamental issues second.

I will try to come up with a issue discussion priority list tomorrow,
but in the meantime... thoughts?

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.

This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.

Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.