open-contracting / ocds-extensions

Collects issues for published extensions in one place
1 stars 0 forks source link

selectionCriteria: Create version for OCDS 1.2 #221

Closed jpmckinney closed 7 months ago

jpmckinney commented 8 months ago

OCDS 1.2 adds tender.selectionCriteria as a string field.

This extension has it as an object containing description and criteria fields. This was needed for the LEFTI section in the EU profile, which is no longer relevant due to eForms.

There are some options:

  1. Change tender.selectionCriteria in OCDS to an object that contains a description field. The extension can then add the criteria field.
  2. Change the extension to move tender.selectionCriteria.criteria to tender.selectionCriteriaBreakdown, to match the proposal for award criteria in #192
  3. Remove tender-level selectionCriteria from the extension, as this is only used in the EU profile, and not in eForms.

2 implies 3, so we can start with 3.

The extension's CI is currently failing due to the conflict with OCDS 1.2-dev.

jpmckinney commented 8 months ago

Note that option 1 is proposed in https://github.com/open-contracting/standard/issues/1607. This issue can be closed if that issue is closed.

odscjen commented 8 months ago

1 also implies 3, the extension would now be adding selectionCriteria to Lot and criteria to tender.selectionCriteria

3 alone would mean that the detailed .criteria would only be available under Lot (until 2 was also completed).

  1. The main rationale given in https://github.com/open-contracting/ocds-extensions/issues/192 for making the change to award criteria is due to a limitation in 1.1 that was planned on being removed in 1.2 by making it the practice that a tender should always include at least one lot. But it now seems to be the case that this limitation will now not be addressed until 1.3 (or maybe even 2.0). If this sort of break down is needed for the award criteria it make sense to have continuity in naming between the award and the selection criteria. But if the recommendation to make everything a lot even if there tender is not technically split into lots isn't going to come into force until 1.3 or later, then if we do 3 as noted above it means no criteria available in tender.

Given all that I think it makes sense to do all 3 as 2 PRs, one to 1.2-dev and one to the extension. So

  1. Change tender.selectionCriteria in OCDS 1.2 to an object that contains a description field.
  2. Move tender.selectionCriteria.criteria to tender.selectionCriteriaBreakdown in the Selection Criteria extension
  3. Remove tender.selectionCriteria from the Selection Criteria extension, leaving lot.selectionCriteria

When the merge of Lots extension into OCDS does happen the lots.selectionCriteria should be revisited to make it consistent with the tender and award criteria elements discussed here.

jpmckinney commented 8 months ago

Hmm, if we do your (1) then we don't need to do your (2) or (3).

In mine, I meant to present (1) and (2) as alternatives, where we'd choose only one of them.

odscjen commented 8 months ago

But if we do (1) (yours or mine) without doing (3) then there'll be a definition of Tender.selectionCriteria in both the core ocds 1.2 and the extension, which is not good or have I misunderstood what the error "Exception: unexpectedly overwrites /definitions/Tender/properties/selectionCriteria/title /home/runner/work/ocds_selectionCriteria_extension/ocds_selectionCriteria_extension/release-schema.json" means?

Or in your (1) did you mean to imply that the extension would also be adjusted to remove the definition of Tender.selectionCriteria and it's .description leaving just criteria being added to Tender.selectionCriteria as defined in the core?

jpmckinney commented 8 months ago

I'll make an exemption to the rule, like I did for submissionTerms, so that the error message won't occur. I can't make an exemption yet, because right now OCDS 1.2 and the extension are inconsistent. Once they are consistent, I'll make the exemption.

odscjen commented 8 months ago

ah, cool, in that case I think (1) is the way to go, I'll make a PR for it