Skip to content

Guiding Principles

Nemo edited this page Feb 9, 2023 · 3 revisions

This document details the guiding principles behind the endoflife.date website. These help us take decisions and ensure consensus on opinionated changes.

Be helpful

The website exists to be useful to the readers, mainly because this information is often hidden behind various clicks. Make sure every product page answers the important questions:

  1. Which versions are supported?
  2. Is my version supported?
  3. Which version am I running?
  4. How long do I have before I have to upgrade?
  5. When is the next release? (if feasible)
  6. What does "supported" mean?

Focus on what's supported

Showing older releases makes it confusing, especially if they are very old releases. Hence, we do not want to link to unsupported releases in the website. The API however, can showcase these - for programmatic uses.

This also means ignoring any development, trunk, rc, nightly releases - we only list releases that are considered as production-ready, or stable.

Consistent tone.

We will often have to rewrite and summarize multiple pages worth of information. Adopt a neutral third-person tone. Remember, this is an unofficial website, and a statement like:

"We make a release roughly every 3 months"

on the product website should be rewritten to something like:

"There is a new minor release approximately every 3 months".

A consistent tone helps keep the content in harmony.

Welcome contributors

Anything that can make things easier for contributors should be welcome. As the project grows, it becomes harder for a small team to track releases across dozens of products, and the easier it is for anyone to make contributions - the better updated the website will be.

Do not be shy in granting contributor access to the repository - do it after a few good contributions.

Automate, but validate

Automated changes are nice, but try to avoid unvalidated changes from being checked in automatically (unless we have high-confidence). If an automation is triggered rarely (such as for major releases of a product) - it might not be necessary.

Always have good URLs

The best URLs are the obvious ones. We support alternate URLs for redirects - use them. As an example, we redirect /golang to /go, so no matter which you type - you reach the right place.

Use primary sources

Do not track content unless we have a first-party link for it. Links from a product page should go out mainly to the official websites, and occasionally to helpful third-party sources. Prefer primary sources wherever possible.

Talk to projects

Anyone can reach out to projects and ask for corrections, or additional information. Be concrete about requests, and link to our recommendations, if relevant.

Clone this wiki locally