Home

This is the wiki for the EJPRD resource metadata model.

Change request process

Our recommendation is that for every change to the resource metadata model, even for very small changes, one or more Github issues need to be opened. This ensures full transparency of the requirements for all stakeholders.

Once a ticket is opened, an awaiting decision status should be assigned. This means that the issue needs to be discussed by the EJPRD technical committee to decide on whether this request should be implemented or not. If this is to be implemented, additional information can be added to the issue as to how this request should or could be implemented. Getting a request ratified is an essential step because changes to the resource metadata model has consequences for how resources can be onboarded, resources that are already onboarded, as well as for downstream systems like the FAIR data point (FDP), the query mechanism and the EJPRD Virtual Platform (VP). It is these stakeholders that form part of the technical committee who are responsible for ratifying requests.

Once a request has been ratified, the status of the issue should be changed to ratified. Only once a request has been ratified can modellers start to implement the change. Once work on implementing a change has started, the issue status can be changed to change in progress. This may seem like an unnecessary status change, but its value is in communicating to stakeholders what is happening. This is particularly important in the following 2 cases:

1. There is a long delay between when a request has been ratified and when working on implementing the change is started.
2. Sometimes, despite careful consideration by the technical committee, a change that has been ratified, can be reverted. This happens when a consequence that was not immediately apparent, becomes apparent through additional information. In this case an issue with status ratified or change in progress can change back to awaiting decision.

In some cases a change request can be declined. This can happen when what is requested can already be achieved by using the model as-is, or if the change is not deemed to be well aligned with the objectives of the EJPRD. In this case the issue status should be changed to declined, ideally with a comment stating the reason for declining the request. Then the issue should be closed.

Once a change has been completed and pushed to the Github repository, the status of the issue should be changed to change completed. Finally the issue can be closed.