This document describes the approach to be adopted for the management of changes to the INSPIRE Registry. It covers the whole process from the initial stage of change proposal up to the final stage of endorsement and change implementation into a new release. It defines actors, responsibilities and timelines for each stage of the process, and the GitHub artefacts (issues and labels) to be used in each process.
The process to update/change INSPIRE Registry content, varies depending on the type of change proposed and its foreseen impact. Based on this, different scenarios are envisaged. They are all captured in the flowchart below and described in the following. An overview of all the labels can be found on https://github.com/INSPIRE-MIF/helpdesk-registry/labels.
The first actor involved in the governance process is the Change Proposer, i.e. the person supported by a Submiting Organisation, that submits a change proposal. The Change Proposer shall describe the proposed change (identifying the URI of the register/reference code proposed to be changed), providing a detailed explanation of the proposed changed as well as the rationale or motivation behind it. The change proposal shall be described by opening a new issue in the issue tracker of this repository.
The sencond actor involved in the governance proces is the INS-Reg Manager who start an initial analysis of the change proposal and carries out several actions throughout the different steps of process. At this point, if further clarifications by the Change proposer are needed, the label further info required will be added. If this is not enough and the proposal is not clear or correct, the INS-Reg Manager shall reject it (and close it in the issue tracker). As part of the analysis the INS-Reg Manager have to analyse whether the proposed change would have an impact on the Technical Guidance documents (TG) and/or on the Implementing Rules (IR). The GitHub labels impact on UML, impact on TG and impact on IR are used in such cases. Once all the information is correct and the analysis is finished, the INS-Reg Manager formalises it in view of its presentation to the MIWP Sub-group.
The next actor involved in the governance process is the MIWP Sub-group (hereinafter referred to as 'Sub-group'), supervised by the JRC and created within Action 2.3 “Simplification of INSPIRE implementation” of the INSPIRE MIWP 2020-2024. The Sub-group, composed of experts, shall evaluate the proposal and, in a first step, check whether: i) the change proposal is reasonable; and ii) the change proposal (including the impact) is correct, clear, described with a sufficient level of detail, and the impact of the change in the INSPIRE Registry is the one described by the INS-Reg Manager. The evaluation shall be performed in close collaboration of the INSPIRE helpdesk facilitators, who may provide contributions. The Sub-group shall pay particular attention to the change proposal to make sure it is complete and covers all the required points, before continuing with the process. If needed, any additional interactions with the change proposer, the Sub-group and the helpdesk facilitators shall happen in the issue tracker of this repository, in the form of a discussion under the same issue initially created.
If the change proposal (including the impact) is not reasonable and/or incorrect, not clear, or not described with a sufficient level of detail, the Sub-group shall either reject it (case in which the issue will be closed) or ask the change proposer to refine the change proposal, or to provide additional evidence or justification – with the help of the helpdesk facilitators – and submit it again. The GitHub label further info required will be used, accordingly. No evidence shall be required in the cases of clear bugs. On the contrary, if the change proposal is clear, appropriate and complete, the Sub-group may consider it and continue the process. At this point, the workflow can follow three different paths (see below), depending on the type of change proposal, based on the criteria and decision of the Sub-group about the most suitable path for the schange proposed. The three paths are the following:
-
If the proposed change analysed by the Sub-group is trivial, i.e. it does not need to be discussed but is added merely for the purpose of informing the users of the change, the Sub-group takes notice of the change, and the GitHub label for INS-Reg Manager is assigned. The INS-Reg Manager shall then implement the change, and once this is done, the issue is closed.
-
If the proposed change analysed by the Sub-group is obvious and minor, e.g. there is a clear bug/typo in the content of the INSPIRE Registry and the proposal is to fix it, with no impact on the TG and no impact on the IR, the Sub-group shall approve the change and invite the INSPIRE Coordination Team (CT) to endorse it. The GitHub label for INSPIRE CT is used. The INSPIRE CT shall either: i) endorse the proposal; ii) reject the proposal; or iii) ask the Change Proposer to amend the proposal and submit it again. If the change proposal is rejected by the INSPIRE CT, the issue is closed and the whole process ends; if the INSPIRE CT asks that the change proposal is amended, the GitHub label further info required is used and the change proposer shall amend it according to the feedback received and submit it again.
-
If the proposed change analysed by the Sub-group is major, for example impacting the TG and/or the IR, the following actor in the process is the INSPIRE MIG-T. The GitHub label for INSPIRE MIG-T is used in this case. The change proposal is presented by the INS-Reg Manager to the MIG-T Sub-group (acting as Control body, as per the Terms of Reference for the Control body and Submitting organisations) for discussion, during the second or the fourth MIG-T meeting of the year (indicatively taking place in April and November, respectively) - according to the current release strategy. The MIG-T members, who will be provided with a summary of the change proposal and its rationale during the meeting, will be able to ask questions, discuss and express their opinion in favor or against the change proposal. An overall decision (in favor/against) from the MIG-T shall be taken during the meeting through a voting process, where MIG-T members voting against the proposal or abstaining from voting need to provide justification. The MIG-T shall either: i) endorse the proposal; ii) reject the proposal, case in which the issue is closed and the whole process ends; or iii) ask the change proposer to amend the proposal according to the MIG-T feedback received, and to submit it again - The GitHub label further info required is used in that cases.
If the change proposal is endorsed by the INSPIRE CT or by the MIG-T, respectively in cases 2) and 3) above, the GitHub label for INSPIRE MIG is used. The INSPIRE MIG is informed about the change proposal and a two-week time window starts, during which MIG members can raise objections to the proposal. If at least one objection is raised during the two-week time window, the GitHub label for INSPIRE MIG discussion is used and the change proposal is discussed at the first MIG meeting immediately following the two-week time window. An overall decision (in favor/against) from the MIG shall be taken during the meeting through a voting process, where MIG members voting against the proposal or abstaining from voting need to provide justification. The MIG shall either: i) endorse the proposal, case in which the GitHub label endorsed is used; ii) reject the proposal, case in which the issue is closed and the whole process ends; or iii) ask the change proposer to amend the proposal and submit it again, case in which the GitHub label further info required is used. If the change proposal is rejected by the MIG, the whole process ends; if the MIG asks that the change proposal is amended, the change proposer shall amend it according to the feedback received from the MIG, and submit it again.
If no objection is raised by MIG members during the two-week time window, or if the change proposal is endorsed by the MIG during the meeting, then:
- If the endorsed change proposal does not require update of IR, the INS-Reg Manager shall implement and publish the change in the INSPIRE Registry in the next release. If it requires changes in the UML (if issue is labeled "impact on UML") and the JRC shall update the affected UML. Once this is done, the issue is finally closed. If the endorsed change proposal has (additionally) an impact on TG, the related changes will follow the specific governance process (defined in the Technical Guidance documents repository), based on a specific group of actors (similar to the one for INSPIRE Registry) and its corresponding release plan. If the endorsed change proposal has (also) an impact on validator, an issue shall be raised in the validator helpdesk.
- If the endorsed change proposal has an impact on IR, the INSPIRE CT shall submit a proposal for a draft amendment of the IR (issue labeled "for Comitology"). The endorsement of this proposal is subject to its own governance process (involving the Comitology procedure) and is outside the scope of the present document. If the change proposal is endorsed and after the publication of the revised IR (issue labeled "IR revised"), the INS-Reg Manager shall implement the change as specified above.
The release of the endorsed changes to the INSPIRE Registry is performed according to the milestones and timeline detailed in the INSPIRE Registry release strategy.
In addition to the scheduled releases, hotfix releases of the INSPIRE Registry, i.e. releases that fix critical errors or bugs, might be released at any time - as required.
For all releases, a full changelog listing the changes made for a release, are published (and will remain available) in the Releases page of this repository. After each release, the content of the INSPIRE Registry - available at https://inspire.ec.europa.eu/registry - is updated accordingly.