Add metadata checkbox for noting if agreement has been amended

[SamCCSI]

Many original contracts are subsequently amended or terminated. If we have this information it is crucial that this is noted on the site, as otherwise users could rely on the version of the contract we have, even if it is outdated.

This will be especially important for the country sites. On a country site, if they have two versions of a contract, it will be especially important to be able to note which contract has been terminated or amended.

Please add metadata checkboxes:

Backend: "Agreement terminated [ ]"
Frontend (if box checked): "This agreement may have been terminated."
Frontend (if box not checked): This category should not appear.

Backend: "Agreement amended [ ]"
Frontend (if box checked): "This agreement was amended in a separate document."
Frontend (if box not checked): This category should not appear.

The information should appear on the metadata column of the contract view page under the Note section, or in place of the note section when there is no note to display.

[anderspeders]

The Open Contracting Data Standard has done some work on changes of contracts, which should be considered here.

For example:
Is there a new amended contracts that we can link to?
What date was the amendment/change conducted?

cc @jpmckinney

[SamCCSI]

Agree that ideally we would have the updated contract on the site as well, which can be linked to the original contract.

Even if we do have the updated contract, I think there is value in explicitly notifying the user that the contract they are viewing has been amended (and hence may be out of date). This tells the user more than simply listing other associated documents.

[jpmckinney]

OCDS is much more metadata-based and less document-based than RC. Its contracts.amendment field answers the question "which metadata fields were amended?" not "what documents amend the original contract?". For the latter use case, it has a contracts.documents field which can link to documents that can have classifications like contract, contractUpdate or contractAmendment.

[jpmckinney]

Splitting issue into two since termination and amendment are pretty different use cases. See #726 for termination.

[jpmckinney]

For RC, do we anticipate cases where we know an amendment exists, but we don't have a copy of that document? If so, then a checkbox would be needed to encode that knowledge.

In my experience, an amendment is a brief document describing insertions/deletions made to the original contract, and is not a complete restatement of the contract. So, it makes more sense to embed information about the amendment into the contract, than to have an amendment exist as its own independent document. An amendment may cause some of the metadata values of the contract to change. So, do we want to keep a history of those metadata values or should the old values just be overwritten once an editor incorporates the amendment? Also, how do users currently view related documents: are they presented in the same sort of PDF viewer as for the main contract?

Another way in which a contract can be "amended" is for there to be a complete update/restatement of the contract. Since it's still the same contract (its identity is the same, ontologically), this update should not be its own independent document either, but should be integral with the original contract. The same questions arise here, but there's the additional issue that the frontend should display this updated contract and not the original contract in the PDF viewer. This also raises issues of what to do with all the annotations on the previous version of the contract, ...

[jpmckinney]

Notes from call with @anderspeders :

• If there's a restatement, then parent_document is used to flag a contract as having been superseded.
• There being a more granular amendment (i.e. a document describing insertions/deletions) is a rare case, so we may not need to handle it at the moment.

[KaitlinCCSI]

To answer your first question: yes, I think there will be cases where we know an amendment exists, but we don't have a copy of that document. For example, the Mittal K from Liberia on RC is the 2005 version; while we know it was renegotiated in 2006 (ratified in 07), we currently don't have that contract.

I don't know if the second bullet point is true -- don't think we have scoped this. For RC, if we take Guinea Ks as an example, there are multiple "avenants" that would probably fit your definition of a granular amendment. See here: http://www.contratsminiersguinee.org/about/projets.html For OLC, we have a lot of granular amendments related to DRC forestry contracts (and we annotate them).

[jedm]

Hi, @jpmckinney - really great to see you here!

I defer to @anderspeders and @KaitlinCCSI on how to make this call but it is worth noting again, as you have already, that to date RC operates with individual documents as single nodes and to date hasn't had any protocol or heuristics for altering documents. As Kaitlin's comment indicates, the Guinea site posts subsequent documents, even if they are amendments or riders (and uses filename/title standards to try to indicate, which is certainly a blunt instrument by OCDS standards).

