2024-06-25 16:00:03 +00:00
|
|
|
---
|
|
|
|
|
sort: 500
|
|
|
|
|
weight: 500
|
|
|
|
|
title: VictoriaMetrics goals
|
|
|
|
|
menu:
|
|
|
|
|
docs:
|
|
|
|
|
parent: 'victoriametrics'
|
|
|
|
|
weight: 500
|
|
|
|
|
---
|
|
|
|
|
|
2024-06-26 14:41:13 +00:00
|
|
|
# VictoriaMetrics goals
|
|
|
|
|
|
|
|
|
|
## Goals
|
2024-06-25 16:00:03 +00:00
|
|
|
|
2024-06-26 09:39:26 +00:00
|
|
|
1. The main goal - **to help users and [clients](https://docs.victoriametrics.com/enterprise/) resolving issues with VictoriaMetrics components,
|
|
|
|
|
so they could use these components in the most efficient way**.
|
2024-06-25 16:00:03 +00:00
|
|
|
1. Fixing bugs in the essential functionality of VictoriaMetrics components. Small usability bugs are usually the most annoying,
|
2024-06-26 09:39:26 +00:00
|
|
|
so they **must be fixed first**.
|
2024-06-25 16:00:03 +00:00
|
|
|
1. Improving [docs](https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/docs) for VictoriaMetrics components,
|
|
|
|
|
so users could find answers to their questions via Google or [Perplexity](https://www.perplexity.ai/) without the need
|
|
|
|
|
to ask these questions at our [support channels](https://docs.victoriametrics.com/#community-and-contributions).
|
|
|
|
|
1. Simplifying usage of VictoriaMetrics components without breaking backwards compatibility, so users could regularly
|
|
|
|
|
upgrade to [the latest available release](https://docs.victoriametrics.com/CHANGELOG.html) and remain happy.
|
2024-06-26 12:01:08 +00:00
|
|
|
1. Improving **the essential functionality** of VictoriaMetrics components, which is used by most users.
|
2024-06-25 16:00:03 +00:00
|
|
|
1. Improving the readability and maintainability of the code base by removing unnecessary abstractions and simplifying the code whenever possible.
|
|
|
|
|
1. Improving development velocity by optimizing CI/CD tasks, so they take less time.
|
|
|
|
|
|
2024-06-26 14:41:13 +00:00
|
|
|
## Non-goals
|
2024-06-25 16:00:03 +00:00
|
|
|
|
2024-06-26 09:39:26 +00:00
|
|
|
1. Convincing people to use VictoriaMetrics components when there are better suited solutions exist for their tasks,
|
|
|
|
|
since users will become angry at VictoriaMetrics after they discover better solutions.
|
|
|
|
|
1. Breaking links to [VictoriaMetrics docs](https://docs.victoriametrics.com/), since users will be unhappy seeing 404 page
|
|
|
|
|
or unexpected results after they click some old link somewhere on the Internet or in the internal knowledge base.
|
|
|
|
|
1. Breaking backwards compatibility in new releases, since users will be unhappy when their working setup breaks after the upgrade.
|
|
|
|
|
1. Adding non-trivial features, which require significant changes in the code and the architecture,
|
|
|
|
|
since these features may break the essential functionality of VictoriaMetrics components, so a big share
|
2024-06-25 16:00:03 +00:00
|
|
|
of the existing users may become unhappy after the upgrade.
|
|
|
|
|
1. Adding unnecessary abstractions, since they may worsen project maintainability in the future.
|
2024-06-26 09:39:26 +00:00
|
|
|
1. Implementing all the features users ask. These features should fit [the goals](#goals) of VictoriaMetrics.
|
|
|
|
|
Other feature requests must be closed as `won't implement`, with the link to this page.
|
|
|
|
|
1. Merging all the pull requests users submit. These pull requests should fit [the goals](#goals) of VictoriaMetrics.
|
|
|
|
|
Other pull requests must be closed as `won't merge`, with the link to this page.
|
2024-06-25 16:00:03 +00:00
|
|
|
1. Slowing down CI/CD pipelines with non-essential tasks, since this results in development velocity slowdown.
|
2024-06-26 09:39:26 +00:00
|
|
|
1. Slowing down development velocity by introducing non-essential requirements.
|
2024-06-26 12:01:08 +00:00
|
|
|
|
2024-06-26 14:41:13 +00:00
|
|
|
## VictoriaMetrics proverbs
|
2024-06-26 12:01:08 +00:00
|
|
|
|
|
|
|
|
- **Small usability bugfix is better than non-trivial feature.** Usability bugfix makes happy existing users.
|
|
|
|
|
Non-trivial feature may make happy some new users, while it may make upset a big share of existing users
|
|
|
|
|
if the feature breaks some essential functionaly of VictoriaMetrics components or makes it less efficient.
|
|
|
|
|
|
|
|
|
|
- **Good docs are better than new shiny feature.** Good docs help users discovering new functionality and dealing
|
|
|
|
|
with VictoriaMetrics components in the most efficient way. Nobody uses new shiny feature if it isn't documented properly.
|
|
|
|
|
|
|
|
|
|
- **Happy users are more important than the momentary revenue.** Happy users spread the word about VictoriaMetrics,
|
|
|
|
|
so more people convert to VictoriaMetrics users. Happy users are eager to become happy [customers](https://docs.victoriametrics.com/enterprise/).
|
|
|
|
|
This increases long-term revenue.
|
|
|
|
|
|
|
|
|
|
- **Simple solution is better than smart solution.** Simple solution is easier to setup, operate, debug and troubleshoot than the smart solution.
|
|
|
|
|
This saves users' time, costs and nerve cells.
|
