Assess taxonomy situation & propose further changes to characterize projects

hernani commented

2026-06-01 12:00:52 +02:00

Member

As just discussed w/ @panayotis & @puer-robustus:

Despite the tags (with an an issue opened on consistency), and the maturity level (introduced, but tagging needed), additional ways to characterize a project (e.g, a Social Media (SM) project) should be given. At least, for the SM TD suggestions already exist in internal CryptPad documents.

I will come up with suggestions (via issues) how to go for this: code can also be added to allow for this. I would, however, be reluctant w/ the actual tagging, unless there's clear agreement.

As just discussed w/ @panayotis & @puer-robustus: Despite the _tags_ (with an an issue opened on consistency), and the _maturity level_ (introduced, but tagging needed), additional ways to characterize a project (e.g, a Social Media (SM) project) should be given. At least, for the SM TD suggestions already exist in internal CryptPad documents. I will come up with suggestions (via issues) how to go for this: code can also be added to allow for this. I would, however, be reluctant w/ the actual tagging, unless there's clear agreement.

hernani self-assigned this

2026-06-01 12:01:24 +02:00

hernani added a new dependency

2026-06-01 12:02:32 +02:00

#26 Check tags currently used

hernani added the due date 2026-06-08

2026-06-01 12:02:58 +02:00

puer-robustus commented

2026-06-01 13:06:30 +02:00

Member

For me the taxonomy of the site should be built around properties on the individual projects. Those "labels" can than be used for the appropriate aggregation (whether that is an interest in a specific category of tools, e.g. working with geo data, or maturity levels, or what not).

This is how I conceptualize the label structure on individual projects:

general labels (i.e. shared across all projects):
- maturity (alpha | beta | stable | discontinued)
- NGI-0 funded (yes | no)
- target audience [multiple selections possible] (end users, sysadmins, developers, etc.)
- category [multiple selections possible] (e.g., Office, Social Media, Messaging, Operating Systems [rather than say Nix OS as we currently have], Video Editing, IoT, Games, etc.)
- user interface: cli only, gui only, cli & gui
- documentation: sparse, full documentation, user platform available (I mean a forum or chat)
- installation: easy (using known paths like app stores, apt-get etc), medium (needs some doing and/or lots of configuration), hard.
- license (optional? developers might need it, end users not so much)
- alternative to as what project can be a replacement for
- software property tags [multiple selections possible] (e.g., self-hostable, ActivityPub, mobile, local, cloud, cross-platform)
tech dossier specific:
- Some tech dossiers might compare projects with respect to specific attributes or properties which are only relevant in the context of the specific dossier, e.g. "identity concept" or "feed composition" in case of social media. Those should live inside the tech dossier and not on the project "page" per se, IMHO.

I think structuring and normalizing the taxonomy this way would reduce the current tag mess with redundant and/or idiosyncratic tags.

For me the taxonomy of the site should be built around properties on the individual projects. Those "labels" can than be used for the appropriate aggregation (whether that is an interest in a specific category of tools, e.g. working with geo data, or maturity levels, or what not). This is how I conceptualize the label structure on individual projects: - general labels (i.e. shared across all projects): - maturity (`alpha | beta | stable | discontinued`) - NGI-0 funded (`yes | no`) - target audience [multiple selections possible] (`end users`, `sysadmins`, `developers`, etc.) - category [multiple selections possible] (e.g., Office, Social Media, Messaging, Operating Systems [rather than say Nix OS as we currently have], Video Editing, IoT, Games, etc.) - user interface: cli only, gui only, cli & gui - documentation: sparse, full documentation, user platform available (I mean a forum or chat) - installation: easy (using known paths like app stores, apt-get etc), medium (needs some doing and/or lots of configuration), hard. - license (optional? developers might need it, end users not so much) - `alternative to` as what project can be a replacement for - software property tags [multiple selections possible] (e.g., `self-hostable`, `ActivityPub`, `mobile`, `local`, `cloud`, `cross-platform`) - tech dossier specific: - Some tech dossiers might compare projects with respect to specific attributes or properties which are only relevant in the context of the specific dossier, e.g. "identity concept" or "feed composition" in case of social media. Those should live inside the tech dossier and not on the project "page" per se, IMHO. I think structuring and normalizing the taxonomy this way would reduce the current tag mess with redundant and/or idiosyncratic tags.

