The IATI Technical Team has written process guidance on how to make changes to the IATI Standard Publishing Guidance pages. Please note that this is a new process and we will monitoring how it works and will revisit this after one year of application. On suggested use of platform, such as Github and Discuss, we will of course also look into how we can use the new IATI community platform once set in place.

In the process of writing this guidance, we looked at Open Contracting Guidance to see how others have approached similar process; we also discussed this with IATI Governing Board Focal Points Melinda Cuzner and Leo Stolk.

We would like to share the IATI Standard Publishing Guidance - How to Make Changes document with you in advance to make sure it is clear and straightforward. Please respond to this thread by Friday 2 October if you have clarification comments and we will make sure we address them. We will then publish this on our main website and link to it from the IATI Publishing Guidance pages as well.

Comments (8)

Pelle Aardema

I find I am having trouble making a clear distinction between categories “Issues which require no change to the interpretation to the Standard” and “Issues which require a change in how the Standard is interpreted”.
Do you have any examples in mind?

For the first category, I think a criterium of ‘supported by 10 or more community members’ is a bit vague, as there is no real definition of who are considered community members.

matmaxgeds

I never quite figured out if/how the Validator implements aspects of the guidance - if so, I would find it useful to identify this in the document as one of the ‘classifications’ of changes, especially if a change in guidance could result in exclusion of data from the datastore?

Linked to this - maybe it is worth linking to the ruleset that the validator implements as another place the guidance is stored.

Herman van Loon

All changes in the ‘discussion’ category potentially have an impact on how the standard should be used. Therefore the proposed governance process seems very lightweight to me. Only 10 agreeing ‘community members’ (at this moment anyone can be a community member whether very knowledgeable about IATI or not) can make changes which impact the whole community of 1200+ publishers.

Another question which seems unanswered is what happens when there is no agreement. E.g. 13 community members of which 10 agree and 3 disagree: would the change be accepted?

I would suggest that all ‘discussion’ category changes to the guidance are being taken care of by one or more IATI working groups, making use of the existing governance structure. The IATI working groups advises the board about proposed changes to the guidance of the standard. In case of disagreements the board can decide whether or not to accept a change.

The 3 monthly cycle seems a bit frequent for me. Especially in the summer period from June-August you can easily miss relevant discussions. An half year cycle seems more appropriate.

Melinda Cuzner

You have a valid point in regards to the 3 month time line. But do I understand you correctly, is it that you object to the 10 community member limit for guidance changes? I agree, if it would be a matter of changing the standard interpretation that would be a thin requirement… but this is only in regards to change/additions to the guidance. Can you elaborate on the risks you have identified with this?

Of course, it could even be that 10 agree and 10 disagree. And there is no “grading” between members, so all count the same. To me this sounds as if this points to an ambiguity in the guidance and thus justifies a change. But please develop further.

As for the Working Groups, there is no logical connection between proposed WG’s and discussions mentioned here because they are more limited in time and scope. Perhaps a Community of Practice would more suitable for surveillance of this sort?

Herman van Loon

For changing the guidance in a substantial way the proposed governance proces is i.m.o. far to thin. It is true that the standard itself is not changed, but the guidance describes how the standard should be used within the limits of its technical definition (e.g. the fields to publish, cardinality, codelists). Maybe even more important: the guidance ensures that different publishers have a common understanding of the meaning and use of the elements in the standard. Guidance is in other words an very important part of the standard to be treated with the same respect as the standard itself. The risk of changing the guidance with a lightweight change process is implicitly altering the meaning or use of the standard without a proper chance for the community to review and agree the proposed changes.

Therefore the proces of changing the guidance in any substantial way should i.m.o. follow a formal and thorough path, comparable to changes in the technical standard itself. Therefore I object to the current proposal.

