Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "VT Scientific Discipline Classification Change Management"

From EGIWiki
Jump to navigation Jump to search
 
(31 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{Template:ScientificDisciplineClassification_menubar}} {{TOC_right}}  
{{EGI_Activity_groups_menubar}}
{{Menubar_VT}}
{{Template:ScientificDisciplineClassification_menubar}}  
{{TOC_right}}
[[Category:Virtual_Teams]]


{{ VirtualTeamProject |
= Overview =
EGI Scientific Discipline Classification
Change Management Policy
   


Abstract:
This page holds the policy regarding the ownership and management of the EGI Scientific Discipline classification to ensure it is both periodically reviewed and managed through defined processes.  
This document defines the policy regarding the ownership and management of the EGI Scientific Discipline classification to ensure it is both periodically reviewed and managed through defined processes. In addition, as the community evolves and potential adoption by other e-Infrastructures expands, the change management policy will provide clarity and transparency regarding its evolution.
This document also satisfies recommendation #5 of the EGI Scientific Discipline Classification Virtual Team final report endorsed by EGI management for implementation.


Table of Contents:
In addition, as the community evolves and potential adoption by other e-Infrastructures expands, the change management policy will provide clarity and transparency regarding its evolution.
1 Roles and Responsibilities 3
1.1 Ownership 3
1.2 Hosting 3
1.2.1 Location 3
1.2.2 Technical Details 3
1.3 Change Manager 3
1.4 Change Advisory Board 4
1.5 Change Initiators 4
2 Change Management 4
2.1 Overview of Requirements 4
2.2 Processes and Procedures 5
2.2.1 Recording Changes 5
2.2.2 Classifying Changes 5
2.2.3 Assessment and Approval 5
2.2.4 Emergency/Urgent Changes 5
2.2.5 Decision Making 5
2.2.6 Schedule of Changes 5
2.2.7 Change Reversal 6
References 7


= Roles and Responsibilities  =


== Ownership  ==


Copyright:
This work has been coordinated by EGI.eu and partially funded through the EGI-InSPIRE project. The work has been produced to harmonise the use of scientific disciplines classification across EGI tools. The work is released under a creative commons license to promote reuse and contribution by other organisations.
This work by members of the EGI-InSPIRE collaboration is licensed under a Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0). This license lets you remix, tweak, and build upon this work, and although your new work must acknowledge EGI.eu, you do not have to license your derivative works on the same terms. Reproductions or derivative works must be attributed by attaching the following reference to the copied elements: “Based on work by members of the EGI-InSPIRE collaboration used with permission under a CC-BY 3.0 license (source work URL: https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification”).
 
 
== Hosting ==
1 Roles and Responsibilities
 
1.1 Ownership
=== Location ===
As this classification has been developed by dedicated Virtual Team supported by the EGI-InSPIRE project for EGI-wide purposes and for implementation with a variety of its tools, EGI.eu will take ownership of the classification.
 
However, as potential adoption of the classification expands, it will be essential to offer mechanisms in which other organisations with invested interest can take part in its future development.
In order to distribute the common scientific classification tree among the EGI services and beyond, while keeping it up-to-date with potential new changes, a single end-point needs to be created that will make the scientific classification available over a simple, developer-friendly, stable/reliable and well defined API.  
1.2 Hosting
 
1.2.1 Location
The host of this service will be IASA
In order to distribute the common scientific classification tree among the EGI services and beyond and keep them up-to-date on potential new changes (new additions, updates or even deletions), a single end-point needs to be created that will make the scientific classification available over a simple, developer-friendly, stable/reliable and well defined API.  
 
Since the EGI Applications Database (appdb.egi.eu) service makes significant use of technologies related to APIs, actually the entire service has been built on the top of a RESTful (XML and JSON) API, it will be used as the central tool for hosting the classification.
=== Query API ===
The host of this service will be IASA.
 
1.2.2 Technical Details
The following [https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification_Query link] provides the latest information for querying the most up-to-date version of the classification.
Marios to add technical details and update text.
 
== Change Manager  ==
 
The Change Manager for the SDC will be: EGI Strategy and Policy Manager or Senior Strategy and Policy Officer, unless otherwise agreed through the Change Advisory Board (CAB is defined in the next section).  


1.3 Change Manager
The Change Manager for the SDC will be: EGI Strategy and Policy Manager or Senior Strategy and Policy Officer, unless otherwise agreed through the Change Advisory Board.
The main duties of the Change Manager, some of which may be delegated, are:  
The main duties of the Change Manager, some of which may be delegated, are:  
• Receives, logs and allocates a priority to all requests for changes that are totally impractical.
• Tables all Request for Changes (RFCs) for a Change Advisory Board (CAB) meeting, issues an agenda and circulates all requests for changes to Change Advisory Board members in advance of meetings to allow prior consideration.
• Chairs all CAB and ECAB meetings and convenes any urgent CAB meetings for urgent RFCs.
• Authorizes acceptable changes, either alone or after a CAB has taken place.
• Issues change schedules.
• Liaises with all necessary parties to coordinate change building, testing and implementation, in accordance with schedules.
• Updates the change log with all progress that occurs, including any actions to correct problems and/or to take opportunities to improve quality.
• Reviews all implemented changes to ensure that they have met their objectives; refers back any that have been backed out of have failed.
• Reviews all outstanding RFCs.
• Analyses change records to determine any trends.
• Closes RFCs.
• Produces periodic management reports.
1.4 Change Advisory Board
The Change Advisory Board (CAB) is an advisory body for handling changes to the classification. The CAB is a body that exists to support the authorisation of changes and to assist change management in the assessment and prioritisation of changes. As and when a CAB is convened, members should be chosen who are capable of ensuring that the change is adequately assessed from both a business and a technical viewpoint. To achieve this, the CAB needs to include people with a clear understanding across the whole range of stakeholder needs. The Change Manager will normally chair the CAB.
The current/active list of CAB members should be hosted on a dedicated page, which is publicly available.
1.5 Change Initiators
A Change Initiator, or person/persons requesting a change to the classification, is open to anyone, but must contain the rationale for the request change in order to be processed. Potential interested parties include:
• Individual Users (e.g. Researchers)
• User manager(s) (e.g. VO Managers)
• User group representative(s) (e.g. Virtual Research Communities such as WeNMR, LSGC, WLCG)
• Applications developers/maintainers
• Tool Developers (e.g. Operations Portal)
• Senior members of e-Infrastructures (e.g. XSEDE)
• EGI SDC VT Members
• Open for participation request


2 Change Management
*Receives, logs and allocates a priority to all requests for changes that are totally impractical.
2.1 Overview of Requirements
*Tables all Request for Changes (RFCs) for a Change Advisory Board (CAB) meeting, issues an agenda and circulates all requests for changes to Change Advisory Board members in advance of meetings to allow prior consideration.
The FitSM standard (lightweight service management in federated IT infrastructures) defines a minimum set of requirements for handling change management. This standard will be used as a baseline for defining the processes, procedures and documentation. The requirements are as follows:
*Chairs all CAB and ECAB meetings and convenes any urgent CAB meetings for urgent RFCs.
• All changes shall be recorded according to a defined procedure.
*Authorizes acceptable changes, either alone or after a CAB has taken place.
• All changes shall be classified according to a defined procedure.
*Issues change schedules.
• All changes shall be assessed and approved according to a defined procedure.
*Liaises with all necessary parties to coordinate change building, testing and implementation, in accordance with schedules.
• There shall be a documented procedure for managing emergency changes.
*Updates the change log with all progress that occurs, including any actions to correct problems and/or to take opportunities to improve quality.
• In making decisions on the acceptance of requests for change, the risks, potential impacts to services and customers, service requirements, technical feasibility and financial impact shall be taken into consideration.
*Reviews all implemented changes to ensure that they have met their objectives; refers back any that have been backed out of have failed.
• A schedule of change shall be maintained. It shall contain details of approved changes, and proposed deployment dates, which shall be communicated to interested parties.
*Reviews all outstanding RFCs.
• The steps required to reverse an unsuccessful change or remedy any negative effects shall be planned and tested.
*Analyses change records to determine any trends.
2.2 Processes and Procedures
*Closes RFCs.
2.2.1 Recording Changes
*Produces periodic management reports.
Should we use RT, a dedicated mailing list and/or the wikipage?
 
2.2.2 Classifying Changes
== Change Advisory Board  ==
If possible, all changes should be provided following a defined classification. If not, then the Change Manager should apply a classification of the change for decision handling with the CAB. The following classification is as follows:
 
• Minor (e.g. grammar)
The Change Advisory Board (CAB) is an advisory body for handling changes to the classification. The CAB is a body that exists to support the authorisation of changes and to assist change management in the assessment and prioritisation of changes. As and when a CAB is convened, members should be chosen who are capable of ensuring that the change is adequately assessed from both a business and a technical viewpoint. To achieve this, the CAB needs to include people with a clear understanding across the whole range of stakeholder needs. The Change Manager will normally chair the CAB.
• Intermediate (e.g. addition to 3rd level; consistency between disciplines; change to single discipline name)
 
• Major (e.g. re-organisation of levels; moving disciplines between levels)
The current/active list of CAB members are:
2.2.3 Assessment and Approval
 
All minor change requests can be handled by the Change Manager. If needed, consultation can be sought through the CAB.
*TBD
All intermediate changes will be sent to the CAB with a request for response within 10 days. If further consultation is needed, an agenda point will be specifically added at the next CAB meeting.
 
All major changes must be sent through the CAB with 20 days for comments, with a specific discussion point for the following CAB meeting.
== Change Initiators  ==
2.2.4 Emergency/Urgent Changes
 
Emergency or urgent changes will be evaluated by the Change Manager for required action.
A Change Initiator, or person/persons requesting a change to the classification, is open to anyone, but must contain the rationale for the request change in order to be processed. Potential interested parties include:
Emergency or urgent changes are defined as a technical malfunction resulting from the classification or for revised required prior to presentation (e.g. to funding agencies).
 
*Individual Users (e.g. Researchers)
*User manager(s) (e.g. VO Managers)
*User group representative(s) (e.g. Virtual Research Communities such as WeNMR, LSGC, WLCG)
*Applications developers/maintainers
*Tool Developers (e.g. Operations Portal)
*Senior members of e-Infrastructures (e.g. XSEDE)
*...
 
= Change Management =
 
== Overview of Requirements ==
 
The FitSM standard (lightweight service management in federated IT infrastructures) defines a minimum set of requirements for handling change management. This standard will be used as a baseline for defining the processes, procedures and documentation. The requirements are as follows:  
 
*All changes shall be recorded according to a defined procedure.  
*All changes shall be classified according to a defined procedure.  
*All changes shall be assessed and approved according to a defined procedure.  
*There shall be a documented procedure for managing emergency changes.  
*In making decisions on the acceptance of requests for change, the risks, potential impacts to services and customers, service requirements, technical feasibility and financial impact shall be taken into consideration.  
*A schedule of change shall be maintained. It shall contain details of approved changes, and proposed deployment dates, which shall be communicated to interested parties.  
*The steps required to reverse an unsuccessful change or remedy any negative effects shall be planned and tested.
 
== Processes and Procedures ==
 
=== Recording Changes ===
 
The EGI Requirements Tracker tool will be used for change submission, recording and tracking: https://rt.egi.eu
Requests can also sent to a dedicate mailing list at: scientific-discipline-classification@mailman.egi.eu
 
=== Classifying Changes ===
 
If possible, all changes should be provided following a defined classification. If not, then the Change Manager should apply a classification of the change for decision handling with the CAB. The following classification is as follows:  
 
*Minor (e.g. grammar)  
*Intermediate (e.g. addition to 3rd level; consistency between disciplines; change to single discipline name)  
*Major (e.g. re-organisation of levels; moving disciplines between levels)
 
=== Assessment and Approval ===
 
All minor change requests can be handled by the Change Manager. If needed, consultation can be sought through the CAB.  
 
All intermediate changes will be sent to the CAB with a request for response within 10 days. If further consultation is needed, an agenda point will be specifically added at the next CAB meeting.  
 
All major changes must be sent through the CAB with 20 days for comments, with a specific discussion point for the following CAB meeting.  
 
=== Emergency/Urgent Changes ===
 
Emergency or urgent changes will be evaluated by the Change Manager for required action.  
 
Emergency or urgent changes are defined as a technical malfunction resulting from the classification or for revised required prior to presentation (e.g. to funding agencies).  
 
If the request cannot be handled by the Change Manager, then CAB is required to response to the request for an urgent change within 48 hours.  
If the request cannot be handled by the Change Manager, then CAB is required to response to the request for an urgent change within 48 hours.  
2.2.5 Decision Making
 
=== Decision Making ===
 
In making decisions on the acceptance of requests for change, the risks, potential impacts to services and customers, service requirements, technical feasibility and financial impact shall be taken into consideration.
In making decisions on the acceptance of requests for change, the risks, potential impacts to services and customers, service requirements, technical feasibility and financial impact shall be taken into consideration.
The Change Manager is able to rectify all minor changes, with consultation through the CAB as his/her discretion.
The Change Manager is able to rectify all minor changes, with consultation through the CAB as his/her discretion.
The CAB is able to vote on all requests for changes by two-thirds (2/3) majority of two-thirds (2/3) total CAB members present. It is possible to vote through the dedicated mailing list and/or regular meetings.
 
2.2.6 Schedule of Changes
The CAB is able to vote on all requests for changes by two-thirds (2/3) majority of two-thirds (2/3) total CAB members present. It is possible to vote through the dedicated mailing list and/or regular meetings.  
 
=== Schedule of Changes ===
 
The overall classification must be reviewed at least once a year. This is scheduled to begin on 1 May and conclude by 30 May of each year.
The overall classification must be reviewed at least once a year. This is scheduled to begin on 1 May and conclude by 30 May of each year.
Changes requested during the year will be evaluated according the change request procedure. Implementation of the change will depend on the complexity of the request and will be handled through the interested party.
2.2.7 Change Reversal
In the case of a reversal of an implemented change that was unsuccessful. The CAB will evaluate each case to determine the cause and required steps to be taken.
 
References
R 1
Scientific Discipline Classification VT Wiki page: https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification
R 2
EGI Scientific Discipline Classification (SDC VT Output) – https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification_Classification
|
VTP_Motivation =
EGI is a multidisciplinary e-Infrastructure where users belong to a variety of different scientific disciplines. EGI needs to categorise these users by disciplines through a number tools (e.g, AppDB, operations portal, training marketplace, CRM). Although a legacy classification was inherited from EGEE, different tools have adopted different classifications and the expanded user base has many virtual organisations falling into the "other" category. As EGI now operates within an open ICT ecosystem, it has become essential to agree on a common, coherent classification that is not only consistent across all tools, but allows for smooth inclusion of future user communities as well.<br>
|
VTP_Output =
A proposal for a new classification of scientific disciplines for EGI that is verified with the VO managers, EGI tools operators and NILs and that is open for the inclusion of new communities in the future.
|
VTP_Tasks = 
*Identify all possible uses of disciplines across EGI.
*Research publically available classifications.
*Define an aggregation of scientific disciplines.
*Understand the technical implications of integrating a new classification scheme.
*Present the proposed list for comments and recommendation by VO Managers, EGI tool operators and NILs.
*Submit an agreed and verified classification to EGI Management and Council for approval with a set of recommendations moving forward.
[[VT_Scientific_Discipline_Classification_Tasks|See dedicated activity page]]
|
VTP_Team =
* Sy Holsinger, EGI.eu / VT Leader
* Sergio Andreozzi, EGI.eu
* Gonçalo Borges, LIP / PT NIL / CRM
* Marios Chatziangelou, IASA / GR NGI / AppDB
* Claire Devereux, STFC / UK NIL / Training Marketplace
* Iván Díaz, CESGA / ES NGI / Accounting Portal
* Maciej Filocha, ICM / PL NGI / User Communities 
* Cyril L'Orphelin CNRS / FR NGI / Operations Portal
* Geneviève Romier CNRS / FR NIL / User Communities
* Alvaro Simon, CESGA / ES NGI / Accounting Portal
* Jelena Tamulienė, VU / LT NIL / User Communities
|
VTP_Resources =
* [[Scientific_Disciplines| Background Information]]
* [http://go.egi.eu/lbhrc Summary of the different EGI uses and comparisons to other publicly available classifications]
|
VTP_Progress =
}}


[[Category:Scientific_Discipline_Classification]]
Changes requested during the year will be evaluated according the change request procedure. Implementation of the change will depend on the complexity of the request and will be handled through the interested party.
 
=== Change Reversal  ===
 
In the case of a reversal of an implemented change that was unsuccessful. The CAB will evaluate each case to determine the cause and required steps to be taken.
 
= References  =
 
*Scientific Discipline Classification VT Wiki page: https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification
 
*EGI Scientific Discipline Classification (SDC VT Output) – https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification_Classification
 
= Copyright =
Copyright © EGI.eu. This work is licensed under the Creative Commons Attribution-NonCommercial- NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. The work must be attributed by attaching the following reference to the copied elements: “Copyright © EGI.eu (www.egi.eu). Using this document in a way and/or for purposes not foreseen in the license, requires the prior written permission of the copyright holders. The information contained in this document represents the views of the copyright holders as of the date such views are published.

Latest revision as of 15:15, 19 June 2015

EGI Activity groups Special Interest groups Policy groups Virtual teams Distributed Competence Centres


EGI Virtual teams: Main • Active Projects • Closed Projects • Guidelines
VT Scientific Discipline Classification: Home • Scientific Disciplines • Change Management • Query API • Tasks/Actions/Plans • Meetings •

