Tech Paper: Revised rules for decimal and integer upgrades

Standard Management Issues for Members Assembly
#1

The current upgrade rules were agreed by the IATI Steering Committee in October 2011 (see Annex here). It was agreed at the Members Assembly meeting in June 2016 that they were in need of revision and that the Technical Team would prepare a proposal and consult on it so that it is ready for approval by the 2017 Members Assembly.

A paper will be prepared which will review governance, content, timing and consultation processes.

Draft paper on revised rules for decimal and integer upgrades is now available here. This document outlines the problem and proposes a number of changes to the page that describes the upgrade process.

This paper (and the proposed specifc changes to the upgrade process) is part of the Agenda for the IATI TAG 2016 Technical Consultation Workshop

:bird: #IATI #TAG2016

Tech Paper: Deprecation of old versions of the standard
Standards Day: Outline Agenda
Our shared understanding of what IATI is, and is not,
#2

Draft paper on revised rules for decimal and integer upgrades is now available here. This document outlines the problem and proposes a number of changes to the page that describes the upgrade process.

#3

I think this is good but I added two proposals to the revised rules document:

  • Firmer deadlines (at the moment each stage is a “minimum duration”) - these deadlines should of course be able to be adjusted if unforeseen challenges arise, in which case the Governing Board could approve changes to the deadlines. But having more reliable deadlines would make it easier to feed into the process as well as to know when changes should / could be made to systems to publish or use the data.
  • Clear set of criteria and process by which proposals would be assessed and accepted / rejected. At the moment this is not very clear. A clear set of criteria and process would make it easier for people to formulate proposals that are more likely to be accepted and lead to higher-quality proposals. It would hopefully also encourage more people to take part in the upgrade process, as they would have a better understanding of how their contributions would help shape the upgrade process.
#4

Agree with @markbrough. In addition to that:

  • The timelines for community input should be longer, since an integer upgrade has potentially large consequences, and only occurs once during two or three years.

  • With regards to the clear set of criteria: change proposals should be assessed against the strategic direction of IATI as defined in the IATI strategy document.

#5

There are three core types of change that could happen at an integer upgrade:

  1. Fixes to incorrect decisions or assumptions from the past (see: making root elements mandatory (slide 90))
  2. General changes akin to a decimal upgrade that are not backwards-compatible (see: making participating-org/@role=”1” mandatory (slide 115))
  3. A full and proper review of the standard with a defined purpose such as simplification or properly integrating changes that were added imperfectly at a decimal (see: discussion in the IATI v3+: Imagining the future together session at the TAG)

The integer upgrade timetable as defined is able to deal with the first two situations (it’s fundamentally an extended version of the decimal proposal plus some Members Assembly approval points). It isn’t, however, able to successfully deal with the third, and fundamentally most important, point.

Integer upgrades are an action that do not and should not occur on a regular basis, and as such should be utilised to improve the Standard in the best way possible. The currently defined piecemeal approach to proposals cannot gain this high-level consistency and vision.

As such, a potential method of rectifying this is that for any integer upgrade that may fall into Category 3 (pretty much any):

  • Move Members Assembly Approval to week -30
  • Add that around the point of Members Assembly Approval, the reason(s) for starting the upgrade process are defined, potentially along with potential visions for the outcome (these should be extractable from Ongoing discussion, and be open for modification as the process continues)
  • From week -26 (if not already occurring on an Ongoing basis), the Tech Team dedicates a couple of persons to work on the development of full and consistent sets of proposals that could satisfy the visions (through use of an informally defined consultation process)
  • The developed proposals are submitted during weeks 1-4 and the process continues as defined (the sets of proposals developed by the Tech Team treated as any other)

This change would allow time for a full review of every part of the Standard to occur, provide room for developing sets of proposals that are fully consistent, and make it clear that integers can be used to make sweeping improvements to the Standard rather than just changes that happen to be backwards-incompatible.

It could alternatively/additionally be seen as noting that, given their other responsibilities, Ongoing may not provide capacity within the Tech Team to work on ensuring that proposals, and so integer upgrades, are the best they could be.

#6

I like this idea since it has the potential to let the vision and strategy of the Members Assembly explicitly define of what needs to be achieved with the next integer upgrade. It may put the Members Assembly more in the drivers seat than it is now, provided that the Members Assembly not only approves but is also actively involved in setting the goals.