From 283061c97f97127410c812eba23d9accebf12c92 Mon Sep 17 00:00:00 2001 From: Yohanna Lisnichuk Date: Mon, 17 Jun 2024 15:42:28 -0400 Subject: [PATCH 1/3] guidance/publish/quality: update basic and contunuous improvement criteria To match the new OCP MEL definitions --- docs/guidance/publish/quality.md | 45 ++++++++++++++++++++------------ 1 file changed, 29 insertions(+), 16 deletions(-) diff --git a/docs/guidance/publish/quality.md b/docs/guidance/publish/quality.md index a782cf5d3..b983b13c0 100644 --- a/docs/guidance/publish/quality.md +++ b/docs/guidance/publish/quality.md @@ -36,7 +36,8 @@ All OCDS publications ought to meet the following criteria: 1. **Reviewable**: The [OCDS Data Review Tool](https://standard.open-contracting.org/review/) is able to report results on the data. 1. **Appropriate**: Concepts are published in semantic accordance with the rules of the OCDS (or registered extensions) rather than using a non-OCDS field or code. 1. **Active**: For each publisher, there is an OCDS release with a top-level `date` field value within the last 12 months. -1. **Parity**: For each publisher, for the _time period_ and _buyers_ covered by the data, there isn’t another dataset by the same publisher that covers more than 25% more contracting processes. +1. **Representative**: It describes all contracting processes within a relevant population. For example: all contracts for a public-private partnership; all above-threshold contracts since 2020 excluding those by state-owned enterprises, etc. +1. **Relevant**: Whether at least 1 contracting process answers "who bought what from whom, for how much, when, and how". The Data Support Team is happy to review draft and newly published OCDS data and can work with publishers with advice to meet the above criteria. A publication that does not meet this minimum threshold will not be listed as a publisher by OCP as part of [OCP’s regular reporting](https://www.open-contracting.org/why-open-contracting/learning/). @@ -48,31 +49,43 @@ From the minimum threshold above, we want to support publishers to continue to i Improvement on the below indicators demonstrate that the published information is becoming more complete about the contracting processes within the publisher’s jurisdiction. +1. Increase the number of indicators covered (volume) +1. Increase the average coverage of fields per compiled release, for example either new fields not previously published in any release, or an increase in the use of a field across releases (e.g. very little data was published about direct awards and now more is being published about direct awards) (density) +1. Increase the number of buyers covered in the publication ("who") +1. Increase the number of methods covered in the publication ("how") 1. Publish subsequent releases per OCID to show how the contracting process is progressing over time -1. Increase the publication of historical information (based on a minimal set of date fields that appear across all sources, e.g. `tender.tenderPeriod`, `awards.date`, and `contracts.dateSigned`) -1. Increase the average coverage of fields per compiled release, for example either new fields not previously published in any release, or an increase in the use of a field across releases (e.g. very little data was published about direct awards and now more is being published about direct awards) -1. Increase the number of buyers covered in the publication -1. Increase the number of concepts covered relative to non-OCDS data +1. Increase the temporal coverage into the past (based on a minimal set of date fields that appear across all sources, e.g. `tender.tenderPeriod`, `awards.date`, and `contracts.dateSigned`) ("when") + +### Timeliness + +1. Publish multiple updates per contracting process +1. Decrease the delay between the information’s creation and publication + +### Accessibility + +Improvements on the below indicators demonstrate that it is becoming easier for users to access the published information. + +1. Publish a user guide or publication policy that describes the scope, at minimum +1. Publish API documentation that describes the endpoints and parameters, at minimum +1. Increase the number of access methods (API endpoints, bulk downloads) +1. Increase the number of data formats (JSON, Excel, CSV) +1. Facilitate indirect data use (e.g. search, dashboards, etc.) + +### Retrievability and legal + +1. Decrease the number of HTTP errors +1. Use a data license that conforms to the [Open Definition](https://opendefinition.org) ### Correctness Improvement on the below indicators demonstrates that the concepts are being published more correctly, improving usability. 1. Decrease the types and number of structural errors reported by the OCDS Data Review Tool, e.g. moving from 20 types of errors, each occurring more than 100,000 times, to 10 types of errors, each occurring less than 100 times -1. Decrease the average number of structural errors per release -1. Decrease the number of instances in which a concept is not published in conformance with OCDS semantics +1. Decrease the average number of structural errors per contracting process +1. Decrease the number of conformance issues 1. Decrease the number of types of quality warnings using OCDS Pelican 1. Decrease the average number of quality warnings per release using OCDS Pelican -### Access - -Improvements on the below indicators demonstrate that it is becoming easier for users to access the published information. - -1. Publish record packages containing compiled releases -1. Decrease the number of HTTP errors -1. Increase the number of access methods (API endpoints, bulk downloads) -1. Decrease the number of license restrictions - As publishers improve, the Data Support Team can work with them to identify how they can improve on the above criteria. OCP will note whether a publisher has improved in [OCP’s regular reporting](https://www.open-contracting.org/why-open-contracting/learning/). ## Advanced criteria From 3aad7dbd487c668c693619be734a841ac0984a51 Mon Sep 17 00:00:00 2001 From: Yohanna Lisnichuk Date: Mon, 17 Jun 2024 15:51:27 -0400 Subject: [PATCH 2/3] changelog: record #1697 --- docs/history/changelog.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/history/changelog.md b/docs/history/changelog.md index db4b7304c..1b8857e6b 100644 --- a/docs/history/changelog.md +++ b/docs/history/changelog.md @@ -49,6 +49,7 @@ Per the [normative and non-normative content and changes policy](https://docs.go * [#1414](https://github.com/open-contracting/standard/pull/1414) Remove the planning section from Easy releases and Change history. * [#1494](https://github.com/open-contracting/standard/pull/1497) Add guidance on preparing test data to Check your data section. * Publish: + * [#1697](https://github.com/open-contracting/standard/pull/1697) Update the Basic Criteria and Continuous improvement to match the OCP's new MEL definitions. * Merge Publication policy and Licensing pages into Publish page [#986](https://github.com/open-contracting/standard/pull/986) [#1012](https://github.com/open-contracting/standard/pull/1012). * Replace guidance on publication levels [#980](https://github.com/open-contracting/standard/pull/980) [#1013](https://github.com/open-contracting/standard/pull/1013) [#1045](https://github.com/open-contracting/standard/pull/1045). * [#1427](https://github.com/open-contracting/standard/pull/1427) Add guidance about recommended extensions. From 8d33f1d978234e302b2d85122fa330265dfee806 Mon Sep 17 00:00:00 2001 From: James McKinney <26463+jpmckinney@users.noreply.github.com> Date: Fri, 28 Jun 2024 18:18:00 -0400 Subject: [PATCH 3/3] guidance/publish/quality: Better align wording with MEL --- docs/guidance/publish/quality.md | 30 +++++++++++++++--------------- docs/history/changelog.md | 4 ++-- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/guidance/publish/quality.md b/docs/guidance/publish/quality.md index b983b13c0..6e79403c3 100644 --- a/docs/guidance/publish/quality.md +++ b/docs/guidance/publish/quality.md @@ -31,13 +31,13 @@ Understanding all of the challenges above, we understand that increasing the tra All OCDS publications ought to meet the following criteria: 1. **Registered**: The data uses a [registered OCID prefix](../../schema/identifiers.md#contracting-process-identifier-ocid). +1. **Reviewable**: The [OCDS Data Review Tool](https://standard.open-contracting.org/review/) can report results for the data. +1. **Appropriate**: The data is in semantic accordance with OCDS. Additional fields and codes do not overlap semantically with standardized fields and codes. +1. **Relevant**: The data answers "who bought what from whom, for how much, when, and how" for at least one contracting process. 1. **Discoverable**: It is possible to discover the data by navigating a website whose homepage is indexed by popular web search engines. -1. **Retrievable**: It is possible to automate the download of all the data, either using an HTML page listing bulk download URLs, or using only machine-readable data as input. -1. **Reviewable**: The [OCDS Data Review Tool](https://standard.open-contracting.org/review/) is able to report results on the data. -1. **Appropriate**: Concepts are published in semantic accordance with the rules of the OCDS (or registered extensions) rather than using a non-OCDS field or code. -1. **Active**: For each publisher, there is an OCDS release with a top-level `date` field value within the last 12 months. -1. **Representative**: It describes all contracting processes within a relevant population. For example: all contracts for a public-private partnership; all above-threshold contracts since 2020 excluding those by state-owned enterprises, etc. -1. **Relevant**: Whether at least 1 contracting process answers "who bought what from whom, for how much, when, and how". +1. **Representative**: The data describes all contracting processes within a relevant population. For example: all contracts for a public-private partnership; all above-threshold contracts since 2020 excluding those by state-owned enterprises, etc. +1. **Active**: The data contains a contracting process release with a top-level `date` value within the previous four calendar quarters. +1. **Retrievable**: It is possible for software to download the data in full, either by using an HTML page listing bulk download URLs, or by using machine-readable data as the only input. The Data Support Team is happy to review draft and newly published OCDS data and can work with publishers with advice to meet the above criteria. A publication that does not meet this minimum threshold will not be listed as a publisher by OCP as part of [OCP’s regular reporting](https://www.open-contracting.org/why-open-contracting/learning/). @@ -50,16 +50,16 @@ From the minimum threshold above, we want to support publishers to continue to i Improvement on the below indicators demonstrate that the published information is becoming more complete about the contracting processes within the publisher’s jurisdiction. 1. Increase the number of indicators covered (volume) -1. Increase the average coverage of fields per compiled release, for example either new fields not previously published in any release, or an increase in the use of a field across releases (e.g. very little data was published about direct awards and now more is being published about direct awards) (density) -1. Increase the number of buyers covered in the publication ("who") -1. Increase the number of methods covered in the publication ("how") +1. Increase the average number of fields covered per contracting process (density) +1. Increase the number of buyers covered ("who") +1. Increase the number of methods covered ("how") 1. Publish subsequent releases per OCID to show how the contracting process is progressing over time -1. Increase the temporal coverage into the past (based on a minimal set of date fields that appear across all sources, e.g. `tender.tenderPeriod`, `awards.date`, and `contracts.dateSigned`) ("when") +1. Increase the temporal coverage into the past ("when") ### Timeliness 1. Publish multiple updates per contracting process -1. Decrease the delay between the information’s creation and publication +1. Decrease the delay between the information's creation and publication ### Accessibility @@ -80,11 +80,11 @@ Improvements on the below indicators demonstrate that it is becoming easier for Improvement on the below indicators demonstrates that the concepts are being published more correctly, improving usability. -1. Decrease the types and number of structural errors reported by the OCDS Data Review Tool, e.g. moving from 20 types of errors, each occurring more than 100,000 times, to 10 types of errors, each occurring less than 100 times +1. Decrease the number of types of structural errors 1. Decrease the average number of structural errors per contracting process -1. Decrease the number of conformance issues -1. Decrease the number of types of quality warnings using OCDS Pelican -1. Decrease the average number of quality warnings per release using OCDS Pelican +1. Decrease the number of [conformance](../../schema/conformance_and_extensions) issues +1. Decrease the number of types of quality warnings +1. Decrease the average number of quality warnings per contracting process As publishers improve, the Data Support Team can work with them to identify how they can improve on the above criteria. OCP will note whether a publisher has improved in [OCP’s regular reporting](https://www.open-contracting.org/why-open-contracting/learning/). diff --git a/docs/history/changelog.md b/docs/history/changelog.md index 1b8857e6b..de29b17fd 100644 --- a/docs/history/changelog.md +++ b/docs/history/changelog.md @@ -49,9 +49,9 @@ Per the [normative and non-normative content and changes policy](https://docs.go * [#1414](https://github.com/open-contracting/standard/pull/1414) Remove the planning section from Easy releases and Change history. * [#1494](https://github.com/open-contracting/standard/pull/1497) Add guidance on preparing test data to Check your data section. * Publish: - * [#1697](https://github.com/open-contracting/standard/pull/1697) Update the Basic Criteria and Continuous improvement to match the OCP's new MEL definitions. * Merge Publication policy and Licensing pages into Publish page [#986](https://github.com/open-contracting/standard/pull/986) [#1012](https://github.com/open-contracting/standard/pull/1012). - * Replace guidance on publication levels [#980](https://github.com/open-contracting/standard/pull/980) [#1013](https://github.com/open-contracting/standard/pull/1013) [#1045](https://github.com/open-contracting/standard/pull/1045). + * Replace publication levels guidance with data quality guidance [#980](https://github.com/open-contracting/standard/pull/980) [#1013](https://github.com/open-contracting/standard/pull/1013). + * Update data quality guidance to match [OCP Strategy 2024-2030](https://www.open-contracting.org/strategy-2024-2030/) [#1045](https://github.com/open-contracting/standard/pull/1045) [#1697](https://github.com/open-contracting/standard/pull/1697). * [#1427](https://github.com/open-contracting/standard/pull/1427) Add guidance about recommended extensions. * Various minor improvements [#1051](https://github.com/open-contracting/standard/pull/1051) [#1080](https://github.com/open-contracting/standard/pull/1080) [#1083](https://github.com/open-contracting/standard/pull/1083) [#1085](https://github.com/open-contracting/standard/pull/1085) [#1091](https://github.com/open-contracting/standard/pull/1091) [#1130](https://github.com/open-contracting/standard/pull/1130) [#1227](https://github.com/open-contracting/standard/pull/1227) [#1299](https://github.com/open-contracting/standard/pull/1299) [#1337](https://github.com/open-contracting/standard/pull/1337) [#1384](https://github.com/open-contracting/standard/pull/1384).