Closed jpmckinney closed 9 months ago
I think it would be helpful to explicitly state in the description of tender
that it can be used in either a planning process or a contracting process and that its properties should be interpreted as such. We can give the different interpretations of tender.value
discussed in #914 as an example.
I think it would be helpful to explicitly state in the description of tender that it can be used in either a planning process or a contracting process and that its properties should be interpreted as such. We can give the different interpretations of tender.value discussed in #914 as an example.
https://github.com/open-contracting/standard/issues/1160#issuecomment-881950573 proposes a description of tender
that explicitly mentions that it can be used within two different types of processes (and gives value as an example, of sorts).
We somehow already do this by having a 'planning' tender.status
code with this definition:
A future contracting process is being considered. Early information about the process can be provided in the tender section. A process with this status might provide information on early engagement or consultation opportunities, during which the details of a subsequent tender can be shaped.
Maybe in the new definition we can refer to this code, and indicate that if the tender has that status, all its content refers to the planning process. I think that should apply for both, core fields but also for existing extensions to the tender block.
For context and reference, this came up during the support to Mexico City who will disclose now the enquires made during the planning/pre procurement process using the enquires extension.
We somehow already do this by having a 'planning' tender.status code with this definition:
https://github.com/open-contracting/standard/issues/1160#issuecomment-887489821 proposes to remove the code, arguing that it duplicates releaseTag
code 'planning'. Maybe let's discuss it there, if appropriate?
The description of tender
itself is already updated to cover both planning and contracting processes and the descriptions of most tender fields make sense in both contexts.
The exceptions are:
Field | Description | Changes | Notes |
---|---|---|---|
.datePublished |
The date on which the tender was published. | None | I think this field is applicable only to a contracting process, but I think that's clear enough from the current description. |
.documents |
Documents related to the tender stage (for example, notices, technical specifications, evaluation criteria, questions and clarifications). | None | I think this field is applicable only to a contracting process, but I think that's clear enough from the current description. |
.amendments |
Description | Don't restate field title and properties |
Thank you for the review. I'm happy to go ahead with the proposed change.
Follow-up to https://github.com/open-contracting/standard/issues/866#issuecomment-751683275