Which codelists to include on codelists.md?

[jpmckinney]

The codelists listed are:

• bidStatistics.csv
• bidStatus.csv
• dataType.csv
• documentType.csv
• financeCategory.csv
• initiationType.csv
• milestoneCode.csv
• milestoneType.csv
• partyRole.csv
• preQualificationStatus.csv
• relatesTo.csv
• releaseTag.csv
• responseSource.csv
• riskAllocation.csv
• riskCategory.csv
• votingRights.csv

From the extensions used, this excludes:

• geometryType.csv (location)
• locationGazetteers.csv (location)
• chargePaidBy.csv (charges, tariffs)
• financeType.csv (finance)
• metricID.csv (ppp)

We can either:

1. Include all codelists from all extensions used
2. Include only codelists used by framework.md

If the former, the solution is easy (add the 5 from the second list). If the latter, we need to review which of the codelists are actually used by the profile. For example, we don't use bidStatistics.csv anywhere.

In fact, why is the bid extension in the profile at all? It's used in the example, but that section of the example is never referenced. (This might lead to a review of which extensions to include in the first place.)

[jpmckinney]

Once this issue is closed, I can update #234 and then ask CDS to translate the iterative improvements.

[jpmckinney]

If we review which extensions to include, we can check each off as we validate which ought to be included.

Used in examples/full.json, but otherwise not referenced?

• bids (bids/details and bids/statistics) remove preQualification extension, update framework reference #245
• documentation_details (Document.author only) Which codelists to include on codelists.md? #233 (comment)

To be removed:

• budget (planning/budget/budgetBreakdown)
• process_title (title and description)
• requirements (tender/criteria and bids/details/requirementResponses)
• transaction_milestones (contracts/implementation/transactions/relatedImplementationMilestone)

Explicitly referenced in guidance:

• milestone_documents (I.10. Project approval dates)

Explicitly referenced in :jsonpointer::

• charges
• finance
• metrics
• performance_failures
• ppp
• project
• qualification
• risk_allocation
• shareholders
• signatories
• tariffs

And lastly:

• location, as dependency of project extension, though Item.deliveryLocation also used in example only

[jpmckinney]

My preference is to omit extensions that aren't mentioned in the guidance, from both the profile's schema and from the example.

There are many extensions that are relevant to PPPs that aren't in the profile (given that many/most extensions have now been authored after OCDS for PPPs was), but they aren't included here. Publishers are expected to consider such extensions in the normal course of publishing OCDS.

[jpmckinney]

Going back to the issue description, if we omit the unchecked extensions, then I'm fine with just including all codelists from all extensions in the profile, since we'll have ended up with the same number of codelists that we have now (after removing 2 bids and 3 requirements codelists).

[duncandewhurst]

Once #245 is merged, bids/details will appear in the framework reference.

The example is based on Red Compartida's implementation of the World Bank framework, which is why it includes some extensions and fields that are not explicitly referenced in the framework reference. So that learning from that implementation is not lost, we should consider whether to update the framework reference to mention these extensions and what they can be used to publish.

[jpmckinney]

Are the extensions directly related to content from The World Bank Framework for Disclosure in Public Private Partnership Projects, or were they just useful for disclosing PPPs in the case of Red Compartida?

If the latter, then they don't belong as part of the consolidated extension, and should be opt-in. If so, we can create a separate issue to add additional guidance pages for using extensions relevant to PPPs.

[duncandewhurst]

bids

See above, this should be included in the consolidated extension.

documentation_details

Although the fields in this extension are not explicitly referenced in the Markdown content on the framework reference page, prior to daf991e the fields in this extension were displayed in the schema tables shown on that page.

The concepts in the extension are not explicitly referenced in the WB framework, but the extension was developed to meet needs identified during the initial development of OCDS for PPPs, including:

• signposting where disclosures required by the framework are located within documents, which can be very long
• identifying whether the authors of studies and assessments carried out during the planning phase were later involved in the procurement process

As such, I think documentation_details should still be included in the consolidated extension. We should also restore at least one Document schema table to the framework reference so that implementers are aware of the extra fields and can consider collecting and publishing them.

process_title

I'm not sure what purpose this is serving. In the example, the same values are provided in title and project/title and description and project/description.

The framework reference only mentions the fields under project so we should remove process_title from the consolidated extension and remove its fields from the example.

budget, requirements, transaction_milestones

These extensions were useful for Red Compartida, but I'm happy for them to be opt-in otherwise.

[jpmckinney]

Sounds good to keep bids and documentation_details, and to remove the rest.

I think all "Document" links point to https://standard.open-contracting.org/profiles/ppp/latest/en/reference/documents/, which has a table with all extended fields.