-
Notifications
You must be signed in to change notification settings - Fork 46
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
Tag: Open the codelist or add new field to track other events? #792
Comments
Noting that the public private partnerships profile extends the releaseTag codelist with new codes relating to qualification and shortlisting |
https://github.com/openprocurement/ocds_currentStage_extension/blob/master/release-schema.json adds |
tender.statusDetails looks more consistant, isn’t it? |
@PaulBoroday Yes, for statuses we prefer the approach in #764. I only mention the other extension as additional information. |
From #777 In Kyrgyz Republic, in procedures with pre-qualification, bid information is disclosed in two stages:
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:
|
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. |
Since the +1 to create a new field, although I'd suggest the |
I think an 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 |
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). |
Any extensions that change the |
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. |
Aha, I understand. If we have no proposed codes that aren't related to extensions, I suppose the codelist will be empty. |
Empty |
Let's track the implementation in a new issue: #1184 |
Several publishers use the
tag
field to indicate a particular event in a contracting process. Thetag
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
The text was updated successfully, but these errors were encountered: