Update location-verification-API-Readiness-Checklist.md

[jlurien]

What type of PR is this?

• documentation

What this PR does / why we need it:

User Story for location-verification is now available

[github-actions[bot]]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.02s
✅ OPENAPI	spectral	3		0	4.94s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.83s
✅ YAML	yamllint	3		0	0.74s

See detailed report in MegaLinter reports

_MegaLinter is graciously provided by _

[hdamker]

The PR is correct, but is there a specific reason that the user story is in Supporting Documents and not in API Documentation as with other APIs? But guess that doesn't matter too much.

[jlurien]

The PR is correct, but is there a specific reason that the user story is in Supporting Documents and not in API Documentation as with other APIs? But guess that doesn't matter too much.

I guess no particular reason. should it be moved to API Doc?

[jlurien]

User Story moved

[jlurien]

@hdamker for

| 9 | Test result statement | O | O | O | M |tbd| link |

Do you know what is expected? Do we have any example from other APIs? Thanks

[bigludo7]

@hdamker for

| 9 | Test result statement | O | O | O | M |tbd| link |

Do you know what is expected? Do we have any example from other APIs? Thanks

I had same issue in OTP validation API. I've pinged @trehman-gsma for help - having a statement from GSMA that at least one implem has go thru the test could perhaps be an option?

[hdamker]

Do you know what is expected? Do we have any example from other APIs? Thanks

I'm not aware of an example that any of the APIs has achieved this line within this release cycle. Suppose we accept this in the TSC for this cycle and have also to define this criteria more precise.

How it is described:

A statement in a discussion issue of the API Sub Project by at least one of the API Sub Project members that the Gherkin feature files have been successfully executed against their (lab) API implementation.

So not an implementation of a previous public version (which GSMA can have certified), but a (lab) implementation of the release candidate version from M3 with the test definition from the same version. The motivation was to reduce the risk that bugs in the API specification and inconsistencies between API and Test specification will be found only after the public release.

But as the release candidates came late and the test definitions in many cases even later, there was no time to fulfil this criteria in the current cycle.

[jlurien]

I agree that is going to be hard to fully comply with this for this meta, due to the time constraints.

[jlurien]

@hdamker @bigludo7 how should we proceed with the PR regarding "Test result statement"? Do we open an issue in RM? Do we keep "tbd" in the meantime?

[hdamker]

@hdamker @bigludo7 how should we proceed with the PR regarding "Test result statement"? Do we open an issue in RM? Do we keep "tbd" in the meantime?

Issue in RM to make them (and the TSC) aware makes sense for to me. The other APIs heading for stable have reported "N" as status, which is maybe more true, as there is no plan to get it done before the meta release.

[jlurien]

Created issue in RM: https://github.com/camaraproject/ReleaseManagement/issues/89

[jlurien]

Until a final resolution to the issue I have filled the row with "N" and a reference to the issue in the comments column

[jlurien]

@bigludo7 @maxl2287 please approve so I can merge