Skip to content
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

Two-stage processes: Review tenderPeriod and add a field for bid submission deadline #1649

Closed
duncandewhurst opened this issue Oct 13, 2023 · 9 comments · Fixed by #1669
Closed
Assignees
Labels
Semantics Relating to field and code descriptions
Projects
Milestone

Comments

@duncandewhurst
Copy link
Contributor

duncandewhurst commented Oct 13, 2023

From: #1160 (comment):

We might need to review the definition of tender/tenderPeriod. In a two-stage process, I think this is usually the deadline for requests to participate (first stage). However, in terms of 'active', I think the relevant deadline is the one for bids (second stage). This second deadline is not actually published in any field, so maybe it's not possible to determine the tender status without a status code.

The description of tender.tenderPeriod on 1.2-dev is clear that the end date is the bid deadline:

The period when the tender is open for submissions. The end date is the closing date for bid submissions.

Prior to #1353, the semantics were ambiguous ("tender submission" could be interpreted as "bid submissions" or as submissions for the tender object, which typically represents the first stage of a multi-stage procedure):

The period when the tender is open for submissions. The end date is the closing date for tender submissions.

I think that there are two options:

  1. Update the description of tenderPeriod to reflect how the field is used in practice, i.e. bid deadline for single-stage processes and first-stage deadline for multi-stage processes, and add a new field for the bid submission deadline. This option is backward compatible but it introduces conditional semantics and requires users to look in two different places for the bid deadline, depending on the type of process.
  2. Keep the description of tenderPeriod as-is and add a new field for the first-stage submission deadline. I prefer this option, however, I'm not sure if the change already made from "tender submissions" to "bid submissions" was actually backward compatible given how the field is being used in multi-stage procedures.

@jpmckinney what do you think?

@duncandewhurst duncandewhurst added the Semantics Relating to field and code descriptions label Oct 13, 2023
@jpmckinney
Copy link
Member

jpmckinney commented Oct 13, 2023

In brief, let's go with option 2 (a simple date field for the requests deadline).

History

Comment originally written May 2022 #1160 (comment) when describing the timeline of a contracting process, as a bullet under:

The contracting documents are made available, and the submission deadline has not yet passed: tender.status = 'active'. This can also be determined by comparing tender/datePublished (new in 1.2) and tender/tenderPeriod/endDate to date.

To which Jáchym responded:

eForms has separate fields for each: (BT-131 and BT-1311).

For context:

  • BT-131 Deadline Receipt Tenders: The time limit for receipt of tenders. (tenders = bids)
  • BT-1311 Deadline Receipt Requests: The time limit for receipt of requests to participate.
  • eForms has only end dates, not start dates, for these.

To which I wrote:

Create an issue about tender/tenderPeriod (and the need for a second field for submission for bids vs. requests to participate)

Contracting process timeline

Although we're deprecating tender status = 'active', I think it's correct for the "active" period to continue until the bid submission deadline.

Backwards compatibility

Re: "tender submission", #1353 (which closed #1230) made many changes from "tender" to "bid", and in all cases I think it was fairly clear that "tender" meant "bid". (Same for changes to extensions, which appear as links in #1230.)

As such, I consider the changes in #1353 to be backwards compatible.

That said, it might very well be the case that some publishers used tenderPeriod for requests and not bids – either because it is the only date they tracked, or because we didn't offer a field for the other date.

However, I don't think that incorrect usage (no matter how common) due to a deficiency in the standard implies that the incorrect usage needs to be preserved or protected.

In terms of how the field is used, there are a few indicators that use tenderPeriod/startDate, though I think they would all prefer tender/datePublished if provided. Almost all use tenderPeriod/endDate to mean the deadline for bids.

  • Comparisons to deadline
    • Average duration of tendering period days
    • Short or inadequate notice to bidders to submit expressions of interest or bids
      • This is the only indicator in OCP's library that uses tenderPeriod/endDate to mean the deadline for requests.
  • Comparisons to other dates
    • Failure to adequately advertise the request for bids or proposals (documents/datePublished)
    • Key tender information and documents are not available (documents/datePublished)
    • Failure to make bidding documents available to all bidders (documents/datePublished)
    • Short time between tender advertising and bid opening (bidOpening/date)
    • Days between award date and tender start date (awards/date)
  • Used to determine the time of the tender notice:
    • Splitting purchases to avoid procurement thresholds
    • Number of new bidders in a system
    • Percent of new bidders to all bidders

