IATI Standard Publishing Guidance: How to suggest changes
What information does the IATI Standard Publishing Guidance contain?
The IATI Standard Publishing Guidance helps explain and interpret the IATI Standard. The Standard is written in a technical language and does not contain much of the context of ‘why’ certain data is needed and when and how to use the different IATI elements and attributes. The Standard also contains some gaps and is open to interpretation, such as: should an organisation publish both an original and a revised budget?
The IATI Standard Publishing Guidance helps address this, by adding context and filling in some of the gaps in the Standard. These pages fit in the “non-normative” content category as described below.
Normative: Normative content is the prescriptive part of a standard. It sets the rules to be followed in order to be compliant with the standard, and from which no deviation is permitted.
Non-normative: Non-normative content is the non-prescriptive, or ‘descriptive’, part of a standard. This may include explanations, illustrations, context, and examples. In the event non-normative content contradicts normative content, the normative content is to be followed.
For a full list of what falls under the normative and non-normative category as part of the IATI standard, see here.
Suggesting changes to the IATI Standard Publishing Guidance
Normative remains the same - changes are made following a clear process and sufficient notice, to ensure relevant stakeholders are involved. The IATI upgrade process presently assures this.
Changes to non-normative content, such as the IATI Standard Publishing Guidance, can happen without triggering an upgrade governance process, and can be updated outside of a formal upgrade process, ensuring that changes do not conflict with normative content.
Changes to the IATI Standard Publishing Guidance can either be proposed by the Secretariat (e.g. in response to specific user feedback or changes needed to deliver on the IATI Strategic Plan) and then consulted with the IATI community, or proposed by the IATI community and then reviewed and considered by the Secretariat. The process for the community to propose changes to be reviewed and considered by the Secretariat is provided below.
How to suggest changes to existing guidance pages
All IATI Publishing Guidance pages are stored and managed in the IATI-Guidance Github repository. If you notice an error, or would like to add a comment about a guidance page, you can raise a GitHub issue. Any issues added by community members directly to Github will be reviewed bi-weekly by the IATI Technical Team and labelled a ‘bug’, ‘clarification’ or ‘discussion’. If users are not familiar with Github and would still like to comment or raise an issue, they can contact the Technical Team via the IATI Helpdesk (support@iatistandard.org) in the first instance. The Technical Team will ensure that your issue/feedback has been addressed and shared publicly.
Review of proposed changes and timelines for implementation
The IATI Technical Team is responsible for reviewing and addressing any requests and issues raised on Github. In line with best practice, requests will be dealt with in batches, to ensure proper quality assurance, every 6 months (except for bugs/clarifications).
Issues labelled as “BUGS” and “CLARIFICATIONS” - any bugs or clarifications will be addressed and incorporated into the relevant guidance pages at the 3 month review period.
Issues labelled as “REQUIRES DISCUSSION/CONSULTATION”. These issues can fall into two categories:
Issues which require no change to the interpretation to the Standard, but are additions or changes to the published guidance. At the 6 month review period the Technical Team will review the discussion on Github and assess whether there is an agreement. We will also signpost/share via IATI Connect (specific category for this will be set up) once the issue has been raised, so users can be alerted and can get involved if they wish to. Issues can also be raised directly on IATI Connect under the relevant category. Following agreement, changes will then be made to the guidance by the Technical Team. More weight will be given to proposals supported by more community members.
Note: we propose that we need agreement of at least 10 community members.
Issues which require a change in how the Standard is interpreted will require an additional community consultation. The issues raised will then be added to IATI Connect and interested community members will be asked to feed in and join a scheduled webinar on the topic during the next 6 months.
The following provides examples to describe the different classifiers above:
Classifier |
Description |
Specific example |
|---|---|---|
| Bug / small error | Spelling mistake or formatting error. | |
| Clarification | A request for part of the guidance to be made simpler, or further explained. | |
| Discussion | A discussion that involves no change to interpretation of the Standard. This can include discussions on best practice and how to structure different types of activities. | Should publishers be advised to publish Result Indicator Periods based on their programme of work or based on their donor’s monitoring timetable? Within the location element, for safety reasons, should an organisation use the midpoint of a region or a known place e.g. town hall or local office? When publishing SDG data, should the tag element predominantly be used? And for UN agencies, should they use both the sector and tag elements to meet their reporting requirements? Each activity should have a country reported at either activity or transaction level (this is currently missing from the standard) Booleans should be reported in a standardised way. Currently True/False, 1/0 and Yes/No are all allowed |
| Discussion | A discussion that involves a change to, or addition of, a new interpretation to the Standard. This includes adding a stricter interpretation to areas where the Standard is vague. | How to publish and understand activity budget types. Should publishers include both original and revised budgets in their data and how should these be aggregated together? Should the presence of the humanitarian flag at activity level mean the activity is wholly or partially humanitarian, with a breakdown of the percentage allocation coming from either sector codes or transaction level humanitarian flags? |
If any of the “discussion” issues is a request for a change that requires an upgrade process, then the issue will be labelled accordingly as a Major or Minor upgrade, and put on hold until the relevant upgrade process has been initiated.
| Require an upgrade | A change that involves changing a rule or guidance in the IATI Standard or involves adding a new element, attribute or occurrence. | To make reporting at least one recipient country or region per activity mandatory would require a major standard upgrade. |
Accessing a log of changes post-implementation
All changes implemented after the 3 month period will be viewed in the Github history log, which acts as a changelog. On each publishing guidance page (see example for activity budgets), users will also be able to view the date when each page was last updated, and a direct link to the changes on Github.
