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> 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.
>
>