I guess the thinking was that this requires an integer upgrade. I was hoping that wouldn’t be the case – or that improvements could be made prior to that.
I don’t see why this would require an integer upgrade. There are no changes to the codelist, only to the descriptions attached to the codes. We had a similar issue with the Aid Type descriptions and the mistake was simply corrected.
I support this idea - just change “post-completion” to “closed” to make it clearer, and to switch the descriptions round, to standardise with the French versions. I think it is clear that the names are the correct way round, and the descriptions the wrong way round, because:
the name of the code in English shows this progression (completion is followed by post-completion)
the name of the post-completion code in French is clearly after completion (fermé follows finalisation)
the numerical ordering is logical (an activity lifecycle should follow 1-2-3-4, not 1-2-4-3)
So this would become:
3 | Completion
Physical activity is complete or the final disbursement has been made, but the activity remains open pending financial sign off or M&E
4 | Closed
Physical activity is complete or the final disbursement has been made.
I also think this clearly falls under the category of “bug fixes” so could be implemented as a minor or decimal change (at least switching the descriptions round).
I totally agree about flipping the descriptions. Descriptions were added in v2.01, and it’s clear that these descriptions included a bug. So the standard mechanism that exists to resolve this is as a bugfix.
On changing names: Important to note that Mark’s proposed name change does not change the meaning at all. It’s just for clarity.
Similarly, if we’re changing names, I wonder if “finalisation” is clearer than “completion”. So:
Happy with this change as well, agree that “Finalisation” is a bit clearer than “Completion”. But also happy to not change the name of code 3 if there are any particular objections to that.
Hi @stevieflow I seem to remember that whilst the codelist could easily be updated to reorder the codes at the next IATI Standard integer update, the issue was actually whether publishers would be happy to retrospectively change all of their existing published data (if required)?
It would therefore be really good to hear the views of publishers on this?
Hi Wendy
If you read the full thread above, you will see that in fact the codes would not have to be re-ordered. The solution only involves flipping 2 descriptions and changing 2 names.
Given this, I don’t see why publishers would have to change their existing published data. The codes do not change at all. Even if some publishers actually publish the names along with the codes and don’t want to replace with the new names, the codes will remain accurate and machines will still be able to read them.
Therefore, I fully agree with Steven to trea this as a bug fix, as we have done in other cases.
Would be great if @IATI-techteam could take this forward – we’ve been having this discussion now for almost 3 years about something that is clearly a bug. It would be great to bring it to a conclusion!
Yes, agree w/ @YohannaLoucheur@markbrough - I do hope we can progress this within the same spirit as the budget definitions - which we agreed was a bug and a hindrance to anyone using the standard right now.
Thank you for the useful discussion and apologies for the delay in responding.
Changing the name and description as proposed here results in a change in meaning of the existing codes and associated names and descriptions.This would be considered a breaking change.
We agree that the order of the codes causes confusion. The only change that can be done as a ‘bug fix’ is amending slightly the names of the existing codes to clarify the meaning (not swapping them):
3- From ‘Completion’ to ‘Closed’- keeping the description as before ‘Physical activity is complete or the final disbursement has been made.’
4- From ‘Post-completion’ to ‘Finalisation’- keeping the description as before ‘Physical activity is complete or the final disbursement has been made, but the activity remains open pending financial sign off or M&E.’
This is incorrect. The codes do not change, only the names OR associated description.
I’m confused by the reasoning here. The names are in fact being flipped - going from “Post-completion” to “Finalisation” - in order to not change the descriptions. Why do we care more about not changing the descriptions than the names? Especially when this patch will further entrench the erroneous order of the codes - 4 and 3 - themselves?
As mentioned above, there was a similar situation in the Aid Type codelist, and the correction was treated as a bug fix. Fixing a mistake, which is what these swaped descriptions are, should not require a standard upgrade.
If anyone arrives fresh to this 38-post mega-thread and is wondering what’s going on, I’d encourage you to read @stevieflow’s original post, which provides a clear summary of the problem, and a proposed solution.
+1 to Yohanna’s comments.
^^ I think this constitutes swapping the ordering of the names. That’s clear when comparing with the French names:
3- Finalisation
4- Fermé
I.e. the exact opposite of the proposed names.
So to summarise the problem: The names and descriptions currently don’t match. There are two ways to solve this: either swap the names, or swap the descriptions. Leaving it as-is isn’t really an option, since there’s clearly a bug here, and this continues to be a source of ambiguity.
I agree with @YohannaLoucheur, @andylolz and @stevieflow, and I understood that we had consensus here. The change we proposed and agreed above is basically to switch the English-language descriptions round. The descriptions were only added in 2.01, and they are clearly in the incorrect order given both the codes and the English names, as well as the French names and descriptions. This is the bug that should be fixed.
Adjusting the names of the codes would make sense as an additional step to improve clarity, and bring them in line with the much clearer French names.
@IATI-techteam, please can you consider proceeding with this proposal as a bug fix, as it appears we have consensus here, and it would be great to bring this issue to a conclusion? It is quite a glaring and confusing error, and this thread is almost three years old now. Many thanks!