 |
 |
Thanks. Re: decimal upgrade - can a “bug fix” be done outside of this?
We have had that just recently with the budget/description description text in the schema.
That was discussed by users, resulting in a fix being proposed. This is now being implemented by the @IATI-techteam
Hi All - where are we headed on this?
This codelists continues to cause confusion , in my experience. Can we resolve?
–> all those who’ve commented: @Herman @markbrough @YohannaLoucheur @andylolz @Wendy @siemvaessen @dalepotter + @IATI-techteam
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.
Agree with @YohannaLoucheur – I think we have consensus on the proposed solution above, which doesn’t involve changing codes or publishers changing any data, just clarifying names and descriptions of codes.
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.
In terms of next steps, then we could create relevant github issues/pull -requests to get this in action ?
@andylolz @markbrough - interested to help?
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.
@markbrough and others propose swapping the descriptions. These descriptions were added in v2.01, so this would be a bugfix for that.
Yes, I understood we’d agreed it was a bug fix
Shall we just proceed with this?
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!
With the greatest of respect four people do not create a consensus - even in the relatively closed world of Discuss.
While no one would disagree that this is a mess and needs fixing, I happen to agree - and always have - with @Herman’s comment above:
Agree, the current definitions are confusing. The problem though is i.m.o. not the description, but the naming of the code. Post-completion suggests that this status comes after the completion status. This is not true though. The 'post-completion’ status comes before the completion status.
In other words, rightly or wrongly, code 4 (“Physical activity is complete or the final disbursement has been made, but the activity remains open pending financial sign off or M&E”) was defined to come before code 3.
To change the logical order in the meaning of the codes is a breaking change. This may well be a pedantic judgement and the bug fix may well be a pragmatic solution, but messing with standards is a slippery slope …
This is not true. Post-completion indeed comes after the completion status, and makes sense if you think of having completed the activities of the project. This is in line with the IATI standard, where project activies (rather than other aspects or phases of the project) tend to be the focus.
You and Herman base your opinion on the descriptions that were added in 2.01. However, until 2.01 everyone understood the codes and agreed that 4 came after 3 (even though the wording was a bit weird). In 2.01 descriptions were added, and unfortunately got mixed.
Again, not true. We are asking for a bug fix precisely because there is no change to the actual meaning of the codes, which is determined by their names. Post-completion is indeed, and will remain, after completion (of activities).
Thanks @bill_anderson for explaining @IATI-techteam thinking here. So, just to be clear:
EITHER (A):
OR (B):
By consensus, yes I meant everybody else in this thread has come to the same conclusion (A). I agree that we should not change the standard without good reason, but I think we need to choose between the two options to fix this glaring logical inconsistency soon (again, it has been three years, so we are hardly being impatient or knee-jerk here).
Or ©
The codes are not wrong, but the names are wrong.
The descriptions (definitions) were, in my recollection, the original intended definition.
In my view Code 3 = Closed and Code 4 = Finalisation is a valid bug-fix.
I wasn’t aware of any knees jerking. Should I have been??
Strangely - I can’t see this addition of the ActivityStatus in the 2.01 changelog, nor the original proposals.
There is an indication that this code list might be modified in the color-coded table view for 2.01, but I can’t see where the text is derived from.
At GitHub, we can see that the all changes on this list were undertaken in 2013 & 14.
NB: I’m not trying to “blame” anyone here, but find it interesting in that we can’t pinpoint the exact source of the issue we’re discussing - this is also very important for standards!
Come on Bill. Changing the order of the codes clearly changes their meaning. And for newcomers to IATI, the idea that 4 comes before 3 will only add more confusion.
Do you have a source for this? Because I cannot find the current descriptions in any of the original consultation documents, whereas the codes and names have remained the same since 1.01. @stevieflow, the first time the descriptions appear is in the 2.01 upgrade process, right at the end in iteration 3, so it is not surprising that there was a mistake introduced here (below screenshot is from the linked Google Doc, clearly showing the descriptions did not exist before).
In which case, changing the English-language descriptions (introduced only at 2.01) would clearly also be a valid bug-fix, as it does not involve both re-ordering the codes in an illogical way (so that 4 comes before 3) and changing the English and French names.
So how do we move this forward as a bugfix? What sort of signoff do we need? What’s the protocol here?
Is there some documentation of process that you can refer us to, @bill_anderson?
