-
Notifications
You must be signed in to change notification settings - Fork 17
Description
Of all the criteria, the one I actually feel the most strongly about is multiple implementations, which I feel is very loosely specified compared to, say, the W3C TAG review process, which often rejects otherwise-final specifications for lack of a second (independent-enough) implementation! W3C's current language, central to the Technical Advisory Group (TAG) review process, is that specs need to document "interoperable, independent implementations" (the "Three I"s), and I personally feel we should adopt at least this standard of "independent".
If you're not familiar with W3C, this thread from the public Advisory Board repo of W3C is a good place to start (bonus: it also contextualizes the "abstract data model", i.e. why W3C didn't just ask DID WG and VC WG to just pick JSON-LD or plain JSON, and instead went along with the Abstract Data Model format). As part of TAG process refinements, more operational definitions of the 3 Is were researched, and the values of INDEPENDENT implementations in particular were laid out in this wiki.
Currently, we are only requiring:
Multiple Impls: Multiple implementations (include proof of multiple implementations, could be in the proposal file at column 4)
I would like to get more concrete, something like
Multiple feature-complete, tested, stable end-to-end implementations with no code or libraries in common (ideally open-source)
I feel like a quick glance at package.json files (or their equivalent manifests in other languages) and a few clicks on github/package-managers is usually enough to unearth shared dependencies, so I don't think this increases the workload for review.
Thumb up if you're generally in favor of this kind of additional scrutiny, thumbs down for status quo, confused-emoji if you are on the fence/undecided/confused. Also happy to debate minutae or field better wordings here in the issue thread.