release-schema: Add finalStatus to tender, award and contract. Clarify tender.datePublished.

[duncandewhurst]

• Closes #1160 (addressing points 3 and 4 from https://github.com/open-contracting/standard/issues/1160#issuecomment-1596302881)

[duncandewhurst]

This might need to be merged into #1509 depending on the answer to https://github.com/open-contracting/standard/issues/1160#issuecomment-1758779508

[jpmckinney]

For #1160 we had started using the phrase "contracting documents (for example, procurement documents)" based on this exchange https://github.com/open-contracting/standard/pull/1509#discussion_r878558410

[jpmckinney]

Re: 'withdrawn', I had commented in https://github.com/open-contracting/standard/issues/1160#issuecomment-1141320491

(3. ii.) I'm not sure that we need "no more publication". I'm not aware that anyone has used the 'withdrawn' code for tender/status. At any rate, this is moreso information for the publication policy (e.g. "We only publish up to the initial contract values. We don't publish any modifications."). We have not yet witnessed any demand for "This specific contract will no longer receive updates, unlike other contracts." If we do end up needing it, it deserves its own field, because "no more updates" is orthogonal (i.e. is a separate concern to) the "status" or "final state" of the object. For example, it could be that a contract has reached a final state, but it can still be updated (evaluations of its performance, contract monitoring results, other later assessments, etc.). "No more updates" shouldn't overwrite the "final state" value.

There hasn't been any disagreement yet.

I suggested a change to the deprecation note for tenderStatus' 'withdrawn' in #1509.

[duncandewhurst]

Ah, I'd missed that. Your reasoning sounds good to me so I've removed the 'withdrawn' codes.

[duncandewhurst]

Sorry about the long list of small commits. GitHub wouldn't let me commit the suggestions in a batch. Turns out you can't do that when there is a conflict with the base branch. I thought I'd resolved merge conflicts, but I hadn't realised another PR was merged into 1.2-dev since I merged 1.2-dev into this branch a few minutes ago!

@odscjen FYI - you don't need to review dereferenced-release-schema.json as that is automatically generated from the release-schema.json by the pre-commit script.

[duncandewhurst]

@jpmckinney just checking that you saw the review request on this PR.

[duncandewhurst]

We need to rename statusDetails to finalStatusDetails, and re-order the fields so that details appears after status. (Use that same order for the two changelog entries.)

Done in df3ca4eb6436fd3366f395209f74ca9fa3642246. finalStatus and finalStatusDetails appear at the end of each object. Let me know if you want them somewhere else. I combined the changelog entries since both changes are made in this PR.

Codelists:

Adding more substantive comments here so that they don't become hard to find as resolved comments.

* terminatedSuccessfully was added to OCDS 1.2 in [Add termination codes to contractStatus #1201](https://github.com/open-contracting/standard/pull/1201) to close [contractStatus: Add termination codes #395](https://github.com/open-contracting/standard/issues/395), and was named as such to be consistent with 'terminated', which was described as:
  > The contract was concluded and in force, and has now come to a close. This might be due to the successful completion of the contract, or might be early termination due to some non-completion.

  However, this new codelist can now be consistent with the other new codelists, and use 'complete' (both for the code and title) for the "happy" result.

* Re: terminatedEarly, to mirror 'complete', I suggest 'incomplete'.

Though it is often used in negative scenarios, I confirmed that "terminated" on its own can mean e.g. "contract expiration", so its use in the code descriptions is okay.

Done in 6ad1ff7814d86ecf1a15524ba0ef4b2258e9db06

Examples:

* Update JSON and CSV examples to use `finalStatus` instead of `status` where possible, and to just remove `status` if not possible (e.g. if 'active'). Note: Milestone `status` remains correct.

Done in 71f3226d3c11153c7dd618a316bdc0dd49eadacd and https://github.com/open-contracting/standard/pull/1648/commits/a3ef96f0dcca7b0b24955c529b932933104e6a8d.

* Update Markdown examples similarly. I think these are only: user_needs, change_history, unsuccessful_processes, framework_agreements.

Done in 9e32f1f1b1d1a4852013abc77a77d16724ef1b68

* We need to revert [Add contract suspension worked example #1344](https://github.com/open-contracting/standard/pull/1344) re: contracts_suspension. I've updated the related issue [Worked example (1.2): Contract suspension #758](https://github.com/open-contracting/standard/issues/758).

Done in 3fc8aa8dd5ce1c8268bc0750ee563056310e0a84

codelists.md:

* Add `{deprecated}` directives to the old status codelists.

* Contract Status still has a `{versionchanged}` directive that should have been removed in [`tenderStatus`, `awardStatus` `contractStatus`: update codes #1509](https://github.com/open-contracting/standard/pull/1509) when we removed those two codes.

* Remove the paragraphs for Tender Status, Award Status and Contract Status, as they add no new content compared to the field description (or in the case of Contract Status, needs to be removed viz contract_suspension).

Done in 1b9c1ca535417d3ad1df390b58b248eaf04a68a7

Other changes:

* `releaseTag.csv` mentions status. I think just delete the last clause. The "pipeline" wording comes from [Codelist updates: Introduce a 'planningUpdate' releaseTag and 'withdrawn' tenderStatus #201](https://github.com/open-contracting/standard/issues/201) but it occurs nowhere else in OCDS.

Done in 50598ca0b461248b411b9c85dcae81adbf1374da

[duncandewhurst]

@jpmckinney I think this PR is ready for review now. Two things to note:

1. In 0da5c89e0b428ca3fc0753afcca111d8ffd1a2c2, I updated the deprecation note for 'complete' in the tender status codelist to refer to 'complete' in the new tender final status codelist.
2. I noticed that docs/examples/unsuccessful_tender/tender.json has lots.status = 'unsuccessful' - should the lot extension also be updated following the same logic as the changes to tender?

[jpmckinney]

I noticed that docs/examples/unsuccessful_tender/tender.json has lots.status = 'unsuccessful' - should the lot extension also be updated following the same logic as the changes to tender?

Yes, please create an issue.

[jpmckinney]

• Contract Status still has a {versionchanged} directive that should have been removed in tenderStatus, awardStatus contractStatus: update codes #1509 when we removed those two codes.

Done in https://github.com/open-contracting/standard/commit/1b9c1ca535417d3ad1df390b58b248eaf04a68a7

I committed this now.

[jpmckinney]

In https://github.com/open-contracting/standard/commit/0da5c89e0b428ca3fc0753afcca111d8ffd1a2c2, I updated the deprecation note for 'complete' in the tender status codelist to refer to 'complete' in the new tender final status codelist.

I changed it to instead match the message for the other codes that got transferred to the new field.