Support tags in endoflife.date

[marcwrobel]

Is your feature request related to a problem? Please describe.

Currently there is not possibility to group products based on some arbitrary criteria on https://endoflife.date/.

There are just categories, but no category pages. And a product can only have one category, so this system is not flexible. What if we want to list products for a particular vendor.

Issues where tags could help : #2221, #2036, #2219, #2220.

Describe the solution you'd like

We could use tags. It will be relatively easy to add and Jekyll has some support for tags.

Describe alternatives you've considered

I also considered we could support multiple categories for a single product, but somehow it does not feel right.

Implementation steps

• define rules for tags: the idea is not to add a random and uncontrolled list of tags on each page. For instance we could allow tags for defining a product vendor (or associated company), tags to group products inside a family (such as windows, linux)...
• define how tags will be integrated in endoflife.date. Should we list tags on product page, on the main page, create a tag page ?
• integrate tags in endoflife.date (after it has been defined of course).
• create a Jekyll Generator for generating the tag pages (there may be a plugin for that ?).

[captn3m0]

1. Primary vendor of the product, if there is one. For vendors with different names, we should have a canonical name.
2. Only create a tag once we have at-least 3 products that it clearly applies to.
3. For hosted-services (category: service), a cloud tag might be helpful? Or does service already imply it?
4. All categories are automatically tags
5. Product sub-categorization perhaps? Such as rdbms/nosql under db?
6. Product family sounds good (linux, bsd, browser, mobile-phone).

I've created a sheet so we can make the change easily and file a combined PR: https://docs.google.com/spreadsheets/d/1imIC64aAYxlVcWSawOJEVz7g523jul1VDOdfLtrNr1A/edit?usp=sharing

[captn3m0]

tags should be singular not plural?

[captn3m0]

Did a first pass on the sheet, feel free to add/delete/update/comment for any suggestions. Once we have a clear idea of our tags, we can perhaps keep a _data/tags.yml file as well to optionally provide a small description for each of the tags that would go on the tag page.

Another feature would be to implement a "related-pages" list based on the tags.

[marcwrobel]

tags should be singular not plural?

It should be plural : https://jekyllrb.com/docs/posts/#tags. Singular can be used, but only for one tag. And in the end it will be much more convenient in the template to always have "tags" and not a mix of both.

[marcwrobel]

feel free to add/delete/update/comment

Will have a look tomorrow.

[captn3m0]

Oops, meant the tags themselves (for eg web-server v/s web-servers)

[marcwrobel]

Oops, meant the tags themselves (for eg web-server v/s web-servers)

I think singular makes more sense. And plural is not always possible (for example for company names).

[captn3m0]

Current Tag Counts from the WIP sheet:

Tag	Count	Note
adobe	1
amazon	1	Could perhaps merge with aws, but these are separate technically
apache	6
apple	6
atlassian	2
aws	1	Could perhaps merge with amazon, but these are separate technically
browser	2
bsd	3
citrix	1
drupal	1	Created as a tag to track drupal and drush together
elastic	4
fortinet	1
go	1	Not sure if I should tag all hashicorp products as go as well?
google	5
hashicorp	4
intel	1	Could be dropped?
java	12
javascript	9
jetbrains	1
kde	1	Should be dropped
kubernetes	2
linux	24
microsoft	13
mobile	1	(Pick one of mobile/mobile-phone)
mobile-phone	3
nutanix	3
nvidia	2
oracle	2
palo-alto-networks	3
php	15
python	5
redhat	1
ruby	3
vmware	5
web-server	5
windows	3

@adriens Are there any tags that you'd like to see? Check the sheet please.

[adriens]

💡 Hmmmm, it pakes me think about a tag that may tell us if :

• It's opensource... or even better
• It's licence (when it makes sens) : MIT, BSD,...

What do you thing about it ?

💡 For licenses, sotring the key would make it possible for third party to create interesting reporting by using The Open Source API

see endpoint output below :

[adriens]

for example

http https://api.opensource.org/license/MIT

[captn3m0]

Using SPDX identifiers should be good enough. But unsure how can we deal with dual licensed projects, or open-core ones.

[marcwrobel]

FYI I already added tag support in #2080.

[marcwrobel]

Looked at the list and at the comments, here are my two cents :

• I fully agree with the rule No tag is better than useless tag.
• I do not agree with the rule Only create a tag once we have at-least 3 products that it clearly applies to though. I find it useful to have a product vendor or product category tag even when there is less than 3 products. I think this rule should be something like Only create a tag if it has the potential to be used by multiple products.
• For hosted-services (category: service), I think a cloud tag is helpful. service is too broad / generic IMHO.
• If all categories are automatically tags, we should either inject it automatically (using something like [layout] Move layout logic to ruby plugin #2226) or add validation (using the validate.py script). And we should also validate that multiple category tags are not used for a single product (using the validate.py script).
• Sub-categorization (such as rdbms nosql for pages with db) might be helpful. But let's wait to see if someone ask for it because he needs it.
• A registry of all the accepted tags may be helpful (like it is done for categories).
• I saw you added the technologies behind some products. It's a good idea if, for instance, the product needs a "runtime" to work (such as PHP for PHPMyAdmin). But if it's just the language used to develop it (such as Go for Hashicorp products) I do not think it adds any value.
• I do not think license make good tags. If this information must be added (Is it the goal of endoflife.date ? Will it be useful ?) it belongs either in its own license key in the frontmatter or directly in the product description.

I think we should start small and wait for feedback from users to add new tags.

[captn3m0]

I like the runtime-lang-only and the validation suggestions. The “atleast-three-rule” should be more of a guidance, to help us avoid spurious tags, and avoid too many tags.

[adriens]

I do not think license make good tags. If this information must be added (Is it the goal of endoflife.date ? Will it be useful ?) it belongs either in its own license key in the frontmatter or directly in the product description.

Indeed. In fact, I had this idea as first I wanted to be able to filter proprietary software vs. Open source one... then found it mode useful to get the license. Behin that it would make it possible to make some datascience... for example discover relationshsips between releases, eols, lts and license.

I think we should start small and wait for feedback from users to add new tags.

Definitiely agree, it's a real mantra 🙏

The “atleast-three-rule” should be more of a guidance, to help us avoid spurious tags, and avoid too many tags.

... would it possible to get somewhere a dictionary of tags publicaly available, within a csv or api ?

[captn3m0]

Instead of using specific licenses as tags, maybe we could have broad license tags to help categorization usecases? Maybe a few of:

• open-core
• source-available
• open-source

[marcwrobel]

Yep, that's a good idea. Think we will need definitions for those, especially for open source.

[marcwrobel]

... would it possible to get somewhere a dictionary of tags publicly available, within a csv or api ?

Don't know about the format yet, but such list will be available.

[marcwrobel]

I wondered, which syntax should we use for tags.

This one :

tags: ["tag1", "tag2"..]

Or this one :

tags:
- "tag1"
- "tag2"
...

I prefer the first one (more compact), but we already use the second one for alternate_urls.

[adriens]

(As a human) I find the following one easier to read:

tags:
- "tag1"
- "tag2"
...

[captn3m0]

I think our automation will anyway rewrite it to the latter. We have a 4-space indentation as per our configuration: https://github.com/endoflife-date/endoflife.date/blob/master/_auto/latest.py#L90

So probably better to go with:

tags:
- "tag1"
- "tag2"

[adriens]

We have a 4-space indentation as per our configuration

😎