Overview

This page holds the policy regarding the ownership and management of the EGI Scientific Discipline classification to ensure it is both periodically reviewed and managed through defined processes.

In addition, as the community evolves and potential adoption by other e-Infrastructures expands, the change management policy will provide clarity and transparency regarding its evolution.

Roles and Responsibilities

Ownership

This work has been coordinated by EGI.eu and partially funded through the EGI-InSPIRE project. The work has been produced to harmonise the use of scientific disciplines classification across EGI tools. The work is released under a creative commons license to promote reuse and contribution by other organisations.

Hosting

Location

In order to distribute the common scientific classification tree among the EGI services and beyond, while keeping it up-to-date with potential new changes, a single end-point needs to be created that will make the scientific classification available over a simple, developer-friendly, stable/reliable and well defined API.

The host of this service will be IASA

Query API

The following link provides the latest information for querying the most up-to-date version of the classification.

Change Manager

The Change Manager for the SDC will be: EGI Strategy and Policy Manager or Senior Strategy and Policy Officer, unless otherwise agreed through the Change Advisory Board (CAB is defined in the next section).

The main duties of the Change Manager, some of which may be delegated, are:

  • Receives, logs and allocates a priority to all requests for changes that are totally impractical.
  • Tables all Request for Changes (RFCs) for a Change Advisory Board (CAB) meeting, issues an agenda and circulates all requests for changes to Change Advisory Board members in advance of meetings to allow prior consideration.
  • Chairs all CAB and ECAB meetings and convenes any urgent CAB meetings for urgent RFCs.
  • Authorizes acceptable changes, either alone or after a CAB has taken place.
  • Issues change schedules.
  • Liaises with all necessary parties to coordinate change building, testing and implementation, in accordance with schedules.
  • Updates the change log with all progress that occurs, including any actions to correct problems and/or to take opportunities to improve quality.
  • Reviews all implemented changes to ensure that they have met their objectives; refers back any that have been backed out of have failed.
  • Reviews all outstanding RFCs.
  • Analyses change records to determine any trends.
  • Closes RFCs.
  • Produces periodic management reports.

