[Implemented as bug fix] ActivityStatus codes - mixup of descriptions for codes 3 & 4?

@YohannaLoucheur are you in agreement with this, too?

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.

2 Likes

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:

  1. the name of the code in English shows this progression (completion is followed by post-completion)
  2. the name of the post-completion code in French is clearly after completion (fermé follows finalisation)
  3. 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).

Any edits / objections @YohannaLoucheur @stevieflow @andylolz @Herman ?
How do we proceed with this @IATI-techteam ?

2 Likes

No edit or objection, fully support this. Thanks Mark!

2 Likes

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:

  1. Pipeline/identification
  2. Implementation
  3. *Finalisation
  4. *Closed
1 Like

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.

1 Like

@andylolz, @markbrough Like your proposal. Agree that this could be in a decimal upgrade, since the actual codes are left unchanged.

1 Like

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

3 Likes

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.

3 Likes

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!

3 Likes

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.

1 Like

In terms of next steps, then we could create relevant github issues/pull -requests to get this in action ?

@andylolz @markbrough - interested to help?

Certainly happy to help! @IATI-techteam – is there any objection to this approach?

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.

2 Likes