If RC/OLC's use of OCDS metadata is robust enough to incorporate these relationships in the data layer, we obviously should. And if there is a usable way to surface those relationships in UI, then we should do that too.

It'll be very helpful to see an example of how the parent/"Main" : child/"Associated" relationship already built into RC/OLC can be used on the front end to illustrate the relationships. Will add a huge amount if it can be done intuitively.

parent_document is used to flag a contract as having been superseded.

[SamCCSI]

Have updated the first entry on this ticket as follows
Backend: "Agreement terminated [ ]"
Frontend (if box checked): "This agreement may have been terminated."

@anderspeders any updates on the progress of this item?

cc @KaitlinCCSI @JesseCCSI

[anjesh]

@anderspeders Please confirm if we are to start implementing this.

[SamCCSI]

@anderspeders any updates on whether this is included?

[charlesyoung]

@SamCCSI is this still required?

[SamCCSI]

@charlesyoung yes please.

[KaitlinCCSI]

Also, we should add a metadata check box option for Cancellation (as noted in #190 (comment), that's the other major status). This will just give us flexibility as needed in future. So this will be a THIRD check box that acts as follows:

Backend: "Agreement cancelled [ ]"
Frontend (if box checked): "This agreement may have been cancelled."
Frontend (if box not checked): This category should not appear.

[charlesyoung]

Thanks @KaitlinCCSI, sounds good.

[KaitlinCCSI]

@charlesyoung @anjesh - One more possible nuance - we've noted that "terminated" does not distinguish for why contract ended - if it was actively terminated before it was meant to end, or if it simply just ran the contemplated course and finished. I checked in with OCDS Helpdesk and they have apparently flagged this as something to modify at some point. Copying full response below (including link to GH issue where it's been discussed), and wondering if for now we can do as they suggest (having 2 types of terminated in our backend, which for now will map to same "terminated" on frontend)?

**There is a discussion related to this issue at open-contracting/standard#395

I will look at updating that ticket with a proposal for modifications to the OCDS codelist, although this might not make it into the next version due to the standard's governance process (current window for updates is closed).

Given that the categories you are proposing could fit hierarchically under 'terminated', to be OCDS compatible for the time being, you could store the more detailed classification of status, and then just map to the smaller OCDS codelist for output as OCDS. For example, storing:

Terminated > Project ended prior to completion
Terminated > Project complete
but mapping both to 'Terminated' in OCDS output.

If we get an extended codelist into OCDS 1.1 then you would be able to just update this mapping.

Please do share any further thoughts, and feedback either here, or on the GitHub issue,**

[charlesyoung]

Should we resurrect discussion on this ticket?

Comments from Perrine; This is something important that will always be known in the context of countries whereas its more difficult to know at the global level. At the country site level this is fundamental to know.

cc @SamCCSI @KaitlinCCSI

[KaitlinCCSI]

Sure. I do see an extremely strong rationale for this feature. We discussed in last call, however, when it was agreed to wait to see what OCDS would do? But I am more than happy to consider implementing now -- at least on the backend, per OCDS helpdesk suggestion above, and think we could also consider doing so on the frontend, though would want to discuss again with OCDS helpdesk to figure out how to do so in a way that minimizes potential problems/incompatibility down the road.

[SamCCSI]

OCDS have now provided some guidance on this issue, though it remains not entirely resolved.

The solution we would like YI to implement is:

• for early termination of a contract: backend metadata field: contract.statusDetails | entry for that field: earlyTermination | front-end text: "This agreement may have been terminated."
• for expiration of contract at end of term: metadata field: contract.statusDetails | entry for that field: expiredAtEndOfTerm | front-end text: "This agreement concluded at the end of the contract term"
• for contracts subsequently amended: metadata field: contract.ammendments.description | entry for that field: something like 'Contract Amended' | front-end text: "This agreement was amended in a separate document."

More details on these from OCDS here: open-contracting/standard#395

[charlesyoung]

Many thanks @SamCCSI

We can look at the details once we have a better understanding of the development budget for 2017.