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

Clarify contracting process, record and ocid, define planning process (866) #1216

Conversation

JachymHercher
Copy link
Contributor

@JachymHercher JachymHercher commented Feb 14, 2021

closes #866 (except the two new tickets to be opened on the basis of the last paragraph of #866 (comment))

closes #1159

together with #1208, closes #903

@JachymHercher JachymHercher added Focus - Documentation Includes corrections, clarifications, new guidance, and UI/UX issues Schema: Fields Relating to adding or deprecating fields in the JSON Schema Semantics Relating to field and code descriptions labels Feb 14, 2021
@JachymHercher JachymHercher added this to the 1.2.0 milestone Feb 14, 2021
@JachymHercher JachymHercher linked an issue Feb 14, 2021 that may be closed by this pull request
2 tasks
…ition of release.

To be checked: I've used \\n\\n to create new paragraphs in the schema. I'm not sure that'll work and I'm not sure whether this should be preceded / followed by spaces (I follow by a space but do not preceed, but I'm afraid that will lead to indentation on the first row of the new paragraph.)
@jpmckinney
Copy link
Member

@JachymHercher Is this still draft?

Add "Contracting and planning processes" section to the Mapping the hard cases of the Guidance. Rename "unsuccessful procedures" and "pre-qualification". Minor updates in other parts of the documentation.

Also: change definition of contracting process from "aimed at concluding"to "aimed at implementing".
@JachymHercher JachymHercher marked this pull request as ready for review July 17, 2021 14:49
@jpmckinney
Copy link
Member

Hi @JachymHercher, this PR now conflicts quite severely with other changes you (and maybe others) made in other PRs. My suggestion would be to:

  1. Get a clean version of the 1.2-dev branch, e.g.

     git checkout 1.2-dev
     git pull --rebase
    
  2. Start a new branch

  3. Look at this PR's changes at https://github.com/open-contracting/standard/pull/1216/files and/or download the PR's changes from https://patch-diff.githubusercontent.com/raw/open-contracting/standard/pull/1216.patch

  4. Replicate the desired changes to the new branch. You can perhaps copy-paste the lines starting with + to the new branch, while paying attention to any changes others might have made to those lines.

Would that work? If not, we can perhaps resolve all the conflicts together on a call.

@jpmckinney jpmckinney removed the Focus - Documentation Includes corrections, clarifications, new guidance, and UI/UX issues label Jul 29, 2021
@yolile
Copy link
Member

yolile commented Jul 30, 2021

@yolile Since this is the most significant clarification/change in 1.2, please also review.

It looks good for me, but should we also update, after merging this, the unsuccessful tender example to have 1 ocid for the planning stage, then another one for the unsuccessful tender, and finally a third one for the successful tender? And, here, for the third ocid, are we going to have two entries in the related process array, one for the unsuccessful tender and another one for the planning stage?

And, should we also update all the other JSON/worked examples where the planning stage is used?

@jpmckinney
Copy link
Member

jpmckinney commented Jul 30, 2021

I'll restore the "Furthermore" construction, as mentioned in my recent comments in #866.

In terms of loose ends:

  • The challenges/hacks for representing multi-stage procedures in OCDS 1.x is a major issue, so it is important to direct people to an issue where they can contribute (and to demonstrate that we are aware of and working on the issue). I retained the box with the link to Handling multi-stage contracting processes #440 on contracting_planning_processes.md. I'll think about linking to it from identifiers.md (Clarify definition of contracting process #866 is more about our current hack for fixing 440, so I'd rather link to 440).
  • Whether to separate planning and contracting processes is one of many decisions that have to be made in OCDS 2.0. Clarify definition of contracting process #866 is not the best place for that discussion, because it is stuck with OCDS 1.1 concerns. It's fine to link to issues about OCDS 1.x in the OCDS 1.x documentation, but since OCDS 2.0 could (in theory) be an entirely different standard, it's less appropriate. We don't want to start conversations about OCDS 2.0 with the baggage/mindset of OCDS 1.x.

I think those are the only two loose ends; both appeared on both contracting_planning_processes.md and identifiers.md.

I have a longer comment about identifying planning processes in #866, but there is no action for now.

@jpmckinney
Copy link
Member

@yolile Since this is the most significant clarification/change in 1.2, please also review.

It looks good for me, but should we also update, after merging this, the unsuccessful tender example to have 1 ocid for the planning stage, then another one for the unsuccessful tender, and finally a third one for the successful tender? And, here, for the third ocid, are we going to have two entries in the related process array, one for the unsuccessful tender and another one for the planning stage?

And, should we also update all the other JSON/worked examples where the planning stage is used?

I think we should do all those things. Is it alright, in your opinion, to do those as a high-priority follow-up issue?

For updating the unsuccessful tender example, I think it's fine for the related processes to just be a chain, e.g. the final process only links to the previous attempt, which in turn only links to the planning process. That said, I don't think it's incorrect for the final process to also link to the planning process.

@yolile
Copy link
Member

yolile commented Jul 30, 2021

I think we should do all those things. Is it alright, in your opinion, to do those as a high-priority follow-up issue?

Not a high priority, just something we need to remember to do

@jpmckinney
Copy link
Member

jpmckinney commented Jul 30, 2021

Follow-up issue is #1362. The problematic commit in my review was 257a279

I have edited ocid. The original in this PR:

A globally unique identifier for this OCDS contracting process. Furthermore, this identifier can also refer to an OCDS planning process or a single stage of a multiple stage procedure.

Now:

A globally unique identifier for the contracting process that the release describes. Alternatively, this identifier can refer to a planning process or a single stage of a multiple stage procedure.

Since this is the release schema, this version more clearly communicates the relationship between a release and contracting process. I also use "Alternatively" instead of "Furthermore" to make clear that these are alternatives: i.e., that a contracting process and planning process are different types of things.

You can read my lengthy commit message for 4abc3af

release:
- Change the first sentence to what OCDS is used for (not releases specifically, defined later).
- Remove sentence about what concepts releases cover, as this is done by the rest of the schema.
- Move "many releases" sentence before "previous releases" sentence, for better flow.
- Small copy-edit.

ocid:
- Restore two-sentence construction, to distinguish primary and secondary use cases.
- Clarify that the secondary use cases are alternative, not additional, semantics.
- Clarify the relationship between the release and process.
- Use "internal identifier" consistently.
…pen Contracting ID"

- schema/identifiers: Use "release" not "OCDS release"
…the description of a record. Adapt title and description for ocid from release schema.
@jpmckinney
Copy link
Member

In the merge commit, I had changed the description of record. The original version in this PR was:

Information about a contracting process or a contracting planning process. Furthermore, a record may also inform about a single stage of a multi-stage procedure (e.g. a framework agreement with reopening of competition).

This unnecessarily replicates semantics that should be deferred to a release. It is now:

A record aggregates releases with the same open contracting process identifier (ocid).

@yolile
Copy link
Member

yolile commented Jul 30, 2021

I guess another follow-up is to address this comment: https://github.com/open-contracting/standard/pull/1335/files#r670825255 by updating the planning definition and fields.

@jpmckinney
Copy link
Member

I guess another follow-up is to address this comment: https://github.com/open-contracting/standard/pull/1335/files#r670825255 by updating the planning definition and fields.

Thankfully, that PR is still open :)

@jpmckinney jpmckinney merged commit 40f2d56 into 1.2-dev Jul 30, 2021
@jpmckinney jpmckinney deleted the 866-clarify-contracting-process-record-define-planning-process branch July 30, 2021 19:26
@jpmckinney
Copy link
Member

🚀 🚢 :shipit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Clarify definition of contracting process
3 participants