### Describe Your Changes
Implement spellcheck command:
- add cspell configuration files
- dockerize spellchecking process
- add Makefile targets
This PR adds a standalone `make spellcheck` target to check `docs/*.md` files for spelling
errors. The target process is dockerized to be run in a separate npm environment.
Some `docs/` typo fixes also included.
### Checklist
The following checks are **mandatory**:
- [x] My change adheres [VictoriaMetrics contributing
guidelines](https://docs.victoriametrics.com/contributing/).
---------
Signed-off-by: Arkadii Yakovets <ark@victoriametrics.com>
Signed-off-by: hagen1778 <roman@victoriametrics.com>
Co-authored-by: hagen1778 <roman@victoriametrics.com>
(cherry picked from commit fabf0b928e
)
4 KiB
sort | weight | title | menu | ||||||
---|---|---|---|---|---|---|---|---|---|
500 | 500 | VictoriaMetrics development goals |
|
VictoriaMetrics development goals
Goals
- The main goal - to help users and clients resolving issues with VictoriaMetrics components, so they could use these components in the most efficient way.
- Fixing bugs in the essential functionality of VictoriaMetrics components. Small usability bugs are usually the most annoying, so they must be fixed first.
- Improving docs for VictoriaMetrics components, so users could find answers to their questions via Google or Perplexity without the need to ask these questions at our support channels.
- Simplifying usage of VictoriaMetrics components without breaking backwards compatibility, so users could regularly upgrade to the latest available release and remain happy.
- Improving usability for the existing functionality of VictoriaMetrics components.
- Improving the readability and maintainability of the code base by removing unnecessary abstractions and simplifying the code whenever possible.
- Improving development velocity by optimizing CI/CD tasks, so they take less time.
Non-goals
- 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.
- Breaking links to VictoriaMetrics docs, 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.
- Breaking backwards compatibility in new releases, since users will be unhappy when their working setup breaks after the upgrade.
- 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 of the existing users may become unhappy after the upgrade.
- Adding unnecessary abstractions, since they may worsen project maintainability in the future.
- Implementing all the features users ask. These features should fit the goals of VictoriaMetrics.
Other feature requests must be closed as
won't implement
, with the link to this page. - Merging all the pull requests users submit. These pull requests should fit the goals of VictoriaMetrics.
Other pull requests must be closed as
won't merge
, with the link to this page. - Slowing down CI/CD pipelines with non-essential tasks, since this results in development velocity slowdown.
- Slowing down development velocity by introducing non-essential requirements.
VictoriaMetrics proverbs
-
Small usability fix is better than non-trivial feature. Usability fix 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 functionality 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. 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.