Since adding and changing parts of the guidance is a continous process (we have had multiple cases in the last few years), I think an IATI working group could be an effective way of managing changes. The reason why I prefer an IATI WG above a CoP is that an IATI WG is accountable to the board who acts on behalf of the whole IATI community. Especially when there are differences of opinion about proposed changes, the board plays an important role in this proces.

Finally the proposed and review changes could be presented to the MA for formal approval, comparably to changes in the technical standard itself.

IATI Technical Team

Thank you very much for the engagement and responses on the proposed guidance changes process.

Your feedback is much appreciated and we would like to extend the deadline for feedback on this process to Monday 12 October to allow other users have the opportunity to feedback, given the current feedback.

We will respond to your specific comments in this post tomorrow.

IATI Technical Team

Hi everyone,

You will have seen that we have extended the deadline to Monday 12 October 2020 to ensure we have addressed your comments and other users have the opportunity to feedback.

Before addressing specific comments below, we want to highlight that this is a new process for IATI and represents a first step to put some guidance in place for how guidance changes are made. We are aiming for a pragmatic and workable solution to address a complex issue. This has been and will continue to be a collective effort and we will evaluate the process over time, based on community feedback. If that feedback indicates that there is a need for a more formalised process, we will of course work with the community on that.

In response to specific comments:

  1. Duration of review: We will be happy to extend the review period for changes from 3 months to 6 months (except for bugs).

  2. Difference between Standard upgrade process and guidance changes process:

  • The IATI standard guidance is aligned with version 2 of the IATI Standard. We are aware that there are imperfections in the current version of the Standard and that through some of the guidance consultations, there might be proposals for changes to the Standard that might require an upgrade, but those will follow the Standard upgrade procedures. The guidance pages under consideration here are additional to the Standard rules, so will not result in substantial changes to the data.
  • We believe that a Community of Practice for interested people to talk about specific improvements to the IATI guidance, if and when they arise, will be beneficial. A CoP will be a better fit than a Working Group as it allows for an on-going process, allowing different user groups to feedback on specific guidance pages and suggest improvements. (Working Groups must be time bound and have a clear aim and deliverable; therefore a CoP may be more appropriate. If in the future there are specific pieces of time-bound work relating to guidance, we can of course assess the need for a Working Group.)
  1. Clarification about the difference between no change and change to the interpretation of the Standard: We can add more examples to the guidance document (see below). The Standard guidance pages are aligned to a major version of the Standard (currently v2). We acknowledge that there are imperfections and inconsistencies with the Standard in v2 and the associated guidance. These can be resolved in the future by having a major upgrade to version 3. In the meantime, we have tried to suggest a process that allows us to help improve data quality and use outside of a major upgrade.

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. See examples below:

  • 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

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. See examples below:

  • 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?

  1. Number of community members- 10 members: As mentioned above this is a new process we are proposing. We initially suggested 10 members, very much acknowledging this is not a perfect solution and it has limitations. We are keen to find a way that ensures the guidance is changed only when there is a community need, rather than on the consensus of one or two actively engaged members. We would welcome alternative / better proposals and will be happy to revisit. Please propose alternatives by responding to this post!

Finally, we wanted to clarify in response to [~350]’s questions about how the Validator implements aspects of the guidance related to this process. As mentioned here, guidance changes will not result in exclusion of data from the Datastore. But it is a good suggestion to clarify how changes to guidance pages will result in the future to changes in the Validator implementation- we will add this to the Validator FAQ.

Again, thank you very much for your comments and feedback!

IATI Technical Team

IATI Technical Team

Hi everyone,

We have not had further feedback following our response to your comments. We have incorporated the suggestion to change the review period to 6 months and we have added in the additional examples to make the document clearer. We would now like to proceed with adding this guidance process next week. If anyone has any additional feedback or comments please let us know by close of play on Tuesday 27 October. We are also happy to speak to anyone if that is easier!

We do want to reiterate that we are aiming for a pragmatic and workable solution to address a complex issue. This will continue to be a collective effort and we will evaluate the process over time, based on your feedback.


Please log in or sign up to comment.