Update Location Activity Status and Improve description

[Jo-Schie]

Our latino team gave us the feedback about the column "location activity status.

1) They say it would be good to have another category for "Location Activity Status". It was suggested to have a "in tender process" or similar to differentiate.

2) Also it was discussed that the differentiation between "implementation" and "finalization" is somehow blurry. where do we start to talk about "finalization". Do we really need this attribute?

3) it would be good to have a clearer description of the statusses in general in our documentation so that people use it consistently. The documentation so far is not giving clear instructions.

Happy to hear your thoughts @Maja4Dev and @fretchen

[fretchen]

Hi,

I thnk that I understand the need and reasoning. However, we currently follow the official IATI standard for the location activity status. This is substantially less word then "forking" it torwards our own lists etc. The divergence on the location types is an example of how much work it creates to diverge I think that it would be very advisable to reduce those divergences to a minimum. So I think that the following process go be more effective:

• We should ask IATI directly for this update. They are active on github here (I think).
• If it is clear what is the IATI position we should reconsider if we really need to fork it for ourselves....

This only answers request 1. and 2.

I think that we can "easily" fix the 3. request once we have a suggestion for what be a more precise description.

[Maja4Dev]

Dear All,I fully agree with Fred.I also can explain the status: in finalization starts with the AK= final review/inspection and ends once the guarantee period has expired. Then it is "closed".I would only include another activity status, if the standard was changed. But I would also advise agaimst this, since this would substantially increase the need for updating the data.Kind regards Maja--Gesendet mit der WEB.DE Mail AppAm 24.07.24, 14:05 schrieb fretchen @.***>:

Hi, I thnk that I understand the need and reasoning. However, we currently follow the official IATI standard for the location activity status. This is substantially less word then "forking" it torwards our own lists etc. The divergence on the location types is an example of how much work it creates to diverge I think that it would be very advisable to reduce those divergences to a minimum. So I think that the following process go be more effective:

We should ask IATI directly for this update. They are active on github here (I think). If it is clear what is the IATI position we should reconsider if we really need to fork it for ourselves....

This only answers request 1. and 2. I think that we can "easily" fix the 3. request once we have a suggestion for what be a more precise description. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[Jo-Schie]

Dear both, I think we need, at some point in time, to have a detailled discussion on this topic. I have the constant feeling, that we are blocking the adaptation of this standard to our own operational needs. We tell a lot of people with great ideas that we cannot change this data model... and what is the real reason here?

Reporting to IATI is only one out of many potential applications for using location information. I think IATI is a great model to get started but things are developing much further and frequently new needs appear when we exchange with those people that should actually collect and use location data. Our operational departments need information for many many purposes and always when the come with new suggestion I should tell them: no wait I need to talk to the IATI secretariat first and only if they approve then wen can change something to our data model?

Don't get me wrong. I think it is good to have a common standard, I think it is good to use existing standards (where possible) and I think it is good to not change the standard too quickly. Nevertheless, I think it should be a standard data model that responds to a broader range of operational needs and I fear that we will always run into the situation that they are conflicting with the IATI standard. So we really need to come to a conclusion here and I will setup a meeting for that.

Nevertheless I will keep this ticket open and I would urge @Maja4Dev to update to documentation as soon as you have some time to better explain the activity statusses.

[Maja4Dev]

Dear Johannes, I dont share your feeling. I explained the logic to the respective colleagues in the last CoP and they were all in full agreement to the logic I had presented.

They also did not want to create a general activity status category "in tendering" and were happy to use the "additional activity description category" for their objective.

I however agree, that this logic needs to be written down.

I propose to add the following to the technical notes:

The "pipeline/identification" phase includes tendering and ends with the signing of the implementation contract regarding the main activity at the respective location. The "implementation" phase starts with the signing of the implementation contract and ends with the completion of the main activity at the location. The "finalisation" phase starts after the completion of the main activity at the location (= start of guarantee period) during which the final review usually takes place, the location is "closed" after the end of the guarantee period or final inspection (if there is no guarantee period).

Do we also need to explain "suspended" and "cancelled"? To me, these seem self-explanatory.

[fretchen]

Hi,

I continue to think that it is perfectly reasonable to evaluate if we should add the "in tender process" and add it when it is considered necessary. However, it would seem that another question was brought up, namely how to handle such changes (similiar questions arise for proposals in #70 I think). A possible way forward:

Semver

This semver is the usual way of numbering releases. The summary is:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

Which means in our case:

• If we decide to add the "in tender process" to the model I do not personally think that it would break compatibility with other templates as it simply adds a choice. Then, we simply have to document that this choice is now allowed and it can become part of the new version 1.X.X . Nothing really problematic about it except that we break compatibility with IATI (which might not be necessary).
• If we somehow end up deciding that finalization should not be used anymore, we would break compatibility with previous version and have to increase the number towards 2.X.X. This kind of changes is a major pain and I would make such major version changes not more often than absolutely necessary.

[Jo-Schie]

@fretchen: Thanks for the clarification.! The semver numbering seems to be a good model for us and I would vote to follow this standard in the future. I agree with you, that for the proposed changes there is no issue with downwards compatibility. Btw: Same is true from my perspective for the extended location types.

As to the question of being compatible with IATI: From my perspective we already broke that "compatiblity" when we introduced new project location types ... so where is the point? More importantly, in our current work we use location data for lots of different purposes but not one single person uses it for IATI reporting. Frankly, I also doubt that we ever will, because this would require us to have financial data on all project locations and a tremendous level of detail and spatial disaggregation. To my knowledge, the IATI secreteriat itself works with aggregated numbers on the country level and there is no regulation or even discussion between the OECD countries to report to IATI in a spatially disaggregated manner.

Don't get me wrong, the IATI standard still is an excellent starting point and helps us to classify our project activities in a standardized manner, but I do not see why we should retain ourselves from further developing the model and adapt it to our operational needs.