-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Changes not required] Moving DocumentCategory and GazetteerAgency to Non-Core [v2.03] #230
Conversation
Sorry, I don’t understand… When was this change agreed? Please could you provide a link to the relevant proposal? Thanks |
Hi @andylolz . During the 2.03 upgrade process there was an agreement for a number of codelists to be moved from embedded to non-embedded. See Final technical proposal post and non-embedded codelist tab in the summary table.. This error has only now been spotted that following 2.03 launch the title for I will be adding this to Discuss before deploying the changes and will aim to do so tomorrow morning at the latest. |
Thanks for this explanation, @PetyaKangalova. However, I didn't think this was an error. I thought the final proposal explicitly excluded these two codelists. See this post from Hayden, who was part of the technical team at the time: |
Yes, I had understood that too. |
Hi @stevieflow and @andylolz - you are both correct. It is not a 2.03 error but an error on my side, so apologies for creating the confusion! I have now updated the google sheet to reflect the final agreement for the two codelists during the 2.03 upgrade process and have changed the title of this pull request to Not-required. The two codelist were kept as core because of the format change from version 1 to version 2 of the IATI standard. With the current codelist management process the two codelist should stay as core , meaning that any additions or modifications can only happen at a major upgrade. |
Thanks @PetyaKangalova Only on Friday was I looking at the DocumentCategory codelist and how to change, on this thread on Discuss Alas, it looks like we are bounded by decisions that were made during the implementation of 2.03 |
Thanks for resolving this quickly, @PetyaKangalova. I admit I panicked a bit when I spotted these 6 pull requests, because this is a breaking change, but it wasn’t clear from the pull requests what the schedule was for merging and deploying. I’m pleased to learn that the plan was to add a discuss post before deploying the changes. But it occurs to me that I don’t know what the agreed process is for SSOT-related bugfixes, and I wasn’t able to find any documentation about it on the reference site. It would be good if some process could be publicly documented for exactly this sort of scenario. Recently, some minor copy fixes were made to the schema, but without any notification. It would be handy to have a documented process for bugfixes, in order to manage expectations. Also, I notice the process for making changes to non-embedded codelists has recently changed on the reference site. Previously, it provided a lot of detail, including that there would be a 7 day notification period. It now says changes can be made “at any point in time, subject to applicable notification and/or consultation”. Maybe this is a very minor point, but I think there’s value in ensuring these processes are documented clearly for the benefit of all parties. |
^^ I guess this was just a typo. I think it’s true that additions or modifications to embedded (core) codelists can happen at minor upgrades, too. |
These codelists are no longer part of the Core, moved to Non-Core
To be merged alongside: IATI/IATI-Codelists-NonEmbedded#299