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

Standard Management 3.0.0 Major Upgrade Proposals
#23

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
#24

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

2 Likes
#25

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
#26

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
#27

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

1 Like
#28

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
#29

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

#30

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?

#31

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
#32

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
#33

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
#34

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

@andylolz @markbrough - interested to help?

#35

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

#36

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.’

#37

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
#38

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.

2 Likes
#39

Yes, I understood we’d agreed it was a bug fix

Shall we just proceed with this?

1 Like
#40

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!

#41

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 …

#42

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).