Was this ever resolved?
We have been looking at this issue in some depth to try to resolve it in the easiest way possible. As a result we have been looking at how publishers are currently using these values and most do appear to be using them in the order 1,2,3 or 1,2,4,3 if the project does have post delivery activities. Whilst the numbers are not concurrent as might be preferred it is not necessarily a problem that the status values are not consecutive if it is clear when each value should be used? Therefore we would ultimately prefer to make the descriptions clearer with regard to how and when they should be used?
We did also discuss the possibility of re-ordering the values but that of course could only be done at an integer update of the IATI Standard. It would of course also mean that almost every publisher would have to amend their existing published datasets which needless to say is something we would want to avoid due to the great inconvenience it would cause.
Sorry to revive this thread – I’ve just run into exactly the same issue, and was perplexed by the documentation!
That’s part of the issue… But there’s also the codelist item names. It’s reasonable to assume the status with the English name ‘Post Completion’ comes after ‘Completion’. Similarly, the French name ‘Fermé’ sounds like it comes after ‘Finalisation’. So the names don’t really match the descriptions, either.
In that case, perhaps it would be useful to:
- Change the names of the codelist items to better reflect the descriptions, and
- Consider reordering the codelist items in the documentation? I.e. list item 3 after item 4. Like this:
Thanks for the comments @andylolz and it would be good to know what option publishers and others would prefer. If we were to re-order the codelist (and make the change as part of an integer upgrade) would publishers be happy to amend any existing published data or would the effort required outweigh any benefit?
Thanks @Wendy! I’ve edited my previous comment to make it clearer that I’m after a solution that wouldn’t require an integer upgrade. I’m fast realising that is tricky!
So just to state: I think it’s okay that the codelist codes don’t proceed in numerically ascending order (according to descriptions and usage). For me, the only problem is that the names and descriptions don’t match, so the documentation is ambiguous. If this could somehow be clarified outside of an integer upgrade (e.g. by reordering the codes in the documentation only, or renaming the codes, or even adding an explanatory note in the documentation) then that would be great.
I don’t think this has made its way to list on Standards Day?
Not that I recall, despite having 120-odd items on Bill’s list.
I don’t think this made it to 2.03 - as it was not on the list
Is this still in need of fixing though? In the same way we’re considering the commitments/budget description to be a “bug”?
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.
This would suggest renaming ‘post-completion’ to ‘pre-completion’, leaving the descriptions unchanged.
Well, note that the descriptions weren’t there at 1.0x: http://iatistandard.org/105/codelists/ActivityStatus/
As I mentioned above, “the names and descriptions don’t match, so the documentation is ambiguous.” So as I see it, the options are:
- Change the name (e.g. to pre-completion)
- Change the description(s)
- Add an explanatory note in the documentation
Of those, I’m most hopeful about option 3, given I suspect the other options will likely be viewed by @IATI-techteam as breaking changes.
I have just been reminded of this problem as I closely review (almost) all IATI codelists for translation. Codes 3 & 4 names remain mismatched with their descriptions.
Absolutely! The code names are in the wrong order (whereas the descriptions are in the right order).
In addition, FWIW, I think the French terms are slightly clearer. “Finalisation” implies that the closing process has started, but it doesn’t say that it’s completed. “Fermé” is unambiguously completed, done, over with. Is it worth trying to clarify the English by replacing “Post-completion” with “Closed”?
BTW, in line with the 1.04 upgrade that replaced all names with codes, the actual codelist is 1, 2, 3, 4, 5, 6. Names in various languages are simply attached to the codes; changing a name in one language should not be seen as a change to the standard.
I just noticed that this post has been filed into “3.01 Integer Upgrade Proposals”. I dont think I did that originally (the first post was July 2015!) so wanted to check @IATI-techteam
@stevieflow if you click the pencil next to the date on your original post, the edit history includes topic changes. This one was moved to #standard-management:3-01-integer-upgrade-proposals by @petyakangalova, back in Apr 2017.
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 (
completionis followed by
- the name of the
post-completioncode in French is clearly after
- 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).
No edit or objection, fully support this. Thanks Mark!
Excellent summary, @markbrough!
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: