Merge pull request #43 from heidivanparys/remove_approved_add_forjrc

Update governance process: remove label "approved", add label "for JRC"

governance-release-process/process.md

@@ -12,11 +12,13 @@ The first actor involved in the governance process is the **change proposer**, i
 
 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”](https://webgate.ec.europa.eu/fpfis/wikis/display/InspireMIG/Action+2.3+Simplification+of+INSPIRE+implementation) of the [INSPIRE MIWP 2020-2024](https://webgate.ec.europa.eu/fpfis/wikis/display/InspireMIG/INSPIRE+work+programme+2021-24). 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 schema 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](https://github.com/INSPIRE-MIF/application-schemas/issues) 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 GitHub label _approved_ will be used. At this point, depending on the type of change proposal to the schema, the workflow can follow two different paths (see below) 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 bugs to a schema (see below). The two paths are the following:
+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 bugs to a schema (see below). The three paths are the following:
 
-1) If the proposed change analysed by the Sub-group is obvious and minor, e.g. there is a clear bug to an application schema 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.
+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 bug to an application schema 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.
 
-2) If the proposed change analysed by the Sub-group is major, i.e. it impacts 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 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. 
+3) If the proposed change analysed by the Sub-group is major, i.e. it impacts 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 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.