milestoneStatus: Add "delayed" code

[tdavis9]

The milestone codelist is closed so one cannot add more values. We would find useful a ‘delayed’ option. We’ve created an extension to cope with this, but again we would benefit from either an open codelist or a closed codelist with this option included, in which case we would not need this extension

https://github.com/devgateway/forms-makueni/tree/master/persistence-mongodb/src/main/resources/extensions/milestone_delayed_authorization

[jpmckinney]

Thanks, @tdavis9, we're happy to consider new codes for this codelist. Could you clarify the semantics?

• Does it mean "re-scheduled", i.e. the entity that set the milestone deliberately changed the due date, in which case the dueDate should have been updated to a date after today's date?
• Does it mean "late", i.e. the entity responsible for meeting the milestone hasn't yet met it, in which case today's date should be after the dueDate and the status should be any value except 'met'?

Presently, either of the above can be derived from the data without adding a new code. However, with respect to #914, if we want to make it simple to determine which milestones have been rescheduled without looking at the history of releases (we would need to evaluate the demand for this use case), we can add a new field to store the initial due date.

[tdavis9]

What we've encountered is when it means "late," while this can be determined by reviewing the dueDate. Per #914, having it explicitly listed would reduce need to calculate this to determine that the project is delayed.

[jpmckinney]

Thanks for the clarification. #914 is about eliminating interdependency between different fields in terms of semantics, i.e. the value of one field changes the meaning of another field. That isn't the case here.

In the case of a milestone that is past due, the only dependency is on the current time (which is not part of the OCDS data). In general, we avoid adding fields or codes whose value needs to be changed based only on time advancing, because that puts a high burden on publishers to make updates to their data even if nothing has changed within their data source (a burden that isn't likely to be met, leading to poor quality data). On the other hand, it is not too great a burden for users or tools to compare the dueDate to today's date for milestones whose status is not 'met'.

It's also important to clarify that the milestoneStatus codes describe the degree to which a milestone is met – not the distance from the dueDate. As such, a 'delayed' or 'late' or 'overdue' code wouldn't follow the semantic pattern of the existing codes. (Neither would an 'early' or 'advanced' or 'premature' code.)

[ColinMaudry]

I agree with your conclusion @jpmckinney: we try not to add fields for information that can be derived from the context and other fields. Not only is it redundant, but it can lead to inconsistencies (late milestones that are not flagged as such).

For those who are willing to properly update this field and want to ease the retrieval of this information, I think that implementing a boolean field via an extension (such as the one developed by @tdavis9) is the best approach.

Shall I close it?

[jpmckinney]

Yes, we can close this issue. If there is new interest, we can of course continue the discussion.