-
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
Milestones #373
Comments
Currently milestones only appear in the tender and implementation sections of the schema. The worked example given by Tim includes a milestones field in the award section and based on the inclusion of planning in the milestoneType codelist we should also add a milestones field to the planning section of the schema. This would be useful for the PPP case where there are various approvals which may take place during the planning phase which could be represented be milestones. |
Draft schema update staged as extension here |
I've updated the draft extension, forked into OCDS repository here. This draft:
Comments welcome. |
Suggested update to definition of milestone type definitions (for requirements of the PPP project)
|
My comment from the 1.1 peer review:
|
This issue is under consideration for the 1.1 milestone.
This builds on prior discussions in #227
The issue
The milestones block in OCDS was developed to provide a flexible space to capture date and process-related information that is not otherwise standardised.
However, to date it has not been widely used, and it is not currently possible to distinguish between the different kinds of milestones that may exist during a procurement process.
For example, is a milestone a delivery requirement of providers? Or a description of key deadlines during an engagement process during planning.
The proposal
We will introduce a milestone type field to:
The proposed codelist for this is:
We will update the milestoneStatus code list to include an extra entry for scheduled milestones, and will add definitions, giving a codelist of:
We will add a
milestone.dateMet
field so that the data a milestone was met on can be explicitly declared.In issue #355 we are also proposing deprecating milestone documents from core. This would be re-introduced in an extension, but to simplify the standard, we would not ask for documents attached to individual milestones.
Questions
dateMet
does not follow our usual pattern of using 'Date' as the suffix rather than prefix. However, it feels more natural thanmetDate
. Views on terminology here are welcome.(dateModified is an existing exception to the pattern, as we follow common terminology in use in other standards for this).
Should we also consider adding a
code
field to milestones that would allow explicit cross-referencing between milestones in tender, award and contract - and that would allow cross-referencing to codelists of more detailed milestones for particular countries?(For example, there could be a code for the 'bid opening date' so that all EU contracts can clearly indicate this).
Should we consider adding a
report
field for free-text information reporting on the milestones progress?Worked example
In the example below, a publisher is providing anticipated dates of the committee meeting in the tender block, along with details of when they took place. In the award they are specifying agreed delivery deadlines and reporting deadlines.
Additional implications
To the best of our knowledge, few procurement systems have very detailed structured information on them on milestones, particularly delivery and reporting milestones. As a result, inclusion of delivery and reporting milestone blocks in the standard for tender and award is driven by user needs, more than existing data supply.
This means we that inclusion of this updated milestone block in the standard constitutes encouragement for improvements in the collection and management of this kind of information.
We should develop some interface guidance on:
(a) Collecting milestone information;
(b) Displaying milestone information;
To ensure that publishers and users have a clear understanding of the capababilities, and the limitations, of the milestone block.
Engagement
Please indicate support or opposition for this proposal using the +1 / -1 buttons or a comment. If opposing the proposal, please give clear justifications, and where possible, make an alternative proposals.
The text was updated successfully, but these errors were encountered: