Today I spent some time going over the proposals for version 2.02. And I’m a bit ambivalent about it:
On the one hand it’s good to fix a few things, and keep the standard moving. People run into problems and come up with fixes for them.
On the other hand, there seems to be limited involvement in the consultation. With risks: we’re solving some problems for a few people, but we’re not addressing the bigger issues of outreach to new publishers and users, and data quality.
- It’s hard for anyone who is “just doing IATI” to understand the proposals or offer meaningful feedback: it’s too technical and too detailed.
- It doesn’t offer time or space for more profound technical and guidance issues in the standard. Recommendations on how to fill certain fields (e.g. flow type) differ depending on who you ask.
- It makes the landscape more complicated for users and developers. AidStream has only just been updated for 2.01, the CSV convertor is behind, and Mark built a script to downgrade 2.01 files to 1.05 in order to keep working with tools.
I think it will be hard to keep mixing the use cases, outreach and technical modifications. We’re missing things, for instance in results:
- A lot of the NGOs that we work with want to publish qualitative results. It’s still a use case to be explored, so there are no technical proposals, and so it’s not in 2.02.
- At the same time, there are fixes to make the quantitative results more usable, but without a long-term vision of where it should lead to.
- Examples around results are usually for outputs, whereas many NGOs (and donors) want to manage on outcomes and impacts, or different types of theory of change, especially in lobby and advocacy.
There is a real risk the extra “optional” elements in the standard quickly turn into “less optional” requirements from donors. NGOs that didn’t embrace IATI because of its potential are looking at these changes as “extra burden”.
So… who are we actually making happy with the current proposals for version 2.02?
- Should we have an active “experimental” branch for opt-in front-runners to experiment with extensions to the standard before they become official part of the standard?
- Can we have an upgrade process where we first have a round of looking at use cases (added value) and then have a round of (very technical) proposals to adapt the standard? A stepping stone from strategy and vision to technical changes, and a way to build guidance how to use the standard as part of the process.
I hope it’s a constructive contribution.