Participating Org @type description incorrect about iati-schemas

[andylolz]

+1, good spot.

This bug was introduced as part of the very large set of changes proposed here.

(This spreadsheet is referenced there, and it includes the typo. I guess it was just a copy and paste error.)

In general, rolling lots and lots of changes together like this can result in bugs being introduced into the standard, because it’s very difficult to spot bugs in a very very large set of changes. (It’s exactly the reason why version control systems like git split changes into meaningful commits).

For that reason, I’m in favour of fixing small bugs like this in a piecemeal way. Rolling this into a larger fix increases the likelihood that something else could be missed.

[akmiller01]

I think this is actually an issue in the Schema text: https://github.com/IATI/IATI-Schemas/blob/version-2.03/iati-activities-schema.xsd#L273

Moving this issue there.

[samuele-mattiuzzo]

my thoughts exactly @andylolz we'll have to discuss this internally a bit more before proceeding

[andylolz]

Why has the bug label been removed? I’m pretty sure (as Amy and Samuele agreed) this is a bug.

[andylolz]

I think this is actually an issue in the Schema text: https://github.com/IATI/IATI-Schemas/blob/version-2.03/iati-activities-schema.xsd#L273

Yes – I think that’s exactly right.

If you use git blame to follow the breadcrumbs back, you’ll find this commit and this issue, linking to the spreadsheet containing the error that was mentioned above.

[akmiller01]

I've been trying to standardize the issue labels between our SSOT repository issues over the last couple of weeks. I've used "bug" to indicate a purely technical issue that can be immediately addressed, and "enhancement" to indicate a purely technical new suggested feature. For anything I thought might require some community consultation or perhaps a standard upgrade, I marked it as "standard management."

Given fixing this bug would involve editing the iati-activities-schema.xsd, I thought it wouldn't make sense to make the change without first seeking input. There are also quite a few issues in this repository that involve small typos in the schema, so it might make sense to handle them all together.

I would be interested in your input on what level of community consultation would be appropriate for these type of typo issues.

[andylolz]

I've used "bug" to indicate a purely technical issue that can be immediately addressed, and "enhancement" to indicate a purely technical new suggested feature. For anything I thought might require some community consultation or perhaps a standard upgrade, I marked it as "standard management."

Okay I see. Thanks for explaining – that system sounds good.

I think the previous bug label was used in the context of the upgrade process, which says backwards-compatible bug fixes can happen as part of a patch upgrade to the standard. In the past I think these have happened without community consultation, but I may be misremembering.

Personally I think this instance could probably be resolved without community consultation, but that’s of course a question for your team. Just to add one further amendment, I’d also consider removing “See IATI codelist for values” which is used inconsistently at present.