The Python special interest group (SIG) meets regularly. See the OpenTelemetry community repo for information on this and other language SIGs.
See the public meeting notes for a summary description of past meetings. To request edit access, join the meeting or get in touch on Gitter.
See to the community membership document on how to become a Member, Approver and Maintainer.
This is the main repo for OpenTelemetry Python. Nevertheless, there are other repos that are related to this project. Please take a look at this list first, your contributions may belong in one of these repos better:
- OpenTelemetry Contrib: Instrumentations for third-party
libraries and frameworks. There is an ongoing effort to migrate into the Opentelemetry Contrib repo some of the existing
programmatic instrumentations that are now in the
ext
directory in the main OpenTelemetry repo. Please ask in the Gitter channel (see below) for guidance if you want to contribute with these instrumentations.
If you are looking for someone to help you find a starting point and be a resource for your first contribution, join our Gitter and find a buddy!
- Join Gitter.im and join our chat room.
- Post in the room with an introduction to yourself, what area you are interested in (check issues marked "Help Wanted"), and say you are looking for a buddy. We will match you with someone who has experience in that area.
Your OpenTelemetry buddy is your resource to talk to directly on all aspects of contributing to OpenTelemetry: providing context, reviewing PRs, and helping those get merged. Buddies will not be available 24/7, but is committed to responding during their normal contribution hours.
To quickly get up and running, you can use the scripts/eachdist.py
tool that
ships with this project. First create a virtualenv and activate it.
Then run python scripts/eachdist.py develop
to install all required packages
as well as the project's packages themselves (in --editable
mode).
You can then run scripts/eachdist.py test
to test everything or
scripts/eachdist.py lint
to lint everything (fixing anything that is auto-fixable).
Additionally, this project uses tox
to automate some aspects
of development, including testing against multiple Python versions.
You can run:
tox
to run all existing tox commands, including unit tests for all packages under multiple Python versionstox -e docs
to regenerate the API docstox -e test-api
andtox -e test-sdk
to run the API and SDK unit teststox -e py37-test-api
to e.g. run the API unit tests under a specific Python versiontox -e lint
to run lint checks on all code
See
tox.ini
for more detail on available tox commands.
Everyone is welcome to contribute code to opentelemetry-python
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-python.git
Add your fork as an origin:
$ git remote add fork https://github.com/YOUR_GITHUB_USERNAME/opentelemetry-python.git
Run tests:
# make sure you have all supported versions of Python installed
$ pip install tox # only first time.
$ tox # execute in the root of the repository
Check out a new branch, make modifications and push the branch to your fork:
$ git checkout -b feature
# edit files
$ git commit
$ git push fork feature
Open a pull request against the main opentelemetry-python
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 Approvers / 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 Approver / Maintainer can merge the PR once it is ready to merge.
As with other OpenTelemetry clients, opentelemetry-python 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
- docstrings should adhere to the Google Python Style Guide as specified with the napolean extension extension in Sphinx.