OpenTelemetry is a big project, and can be overwhelming at first glance. This guide aims to help you understand how to find things to work on, how to find help, and how changes are merged and released.
- Contribution Lifecycle and Processes
Would you like to help make robust, modern telemetry a built-in feature of modern software? We will help you understand the organization of the project and direct you to the best places to get started. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged.
Please be aware that, due to the number of issues our triage team deals with, we cannot offer technical support in GitHub issues. If you have questions about the development process, feel free to jump into our Slack Channel (Get an invite to join CNCF). You can also ask questions on Stack Overflow.
Help is always welcome! For example, documentation (like the text you are reading now) can always use improvement. There's always code that can be clarified and variables or functions that can be renamed or commented. There's always a need for more test coverage. You get the idea: if you ever see something you think should be fixed, you should own it.
You can also find issues crafted for contributions using the tag opentelemetry at up-for-grabs.net.
Those interested in contributing without writing code may help documenting, evangelizing or helping answer questions about OpenTelemetry on various forums.
There are multiple repositories within the OpenTelemetry organization. Each repository has beginner-friendly issues that provide a good stepping stone to larger contributions. For example, Java SDK has help wanted and good first issue labels for issues that should not need deep knowledge of the system. The good first issue label indicates that members have committed to providing extra assistance for new contributors.
Often, new contributors ask to be assigned an issue they are willing to take on. Unfortunately, due to GitHub limitations we can only assign issues to org members or repo collaborators. Instead, please state in a comment that you intend to work on this issue and it will be assumed to be yours.
You may have noticed that some repositories in the OpenTelemetry Organization are owned by Special Interest Groups, or SIGs. We organize the community into SIGs in order to improve our workflow and more easily manage a community project. The developers within each SIG have autonomy and ownership over that SIG's part of OpenTelemetry.
A SIG is an open, community effort. Anybody is welcome to jump into a SIG and begin fixing issues, critiquing design proposals and reviewing code. SIGs have regular video meetings which everyone is welcome to attend.
Some SIGs have their own CONTRIBUTING.md files, which may contain extra information or guidelines in addition to these general ones. These are located in the SIG-specific GitHub repositories.
Not ready to contribute code, but see something that needs work? While the community encourages everyone to contribute code, it is also appreciated when someone reports an issue (aka problem). Issues should be filed under the appropriate OpenTelemetry subrepository.
Make sure to adhere to the repository specific policies or issue templates to provide detailed information that will help prompt answer and resolution of an issue.
OpenTelemetry is open source, but many of the people working on it do so as their day job. In order to avoid forcing people to be "at work" effectively 24/7, we want to establish some semi-formal protocols around development. Hopefully, these rules make things go more smoothly. If you find that this is not the case, please complain loudly.
As a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays. Please do not ever hesitate to ask a question or send a pull request.
It is best to contact your SIG for issues related to the SIG's topic. Your SIG will be able to help you much more quickly than a general question would.
For general questions and troubleshooting, use the standard lines of communication.
To check out code to work on, please refer to the GitHub Workflow Guide from Kubernetes. OpenTelemetry uses the same workflow. One of the main highlights - all the work should happen on forks, to minimize the number of branches on a given repository.
Pull requests are often called simply "PR". OpenTelemetry follows the standard github pull request process.
Common new contributor PR issues are:
- not having correctly signed the CLA ahead of your first PR (please Sign the CLA)
- following any SIG or repository specific contributing guidelines (see CONTRIBUTING.md of the corresponding repository)
- dealing with test cases which fail on your PR, unrelated to the changes you introduce
- Introducing change that should be first be approved by TC, for instance, the introduction of new terminology
- Leaving the description blank or only including an issue number.
There are two aspects of code review: giving and receiving.
To make it easier for your PR to receive reviews, consider the reviewers will need you to:
- follow the project and repository coding conventions
- write good commit messages
- break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue
- label PRs with appropriate SIGs and reviewers: to do this read the messages the bot sends you to guide you through the PR process
Reviewers, the people giving the review, are highly encouraged to revisit the Code of Conduct and must go above and beyond to promote a collaborative, respectful community.
When reviewing PRs from others The Gentle Art of Patch Review suggests an iterative series of focuses which is designed to lead new contributors to positive collaboration without inundating them initially with nuances:
- Is the idea behind the contribution sound?
- Is the contribution architected correctly?
- Is the contribution polished?
Note: if your pull request isn't getting enough attention, you can explicitly mention approvers or maintainers of this repository.
License information should be included in all source files where applicable. Either full or short version of the header should be used as described at apache.org. It is OK to exclude the year from the copyright notice. For the details on how to apply the copyright, see the next section.
OpenTelemetry follows CNCF recommendations for copyright notices. We use "Copyright The OpenTelemetry Authors" notice form.
According to CNCF recommendations if you are contributing third-party code you will need to retain the original copyright notice.
Any contributed third-party code must originally be Apache 2.0-Licensed or must carry a permissive software license that is compatible when combining with Apache 2.0 License. At this moment, BSD and MIT are the only OSI-approved licenses known to be compatible.
If you make substantial changes to the third-party code, prepend the contributed third party file with OpenTelemetry's copyright notice.
If the contributed code is not third-party code and you are the author we strongly encourage to avoid including your name in the notice and use the generic "Copyright The OpenTelemetry Authors" notice. See rationale for this recommendation here.
OpenTelemetry is driven by its specification and semantic conventions. Making cross-cutting changes to the project will start in one of these two places. This section details how an idea becomes a specification change.
A specification issue can be big, or small. A good specification issue, though, will be clear, concise, and scoped to a single, well-defined problem. Be sure to include specific examples of the problem you're trying to solve by opening a specification issue, along with any prior art or other relevant documentation.
Specification issues are regularly triaged by the Governance Committee (GC). The GC may accept, decline, or defer the issue until more details are added. Once an issue is accepted, it may need a sponsor from the TC who will be responsible for driving the issue to completion. Some issues may be small enough that they do not need a sponsor -- these issues can be worked on as soon as they are accepted.