Add issue markers #1127
Add issue markers #1127
Conversation
OR13
requested review from
msporny,
selfissued,
decentralgabe and
awoie
as code owners
| @@ -1336,7 +1336,7 @@ <h3>Types</h3> | |||
| <td> | |||
| <code>VerifiableCredential</code> and, optionally, a more specific | |||
| <a>verifiable credential</a> <a>type</a>. For example,<br> | |||
| <code>"type": ["VerifiableCredential", "UniversityDegreeCredential"]</code> | |||
| <code>"type": ["VerifiableCredential", "IdentityCredential"]</code> | |||
There was a problem hiding this comment.
I made this more neutral, since our spec does not define UniversityDegreeCredential, the example here is misleading.
Obviously since the context is omitted, this term is expected to be defined as:
https://www.w3.org/ns/credentials/issuer-dependent#IdentityCredential
There was a problem hiding this comment.
I can revert this change if we get stuck on this attempt to improve this currently invalid example.
There was a problem hiding this comment.
IdentityCredential is going to confuse people given the charter in progress for the "Identity Credentials" work by Google, Apple, etc. We should avoid that terminology for two reasons:
- It will get confused by the upcoming W3C WG that will be similarly named.
- "Identity" is a lightning rod word that we should avoid in the specification, especially in examples.
- Using an issuer-dependent term as the core example is not something that will achieve consensus. Continuing to raise PRs that use issuer-dependent terms in core examples will continue to be objected to.
Alternate suggestion: ExampleDegreeCredential with a more comprehensive set of fixes in PR #1129.
There was a problem hiding this comment.
I think we are not a working group dedicated to the education vertical... and I find t he consistent bias towards academic use cases harmful to the standard... I hope we can find more neutral examples.
There was a problem hiding this comment.
Perhaps ExampleAchievementCredential which could include merit badges from scouting-like organizations; trophies/medals from athletic competitions; "top salesperson" from employer, professional org, etc.; and so on?
There was a problem hiding this comment.
This PR isn't just adding issue markers, it's attempting to also change the core example in the specification to language that is going to be problematic given the new W3C WG being formed around identity credentials. The naming is going to create unnecessary conflict.
| @@ -1336,7 +1336,7 @@ <h3>Types</h3> | |||
| <td> | |||
| <code>VerifiableCredential</code> and, optionally, a more specific | |||
| <a>verifiable credential</a> <a>type</a>. For example,<br> | |||
| <code>"type": ["VerifiableCredential", "UniversityDegreeCredential"]</code> | |||
| <code>"type": ["VerifiableCredential", "IdentityCredential"]</code> | |||
There was a problem hiding this comment.
IdentityCredential is going to confuse people given the charter in progress for the "Identity Credentials" work by Google, Apple, etc. We should avoid that terminology for two reasons:
- It will get confused by the upcoming W3C WG that will be similarly named.
- "Identity" is a lightning rod word that we should avoid in the specification, especially in examples.
- Using an issuer-dependent term as the core example is not something that will achieve consensus. Continuing to raise PRs that use issuer-dependent terms in core examples will continue to be objected to.
Alternate suggestion: ExampleDegreeCredential with a more comprehensive set of fixes in PR #1129.
| <code>"type": "StatusList2021Entry"</code> | ||
| <code>"type": "StatusList2021Entry"</code>. | ||
|
|
||
| <p>See <a href="https://www.w3.org/TR/vc-status-list/">vc-status-list</a>.</p> |
There was a problem hiding this comment.
This should be an informative ref to the status list spec.
| @@ -1401,6 +1406,8 @@ <h3>Types</h3> | |||
| <td> | |||
| A valid terms of use <a>type</a>. For example,<br> | |||
| <code>"type": "OdrlPolicy2017"</code>) | |||
|
|
|||
| <p class="issue" data-number="1123"></p> | |||
There was a problem hiding this comment.
Not sure that I'm a fan of adding issue markers throughout the spec for every issue. We have 65+ issues where we'd have to do that, only to go back through and remove them. It's unnecessary churn for the Editors (without good reason for the churn), and this isn't being done consistently, AFAICT, from the latest issue marker additions.
There was a problem hiding this comment.
It seems to me that issue markers are appropriate for significant publication milestones, like CRs. Less so, though arguable, for FPWDs. Far less so for ED-per-commit and/or daily-ED, though editor's prerogative probably holds.
Given that, I'd suggest that there be some rule of thumb that issue markers be added based on exceeding some number of comments and/or duration of discussion (I don't have a suggestion for either trigger), on the presumption that the issue is less likely to be closed quickly, and so more likely to persist beyond the next milestone publication and/or transition, which is likely to bring more unfamiliar readers for whom the issue markers are intended.
Preview | Diff