Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 43 commits into from Mar 25, 2024

Conversation

duncandewhurst
Copy link
Contributor

@duncandewhurst duncandewhurst commented Oct 12, 2023

@duncandewhurst
Copy link
Contributor Author

duncandewhurst commented Oct 12, 2023

This might need to be merged into #1509 depending on the answer to #1160 (comment)

@duncandewhurst duncandewhurst changed the title release-schema: Add finalStatus to tender, award and contract release-schema: Add finalStatus to tender, award and contract. Clarify tender.datePublished. Oct 12, 2023
@jpmckinney
Copy link
Member

For #1160 we had started using the phrase "contracting documents (for example, procurement documents)" based on this exchange #1509 (comment)

@duncandewhurst duncandewhurst marked this pull request as ready for review October 23, 2023 22:56
@jpmckinney
Copy link
Member

Re: 'withdrawn', I had commented in #1160 (comment)

(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
Copy link
Contributor Author

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

schema/codelists/awardFinalStatus.csv Outdated Show resolved Hide resolved
schema/codelists/awardFinalStatus.csv Outdated Show resolved Hide resolved
schema/codelists/contractFinalStatus.csv Outdated Show resolved Hide resolved
schema/codelists/contractFinalStatus.csv Outdated Show resolved Hide resolved
schema/dereferenced-release-schema.json Outdated Show resolved Hide resolved
schema/dereferenced-release-schema.json Outdated Show resolved Hide resolved
schema/dereferenced-release-schema.json Outdated Show resolved Hide resolved
schema/release-schema.json Outdated Show resolved Hide resolved
schema/release-schema.json Outdated Show resolved Hide resolved
schema/release-schema.json Outdated Show resolved Hide resolved
duncandewhurst and others added 10 commits November 14, 2023 09:34
Co-authored-by: odscjen <95221058+odscjen@users.noreply.github.com>
Co-authored-by: odscjen <95221058+odscjen@users.noreply.github.com>
Co-authored-by: odscjen <95221058+odscjen@users.noreply.github.com>
Co-authored-by: odscjen <95221058+odscjen@users.noreply.github.com>
Co-authored-by: odscjen <95221058+odscjen@users.noreply.github.com>
Co-authored-by: odscjen <95221058+odscjen@users.noreply.github.com>
Co-authored-by: odscjen <95221058+odscjen@users.noreply.github.com>
@duncandewhurst
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@duncandewhurst
Copy link
Contributor Author

duncandewhurst commented Feb 27, 2024

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 df3ca4e. 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 6ad1ff7

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 71f3226 and a3ef96f.

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

Done in 9e32f1f

* 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 3fc8aa8

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 1b9c1ca

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 50598ca

@duncandewhurst
Copy link
Contributor Author

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

  1. In 0da5c89, 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
Copy link
Member

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
Copy link
Member

Done in 1b9c1ca

I committed this now.

docs/guidance/build/change_history.md Outdated Show resolved Hide resolved
docs/guidance/build/change_history.md Outdated Show resolved Hide resolved
docs/history/changelog.md Outdated Show resolved Hide resolved
@jpmckinney
Copy link
Member

In 0da5c89, 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.

guidance/build/change_history: Restore mention of finalStatus in merged releases. changelog: Remove repetitions.
@jpmckinney jpmckinney merged commit fd47de6 into 1.2-dev Mar 25, 2024
10 checks passed
@jpmckinney jpmckinney deleted the 1160-add-finalStatus-fields branch March 25, 2024 03:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update all status codelists
3 participants