Re: Support for Verifiable Claims

Thanks Chris, +1 especially to

> the difference between incubation and and a WG literally *IS* that incubations can fail gracefully,
> without it being seen as a failure of those involved.  And WGs, by definition, start with a a statement of
> "this is WHAT we're going to solve, HOW we're going to solve it (in terms of deliverables), and WHEN we plan to be done by."

Adrian made a couple of points I’d like to discuss:

> For smaller members without the resources to seed an ecosystem their only hope is to propose work that the
> large members are also interested in pursuing or that is so uninteresting it slips past them unnoticed.

20 years ago I probably would have agreed, but with the rise of open source software development, plentiful venture capital in this space, and cheap cloud computing infrastructure it’s no longer true the barriers to ecosystem formation are so steep that only large members can build one.  A glance at the  http://fortune.com/unicorns/ shows lots of companies that got big by building their own ecosystems in the last few years.  There are other ecosystems that have gotten booted up around non-profit foundations to build code (and only later defined standards) leveraging OSS and cloud services, see for example https://www.linuxfoundation.org/projects.  I don’t think W3C will be successful if it doesn’t adapt to this new reality.

> Sometimes standardization is the reason the ecosystem exists at all. All I hear to the contrary are anecdotal assertions.

I have a long-neglected hobby project to apply some data science to predict which standards efforts will succeed and fail, and would be very interested in exploring this. For starters, what are some anecdotal examples of the standards-first, ecosystem later approach working well, preferably in the last 10 years or so?  And how might we measure “success” non-anecdotally… Getting to W3C Recommendation?  Mentions of the standard that can be found by the search engines?  Number of books on Amazon that have the standard in the title? Implementation status in caniuse.com?  All thoughts appreciated.

> the Credentials CG has incubated this work to death and has been told repeatedly that they can't form a WG on the back of such
> opinionated technology choices so they have paired down their initial scope to almost a shell of what it was before)

I’d appreciate more context on “opinionated technology choices” means to you.  W3C has not had a great experience with WGs that start with a technology opinion looking for a problem it can solve (XHTML being the poster child). If earlier proposals were explicit that the objective is to show how linked data can address the claims problem, I think you got good advice to avoid baking that technology opinion into the charter. But if one started with running code and real services that demonstrate good functionality and performance without undue complexity, the WG would be much less likely to bog down in the JSON vs JSON-LD tarpit, for example.

Another concern with the earlier proposal was that it sounded like an effort to boil the ocean / create the 15th standard that tries to unify the other 14 (but becomes yet another source of cost, confusion and conflict.). [obligatory reference to xkcd 927]. Paring the VCWG proposal down to a shell of what it was before has mitigated this concern for me, and for the team as I understand it.  Are you saying that was a mistake?

From: Chris Wilson <cwilso@google.com>
Date: Thursday, November 3, 2016 at 11:00 AM
To: Adrian Hope-Bailie <adrian@hopebailie.com>
Cc: "刘大鹏(鹏成)" <max.ldp@alibaba-inc.com>, public-webpayments-comments <public-webpayments-comments@w3.org>, "w3c-ac-forum@w3.org" <w3c-ac-forum@w3.org>
Subject: Re: Support for Verifiable Claims
Resent-From: "w3c-ac-forum@w3.org" <w3c-ac-forum@w3.org>
Resent-Date: Thursday, November 3, 2016 at 11:01 AM

On Thu, Nov 3, 2016 at 8:57 AM, Adrian Hope-Bailie <adrian@hopebailie.com<mailto:adrian@hopebailie.com>> wrote:
Is a standard designed or does it evolve as a result of collaboration between implementers to standardize what they have already incubated?

I would paint that debate as "does a standard start with the creation of a WG (with the attendant timelines and deliverables stated up front), or a collaboration between potential users and implementers?"

Respectfully, I think the larger browser vendors prefer the incubation approach because for the majority of cases at W3C this does work best, for them. The set of implementors is small, their participation at W3C is extensive and when they incubate something they have the size, on their own, to influence the whole market. Further, they generally have the resources to assign at least one person to almost every WG so their influence across the consortium is significant.

Yes, we believe incubation *IS* a good idea - but actually, it's quite a bit for the opposite reason than the one you state:  it's a way to keep us from soldifying something half-baked directly into a standard, and forcing us to prove to ourselves and others that it's a good idea.