In terms of usage, it seems like the semantics of bid deadline is preferred.

As for, "In a two-stage process, I think this is usually the deadline for requests to participate (first stage)." – I don't remember why I thought that (I might have been thinking of options related to #440 that we didn't opt for).

Options

Another option to sidestep the issue is to deprecate tenderPeriod and add two date fields for bid deadline and requests deadline (as I'm not sure the start date is relevant now that we have datePublished). However, tenderPeriod is one of the most used fields, and it's mostly used with the intended semantics, so I think this would be overkill.

So, best to go with option 2.

@duncandewhurst
Copy link
Contributor Author

All sounds good to me!

@duncandewhurst duncandewhurst added this to To do in OCDS 1.2 via automation Oct 16, 2023
@duncandewhurst duncandewhurst added this to the 1.2.0 milestone Oct 16, 2023
@jpmckinney
Copy link
Member

jpmckinney commented Oct 16, 2023

We’ll want to review the first stage mapping in the framework agreements example. I’m not sure if we want to keep it as is, as the setup has only one type of submission, but also has awards. If so, we might need the tender period definition to have a caveat for multistage procedures (like in the release definition).

I can’t remember if we have other examples with requests to participate.

@duncandewhurst
Copy link
Contributor Author

Good spot. I will check for any other occurrences of "request to participate" or "first stage" etc. in the documentation.

@duncandewhurst
Copy link
Contributor Author

@jpmckinney let me know what you think of the following

Schema changes

Path Title Description Type (format) Change
Tender.participationRequestDeadline Participation request deadline The deadline for submission of requests to participate. string (date-time) New field
Tender.tenderPeriod Tender period The period when the tender is open for submissions. The end date is the closing date for bid submissions. In multi-stage procedures (e.g. framework agreements with reopening of competition), each round of competition is treated as a separate contracting process. Period object Description

Would it be helpful to add further clarification to the description of tenderPeriod? e.g.

The first-stage deadline for requests to participate is expressed in tender.participationRequestDeadline.

Documentation changes

  • If the framework agreement is closed, set tender.tenderPeriod.endDate tender.participationRequestDeadline to the deadline for responses to the invitation.
  • If the framework agreement is open, set tender.tenderPeriod.endDate tender.participationRequestDeadline to the last date that new suppliers can be added.

@jpmckinney
Copy link
Member

jpmckinney commented Dec 5, 2023

I think request to participate might be a more EU-specific term based on some quick research, so maybe

Field name Title Description
expressionOfInterestDeadline Expression of interest deadline The submission deadline for expressions of interest. This submission is also called a request to participate.

Other than the change from "tender" to "bid", tenderPeriod's description hasn't changed since 87965a3. I think it can be:

The submission period for bids. Depending on the procedure, a bid can be an estimate, offer, proposal, quote or quotation, but not an expression of interest or request to participate.

I omitted "tender" as a synonym to avoid introducing confusion.

I'm not sure what more we can add to its description that is directly relevant to the field itself. We explain framework agreements elsewhere, and we generally avoid pointing out other fields unless essential.

@jpmckinney
Copy link
Member

Agreed on documentation changes. I haven't done a review of my own to find any other cases.

@odscjen odscjen self-assigned this Jan 11, 2024
@odscjen
Copy link
Contributor

odscjen commented Jan 11, 2024

@jpmckinney are you happy for me to make a start on a PR for this? I can double check for any other documentation changes that might be needed while working on it.

@jpmckinney
Copy link
Member

jpmckinney commented Jan 12, 2024

Yes! In other words, the documentation changes from Duncan's #1649 (comment) (and any others you find) and the schema change from my #1649 (comment).

There are two cases where we use "request/requests to participate". We can change this to expressions/expression of interest.

Edit: These extensions also use "requests to participate" in the schema or codelists

  • awardCriteria
  • bid
  • eu (can be left as-is, as it's EU-specific)
  • procedure
  • submissionTerms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Semantics Relating to field and code descriptions
Projects
OCDS 1.2
  
Done
Development

Successfully merging a pull request may close this issue.

3 participants