A couple of questions

[johanlinaker]

Hi all!

We've started to look into the publiccode.yml standard for a Swedish catalouge and have run into a couple of initial questions.

• releaseDate can get outdated very quickly - why is this as a mandatory field?
• softwareType - what would be the appropriate field for projects with both backend and client? standalone/other?
• shortDescription/shortDescription - the 150 max and 500 min char limits are rather limiting, why not have this as recommendations and have the catalouges cut the length is needed?
• Contact field is a sensitive area. I expect not many would feel comfortable to have their names here. What's the rationale and experience on this? Don't see how this can be a mandatory field.
• usedBy - we see alot of value in listing PAs in Sweden using an OSS project. What are your thoughts on having usedBy per nation, e.g., swe/usedBy as with descriptions and features?

Br, Johan

[ruphy]

releaseDate can get outdated very quickly - why is this as a mandatory field?

The rationale behind is that it helps to assess how alive/maintained is a certain software and it's not an additional burden as is supposed to be updated in tandem with every release (i.e. bump the latest release and mark the date of when it happens).
I understand that it might get outdated but I tend to believe the real solution should be automation in the toolchain here (e.g. through actions/scripts that can parse git tags, ...). Having solely a version number does not speak to most people.

softwareType - what would be the appropriate field for projects with both backend and client? standalone/other?

it's about the client interface (answers the question: what platform do I need to use to use it?) - but if it's not clear from the doc we should totally improve it.

shortDescription/shortDescription - the 150 max and 500 min char limits are rather limiting, why not have this as recommendations and have the catalogues cut the length is needed?

Because it's intended to be a brief description you can use in the UI as a subheading. This will substantially differ from what a simple cut could offer, in terms of marketing and density of information. I do not believe it is limiting as there's the longDescription field which on the contrary allows vendors to be as detailed as they wish.

Contact field is a sensitive area. I expect not many would feel comfortable to have their names here. What's the rationale and experience on this? Don't see how this can be a mandatory field.

It has been very important for the first use cases to have a contact which is not a catch-all and can act as a responsible point of contact for security reasons or for contributions. I do not believe a person's name is particularly sensitive (as opposed to e.g. their phone number), and it will be listed in the majority of cases in the code repository anyways. However, I don't claim to speak for the world and am open to contradicting empirical evidence.
So far, we have not had a case yet where this was a problem (as long as e-mail or phone don't need to be private).

usedBy - we see alot of value in listing PAs in Sweden using an OSS project. What are your thoughts on having usedBy per nation, e.g., swe/usedBy as with descriptions and features?

+1, this field in retrospect was a big mistake and we should fix it. it's unmaintainable and does not offer any real indication on who is using what. It's my number one pain I'd like to address in the 1.0

[johanlinaker]

Thanks for the clarifications! I do see the value with the contact field but would have preferred it being optional for integrity reasons (which of course may not always be an issue). I will stick to "NoName" for cases where this may be an issue (which I guess will relate mostly to community-developed projects).

Concerning the descriptions, again, I see your point, but would personally have preferred the length min/max as recommendations rather than defined, especially for description/[lang]/longDescription with the min length of 500 chars. For example, if a 400 char description is considered enough, why force the author to put in 100 char extra?

[bfabio]

Hi @johanlinaker

releaseDate can get outdated very quickly - why is this as a mandatory field?

just checked and it's required only if softwareVersion is present, which is even trickier. We should be more explicit and in general avoid fields that are conditionally mandatory, something like:

release:
   version: '1.0'
   date: '2021-12-31'

release being the optional key. Unfortunately this would be a breaking change.

[johanlinaker]

Thanks, that helps alot!

[tomootes]

@bfabio im currently working on the example publiccode.yml for https://developer.overheid.nl. Our goal is making the process of writing the yml as smooth as possible. Thus we would like to consider properties that create confusion during the process.

I'm running into the same dilemma. We are not using SEMVER and don't use version tags when releasing. In this case it's not fitting to use the releaseDate property.

Maybe a solution for now can be making the property optional?

[bfabio]

@tomootes yeah, that's probably the right solution. Bumping the version and the date is annoying, even if automated.

[libremente]

releaseDate can get outdated very quickly - why is this as a mandatory field?

Hey @johanlinaker, just a quick side note: @astagi developed a GH Action to help keeping some fields updated, one of which is the software version: https://github.com/italia/publiccode-softwareversion-check-action
This is just to say that many things can be quickly scripted/automated in order to keep the publiccode.yml updated

[ruphy]

Adding this here for reference Amsterdam/signals-frontend#1742 (comment)