New categories

[alranel]

Let's use this issue for tracking proposals for new categories:

• whistleblowing

[libremente]

I propose:

• library-management-system

For example, see https://github.com/IstitutoCentraleCatalogoUnicoBiblio

[bfabio]

Moved to GitHub Discussions

_Why?

[bfabio]

I think we should make a Proposal PR for library-management-system.

whistleblowing already has one at #97 by @evilaliv3

There's also educational-content from #88

[giosce]

I think that having a fix set of values for drop-downs is a limitation on the adoption of publiccode.
I'm trying to customize it for a US non-profit organization and we need different values for "Scopes".
I think the validity of a publiccode.yml should be that it conforms to a schema, mainly which fields are mandatory and their type.
I have the same problem with other drop-downs list of values.
It doesn't seem too smart to make forks of the project just to add or remove a handful of items in a dropdown.
Practically, in my case, my approach is that I'm calling our Taxonomy API to get the values to populate "Scopes".

[ruphy]

do you have a link to this API? I don't think this list should be dynamic, it would create a real mess during validation. There is a possibility of adding a free text string if needed, either in the core standard or as a national extension. Would you like to make a proposal we can work on?

[bfabio]

Linking to this discussion to keep things related: #135

[giosce]

Sorry to reply late. I joined the slack channel, maybe it's easier to discuss there.
Is there a validation in place (from what I saw so far only on mandatory fields and in a couple of case their length)?
Is there a validation checking for valid values in fields? That seems too strict to allow broad adoption as some organizations categorize their projects differently. For example, I have been in lengthy conversations on having a common Civic Tech Taxonomy. The way to see software projects between a P.A. and open-source Civic Tech is quite different.
If we can't make the editor flexible enough we'll need to make our own version.

[giosce]

This PR shows my approach to have more customizable values for dropdowns. Technically, the approach doesn't break anything of the current architecture, if a different source of values (like an API) is provided, the values will be fetched from there.
italia/publiccode-editor#237

[giosce]

I discussed the problem of different list of values with the Code For America team.
We are really getting to the point where we need to decide whether and how to keep in synch with the "italia" repository.
We really think that if we want this tool to be adopted by many organizations across many countries it needs to be more customizable. Which fields are mandatory, their length (for example long-description) and mainly values to chose from needs to be customizable without changing the main codebase.
A yml validation should validate the structure of the yml, the format of values (multiple vs single, phone number or email, etc), not the actual value.

[ruphy]

hello @giosce , I see two problems here, which I wouldn't mix:

• the standard, which definitely has some limitations and should be improved
• the editor, which enforces the current standard in a way that's not good enough for CfA

I believe that a good editor, in spite of whoever maintains it, needs to always produce a valid publiccode.yml file, according to the standard that we develop here, together. The current change you propose is currently incompatible with the standard, but of course it's a problem with a solution.

I think that your question is related to either choosing new categories (great for a minor version), rendering categories a free field (breaking or minor) or making it optional overall (minor as well). Categories are something we are struggling with since a long time and I think everyone is more than happy to finally tackle the problem.

However, we need to follow a logical direction which allows us to properly communicate the change of version to updates the many tools that currently exist. Thus, can we first work on solving this issue on the standard side? Once it is approved, discussing the opportunities and problems with the other participants we can adjust the editor accordingly.

There's a very lightweight procedure in place to ensure all international stakeholders are aligned, you can read more here: https://github.com/publiccodeyml/publiccode.yml/blob/main/governance/procedure-proposing-changes-and-voting.md