Skip to content

Latest commit

 

History

History
39 lines (22 loc) · 10.5 KB

process.md

File metadata and controls

39 lines (22 loc) · 10.5 KB
Raw

Management of changes to the INSPIRE Technical Guidance documents

This document describes the approach to be adopted for the management of changes to the INSPIRE Technical Guidance documents (TG). 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 version of a TG. 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.

Governance process

The process to update/change INSPIRE TGs 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/technical-guidelines/labels.

Workflow

The first actor involved in the governance process is the change proposer, i.e. the person, organisation or group of people/organisations that submits a change proposal. The change proposer shall outline the need for the change in a TG. The change proposer shall then describe the proposed change and explain whether it would have an impact on the INSPIRE validator, the INSPIRE XML schemas, the contents of the INSPIRE registry and/or on the Implementing Rules (IR). The GitHub labels impact on validator, impact on schemas, impact on registry and impact on IR are used in such cases. The change proposal shall be described by opening a new issue in the issue tracker of this repository.

The next actor involved in the governance process is the MIWP Sub-group of experts (referred to as Sub-group in the following), supervised by the JRC and created within Action 2.3 “Simplification of INSPIRE implementation” of the INSPIRE MIWP 2020-2024. The Sub-group 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 TG is the one described by the change proposer. To do so, the Sub-group shall interact with the change proposer and shall be closely supported by the INSPIRE helpdesk facilitators. The latter shall also contribute to the analysis of the change proposal and make sure it covers all the required points and is ready to be discussed by the Sub-group. All the interactions between 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 not correct, not clear, or not described with a sufficient level of detail, the Sub-group shall either reject it (in which case the issue will be closed) or ask the change proposer to improve it – with the help of the helpdesk facilitators – and submit it again. In this case, the GitHub label further info required is used. On the opposite, if the change proposal is correct, clear and described with a sufficient level of detail, the workflow can follow three different paths (see below), depending on the type of change proposal and based on a decision of the Sub-group. To determine what is the most suitable path for the specific type of change proposed, the Sub-group reserves the right to ask the change proposer for additional evidence or justification of the change proposal (to be given by e.g. a MIG/MIG-T member) and the GitHub label further info required is used. No evidence shall instead be required in the cases of clear errors in a TG (see below). The three paths are the following:

  1. If the proposed change analysed by the Sub-group is trivial (e.g. a change in the repository structure), 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 JRC is assigned. The JRC shall then implement the change, and once this is done, the issue is closed.

  2. If the proposed change analysed by the Sub-group is obvious and minor, e.g. there is a clear error in the TG and the proposal is to fix it, with no impact on the validator, the XML schemas, the registry or 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.

  3. If the proposed change analysed by the Sub-group is major, i.e. it impacts the validator, the XML schemas, the registry and/or the IR, the following actor in the process is the INSPIRE MIG-T. The GitHub label for INSPIRE MIG-T is used. The change proposal is presented by the Sub-group (ideally together with the original change proposer) to the MIG-T during the second or the fourth MIG-T meetings of the year, indicatively taking place in April and October. The MIG-T members, who will receive the rationale for the change proposal in written form before the meeting, will be able to ask questions and discuss with the change proposer and express themselves 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, in which case the issue is closed; or iii) ask the change proposer to amend the proposal and submit it again, in which case the GitHub label further info required is used. If the change proposal is rejected by the MIG-T, the whole process ends; if the MIG-T asks that the change proposal is amended, the change proposer shall amend it according to the feedback received and submit it again.

If the change proposal is endorsed by the INSPIRE CT or by the MIG-T, respectively in cases 1) and 2) 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, in which case the GitHub label endorsed is used; ii) reject the proposal, in which case the issue is closed; or iii) ask the change proposer to amend the proposal and submit it again, in which case 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 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:

  1. If the endorsed change proposal does not require update of IR, the JRC shall implement the change in the relevant TG and in the UML (if issue is labeled "impact on UML"). Once this is done, the issue is finally closed. If the endorsed change proposal has (also) an impact on schemas, the related changes will follow the specific governance process (defined in the XML schema repository), based on a specific group of actors (similar to the one for TGs) and a different release plan. If the endorsed change proposal has (also) an impact on the validator, an issue shall be raised in the validator helpdesk. If the endorsed change proposal has (also) an impact on the registry, an issue shall be raised in the registry helpdesk.
  2. 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 JRC shall implement the change as specified above.

Release process

The release of the endorsed changes to the INSPIRE TGs happens twice a year and it is scheduled to take place by January 31 and July 31. This means that:

  • all the changes endorsed by the MIG between August and January (either after the two-week scrutiny or during the MIG meeting in November) will be included in the release published by January 31 in the following year. This will be the first release of the year ‘20xx’ and will be named 20xx.1.
  • all the changes endorsed by the MIG between February and July (either after the two-week scrutiny or during the MIG meeting in June) will be included in the release published by July 31 on the same year. This will be the second release of the year ‘20xx’ and will be named 20xx.2.

All the releases, including a full changelog listing the changes made, are published (and will remain available) in the Releases page of this repository. After each release, the TGs at https://inspire.ec.europa.eu/Technical-guidelines3 are updated accordingly.