open-contracting / standard

Documentation of the Open Contracting Data Standard (OCDS)
http://standard.open-contracting.org/
Other
138 stars 46 forks source link

Bid evaluation publication #1546

Open yolile opened 2 years ago

yolile commented 2 years ago

Currently, with Bid statistics and details extension, the publisher can publish if a bid was accepted or disqualified (among other statuses). However, there is no way to disclose the information about each bid evaluation.

In Argentina, this information is available as structured data. It includes information about each item and tenderer bid evaluation, including the price evaluation, the technical evaluation, and the administrative evaluation (but only for the disqualified bids). All are disclosed as free text but in separate fields, as seen in example 1 and example 2.

For the qualified bids, they suggest an "order of preference" for each bid that should be followed when awarding the process.

Discussion

To disclose this information, we could add a "evaluation" object to the Bid object and model the evaluation here. Another option could be to put this as part of the requirementsResponse object from the requirements extension, and another option is to model this differently in a separate extension.

jpmckinney commented 1 year ago

Regarding the requirements extension, in the Core Criterion and Core Evidence Vocabulary (CCCEV) model on which it is based, a Requirement Response is how a bid responds to a requirement.

How a buyer (or bid evaluation committee) evaluates that response is semantically different.

That said, if we have publishers who use the requirements extension and who have detailed, requirement-specific evaluations, then we can integrate with that extension.

jpmckinney commented 1 month ago

On a Slack thread linking to this issue, I had written:

At a high level: In CRM-6763 (referenced in https://github.com/open-contracting/ocds-extensions/issues/155) I wrote:

There is the concept of a “bid” and the concept of a “bid assessment”, and mixing the two will lead to confusion and error

And, for context:

status fields tend to be at the boundary of many concepts, so it’s fine for the bid to have a status [despite including the results of bid assessments] – though there might have been a better modelling

I still think it makes sense to clearly separate the bid that the bidder submitted from its assessment by the buyer.

And later:

In general, we don’t know enough about the various ways in which evaluation is performed or published across governments.

The Slack thread had started drafting something like:

{
  "details": [
    {
      "id": "XYZ",
      "status": "valid",
      "tenderers": [
        {
          "id": "MEGA",
          "name": "Mega Consortium"
        }
      ]
    },
    {
      "id": "ABC",
      "status": "valid",
      "tenderers": [
        {
          "id": "BETA",
          "name": "Beta Consortium"
        }
      ]
    }
  ],
  "evaluation": {
    "ranking": [
      "XYZ",
      "ABC"
    ]
  }
}

The Bid object's rank field also mixes in concepts of assessment; we didn't have anywhere else to list bids in a rank order, so I suppose that's why we added it to bids for the eForms profile. rank was added for https://github.com/open-contracting/european-union-support/issues/125 (earlier: https://github.com/open-contracting/european-union-support/issues/80) in https://github.com/open-contracting-extensions/ocds_bid_extension/pull/49.

That pull request was already merged prior to the Slack thread (but I think it was forgotten).


An issue where bid assessment almost became relevant is https://github.com/open-contracting/european-union-support/issues/219#issuecomment-2261540278, but in the end it was about an award's final status details/rationale.


(I tried to find other past discussions of bid evaluations, and only found #36 (continued in #223), but they are not relevant.)