Change Advisory Board

The Change Advisory Board (CAB) is an advisory body for handling changes to the classification. The CAB is a body that exists to support the authorisation of changes and to assist change management in the assessment and prioritisation of changes. As and when a CAB is convened, members should be chosen who are capable of ensuring that the change is adequately assessed from both a business and a technical viewpoint. To achieve this, the CAB needs to include people with a clear understanding across the whole range of stakeholder needs. The Change Manager will normally chair the CAB.

The current/active list of CAB members are:

  • TBD

Change Initiators

A Change Initiator, or person/persons requesting a change to the classification, is open to anyone, but must contain the rationale for the request change in order to be processed. Potential interested parties include:

  • Individual Users (e.g. Researchers)
  • User manager(s) (e.g. VO Managers)
  • User group representative(s) (e.g. Virtual Research Communities such as WeNMR, LSGC, WLCG)
  • Applications developers/maintainers
  • Tool Developers (e.g. Operations Portal)
  • Senior members of e-Infrastructures (e.g. XSEDE)
  • ...

Change Management

Overview of Requirements

The FitSM standard (lightweight service management in federated IT infrastructures) defines a minimum set of requirements for handling change management. This standard will be used as a baseline for defining the processes, procedures and documentation. The requirements are as follows:

  • All changes shall be recorded according to a defined procedure.
  • All changes shall be classified according to a defined procedure.
  • All changes shall be assessed and approved according to a defined procedure.
  • There shall be a documented procedure for managing emergency changes.
  • In making decisions on the acceptance of requests for change, the risks, potential impacts to services and customers, service requirements, technical feasibility and financial impact shall be taken into consideration.
  • A schedule of change shall be maintained. It shall contain details of approved changes, and proposed deployment dates, which shall be communicated to interested parties.
  • The steps required to reverse an unsuccessful change or remedy any negative effects shall be planned and tested.

