-
-
Notifications
You must be signed in to change notification settings - Fork 670
Guiding Principles
This document details the guiding principles behind the endoflife.date website. These help us take decisions and ensure consensus on opinionated changes.
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:
- Which versions are supported?
- Is my version supported?
- Which version am I running?
- How long do I have before I have to upgrade?
- When is the next release? (if feasible)
- What does "supported" mean?
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.
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.
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.
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.
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.
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.
Anyone can reach out to projects and ask for corrections, or additional information. Be concrete about requests, and link to our recommendations, if relevant.