Hi Rolf and Sarah
If I could reply jointly ...
To get formalities out of the way first, the standing ‘rules’ for upgrades that the IATI Secretariat and Tech Team must follow were agreed by the IATI Steering Committee in October 2011. (See Annex 1 in this SC document for details).
A number of your comments relate to the overall governance and process involved in conducting upgrades. We welcome these and hope that, continuing the review of the 2.01 process started at the last TAG, we can find a way to make change control more inclusive and purposeful.
If I could limit my response here, though, to comments that either directly or indirectly relate to the current upgrade and the immediate responsibilities of the technical team.
2.02 has come too soon and makes the landscape more complicated for users and developers
I take the point that every upgrade creates challenges for users and developers. You will see that our original mandate was to conduct a decimal upgrade on a quarterly basis. Our thinning out of this schedule (to say one decimal per year and an integer every 3 to 5 years) is recognition of this. The fact remains we do, from time to time, need to improve the standard. Don’t you agree?
Limited involvement in the consultation
We’re open to suggestions as to how to get more people interested. Standards work is not ‘sexy’ and by its nature needs to be fairly dry and pedantic. I would argue that this lack of wider interest is an issue for IATI as a whole, not the current consultation. We send emails about upgrades to the Steering Committee, the TAG and the IATI Notifications list (which includes the SC, TAG and the main contact for each publisher). We also post notifications about the process on the website, on Discuss and on Twitter. We had a good response to the consultation calls we did for 2.01 so are repeating these for 2.02. I would hope that we reach the vast majority of the IATI community through at least one of these channels
We’re not addressing bigger issues
We’re trying to improve reporting of humanitarian activities and results in this upgrade. I think those are fairly big issues.
Vision and strategy
I think there is a long term vision for the development of the standard: making it fit for purpose for all financial and technical resource flows relating to humanitarian aid and development cooperation. Some of this work has started (private sector flows, humanitarian aid, results) and others are in a longer term pipeline (South South Cooperation).
We’re not addressing outreach to new publishers and users, and data quality
These are important issues - and with our limited resources the tech team and Secretariat are attempting to address these – but how can upgrades help? Adding mandatory fields in 2.01 is the kind of thing the standard can do to improve data quality.
It’s too technical and too detailed
That is the nature of this standard. There are different approaches to standards – such as the very user-friendly Humanitarian Exchange Language. I am not sure there would be appetite for the entire standard to be completely engineered into a less technical and less detailed schema.
Insufficient time on guidance
We can always improve our guidance and we welcome more help on this. Guidance in most instances is not tied to upgrades and can be improved at any time (provided that it does not alter the formal meaning of the standard).
We have been talking about results for a long time. There was a very constructive session at the last TAG. And we are currently consulting on how best to improve results reporting. This consultation is ongoing.
New optional elements will become “less optional”
The only way an element can become mandatory is through an integer upgrade in which wide ranging consent is required. It’s a fairly democratic process, I think.