docs(standard): deprecate it.conforme.* keys

[bfabio]

Deprecate it.conforme.* (conforme/lineeGuidaDesign, conforme/modelloInteroperabilita, misureMinimeSicurezza, gdpr) keys, as they refer to obsolete guidelines and/or are about legal compliance which maintainers are unlikely to take responsibility for.
Because of that, in practice they are rarely used.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Project	Deployment	Preview	Comments	Updated (UTC)
publiccode-yml	✅ Ready	Preview	Comment	Aug 12, 2025 4:05pm

[bfabio]

cc @Fupete @Giaimo-DTD

[bfabio]

@yaml-9000 deprecation
@yaml-9000 national dptdgi

[yaml-9000]

This is now marked as a national section change to the Standard and it will require the approval of the Steering Committee member representing the Country (@dptdgi) and at least 50% approve votes.

National section rules

cc @publiccodeyml/chair @publiccodeyml/steering-committee

_{📄 Voting procedure | 📄 Working Group Charter | 🤖 bot commands}

[yaml-9000]

Thanks for your contribution 🙏

This is now marked as a deprecation-change proposal to the standard, this means that this change won't break any compatibility with the old versions of the Standard,
and it will be possibile to make the definitive change 6 months after the deprecation with a new major release.

The Chair will eventually pick up this proposal and start the voting procedure using @yaml-9000 vote-start

cc @publiccodeyml/chair @publiccodeyml/steering-committee

_{📄 Voting procedure | 📄 Working Group Charter | 🤖 bot commands}

[bfabio]

@yaml-9000 vote-start

[yaml-9000]

Voting is now open on this proposal!

If you are a member of the Steering Committee you can now vote!

The polls will stay open for 14 days, until Tue, 14 Oct 2025 07:14:49 GMT.
At the end of that period the Chair (@publiccodeyml/chair) will mark the voting period as over using @yaml-9000 vote-end

Leave a 👍 (thumbs up) on this comment to accept the proposal or a 👎 (thumbs down) to reject it.

cc @publiccodeyml/steering-committee

_{📄 Voting procedure | 📄 Working Group Charter | 🤖 bot commands}

[bfabio]

@dptdgi
as a reminder, since this PR affects the national section (Italy), it cannot be approved unless the Italian representative explicitly votes as clearly stated in the governance procedure.

Silence is formally allowed, but it would be much more constructive to have an explicit position, so the community can understand the rationale.

[dptdgi]

Hello @bfabio,
thanks for the proposal, at the first sight I was convinced, but after some checks I think that your statement:

Because of that, in practice they are rarely used.

does not hold.

I made a quick check on a recent copy of the Italian catalogue (around 420 repos) and here are the normalized counts:

    146 gdpr:no
    229 gdpr:yes
    218 lineeGuidaDesign:no
    134 lineeGuidaDesign:yes
    142 misureMinimeSicurezza:no
    235 misureMinimeSicurezza:yes
    222 modelloInteroperabilita:no
    134 modelloInteroperabilita:yes

So ~380 repos use the keys and hundreds with yes. This is enough for me to keep them.

I agree with you that the meaning of those flags is not so useful, do you think that instead of deprecating them we can think of better replacement (e.g. incorporating versioning, partial support) and offer a migration path?

[bfabio]

@dptdgi thanks for finally taking the time to look into this, but I think you might have missed a few important details about how this actually works.

First, those numbers don't tell the whole story. The old publiccode-editor used to create many of those files didn't show those fields as optional unfortunately, even though they were. People either set them to random 'no' or were forced to add them.

Also, the count is off to me: the Italian catalogue has 479 software entries right now, not 420.

❯ publiccode-api-client software | wc -l
479

Second, the publiccode-parser currently has a bug as well: when serializing, it sets those optional flags to false even when they are unset. This means that any data extracted via the APIs is misleading. That needs fixing and it makes the usage look higher than it really is.

But more importantly, this is exactly what deprecations are for. These fields refer to conformance with models that are now deprecated, they makes no sense for new files and we can't semantically reuse them to mean some later versions of the model. It's precisely the way to later remove or replace those fields to have an upgrade path, since that requires a breaking change in the next major version.

