Add a softwareType "standard"

[tomootes]

Hi publiccode.yml fellows,

I was discussing this with @valeriocomo the other day.

I always found it funny and slightly ironic that the publiccode.yml standard itself has no publiccode.yml. Of course a software standard itself probably does not consist of actual code but still i think its important that we'll be able to browse software standards and exchange them in the future.

I think they are important artefacts that should be findable in for example the new european catalog:
https://interoperable-europe.ec.europa.eu/eu-oss-catalogue/solutions/globaleaks

Also we would like to add it to the Dutch catalogue at some point:
https://oss.developer.overheid.nl/repositories

I wonder what you guys think 🙋

[bfabio]

Hey all,

Interesting point, I get where it’s coming from.

That said, I don’t think a publiccode.yml makes sense for a standard:

The spec is really meant for actual software. Fields like softwareType, platforms, features, softwareVersion, license, etc, all assume there’s code behind it. Applying it to a standard feels like a stretch, it’s not really what the format was designed for.

Catalogues like the EU one are meant to help people find usable tools. Specs aren’t tools, and adding them would clutter the experience.

Standards aren’t meant to be reused or deployed: they’re consulted. If you’re "reusing" a standard (as in forking), you’re likely duplicating it, which isn’t ideal.

On the other hand IMO, tooling around the standard (validators, generators) should absolutely include a publiccode.yml. That’s software, and it benefits from cataloguing and reuse. Even tiny stuff in this very org like https://github.com/publiccodeyml/bot.

My 2 cents!

[bzg]

I agree with Fabio and Italo.

I also sympathize with the idea that publiccode.yml should be able to expose what software standards are being used, which needs a separate (and careful) discussion for each standard.

Should publiccode.yml add a field for ISO/IEC 5230? No, because it's not a software standard, it's one for organizations.

Should publiccode.yml use ISO/IEC 18670:2025? Probably as a way to store values in some fields (e.g. pointer to the last stable release commit).

Should publiccode.yml express the fact that commit messages follow v1 of [conventionalcommits] (https://www.conventionalcommits.org)? Yes, in a new field about commit message conventions.

Should publiccode.yml allow to express that the project behind the code adheres to the Standard for Public Code? Probably.

Now, as Johan suggests, it would be nice to be able to better express the relationship between a piece of software and its parent organization. I see two ways: publiccode.yml makes it easy but limited (contractor, fundedBy, etc.) and codemeta makes it a bit more difficult but very flexible (the whole semantic web is at your feet). Again, this requires a dedicated discussion.

Last (but not least?), both publiccode.yml and codemeta conflate software as a product (code) and software as a project. The project goes beyond the code (e.g., CI is part of your project, not your code), and a project is not an organization (a community-driven wiki is part of the project, not the organization). Perhaps this distinction can be overlooked, but sometimes I feel like we're jumping too quickly on the software-organization connection, where it would be nice to have this notion of project in between (especially when it comes to expressing facts about the project's resources that are not a property of the software as a product).

Sorry for the long message, I think this discussion is important!

[tomootes]

@itamair fair point. I do agree that it would widen the scope of the standard. An example of a standard is the NLGov REST API Design Rules: https://gitdocumentatie.logius.nl/publicatie/api/adr/2.0.2/. Which is a technical standard.

[tomootes]

I also like the idea of a field for listing standards that are being used in the project.

@bzg i don't get this point "which needs a separate (and careful) discussion for each standard." > do you think it's preferable to create a list with pre-determined options? I think that would be quite a job when it comes to software standards.

@bzg i think your comments on the difference between a "project" and the ''product (in the sense of code)" make sense. A project probably has team-members/ communication-channels and all that sort of things.

I also like the idea that @jgroenen sketches; creating an ecosystem/set of models that all describe specific pieces or actors in it. When doing so, one of the technical challenges seem to create a unique ID for for example a single "software standard". Having this unique id would be necessary if we were to reference to other pieces in the ecosytem, like a single organizations. This would kind of imply a federated system behind it i suppose? Quite tough matter to brainstorm about in a Github thread ;)

[jgroenen]

"unique ID" could (should?) be a URL, like https://yml.publiccode.tools/

"create a list with pre-determined options": a register can be nice, but can always be created from indexing the url's used in all the publiccode.yml files (and evaluating them)

[tomootes]

@jgroenen hmmm. Maybe a URL is sufficient. I thought the problem could arise with dead URLs after a while.

I like the way of doing it the other way around :) Creating a register, based on the existing standards in publiccode.yml.

[tomootes]

@bzg do you have an opinion on this matter?

[bzg]

Yes, I do! I'm on vacation right now, but I'll try to express it before the end of the week.

[bzg]

@bzg i don't get this point "which needs a separate (and careful) discussion for each standard." > do you think it's preferable to create a list with pre-determined options? I think that would be quite a job when it comes to software standards.

I meant that if publiccode.yml proposes a set of predefined software standards, we should carefully consider which ones are relevant. If software standards are added in optional predefined fields (e.g. apiDesignRules, commitMessageSpec, etc.), then we need to discuss what fields are relevant.

@bzg i think your comments on the difference between a "project" and the ''product (in the sense of code)" make sense. A project probably has team-members/ communication-channels and all that sort of things.

Yes. Typically, the bug tracker belongs to the project, not to the product.

[tomootes]

@bzg i don't get this point "which needs a separate (and careful) discussion for each standard." > do you think it's preferable to create a list with pre-determined options? I think that would be quite a job when it comes to software standards.
I meant that if publiccode.yml proposes a set of predefined software standards, we should carefully consider which ones are relevant. If software standards are added in optional predefined fields (e.g. apiDesignRules, commitMessageSpec, etc.), then we need to discuss what fields are relevant.

Check. I think a list of pre-determined standards would be too much work to maintain though. Also i'm not sure if its desirable if we are the gatekeepers of standards within the OS ecosystem.

@bzg i think your comments on the difference between a "project" and the ''product (in the sense of code)" make sense. A project probably has team-members/ communication-channels and all that sort of things.
Yes. Typically, the bug tracker belongs to the project, not to the product.

Agree!