So, while every member has only one vote, setting a bar that says forming a WG happens only on the back of an incubated ecosystem is a way to ensure only the large members ever form a WG. For smaller members without the resources to seed an ecosystem their only hope is to propose work that the large members are also interested in pursuing or that is so uninteresting it slips past them unnoticed.

You seem to imply that smaller members should get the ability to form WGs without any proof it's a good idea, or that an ecosystem will grow up around it.  I don't believe there should be shortcuts like this - for large members OR small members.  If you want broad impact, you will need to coordinate the effort.

But, there are exceptions to this where the likelihood of a coherent standard emerging out of independent efforts is low and the implementors are diverse. Sometimes the technology being standardized is sufficiently abstract, or cuts across such a wide range of industries that trying to take all of the incubated, or existing implementations and extract a standard is far less efficient than designing the standard upfront.

What?!?  I would think in precisely that case, it would become even MORE important to take the incubated work and create an eventual standard based on them, rather than throwing that all away and starting with "let's design a standard."  (Obligatory reference to xkcd 927<https://xkcd.com/927/> here.)

I agree that sometimes these efforts fail, but so do incubation-first initiatives. Rather than preventing these initiatives from starting shouldn't we try to find better ways to evaluate if they are succeeding while the WG is doing it's work? We should be more accepting of a WG forming and then shutting down after a short time with no output if we determine that assumptions made in the charter have not turned out to be true.

Except the difference between incubation and and a WG literally *IS* that incubations can fail gracefully, without it being seen as a failure of those involved.  And WGs, by definition, start with a a statement of "this is WHAT we're going to solve, HOW we're going to solve it (in terms of deliverables), and WHEN we plan to be done by."

We should also accept that when these kinds of up-front standardization efforts are undertaken it is natural for stakeholders to be cautious about throwing resources into the work until a reputable body like W3C has given the group their endorsement.

Well, fortune favors the brave?  Charting a new path takes resources and involves risk; there's no way around that.  Rewards can be great, but risk and cost are certainly part of it, and if you throw around early endorsements, you simply place the risk and cost on the ecosystem later (like how XHTML turned out to not be the right path forward for the bulk of the web, and the ecosystem paid the cost).

In fact, the larger W3C members often rely on their own brand and their own endorsement of a project to grow the ecosystem around that project. We have all been part of those technology decisions where a particular code library or technology is chosen because "that's what Google use" or "it was developed and is maintained by Facebook's open source team".

Umm, we have?  Because I tend to question everything.

I think what this thread illustrates is that work by a sub-group of members can never get off the ground (even if the impact to the members that don't wish to be involved or agree with the work is basically nil) as long as that sub-group doesn't include one of the W3C super-powers.

I'll have to agree strongly with Jeff that that is an incorrect assessment of the situation.  At MOST all that you have at this point is concern by some members about the level of preparatory work that's been done.  (And again - I have a lot to review, and won't be able to do it for the next week.)

Unless these members are being dishonest about their reasons for blocking the work I can only assume that they are doing so because they fear the overhead of forming the group is a waste of W3C resources. However, by that argument all of the members that are interested in forming the VCWG should formally object to the formation of any other WG until such time as the resources ARE available to form the VCWG.

I would expect that members who believe that other WGs that are proposed but are of lesser importance to them than VCWG *could* offer such objections; however, your blanket threat of "we will just stonewall everything until we get our WG" is unlikely to be very effective, since incubations would continue.

And most importantly, please stop characterize a strong preference for incubation-first as "blocking the work," because that is not what has been happening here.

This is clearly not a situation we want to get ourselves into in the long run but I fail to see, given the current policies, how the smaller members can ever exercise their rights to do work that they feel is important.

Umm, fairly easily - they incubate work first, and prove that solutions are possible, and build some consensus behind those solutions before asking to create a WG to declare the "right solution" on a given time scale.

My hope is we will find a way to make forming (and most importantly closing) a WG a more lightweight process so that opposition to forming a WG is far less common and the grounds to shut down a non-delivering WG more clear and easily executable.

What is the difference, to you, between this and incubation?  Because the goal of incubation is making it easier to form, and easier to shut down, efforts that aren't yet proven.  I don't see why you need a WG, particularly as you suggest eroding the equation that WG == a solution that is definitely gonna happen.