Publishing Practices – Getting the basics right
It has only been a month since we released the 2018 Aid Transparency Index, but we’ve been excited to see lively discussion about the results.
As we have emphasised before, the Index process is an interactive one and this does not stop with the publication of the report. We consider the Index to also be a tool for facilitating peer learning, and that is why we were pleased to see many donors asking us to share publishing practices in order to improve their own data.
We went back to all the data we looked at and pieces of information which we sampled and verified during data collection, hand-picking examples of various publishing practices. We’re doing this instead of putting forward specific donors as good examples, given that the quality of the data varies across donors’ IATI files and even ‘very good’ performers have room for improvement on some of these points.
But instead of these examples disappearing in the inboxes of donors’ email accounts, we wanted to share them publicly with everyone as we consider these insights relevant and valuable for all donors.
This is the first blog of a two-part series on publishing practices: the first with a focus on getting the basics right and the second on improving project performance-related information as these were two key recommendations from our report.
Getting the basics right: Avoid noisy data
1. The organisation file – a document treasure trove or a frustrating rabbit hole?
The organisation file in the IATI Standard can offer a bunch of relevant data and documents if you want to find out about the broader operating and strategic procedures of a donor. It covers forward-looking total budgets and disaggregated budgets as well as documents related to organisational planning, for example organisation strategy, annual reports or allocation policy – all of which we capture in the Index.
However, we found that some donors’ organisation files include unrelated documents for specific IATI document categories (as IATI calls them). Document category codes are used to identify what kind of information a linked document includes. For example, one indicator assessed in the Index is whether an organisation publishes an annual report. In IATI, the document category reference (i.e. what you would search for in a donor’s IATI file to find the annual report) is B01. The following example is an actual search result of a donor’s organisation file, giving us 206 results.
It is unlikely that all of these documents are annual reports. The latest annual report might be among these 206 documents but we will have to click through them all in order to find out. This is both confusing and time-consuming for data users. Publishers should use the appropriate document category codes and refrain from uploading documents unrelated to a document category to prevent users from getting lost in an organisation file rabbit hole.
2. Using document dates and labelling your documents – avoid data user frustration!
Development activities usually span over a few years and multiple pieces of information, for example multiple tenders, contracts or progress reports can be published every year or multiple times in the same year. This is not problematic and often adds to the comprehensiveness of the data. However, when several unlabelled documents are tagged for one category without indicating which is the most recent or relevant one, a user has to open and inspect all tagged documents, trying to find the information that they need. While doing sampling as part of the Index data collection process, we experienced ourselves how confusing and time-consuming this can be.
Since version 2.02, document dates can be published as part of the IATI standard to indicate the publication date of the relevant document. We would recommend using the document date reference as compared to only naming the documents with the given date. But, since document dates are currently not displayed on d-portal (we are pushing for that to change), naming documents with the publication year is still a big help for any data user.
What shouldn’t it look like?
What should it look like?
Getting the basics right: titles and descriptions
As we have outlined in an earlier blog post, we discovered that many donors failed to provide very basic information like titles and descriptions. These are important pieces of information that provide an essential entry point for the data user. If missing or not usable due to using jargon or internal language, a user might have a hard time understanding what a development activity is about, in particular if more detailed documentation is not published either.
Titles
What do we expect?
The title provides a one-line summary of the activity, with any abbreviations or acronyms explained.
For further details on how our Aid Transparency Tracker runs automated tests on titles, please see the Technical Paper.
What shouldn’t it look like?
What should it look like?
Descriptions
What do we expect?
The description of the activity is a descriptive text, longer than the title, explaining what the activity is.
Descriptions must be specific to the individual activity.
IATI offers four different description types. It is optional to include multiple description types. For further details on how our Aid Transparency Tracker runs automated tests on descriptions, please see the Technical Paper.
What shouldn’t it look like?
What should it look like?
Small changes, big benefits
Getting the basics right was one of our main recommendations of the 2018 Index report. In order for information to remain truly transparent and accessible, data has to be structured and comparable. Avoiding noisy data as well as having understandable titles and descriptions are key for this and are essential to allow non-experts to access and use the data. Small changes to the way information is published to IATI can improve both the user-friendliness and the usefulness of one’s data, removing barriers to data use.
Stay tuned for more information on publishing practices regarding performance-related indicators.