Processes and Procedures

Recording Changes

The EGI Requirements Tracker tool will be used for change submission, recording and tracking: https://rt.egi.eu Requests can also sent to a dedicate mailing list at: scientific-discipline-classification@mailman.egi.eu

Classifying Changes

If possible, all changes should be provided following a defined classification. If not, then the Change Manager should apply a classification of the change for decision handling with the CAB. The following classification is as follows:

  • Minor (e.g. grammar)
  • Intermediate (e.g. addition to 3rd level; consistency between disciplines; change to single discipline name)
  • Major (e.g. re-organisation of levels; moving disciplines between levels)

Assessment and Approval

All minor change requests can be handled by the Change Manager. If needed, consultation can be sought through the CAB.

All intermediate changes will be sent to the CAB with a request for response within 10 days. If further consultation is needed, an agenda point will be specifically added at the next CAB meeting.

All major changes must be sent through the CAB with 20 days for comments, with a specific discussion point for the following CAB meeting.

Emergency/Urgent Changes

Emergency or urgent changes will be evaluated by the Change Manager for required action.

Emergency or urgent changes are defined as a technical malfunction resulting from the classification or for revised required prior to presentation (e.g. to funding agencies).

If the request cannot be handled by the Change Manager, then CAB is required to response to the request for an urgent change within 48 hours.

