Avoid "tender" outside references to the field, tag or "tender stage"

[jpmckinney]

A tender in most places means the offer from the supplier – not the opportunity from the buyer.

Depending on the context, it can be replaced with:

• contracting process (like in tenderStatus, awardStatus contractStatus: update codes #1509 in tenderStatus.csv – see Update all status codelists #1160 for next steps)
• procurement opportunity (in many examples), or simply opportunity (in the schema)
• bid ("limited tenders")
• changing it to an allowed noun phrase:
  • tender notice (documentType code)
  • tender release (releaseTag code)
  • tender section (field)
  • tender stage (concept)
• omitting it entirely (it sometimes adds nothing to the sentence)

The paragraphs for Tender in reference.md should also be updated (e.g. announcement -> opportunity).

In most cases, then language contributed by Jáchym in earlier Semantics issues should be reused or adapted.

We don't currently use these other synonyms, and shouldn't use them, for consistency:

• solicitation

The style guide can be updated once we enumerate the preferences.

Regex:

(?<![{`'-])(?<!:expand: )(?<! tag, )(?<! parties, )(?<! compiledRelease, )(?<!:jsonpointer: /releases/0/)\btender(?! notice| release| section| stage|er|Amendment|Cancellation|Update|Currency|Value|\.\S|["_])

File pattern:

-*.po,-examples/*,-changelog.md

[odscjen]

I'm making a start on this issue, putting everything into a google sheet to start, with a sheet for the schema and a sheet for the docs.

@jpmckinney can you confirm a couple of examples before I really get going to ensure I'm interpreting the guidance above correctly?

tender/identifiers

An identifier for this tender. This may be the same as the ocid, or may be an internal identifier for this tender. Although an integer is allowed, it is recommended to use a string.

Becomes -> "An identifier for the opportunity. This may be the same as the ocid, or may be an internal identifier for the opportunity. Although an integer is allowed, it is recommended to use a string."

Document/datePublished

The date on which the document was first published. This is particularly important for legally important documents such as notices of a tender.

Becomes -> "The date on which the document was first published. This is particularly important for legally important documents such as notices of a contracting (or planning) process."

And in the docs
Release structure > Release reference > Award

The award section is used to announce any awards issued for this tender.

Becomes -> "The award section is used to announce any awards issued for the contracting process."

[jpmckinney]

This is particularly important for legally important documents such as notices of a tender.

I think we can omit this sentence. The schema in general doesn't explain why each field is important. But, "tender notices" (my 4th bullet) would be an appropriate substitution if we had kept it.

Others are correct.

[odscjen]

I've gone through all the docs and the schema as they currently stand, my suggestions for word replacements are in the google sheet linked to in my previous comment. @jpmckinney whenever you've the time if you could please review this and a PR can be created after that.

[odscjen]

The spreadsheet has been re-checked to take into account changes to 1.2-dev that have been applied since February. @jpmckinney would it make sense for @duncandewhurst to take the first pass of reviewing the suggestions, noting where your input may be required?

[jpmckinney]

I think it'll be better for me to merge the big open PRs like #1680, then check that diff, and continue from there.