`partyRole` codelist: clarify description of interestedParty

[JachymHercher]

Spin-off from #1513 (comment).

'enquirer' in partyRole is defined as

An organization that has made an enquiry during the enquiry phase of a contracting process.

There are several grey areas:

1. Organizations also ask questions at other stages and currently we don't have any codes for that:

   • planning ("could you clarify vague paragraph XYZ in the PIN", "are you aware of solution X that would solve your need but might end up not being applicable in your future contracting process because of thing ABC that you mention in your planning process" or perhaps even "do you have any news on when the contracting process will be launched")
   • award ("when will you publish the evaluation results")
   • contract ("is the contract published anywhere?")

   The two obvious solutions would be to Broaden the scope of 'enquirer' by removing "the enquiry phase" or adding codes for questions asked in other phases. (I note that "the enquiry phase" is not something I would a priori know, or know where it starts).

2. 'interestedParty' is defined as

   "An organization that has expressed an interest in the contracting process: for example, by purchasing tender documents or submitting clarification questions."

   where the second condition overlaps with 'enquirer', so it might be better to reduce the scope of 'interestedParty' to avoid the overlap (i.e. remove "or submitting clarificiation questions" from 'enquirer'.). (However, this is isn't a backward compatible change...)

3. There is no code for organizations that submit replies (or ask questions?) when doing a market consultation doing a planning phase (market consultations might sometimes be a bit of a dialogu, so this might overlap a bit). We could have a new code for that.

I would have a tendency to enlarge the scope of 'enquirer', remove the overlap with 'interestedParty', and add a code for 'marketConsultationRespondent' or something like that and do the rest only if user demand requires it. (One question could be whether people want to be distinguishing tenderers that did and didn't ask a question, but if went down that route, then we should just remove 'enquirer', because it would be subsumed already under 'interestedParty'...)

[jpmckinney]

The role was added during the resolution of #259.

Besides the enquiry-related fields hasEnquiry and enquiryPeriod in OCDS, there is also an extension that adds tender/enquiries which has an author field (an organization reference). In OCDS, there is a role code that corresponds to each organization reference.

The 'enquirer' code would have been expected to be added by the extension, rather than OCDS 1.1. That said, for #1157, we decided to add codes added by extensions to the standard repository, to reduce complexity. So, the 'enquirer' role would have been merged into OCDS 1.2 as part of #1157.

So, in brief, 'enquirer' is specifically for the organizations that submit enquiries during contracting processes, during the enquiry period, which typically ends sometime before the submission deadline and starts at the same time as the notice publication (Period objects do not require a startDate, FWIW).

We have no field similar to tender/enquiries for planning processes (including market consultations), and we don't need a role code until we have such a field. For questions at the award and contract stages, I don't see any reason (or demand) to publish such data.

---

'interestedParty' was added in #725 to close #557. It is designed as a sort-of catch-all, and so I have no issue with the overlap.

[JachymHercher]

1. Hmmmm, ok.

2. My first thought was, that overlaps are bad on principle. For example, if there is an equirer in the process, then the publisher should publish both 'interestedParty' and 'enquirer', which sounds like a hassle. However, looking at https://standard.open-contracting.org/latest/en/schema/conformance_and_extensions/#publication-conformance (1), do I understand it correctly that a publisher can choose to use 'enquirer' but not 'interestedParty' (or vice versa) and then he can publish just one and not the other?

   That's good news from a simplicity point of view, I guess, but bad news from the point of view of e.g. trying to analyze the data to learn about enquirers, because for each buyer they can be encoded differently?

3. What about 3, a field for the prior market consultation participants? Shall we add it or wait for actual user demand?

[jpmckinney]

1. To clarify further, the example questions you shared are unlikely to be published as answers to questions as part of contracting disclosures – they are more likely to use existing fields (tender/datePublished, tender/awardPeriod, contracts/documents). (For planning questions, see 3). The more likely questions at award stage are along the lines of challenges, and at contract stage along the lines of contract monitoring. These are expected to be modelled differently than the simple Q&A model. (See 3 for why we are not designing that model now.)

2. Publishers can and should use as many roles as are correct. If a user wants to analyze enquirers, they simply query for the 'enquirer' role. The 'interestedParty' role is not a sufficient filter for this analysis. If you read #557, you'll see that 'interestedParty' was intentionally designed to capture many ways of expressing interest, e.g. signing up for notifications about the process, submitting questions, downloading procurement documents, etc. This serves the use case of analyzing who is "interested" in a contracting process (whether it's potential financers of PPPs, NGOs, suppliers, etc.), without having half a dozen roles for every way of expressing interest (which we doubt publishers can or would implement).

   For this issue, we can perhaps clarify the code description to capture its broad semantics with more examples.

3. We are not aware of any publisher using OCDS for market consultations. As such, we have no information from real-world implementations. We typically wait for at least two publishers to have data to publish. That way, when we model a concept, we know that it will work for at least two publishers. For now, we postpone this.

[duncandewhurst]

I've updated the issue title to reflect the proposal in the previous comment:

For this issue, we can perhaps clarify the [interestedParty] code description to capture its broad semantics with more examples.