Re: Support for Verifiable Claims

On Thu, Nov 3, 2016 at 8:57 AM, Adrian Hope-Bailie <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.