Ensure tender field descriptions make sense for planning and contracting processes

[jpmckinney]

Follow-up to #866 (comment)

@jpmckinney: Publishers can create OCDS releases/records for planning processes, even though these are not the same as contracting processes. The contracting process(es) that result from the planning process should refer to it using relatedProcesses and use different OCID(s). Those contracting processes should omit the planning section. As for the planning processes, they should omit the awards and contracts section. Right now, in OCDS, the tender section covers fields relevant to describing the procedure (not just the solicitation), so planning processes might include some tender fields.

@JachymHercher: I'm wondering what implications this ambiguity (Tender block being used both during the "planning stage" and "tender stage") has for definitions of Tender, Planning and potentially also others blocks. Perhaps their definitions should not refer to "stages" at all, but simply talk about the data that they contain.

[duncandewhurst]

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.

[JachymHercher]

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.

#1160 (comment) 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).

[yolile]

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.

[JachymHercher]

We somehow already do this by having a 'planning' tender.status code with this definition:

#1160 (comment) proposes to remove the code, arguing that it duplicates releaseTag code 'planning'. Maybe let's discuss it there, if appropriate?

[duncandewhurst]

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	A tender amendment is a formal change to the tender, and generally involves the publication of a new tender notice/release. The rationale and a description of the changes made can be provided here. Formal changes to the tender, which generally involve the publication of a new notice/release.	Description	Don't restate field title and properties

[jpmckinney]

Thank you for the review. I'm happy to go ahead with the proposed change.