Remove at risk issue markers for property extension points.

[msporny]

The WG discussed the process for removing "AT RISK" issue markers for properties and property sections during the call today. The following was the agreed-upon process (see transcript below). In order for an "AT RISK" marker to be removed, and the property to remain in the specification, the section MUST:

1. Update the example to use an extension specification that has been implemented, and values that utilize the extension point.
2. Have the type field specified, using a type specified by the extension specification.
3. A test in the VCDM v2.0 test suite that tests the example by issuing a VC that contains the example.
4. Result in at least two implementations issuing a conforming VC that contains the example.

The following property extension points are currently at risk:

• confidenceMethod
• evidence
• refreshService
• renderMethod
• termsOfUse

[iherman]

The issue was discussed in a meeting on 2024-02-14

• no resolutions were taken

View the transcript

2.1. Remove the at risk issue marker for Evidence (issue vc-data-model#1303)

See github issue vc-data-model#1303.

Michael Jones: looking at 1303 first Remove the at risk issue marker for Evidence.

Manu Sporny: See section in the spec.

Manu Sporny: question for the group: Jefferey Yaskin asked for a mini-registry and to be done with this. we could do that. w.r.t tests what did we say we would do? I have two recollections.
… have to demonstrate there is a spec using the property. there are multiple impls. 1EdTech have an evidence property. thought the tests we were writing were just testing the 'type' for evidence. need to ask what are we testing for these extension points.
… normative guidance we give is : it can't be empty, have to specify it's type, id should be a URL, ... 1EdTech has multiple impls. at what point do we remove the at risk marker? when we create tests?
… is that the bar we're trying to hit?

Ivan Herman: from a practical point of view, the only obligation we have is to remove these markers and feature itself when we go to PR. at this point there is no rush. at some point we'll have to look at the whole test suite report and then risk markers.
… issue was raised before CR. why bother at this point? went to CR with marker in.

Brent Zundel: less a post-CR and then a pre-PR?

Ivan Herman: yes.

Manu Sporny: #1295 (review).

Manu Sporny: agree, but still need clarity. Orie said the example needs to be updated and covered in tests. what does 'covered' mean? ... having input/output that looks like the example. then we can remove the at risk flag. concretely we update the example to use the IMS Global evidence property.
… there will be a test for that in the core data model. to make sure there's a type and to make sure nobody throws an error (or at least 2 don't.) and then at if at the end of CR two impls are doing this, we remove the issue marker.

Gabe Cohen: +1 to that proposal.

Manu Sporny: does anyone disagree with that proposal?

Manu Sporny: +1 for it being for how we evaluate /all/ properties.

Manu Sporny: (all "at risk" properties).

Ivan Herman: fine with that. need to be clear this is not for the evidence property only. what's being described is 'how do we accept that a given property/term stays in the spec as a normative thing' need a general approach to do that.

Brent Zundel: labeled as before-PR. manu has outlined a clear course of action. no one assigned yet.

Ivan Herman: Manu has outlined ... but needs to be documented somewhere.
… will there be some document that says this is the way we remove the markers?

Brent Zundel: do you have a proposal?

Ivan Herman: at the end of the CR process we need a report. to say whether we are fine or not. criteria may differ, this is not in the same category as other issues. my proposal is to have a document and record this in it.

Manu Sporny: I have raised an issue to track this (#1437), will add details. to remove at risk issue markers & properties. will be a before-PR thing. will document the process and track at risk properties.

See github issue vc-data-model#1437.

Brent Zundel: can anyone take the issue?

Manu Sporny: yes, I will.