The Modified Jaffe Inverted Scale of Standardization Readiness

Mark Nottingham responding to Jeff Jaffe:
  https://lists.w3.org/Archives/Public/public-w3process/2015Sep/0005.html
> 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*.

* Jaffe Inverted Scale of Standardization Readiness

>  Some of the factors [in choosing to start a standards effort] 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.

Jeff Jaffe: https://lists.w3.org/Archives/Public/public-w3process/2015Sep/0006.html
I think that your criteria 3-5-3.7 are all very sensible and setting a
target of 3.7 is desirable as well.  I like how you think about this.
Clearly we are bootstrapping a new area of work for W3C, and probably
the area where we disagree is what are the right steps to bootstrap the
new work.  So keep after us and let's work together to continue to crisp
up the work.

Wayne Carr: https://lists.w3.org/Archives/Public/public-w3process/2015Sep/0007.html
3.7 could be interpreted to mean you know deliverables (typical line or
two describing each), but may not have any idea how to define those or
how they fit together if multiple deliverables jointly solve a
problem.   Many approved charters could be said to meet that type of
interpretation of 3.7 now and I think that's what is driving the push to
move toward requiring a straw man spec (3.6) before moving work to a
WG.  But, something in between those may be what's needed.

3.7* could be that if multiple deliverables make up a solution, you have
a strawman architecture for how they fit together and for each
deliverable you have a strawman outline for a possible approach and a
description of how to solve any serious problems.  That isn't at the
level of a CG spec, but could be clear it is ready for standardization
without the detail of a CG spec.

But, for some new work, other factors may be a reason for a WG instead
as an exception.  In that case, the Charter should be clear it is
exploring.  It could list some specific technical questions it wants to
try to solve and maybe create REC track specs on those narrow areas (and
merge them into a later spec) or possible no specs at all.  Broad, vague
deliverables are not a good match for W3C's patent policy.

Longer term, W3C could consider an alternative type of WG that does not
create Recommendations, but instead puts out something else under a CG
contribution only style patent policy for (exceptional) broad
exploratory type groups where incubation with more direct W3C control is
wanted.

Summary by
Steve Zilles