Extend list of valid categories (or make optional)

[annejan]

Oh hi, one of the people mentioned in #216 here.

Our main problem with adopting publiccode.yml lies with the mandatory categories.

The strict list of valid categories is very weird and arbitrary in my opinion.
https://yml.publiccode.tools/categories-list.html

For most of our modules and even complete projects there is no fit at all with this seemingly hodge-podge collection of mostly marketeer driven (again my opinion) categories that are of no use for most software developers and end-users looking for software or code.

[tomootes]

I recognize this problem. Lots of tailormade software doesn't resemble these categories.

The categories seem to derive from big application-type products which solve typical usecases. The organizations I'm trying to onboard normally don't have codebases that fit in this mold.

[bzg]

I'm in favor of removing categories altogether: they are useful in the downstream catalog, not as static data about software projects.

[bfabio]

Yeah, this has come up multiple times and it's a recurring problem.

We're always stuck between:

• keeping the list short and curated, which excludes legit use cases and annoys authors
• making it huge and comprehensive, which turns it into a mess nobody can navigate
• maintaining it manually, which is slow, political, and opaque
• avoiding local categorizations (probably a good call), but ending up with a list that feels disconnected

The list was probably a starting point to have categories in Developers Italia, but the cost lands on whoever writes the publiccode.yml. They have to pick from a set of categories that often don't fit.

Maybe it's time to make categories optional or remove them. If we go that route, it'd be a breaking change, so 1.0 material.

But I keep wondering: are we throwing out the baby with the bathwater?

[jgroenen]

Maybe make it optional and have a core taxonomy (including "other")?

[tomootes]

I'm also in favour of making it optional. I guess in some catalogues it can be helpful.

@bzg can you elaborate on the fact that it is only useful in a downstream catalogue? In that case it's simply useful in some situations right?

[bfabio]

Let's try making them optional and adding other as @jgroenen suggested. PR incoming.