TAG session on reviewing the need for a next minor or major IATI standard upgrade

[IATI-techteam (IATI Technical Team)]

At the TAG 2018, we want to review the community need for a next IATI Standard upgrade. The IATI technical team will run a short session that will focus on the appetite for a next upgrade (minor or major) and discuss the potential timeline if there is a need for one.

Before we get to the TAG we want participants to be aware of outstanding minor and major upgrade proposals, and to have a discussion about whether or not they are still relevant. Please refer to all proposals listed below. If you think there are proposals we have missed out, please add a link to the relevant Discuss post on this thread.

Please note that at this year’s TAG there won’t be a full IATI standards day and the TAG will not be a place to raise new proposals. This can be done at any time via the normal process on IATI Discuss. We want to review the appetite for an upgrade given the current state of play.

Outstanding minor upgrade changes:

• Exchange rate options (Needs further consultation and alignment with the open contracting community before being taken forward)

• Publishing Application (Requires further discussion about whether it’s needed and why)

• Adding links to related OCDS contracts (Agreed that more work was needed to get this right)

• Results – recognising partner contributions (Need to gain more experience and use cases first)

• Outgoing Commitment - conflicting description & use? (Need more consensus and worked examples)

Outstanding major upgrade changes:

Proposals from the IATI community:

• Fix Activity Status Mix Up (agreement reached, but solution changes the meaning of the code and is therefore not backward compatible)

• Add a new transaction type (no consensus and needs further discussion)

• Add an indicator schema to the IATI Standard (needs discussion)

• Deprecate: location/coordinates elements; legacy data element; organisation type ‘Accountable’. (agreement reached)

• Make mandatory: elements ‘iati-activities’ and ‘iati-organisations’ (consensus); attribute @generated-datetime (not discussed); @value-date

  • Need a major upgrade to include new rules

Creation of rules following previous minor upgrade proposals:

• There are multiple occasions where rules need to be created. This is where ‘shoulds’ have been added as part of previous decimal upgrades, with the agreement they would become ‘musts’ at version 3.0.0.

Technical changes to ‘fix’ the standard:

• Contradictions within the schema: There are number of rules and guidelines within the schema which contradict each other. E.g.

  • For a <sector> at activity level both are true: “Each vocabulary’s percentages should add up to 100%” compared with, “All reported sectors from the same vocabulary must add up to 100%”.

• There are a number of places in the standard, in which documentation can be made consistent. This does not change the meaning of the Standard, but will make it easier to use for publishers, data users and tool providers.

Note: The IATI tech team will separately run a workshop on how to engage in a possible next upgrade. IATI has a new upgrade process, which requires changes to the standard to be suggested in non-technical language and to be presented with use cases. We want to test how this works in practice, and help attendees gain confidence in writing proposals.

[amys (Amy Silcock)]

@markbrough and @YohannaLoucheur you should now be able to comment. I’ve moved the post to another category, as the previous one was closed for public comments. My apologies for not realising.

[YohannaLoucheur]

Thank you @amys for fixing the post, and to the Techteam for sharing information on the very important TAG session on the next minor or major IATI standard upgrade.

As mentioned in the related post, Canada disagrees with the inclusion of the Activity Status mix-up issue in the “Outstanding major upgrade changes”. Fixing this mix-up does not require a major upgrade (or a minor one for that matter), as has been discussed at lenght already.

It should be removed from the upgrade list, and clear timelines provided to fix it already.

Thanks

[markbrough]

Unsurprisingly (given the discussion on that thread) I agree with @YohannaLoucheur on ActivityStatus. I think we are quite clearly talking about a bug fix here, and it shouldn’t need an integer upgrade to fix this kind of mistake. It is a little unfortunate that it’s been over three years since this inconsistency was first pointed out – this suggests there is something more generally wrong with the process around handling these kind of issues. It also means that those of us implementing tools that use IATI data have to label these codes differently from the “official” codes to avoid confusing our own users (or stick with confusing and logically inconsistent labelling).

In general, regarding integer upgrades: I think the possible benefits of making changes to the Standard should be balanced against the costs. I don’t think any of the changes identified above under “major upgrade changes” above are particularly important or urgent – implying that an integer upgrade would have limited benefits – but quite high costs.

Integer upgrades make using the data much harder (even if undertaken under the banner of “simplification”) because it means you have to:

1. go back and change existing software – which often requires more TA and a fresh round of procurement, i.e. money and contracts – and
2. support another version of the Standard.

At this point, I really think we should be focusing our efforts on making sure it is easier to use the data, rather than forcing the rather unsatisfyingly limited number of systems that are using the data to make complicated or costly changes just to provide continuity of service. Accordingly, I am very much against a new integer upgrade.

[YohannaLoucheur]

Please add to the outstanding minor upgrade changes:

Addition of the SDG codelists to the tag element in order to align with the WP-STAT decision (per this post )

[IATI-techteam (IATI Technical Team)]

@YohannaLoucheur Adding a new TagVocabularies to incorporate SDG goals, targets and sectors does not require a minor upgrade. TagVocabulary is a non-embedded codelist which means additions can happen at anytime by adding a proposal in this section.

I agree that this is a relevant discussion to be had at the TAG to talk about the most suitable place for publishing SDG data- some of those discussions can take place during one of theSDG workshops at the TAG.

[YohannaLoucheur]

Thank you, will add the proposal then.

[bill_anderson]

In the interests of peace and progress the Tech Team is happy to treat the Activity Status codes issue as a bug fix. We will slot this into the job queue.

(For the record, we still disagree…)

[andylolz (Andy Lulham)]

Okay excellent – great to get this resolved!

I’ve opened a github issue and sent all the relevant pull requests.

[reidmporter (Reid Porter)]

I am neither arguing for nor against it, but should @amys’s Future use of Hierarchies proposal be included in the list as well?

[siemvaessen]

Deprecate: location/coordinates elements; legacy data element; organisation type ‘Accountable’. (agreement reached)

What is the rational of removing location/coordinates elements and when was agreement reached on this? Any community paper trail on this? I’d vote against it.

This defies the concept of location and would render location incomplete (“global to local”). There are use cases around the actual use of location/coordinates elements even outside of the IATI realm where analysis and comparison is done combined with other data sets… Perhaps misreading, but this actually proposes to get rid of the element location/coordinates elements right?

[bill_anderson]

Replaced in v1.04 with location/point/pos

http://reference.iatistandard.org/203/activity-standard/iati-activities/iati-activity/location/point/pos/

[siemvaessen]

n/coordinates elements;

Thanks for reminding me.

[andylolz (Andy Lulham)]

• Make mandatory: elements ‘iati-activities’ and ‘iati-organisations’ (consensus); attribute @generated-datetime (not discussed); @value-date

I’m pretty sure @value-date is already required. I’m afraid I’m not sure exactly when that was changed, though. In any case, I think this proposal can be marked as done / closed.