W3C home > Mailing lists > Public > public-w3process@w3.org > September 2015

Re: Chartering work

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 2 Sep 2015 16:01:49 +1000
Cc: Revising W3C Process Community Group <public-w3process@w3.org>
Message-Id: <8BE792F4-F591-4FC2-AC5A-3BB266D43E9F@mnot.net>
To: Jeff Jaffe <jeff@w3.org>
Hi Jeff,

On 2 Sep 2015, at 2:58 pm, Jeff Jaffe <jeff@w3.org> wrote:
> 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., <https://github.com/mnot/webpayments-ig>) 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 implementation.
> 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.

Are any of them (especially the "big guys") offering their implementation, specifications, or patents?

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

Nowhere did I suggest that, Jeff.

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

3.5 There's an implementation of 3.6
3.6 There's a proposed starting point (e.g., straw-man specification) for the work that can be referenced by the charter
3.7 The crisp technical problem has been segmented into specific deliverables and bounded by chartered requirements

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

My experience is that 3.6-3.7 is the minimum bar for viability; if people can't be bothered to write a spec and agree upon it as a starting point, you've got a group of people interested in a problem, nothing more. Giving them a WG is a recipe for a disaster that many of us have lived through, several times.

All I'm really asking for for Web Payments is 3.7, but it seems to be having trouble conforming to "broad" in 5, much less going lower on the JISSR*.

Yes, there are exceptions to this, but I very much disagree with saying that Web Payments is one of those exceptions; it borders on a moral hazard, since we're sucking in a lot of people who aren't used to working in standards.

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

Those are all important things to consider when starting the work, but they don't help the effort actually succeed. 


* Jaffe Inverted Scale of Standardisation Readiness

Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 2 September 2015 06:02:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:31 UTC