definition of "aspirational" should be further clarified about standards-track

[msporny]

This issue was created during a discussion around the Verifiable Claims Working Group Charter Vote. The complete thread can be found here:

https://lists.w3.org/Archives/Member/w3c-ac-forum/2016OctDec/0139.html

I've taken an excerpt of that discussion and included it below:

The primary concern right now is that there seems to be push-back on the creation of the Verifiable Claims WG based on a shifting definition of "Anticipatory/Aspirational Standard" that is not included in the W3C Recommendation Track Readiness Criteria[1]. It seems that those that continue to not be convinced, and are their organizations AC Representatives, may vote to reject the Charter. If this happens, it will be for reasons outside of the Rec Track Readiness Criteria which will be imposing a set of new criteria on the Verifiable Claims work.

In the last email[2], it was demonstrated that the Verifiable Claims work does meet the current Rec Track Readiness Criteria[1]. Some would argue that it exceeds the criteria in a variety of ways.

Arguments ... seem to indicate that it has not met the criteria in some way and the common thread seems to be that it is aspirational in nature even though there is evidence to the contrary:

• Active community development for 4+ years[3][4]
• Community of 92+ participants with an average weekly telecon participation from 15-25 participants[5]
• Data demonstrating Charter support from 48+ organizations[6]
• A consensus-based set of use cases[7]
• A consensus-based specification with community buy-in[8]
• Multiple implementations of specification with active deployments[9][10][11][12][13][14]
• Expert interviews with concerned/critical experts[15]
• Data documenting commitments from key ecosystem implementers[16]

It is also clear from the responses that those pushing back on the creation of a Verifiable Claims WG don't share a common definition of "Anticipatory/Aspirational Standard" but are still using that as a reason to argue against placing the work on the Rec Track.

I'm personally very much in favor of each of you working together with the W3C Advisory Board to do the following:

1. Research and document past W3C successes and failures.
2. Derive additional W3C Rec Track Readiness Criteria from that research and include it in the current document[1].
3. Seek consensus among the W3C Membership for the new readiness criteria.

Until this is done, your colleagues, even though we agree with some of what each of you are saying to some degree, will find it difficult to clearly understand the criteria each of you have in your head. We will continue to find it frustrating when you assert that Verifiable Claims has not met a particular bar you feel should be met but is not documented (or supported via research). If the items above exist, please link to them.

[1]https://www.w3.org/Guide/standards-track/
[2]https://lists.w3.org/Archives/Member/w3c-ac-forum/2016OctDec/0139.html
[3]https://lists.w3.org/Archives/Public/public-credentials/
[4]https://lists.w3.org/Archives/Public/public-webpayments/2013Sep/
[5]http://w3c.github.io/vctf/meetings/
[6]http://w3c.github.io/webpayments-ig/VCTF/support/
[7]https://opencreds.github.io/vc-use-cases/
[8]https://opencreds.github.io/vc-data-model/
[9]https://openbadgespec.org/
[10]https://github.com/digitalbazaar/bedrock-issuer
[11]https://demo.checkpoint.veres.io/
[12]https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/draft-documents/DIDSpecificationWorkingDraft04.pdf
[13]https://github.com/WebOfTrustInfo/portable-reputation-toolkit
[14]http://www.credreg.net/
[15]http://w3c.github.io/webpayments-ig/VCTF/charter/VCTF-final-report.html#kix.hb21ok384y8r
[16]http://w3c.github.io/webpayments-ig/VCTF/implementers/

[tantek]

Other than this point*:

Multiple implementations of specification with active deployments[9][10][11][12][13][14]

The rest of the list items don't show anything contrary to aspirational, and on the contrary (so to speak) actually strengthen the "aspirational" impression/assertion. with words like "community", "consensus", "buy-in", "experts" (appeal to authority), "commitments".

Aspirational vs empirical has been in practice about actual implementation (demonstrated running code) vs. just political advocacy (rough consensus). Both are needed.

Here is some straw text that I have found resonates with a few people. Documenting here for the sake of discussion/iteration/improvement:

aspirational in the context of a spec: normative spec feature text describing a behavior that has no evidence of implementation, e.g. prototyping, with actual running code.

(*) Aside: the "Multiple implementations … with active deployments" point is diluted by the fact that many of the [n] citations are not to implementations, but rather other specifications[9][12]. Another spec is just more text, not an implementation, certainly not a deployment nor actively so. Others are advocacy homepages which may have deployments but are buried so deep that it is unreasonable to expect anyone attempting to verify the claim of deployment to find them.[14] A few are github repos[10][13], which is likely good evidence of prototyping (implementations worth noting!), but do not on their own constitute an "active deployment", lacking a URL where said repo is deployed and running. Of all the citations, only one, [11]https://demo.checkpoint.veres.io/, seems to actually be an "active deployment". All that being said, any apparent source or running implementations[10][11][13] helps demonstrate incubation, and thus work beyond just "aspirational".