https://github.com/publiccodeyml/publiccode.yml/blob/main/governance/procedure-proposing-changes-and-voting.md#country-specific-sections
Breaking changes can be released at most once every two years, provided the current version of the Standard has been deprecating the relevant feature for at least 6 months.

If we don't remove stuff that needs to go, we're either holding back v1 or worse carrying into it and forcing another breaking change for v2 later.

Also note that deprecating something does not remove it. Deprecated fields continue to work until a new major version, which adopters can choose to upgrade to whenever they want. Please take a look at the documentation and how the deprecation process and Semantic Versioning work in this project.

[dptdgi]

@dptdgi thanks for finally taking the time to look into this, but I think you might have missed a few important details about how this actually works.

First, those numbers don't tell the whole story. The old publiccode-editor used to create many of those files didn't show those fields as optional unfortunately, even though they were. People either set them to random 'no' or were forced to add them.

Thank @bfabio for the detailed explanation, in short is not because they are not used, but because we are not sure they were used correctly.

Also, the count is off to me: the Italian catalogue has 479 software entries right now, not 420.

❯ publiccode-api-client software | wc -l
479

Ok, but the diff is a minor percentage, as far as I know in the Italian catalogue there are repos counted twice and old unreachable repos are not purged and I would exclude 3rd party sources in the count (to focus only in the local use).

Second, the publiccode-parser currently has a bug as well: when serializing, it sets those optional flags to false even when they are unset. This means that any data extracted via the APIs is misleading. That needs fixing and it makes the usage look higher than it really is.

Oh, glad to know, but I did not used the publiccode parser but used the original publiccode.yml from the repos with some yq and sed. I think I run in the opposite problem (I missed some repos due their unavailability and your total count is higher because of that).

But more importantly, this is exactly what deprecations are for. These fields refer to conformance with models that are now deprecated, they makes no sense for new files and we can't semantically reuse them to mean some later versions of the model. It's precisely the way to later remove or replace those fields to have an upgrade path, since that requires a breaking change in the next major version.

https://github.com/publiccodeyml/publiccode.yml/blob/main/governance/procedure-proposing-changes-and-voting.md#country-specific-sections
Breaking changes can be released at most once every two years, provided the current version of the Standard has been deprecating the relevant feature for at least 6 months.

If we don't remove stuff that needs to go, we're either holding back v1 or worse carrying into it and forcing another breaking change for v2 later.

Also note that deprecating something does not remove it. Deprecated fields continue to work until a new major version, which adopters can choose to upgrade to whenever they want. Please take a look at the documentation and how the deprecation process and Semantic Versioning work in this project.

I think that proposing to deprecate the keys, without any proposal on a possible replacement (that does not need to be final) is not looking for a solution but just hiding a problem.

Anyway I will forward the question to my colleagues at DTD to try to reach a consensus for this decision.

[bfabio]

Thank @bfabio for the detailed explanation, in short is not because they are not used, but because we are not sure they were used correctly.

No, the deprecation is because those keys don't make sense anymore for new files because those guidelines are deprecated: for example lineeGuidaDesign: https://docs.italia.it/italia/designers-italia/design-linee-guida-docs/it/stabile/index.html

[dptdgi]

Thank @bfabio for the detailed explanation, in short is not because they are not used, but because we are not sure they were used correctly.

No, the deprecation is because those keys don't make sense anymore for new files because those guidelines are deprecated: for example lineeGuidaDesign: https://docs.italia.it/italia/designers-italia/design-linee-guida-docs/it/stabile/index.html

Ok, for lineeGuidaDesign but others are still valid, like gdpr and misureMinimeSicurezza, not sure about modelloInteroperabilita since the link is broken but the model may be the same.

Deprecating all instead of only broken is another pain point of the proposal.

[dptdgi]

We had a consultation, and we are in favor of the deprecation. For the future we may think of some keys that better specify some form of compliance with external references (being software or regulation).