Review usage of "contracting process" to account for planning process

[jpmckinney]

@JachymHercher in #866:

From #866 (comment):

3. I have replaced "contracting process" with "contracting and/or planning process" only in a few prominent places where I thought it would be useful. The rest I propose doing once the "Getting Started" section is reviewed.

The getting section is reviewed, so we can do this now. However, on second thought, we should probably also wait for a moment when there are no - or very few - unmerged PRs, because since this change will go through all parts of the standard, it would otherwise cause plenty of conflicts?

Since there are almost 600 results for "contracting process", before going through them, two questions:
     a) are we sure we want to replace them? I would, as just defining somewhere that "a contracting process can be a contracting or planning process" would be cyclical and ignored anyway.
     b) what should we replace them with? I'd go for "contracting (or planning) process", "contracting or planning process" or "contracting/planning process"; in this order of preference (I think the parentheses nicely hide the less important process and make the text more easily readable, because one doesn't get sidetracked by the "or"; backslashes are a bit hard to read). Just calling it "process" doesn't seem clear enough.

Detail: there is a repeating formulation "within the scope of the contracting process". I would leave out "the scope of", it seems unnecessary.

[jpmckinney]

If I omit translations, the dereferenced schema, and the changelog, there are about 330 results, which is still a lot.

That said, there are not too many open PRs that will conflict, so we don't need to wait. #1303 is already heaving conflicted, but the solution there, I think, is to move the work to a document or spreadsheet, and then only make the PR once the new definitions are agreed. The only way we'll resolve the conflicts is to overwrite the main branch's version, anyway.

I agree that it is better to replace "contracting process" where appropriate, rather than to be ambiguous as to whether we might also mean "planning process".

I prefer "contracting (or planning) process" as well. That said, I think "process" is fine once we've already used "contracting (or planning) process" in the same (or nearby) paragraphs; this is already done in some places. It's similar to using a pronoun.

I think I only see "within the scope of" when discussing uniqueness, and "scope" is a common concept for uniqueness. Some identifiers are synthetic, so they are not properly "within" the real-world contracting process itself.

[JachymHercher]

Here is a draft PR. Before marking the PR ready for review, I'd like to get feedback on the highlights below.

There are quite a few changes, so reviewing will likely be a mouthful, sorry for that. (If I had commits per issues below, the review would have been easier, but regrettably the issue classification emerged from doing the changes, not the other way around. There are separate commits only for points 7 and 8. Points 9 and 10 are not reflected in the PR yet.)

1. We should try to consistently use "contracting process" (and "planning process") only in the OCDS sense, as defined in the schema's description. Real-world "things" which we now sometimes call "contracting processes" should instead be called, for example, "contracting activities" or "procedures", as we already do in https://standard.open-contracting.org/staging/1.2-dev/en/guidance/map/contracting_planning_processes/#contracting-processes-and-planning-processes.

   Accordingly, I have, for example, proposed the following change in https://standard.open-contracting.org/staging/1.2-dev/en/guidance/map/framework_agreements/#modelling-framework-agreements-in-ocds

   In some cases, complex contracting processes activities cannot be represented under as a single identifier contracting processes, because there are multiple stages. For example, this is the case when a framework is set up, and then mini-competitions are used for purchases from the framework.

   ("Contracting activities" should be used only when we cannot use "contracting (or planning) process", so that we stick as much as possible to terms that we have ourselves defined.)

2. I think we've agreed previously (but can't find where) that we want to avoid the expression "Open Contracting Process", with the exception of ocid having the title "open contracting process identifier". I have replaced it with "contracting (or planning) process" in https://standard.open-contracting.org/staging/1.2-dev/en/schema/reference/#relatedprocess and with "contracting process" in Award.id and Contract.id.

3. I did not change anything in the primer, because the distinction between contracting and planning process seems too technical for the super-general intro.

4. The standard phrase "contracting (or planning) process" is ambiguous (I think) in sentences that deal with uniqueness, e.g. the release schema's id's "The release ID must be unique within the scope of the contracting (or planning) process." The ambiguity lies in whether the uniqueness concerns only a given process or both a planning and a linked contracting process. I think the ambiguity is resolved by saying "(contracting or planning) process", so I have replaced it as such in several places (e.g. id, date, https://standard.open-contracting.org/staging/1.2-dev/en/schema/records_reference/#linked-releases, https://standard.open-contracting.org/staging/1.2-dev/en/schema/identifiers/).

5. Fields in budgets and Budget use formulations such as "budget [....] which provides funds for this contracting process". Since the budget is published in a planning process, "this contracting process" rather needs to be "a future contracting process". Changed everywhere to a phrasing along the lines of "will be used in a future contracting process" (and spin off issues in Replace "contracting process" with "contract" in fields linked to budget and value #1516 and Align wording of budget.project and budget.projectID  #1517).

6. Similar to the above, many documents in documentType that are published in the planning stage speak about "this contracting process" (e.g. "planning,procurementPlan,Procurement plan,Documentation that sets out the basis for the contracting process"). I have replaced it with "the future contracting process".

7. In various places linked to tag, we explain that tags "indicate the specific stage of a contracting (or planning) process they represent". However, with the introduction of the separate planning proces, tags now also distinguish the different types of processes. I've changed this with a new phrasing along the lines of "[releases] must be tagged to distinguish planning and contracting processes and to indicate the stage of the contracting process they relate to".

8. I've noticed we use "Tender proceses". I've changed one where I think the intended meaning was "contracting process" and opened a new issue for the rest in Change "tender process" to "tender stage" #1514.

9. EDIT: moved to Clarify reference on identifiers and registered prefixes #1524

10. Since we have split planning processes from contracting processes, I guess we should go through all worked examples and make sure they don't contain planning (and instead perhaps link to to a relatedProcess )

[jpmckinney]

1. Agreed. I would use the singular in your example, to make the wording easier

   In some cases, a complex contracting activity cannot be represented as a single contracting process, because there are multiple stages. For example, this is the case when a framework is set up, and then mini-competitions are used for purchases from the framework.

2. We might have never explicitly agreed to it, but it's not a meaningful term, so I agree with the changes. Clarify contracting process, record and ocid, define planning process (866) #1216 changed "open contracting ID" to "open contracting process identifier".

3. Yes, agreed to keep things simpler in the primer, where there is already an expectation that specific scenarios require further reading.

4. Yes, that seems like a reasonable and concise resolution to the ambiguity.

5. Sounds good - let's create the PRs for those new issues once this one is merged, to avoid conflicts.

6. 👍

7. 👍

8. 👍 As with (5) we can create the PRs after this one.

9. EDIT: moved to Clarify reference on identifiers and registered prefixes #1524

10. I think @yolile did this when we originally split out planning processes? @yolile, can you confirm?

[JachymHercher]

Cool. I've implemented your comment 1) in f19a741 (together with adding the word "tender" in "In some cases, a complex contracting activity cannot be represented as a single contracting process, because there are multiple tender stages.") and marked the PR as ready for review.

Do we want to deal with 9) within the same PR or do a broader rewrite somewhere else?

[jpmckinney]

Thanks! Let's do 9 in another PR since we already have a PR ready for review.