hernani commented

2026-06-02 22:53:48 +02:00

Author

Member

@puer-robustus: Thanks for your suggestions so far, I started to analyse the tags we have in ticket #26 (related to this one) and putting suggestions out there, given the concrete situation I encounter.

I will comment on your other suggestions above, specifically given the status quo (on it).

@puer-robustus: Thanks for your suggestions so far, I started to analyse the tags we have in ticket #26 (related to this one) and putting suggestions out there, given the concrete situation I encounter. I will comment on your other suggestions above, specifically given the status quo (on it).

ijohn commented

2026-06-08 18:47:32 +02:00

Owner

These improvements are fine with me, I have no problem adding them, but it will lead to much more work, when creating a new dossier page. The project maturity doesn't seem to be up to date in the export (#25 (comment)) so I think that deciding the maturity could prove difficult.

These improvements are fine with me, I have no problem adding them, but it will lead to much more work, when creating a new dossier page. The project maturity doesn't seem to be up to date in the export (https://git.ngi-0.eu/tech-dossiers/ngi0-landing/issues/25#issuecomment-142) so I think that deciding the maturity could prove difficult.

hernani removed the due date 2026-06-08

2026-06-09 17:06:29 +02:00

puer-robustus referenced this issue

2026-06-22 10:28:29 +02:00

Who are you button #13

hernani commented

2026-06-22 18:50:17 +02:00

Author

Member

Just to show further efforts which already exist here:

D1.1 NGI CLASSIFICATION AND ASSESSMENT METHODOLOGY: PDF
https://github.com/ecosyste-ms/oss-taxonomy/tree/main/oss-taxonomy
- Quite exhaustive list for audience: https://github.com/ecosyste-ms/oss-taxonomy/tree/main/oss-taxonomy/audience
SMW:
- SemanticMediaWiki has thousands of attributes, universal, community-adapted and domain-specific ones which can be defined.
- Examples:
  - FSF/Categories: https://directory.fsf.org/wiki/Category/All
    - Some categories, keys and/or values might be outdated to this day; but still solid ground.
  - OSM/Categories (also SMW): https://wiki.openstreetmap.org/wiki/Category:Software

Just to show further efforts which already exist here: - **D1.1 NGI CLASSIFICATION AND ASSESSMENT METHODOLOGY**: [PDF](https://ngi.eu/wp-content/uploads/2019/01/HUB4NGI_D1.1_V2.0_Final.pdf) - https://github.com/ecosyste-ms/oss-taxonomy/tree/main/oss-taxonomy - Quite exhaustive list for *audience*: https://github.com/ecosyste-ms/oss-taxonomy/tree/main/oss-taxonomy/audience - SMW: - [SemanticMediaWiki](https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki) has thousands of attributes, universal, community-adapted and domain-specific ones which can be defined. - Examples: - FSF/Categories: https://directory.fsf.org/wiki/Category/All - Some categories, keys and/or values might be outdated to this day; but still solid ground. - OSM/Categories (also SMW): https://wiki.openstreetmap.org/wiki/Category:Software

puer-robustus referenced this issue from ISOC-CH/tech-dossier-project-data

2026-06-22 18:56:05 +02:00

Overview of existing schemas or taxonomies #1

puer-robustus added a new dependency

2026-06-22 18:56:30 +02:00

ISOC-CH/tech-dossier-project-data#1 - Overview of existing schemas or taxonomies

puer-robustus removed a dependency

2026-06-22 18:56:39 +02:00

ISOC-CH/tech-dossier-project-data#1 - Overview of existing schemas or taxonomies

puer-robustus added a new dependency

2026-06-22 18:56:47 +02:00

ISOC-CH/tech-dossier-project-data#1 - Overview of existing schemas or taxonomies