Re: Chartering work

On 9/1/2015 4:18 AM, Mark Nottingham wrote:
> FYI, below are my charter review comments on the Web Payments WG, which I think echo some of what Harry was saying recently.
> —8<—
> This area of work is very important to the Web, and we support its chartering in general.
> I've talked through the issues I had with the charter with Ian and Dom, and made proposals (e.g., <>) to make it less verbose and more concrete (although there are still parts, especially in Deliverables, that aren't clear). Hopefully, those changes will make it into the final charter (AIUI the Process doesn't give much visibility into that until after approval).

+1 (always) to less verbose and more concrete.

> At a high level, I'm still uncomfortable with this charter, because it isn't based upon a concrete, technical proposal. It also lacks solid information on how it will be implemented; e.g., will it require browser support, or will it be possible to polyfill?
> IME successful standards are based upon real implementation and deployment experience with a specific proposal, not confected from whole cloth. Good (even heroic) chairing might give it better odds, but this proposal doesn't name any chair(s), yet.

While I agree that we get the greatest success from real implementation 
and deployment experience, I don't feel that "one size fits all", and I 
don't think we should hold up all chartering until we have real 

Especially for web payments.

Payments on the web is not at all new.  It should have been standardized 
twenty years ago, but it wasn't.  So we are left with a large set of ad 
hoc, incompatible, often proprietary, and often insecure implementations.

We don't have a single prototype implementation of a standard, in some 
sense we have too many.

This problem is getting worse as the scenarios, use cases, and 
techniques for payment proliferate.

I applaud your efforts to get this to be more concrete.  But if we wait 
until we have "real implementations of a standard" I fear in this case 
we will have a chicken-and-the-egg problem.  The more solutions claim to 
be standard, the more diverse non-standards are also being implemented.

> As such, I'd rather the charter nominate specific technical proposals -- something that the IG can work on and bring back to the AC.

Certainly good if we can get there.

> Failing that, I'd expect a more limited charter, where the work was chopped up into manageable bits, so that we can re-charter as the work progresses, contingent upon success in each milestone.
> I'm going to leave this as a FO for now, because I think this is a fundamental issue in how we charter work, and I'd like to see a formal response (even if it's overruled, which is fine).
> —>8---
> Would love to chat through it if people are interested.

Yes, we should chat through this.  There are several hurdles we might 
expect to achieve before we take something in for standardization:

1. It's already defacto standard.
2. Several interoperable implementations already exist and have majority 
market penetration.
3. Several interoperable implementations already exist, although there 
are many incompatible solutions as well.
4. We agree on a crisp technical problem.
5. We agree on a broad area of work which requires attention.

I would be interested in where you would draw the line of starting a new 
Working Group.  My own intuition is that it would depend on a whole 
bunch of factors, and would be different for each WG.  Some of the 
factors would include:

a. Is this already an area that W3C already has worked in?
b. Are there real interoperability problems on the web which need to be 
c. Is the area important to Lead the Web to its Full Potential?
d. Are there a set of critical stakeholders that are eager to address 
the problem?

In the case of payments, part of the challenge in getting concrete is 
that it is a new area for W3C (so we are challenged by point (a)).  (b) 
is a huge reason to get started, as is (c) imho.  The number of new 
Members flocking to W3C to address payments seems to imply that (d) is 
applicable as well.

> --
> Mark Nottingham

Received on Wednesday, 2 September 2015 04:58:35 UTC