github-mirrors/VictoriaMetrics
1
0
Fork 0
mirror of https://github.com/VictoriaMetrics/VictoriaMetrics.git synced 2024-11-21 14:44:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
VictoriaMetrics/docs/CONTRIBUTING.md
Aliaksandr Valialkin a402847eb6
Move CONTRIBUTING.md to docs/ 
It is better from visibility PoV if the CONTRIBUTING.md file is visible at https://docs.victoriametrics.com/contributing/ .
This page can be indexed by search engines and searched by our users later.
It is also easier to provide a link to this page now comparing to the old link, which is much harder to remember:
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/CONTRIBUTING.md

While at it, syncrhonize docs/CONTRIBUTING.md with .github/PULL_REQUEST_TEMPLATE/pull_request_template.md ,
so they do not contain duplicate information, which can be outdated over time. Now all the relevant information
is located at docs/CONTRIBUTING.md, while .github/PULL_REQUEST_TEMPLATE/pull_request_template.md refers this doc.

This is a follow-up for c006db1798

Updates https://github.com/VictoriaMetrics/VictoriaMetrics/pull/6040
2024-04-20 23:11:22 +02:00

6.2 KiB
Raw Blame History

sort weight title menu aliases
400 400 Contributing to VictoriaMetrics
docs
parent weight
victoriametrics 400
/CONTRIBUTING.html

Contributing to VictoriaMetrics

If you like VictoriaMetrics and want to contribute, then it would be great:

  • Joining VictoriaMetrics community Slack (Slack inviter and Slack channel) and helping other community members there.
  • Filing issues, feature requests and questions at VictoriaMetrics GitHub.
  • Improving VictoriaMetrics docs. The docs' sources are located here.
  • Spreading the word about VictoriaMetrics via various channels:
    • conference talks
    • blogposts, articles and case studies
    • comments at Hacker News, Twitter, LinkedIn, Reddit, Facebook, etc.
    • experience sharing with colleagues.
  • Convincing your management to sign Enterprise contract with VictoriaMetrics.

We are open to third-party pull requests provided they follow KISS design principle:

  • Prefer simple code and architecture.
  • Avoid complex abstractions.
  • Avoid magic code and fancy algorithms.
  • Apply optimizations, which make the code harder to understand, only if profiling shows significant improvements in performance and scalability or significant reduction in RAM usage. Profiling must be performed on Go benchmarks and on production workload.
  • Avoid big external dependencies.
  • Minimize the number of moving parts in the distributed system.
  • Avoid automated decisions, which may hurt cluster availability, consistency, performance or debuggability.

Adhering KISS principle simplifies the resulting code and architecture, so it can be reviewed, understood and debugged by wider audience.

Before sending a pull request to VictoriaMetrics repository please check the following:

  • The pull request contains clear description of the change, with links to the related GitHub issues and docs, if needed.
  • Commit messages contain concise yet clear descriptions. Include links to related GitHub issues in commit messages, if such issues exist.
  • All the commits are signed and include Signed-off-by line. Use git commit -s to include Signed-off-by your commits. See this doc about how to sign your commits.
  • Tests are passing locally. Use make test to run all tests locally.
  • Linting is passing locally. Use make check-all to run all linters locally.
  • If the change fixes some bug, it would be great to cover it by tests (if it isn't covered yet by existsing tests).
  • If the change improves pefromance or reduces resource usage, then it would be great to add benchmarks and mention benchmark results before and after the change in the description to the pull request.

Further checks are optional for External Contributions:

  • The change is described in clear user-readable form at docs/CHANGELOG.md, since it is read by VictoriaMetrics users who may not know implementation details of VictoriaMetrics products. The change description must clearly answer the following questions:

    • What does this change do?
    • Why this change is needed? The change description must link to related GitHub issues and the related docs, if any.

    Tips for writing a good changelog message:

    • Write a human-readable changelog message that describes the problem and the solution.
    • Use specific text, which can be googled by users interested in the change, such as an error message, metric name, command-line flag name, etc.
    • Include a link to the issue or pull request in your changelog message.
    • Provide a link to the relevant documentation for any new features you add or modify.

  • After your pull request is merged, please add a message to the issue with instructions for how to test the fix or try the feature you added before the new release. Here is an example.

  • Do not close the original issue before the change is released. Please note, in some cases Github can automatically closes the issue once PR is merged. Re-open the issue in such case.

  • If the change introduces a new feature, this feature must be documented in user-readable form at the appropriate parts of VictoriaMetrics docs. The docs' sources are located in the docs folder.

Examples of good changelog messages:

  1. FEATURE: vmagent: add support for VictoriaMetrics remote write protocol when sending / receiving data to / from Kafka. This protocol allows saving egress network bandwidth costs when sending data from vmagent to Kafka located in another datacenter or availability zone. See this feature request.

  2. BUGFIX: stream aggregation: suppress series after dedup error message in logs when -remoteWrite.streamAggr.dedupInterval command-line flag is set at vmagent or when -streamAggr.dedupInterval command-line flag is set at single-node VictoriaMetrics.