-
Notifications
You must be signed in to change notification settings - Fork 46
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
Clarify contracting process, record and ocid, define planning process (866) #1216
Conversation
…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.)
@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".
Hi @JachymHercher, this PR now conflicts quite severely with other changes you (and maybe others) made in other PRs. My suggestion would be to:
Would that work? If not, we can perhaps resolve all the conflicts together on a call. |
Signed-off-by: Yohanna Lisnichuk <[email protected]>
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'll restore the "Furthermore" construction, as mentioned in my recent comments in #866. In terms of loose ends:
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. |
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. |
Not a high priority, just something we need to remember to do |
Follow-up issue is #1362. The problematic commit in my review was 257a279 I have edited
Now:
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.
…d concepts, not OCDS concepts.
…pen Contracting ID" - schema/identifiers: Use "release" not "OCDS release"
…the description of a record. Adapt title and description for ocid from release schema.
In the merge commit, I had changed the description of record. The original version in this PR was:
This unnecessarily replicates semantics that should be deferred to a release. It is now:
|
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 :) |
🚀 🚢 |
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