Over time the IATI Standard needs to change and adapt, responding to the needs of different stakeholders. Some changes have very little impact and can be made easily, others will have greater direct and indirect for the Standard and its users. The process below defines what type of change can be made when, how this should happen, who needs to be consulted and who needs to approve the change.
Patches (previously minor changes) can cover backwardly-compatible bug fixes. Changes are carried out by the IATI Secretariat under the approval of the Secretariat.
Following version 3.0.0, each patch will have a version number.
Patches can currently be tracked through the IATI GitHub account.
More significant changes to the standard are handled via upgrades. There are two types of upgrades - minor upgrades and major upgrades.
Minor (previously decimal) upgrades can cover changes that are optional and backwardly compatible. The Governing Board is responsible for initiating, overseeing and approving the upgrade.
Minor upgrades can include:
Bug-fixes, including resolution of spelling and grammar errors (where edits have implications for usage and/or meaning)
Modifications to core codelists
Minor additions to the standard which improve the functionality without introducing substantial new content
All changes will be optional and backwardly compatible.
Major (previously integer) upgrades can cover non-backwardly compatible changes. The Members’ Assembly is responsible for initiating and approving the upgrade. The Governing Board is responsible for overseeing progress.
Major upgrades can include:
Substantial additions to the Standard
New mandatory fields
Changes that are not backwardly compatible
Major and minor upgrades will be conducted in two distinct phases:
Content (what).This refers to the real-world use case. What problem will the change solve.
Technical implementation (how). This refers to the translation of the content into the syntax required by schema/codelist/rule. How do we solve the problem?
Wherever possible, decisions on changes to the standard should be reached by consensus. This means an absence of active dissent amongst those involved in the consultation process. If consensus cannot be reached the matter will be referred to the Governing Board for its assistance in resolving the dispute. The Governing Board, taking note of advice from the TAG chair, may adjudicate on an unresolved dispute.
The Governing Board will approve a timeline for each upgrade prepared by the IATI Secretariat. The timeline will consist of the following phases:
- Content consultation
Proposals are submitted and discussed by the community on. (Consultations mentioned in all phases can be conducted on IATI Discuss, conference calls and meetings of the TAG.)
- Content approval
The community attempts to reach consensus on the final content. Wherever possible this phase should take place at a full meeting of the TAG.
The final content is submitted to the Governing Board (minor) or Members’ Assembly (major) for approval or resolution.
- Technical consultation
The IATI Secretariat and community technical experts translate the agreed content into the syntax of the Standard.
Consultations take place on the technical proposals.
- Technical approval
The community attempts to reach consensus on the final content.
The final content is submitted to the Governing Board for approval or resolution.
- Technical Implementation
The IATI Secretariat creates a new candidate version of the standard.
The IATI Secretariat updates all utilities and services maintained by IATI to be compatible with the new version.
The candidate version is made available to the community for publisher and user testing.
- Final Approval
The Governing Board, following advice from the TAG Chair, approves the final version and announces a Go Live date.
A changelog for each minor and major upgrade will be made available on the Upgrades section of the IATI Standard website.