Decision Making

In making decisions on the acceptance of requests for change, the risks, potential impacts to services and customers, service requirements, technical feasibility and financial impact shall be taken into consideration.

The Change Manager is able to rectify all minor changes, with consultation through the CAB as his/her discretion.

The CAB is able to vote on all requests for changes by two-thirds (2/3) majority of two-thirds (2/3) total CAB members present. It is possible to vote through the dedicated mailing list and/or regular meetings.

Schedule of Changes

The overall classification must be reviewed at least once a year. This is scheduled to begin on 1 May and conclude by 30 May of each year.

Changes requested during the year will be evaluated according the change request procedure. Implementation of the change will depend on the complexity of the request and will be handled through the interested party.

Change Reversal

In the case of a reversal of an implemented change that was unsuccessful. The CAB will evaluate each case to determine the cause and required steps to be taken.

References

Copyright

Copyright © EGI.eu. This work is licensed under the Creative Commons Attribution-NonCommercial- NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. The work must be attributed by attaching the following reference to the copied elements: “Copyright © EGI.eu (www.egi.eu). Using this document in a way and/or for purposes not foreseen in the license, requires the prior written permission of the copyright holders. The information contained in this document represents the views of the copyright holders as of the date such views are published.

Retrieved from "https://wiki.egi.eu/w/index.php?title=VT_Scientific_Discipline_Classification_Change_Management&oldid=80690"