Tag: Open the codelist or add new field to track other events?

[jpmckinney]

Several publishers use the tag field to indicate a particular event in a contracting process. The tag field itself is loosely related to such events. However, it only contains events covered by core OCDS – not from extensions, which might include: bids disclosed, enquiry received, enquiry answered. A publisher might have other events they want to indicate the release being related to, e.g. complaint received, complaint declined.

An open codelist might decrease conformance to the most important tags. We might therefore want to add a separate field to identify the event to which the release is related.

Related: #791

[duncandewhurst]

Noting that the public private partnerships profile extends the releaseTag codelist with new codes relating to qualification and shortlisting

[jpmckinney]

https://github.com/openprocurement/ocds_currentStage_extension/blob/master/release-schema.json adds tender.currentStage to more narrowly track events/status.

[PaulBoroday]

tender.statusDetails looks more consistant, isn’t it?

#764

[jpmckinney]

@PaulBoroday Yes, for statuses we prefer the approach in #764. I only mention the other extension as additional information.

[jpmckinney]

From #777

In Kyrgyz Republic, in procedures with pre-qualification, bid information is disclosed in two stages:

1. response to qualification requirements
2. response to technical requirements and price proposal

We might consider more granular tags with respect to such events/disclosures.

From #983

Add a tag for updates that fall outside the procedure's lifecycle. For example, if a publisher adds address details to all its parties, there is no appropriate tag.

In the meantime, 'tenderUpdate' can be used for updates to the buyer and procuring entity parties, 'awardUpdate' for suppliers, 'implementationUpdate' for payees and payers, etc. These can of course be used in combination if a release updates all the parties.

To which @yolile replied:

Same for some extensions as: bids (tenderUpdate), auctions (tenderUpdate), complaints (tenderUpdate), secondStage (tenderUpdate? tender?)

[jpmckinney]

Noting that open-contracting-extensions/ocds_ppp_extension#11 removed some tags relating to pre-qualification from the releaseTag codelist in the OCDS for PPPs profile. We can consider re-adding them in OCDS itself.

[ColinMaudry]

Since the tag field is key, I'm not keen on modifying it in a minor version. It's hard to anticipate the impact of turning it into an open codelist.

+1 to create a new field, although statusDetails is a free text field that is meant to clarify a status field.

I'd suggest the additionalTag array, as an open codelist that could be extended in extensions.

[jpmckinney]

I think an additionalTags array is a good compromise.

Right now, we don't have clear and consistent demand for specific new codes. Even if we spent the time to define new codes, we wouldn't support every code that publishers would want to use, so there would still be a use case for additionalTags.

[ColinMaudry]

Do we need at least one code to create the field and the open codelist? The examples you give (#792 (comment)) would rather be implemented in the related extensions than in core (see #1179 about moving extensions to core).

[jpmckinney]

Any extensions that change the releaseTag closed codelist are non-compliant. So, we can consider those codes for the new codelist that goes with the additionalTags field.

[ColinMaudry]

Do you mean creating a codelist in the standard with codes related to bids, enquiries, etc.? Since these codes are related to concepts that are currently modeled in extensions, I thought these codes should be defined in the corresponding extensions.

[jpmckinney]

Aha, I understand. If we have no proposed codes that aren't related to extensions, I suppose the codelist will be empty.

[ColinMaudry]

Empty enum array in the schema, only headers in additionalTags.csv.... the tests are not going to like it!

[ColinMaudry]

Let's track the implementation in a new issue: #1184

[jpmckinney]

#1184 (adding a new field) was discussed but not taken forward. #1214 is the new issue to describe the only other alternative discussed in this issue: opening the releaseTag codelist.