Clarify presence rules for contractors and contacts

[bfabio]

This clarifies when maintenance/contractors and maintenance/contacts are expected to be present.

For contractors, we now explicitly say it's mandatory if the type is contract, and must not be present otherwise. This is technically a breaking change, but it's a sensible and consistent interpretation and we can see it as just removing ambiguity.

For contacts, being optional if type is not internal or community was already enforced by publiccode-parser-go, and even the examples in this repo include contacts with type contract, so it's just stating the de facto behavior.

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
publiccode-yml	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 19, 2025 9:55am

[bfabio]

@yaml-9000 minor-change

Minor change, but not really, but then again I don't see it worth of a major version just for this

[yaml-9000]

Thanks for your contribution 🙏

This is now marked as a minor-change proposal to the standard,
this means that old versions of publiccode.yml will still be valid with this change.

Example of minor changes are additions of new keys or making keys optional.

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}

[ruphy]

@bfabio agreed -- I would even say it's a bugfix

[bfabio]

A quick check in the Italian catalog shows that the affected software, those having contractors and a maintenance.type other than contract, amount to 12 out of 473. I think we can go ahead with the change, they'll get notified of it by https://github.com/italia/publiccode-issueopener.

❯ publiccode-api-client -- software --publiccode-yml | jq '.[] | select(.maintenance.type != "contract" and .maintenance.contractors != null) | {contractor: .maintenance.contractors[0].name, type: .maintenance.type, url: .url}'
{
  "contractor": "Leonardo S.p.a.",
  "type": "internal",
  "url": "https://github.com/DGSCU/SistemaUnicoSCU"
}
{
  "contractor": "Unicode srl ",
  "type": "internal",
  "url": "https://github.com/AUSL-ReggioEmilia/Matilde"
}
{
  "contractor": "SPAC Community",
  "type": "internal",
  "url": "https://github.com/RegioneDelVeneto/mypivot.git"
}
{
  "contractor": "SPAC Community",
  "type": "internal",
  "url": "https://github.com/RegioneDelVeneto/mypay.git"
}
{
  "contractor": "Links Management and Technology S.P.A",
  "type": "internal",
  "url": "https://github.com/consiglionazionaledellericerche/STI"
}
{
  "contractor": "smartme.IO",
  "type": "internal",
  "url": "https://github.com/MDSLab/s4t-iotronic-standalone.git"
}
{
  "contractor": "Engineering",
  "type": "community",
  "url": "https://github.com/regione-marche/meetpad-public"
}
{
  "contractor": "smartme.IO",
  "type": "internal",
  "url": "https://github.com/MDSLab/s4t-lightning-rod.git"
}
{
  "contractor": "Corvallis S.p.A.",
  "type": "internal",
  "url": "https://github.com/CittaMetropolitanaVenezia/WebMappVenezia"
}
{
  "contractor": "Link.it",
  "type": "community",
  "url": "https://github.com/link-it/govway"
}
{
  "contractor": "Invisible Farm",
  "type": "internal",
  "url": "https://github.com/atsmilano/Controllo-di-gestione"
}
{
  "contractor": "Link.it",
  "type": "community",
  "url": "https://github.com/link-it/govpay"
}

[valeriocomo]

hi @bfabio. This has been a relevant topic in the last months about the standard and its evolution. As DTD, we discussed about this issue. So, we had the time to develop a proposal.

At the end of this discussion, we propose that both contractors and contacts must be take out of maintenance object. The should become a top-level keys of the standard, as maintenance is at the moment.

[tomootes]

@valeriocomo i agree on this proposal.

The fact that there can only be contractors or contacts seems a bit odd to me as well. There might be contractors and contacts at the same time.

I wonder if it would be useful to add a field role as well to both contractors and contacts? I think it would be nice to know what role a person has, this could be: community manager, product owner, back-end developer, front-end developer. It's valuable to know who to contact for what.

I'll make a discussion for this.

@valeriocomo maybe you can create a different PR for your new proposal? I'd like to know which arguments you guys have for it.

[bfabio]

The fact that there can only be contractors or contacts seems a bit odd to me as well. There might be contractors and contacts at the same time.

@tomootes contacts are always allowed. It means that both contractors and contacts can be included at the same time, this PR clarifies that

@valeriocomo can you please open a new issue or Discussion for your proposal so it can be discussed separately?

[valeriocomo]

@bfabio @tomootes

there's a discussion about this topic here.

[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:21:29 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]

@yaml-9000 vote-end

[yaml-9000]

Vote results

The results of the vote are:

Vote	Members	Votes count	Percentage
👍 Approve	@bzg @dptdgi	2	100.0%
👎 Reject		0	-

Proposal approved 👍

This proposal is now ready to be merged and get released with a new version of the standard.

cc @publiccodeyml/chair @publiccodeyml/maintainers

_Details

First round: unanimity required

The following users voted (includes non-members of the steering committee):

• bzg voted 👍

• dptdgi voted 👍

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