The Erlang/Elixir special interest group (SIG) meets as part of the Erlang Ecosystem Foundation. See the OpenTelemetry community repo for information on this and other language SIGs.
Everyone is welcome to contribute code to opentelemetry-erlang-api
via
GitHub pull requests (PRs).
To create a new PR, fork the project in GitHub and clone the upstream repo:
$ git clone https://github.com/open-telemetry/opentelemetry-erlang-api/
This would put the project in the opentelemetry-erlang-api
directory in
current working directory.
Enter the newly created directory and add your fork as a new remote:
$ git remote add <YOUR_FORK> [email protected]:<YOUR_GITHUB_USERNAME>/opentelemetry-erlang-api
Check out a new branch, make modifications, run tests, and push the branch to your fork:
$ git checkout -b <YOUR_BRANCH_NAME>
# edit files
$ rebar3 ct
$ mix test
$ git add -p
$ git commit
$ git push <YOUR_FORK> <YOUR_BRANCH_NAME>
Open a pull request against the main opentelemetry-erlang-api
repo.
- If the PR is not ready for review, please put
[WIP]
in the title, tag it aswork-in-progress
, or mark it asdraft
. - Make sure CLA is signed and CI is clear.
A PR is considered to be ready to merge when:
- It has received two approvals from Collaborators/Maintainers (at different companies).
- Major feedbacks are resolved.
- It has been open for review for at least one working day. This gives people reasonable time to review.
- Trivial change (typo, cosmetic, doc, etc.) doesn't have to wait for one day.
- Urgent fix can take exception as long as it has been actively communicated.
Any Collaborator/Maintainer can merge the PR once it is ready to merge.
As with other OpenTelemetry clients, opentelemetry-erlang-api follows the opentelemetry-specification.
It's especially valuable to read through the library guidelines.
OpenTelemetry is an evolving specification, one where the desires and use cases are clear, but the method to satisfy those uses cases are not.
As such, Contributions should provide functionality and behavior that conforms to the specification, but the interface and structure is flexible.
It is preferable to have contributions follow the idioms of the language rather than conform to specific API names or argument patterns in the spec.
For a deeper discussion, see: open-telemetry/opentelemetry-specification#165
- Make sure to run
make precommit
- this will find and fix the code formatting.
Approvers:
- Fred Hebert, Postmates
- Greg Mefford, Bleacher Report
- Zach Daniel, Variance
Maintainers:
- Tristan Sloughter, Postmates
- Ilya Khaprov, Kobil Systems GmbH
- Łukasz Jan Niemier, Kobil Systems GmbH
See the community membership document in OpenTelemetry community repo.