Thanks for your interest in contributing to OpenTelemetry.io! Here are a few general guidelines on contributing and reporting bugs that we ask you to review. Following these guidelines helps to communicate that you respect the time of the contributors managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests. In that spirit of mutual respect, we endeavor to review incoming issues and pull requests, and will close any lingering issues or pull requests after long times of inactivity.
Note that all of your interactions in the project are subject to our Code of Conduct. This includes creation of issues or pull requests, commenting on issues or pull requests, and extends to all interactions in any real-time space e.g., Slack, Discord, etc.
Also review the general OpenTelemetry Contributor Guide, that will provide additional details, especially that you need to sign a Contributor License Agreement (CLA) before you can contribute.
If you discover a security issue, do not report it through GitHub. Instead, follow the steps in our Security Policy.
If you find a problem with the content of this repository, or you would like to request an enhancement, create an issue.
Before reporting a new issue, please ensure that the issue was not already reported or fixed by searching through our issues list.
When creating a new issue, include a short meaningful title and clear a description, as much relevant information as possible, and, if possible, a test case.
This is the best way how you can help us to make our documentation better! Take a look at issues tagged with help wanted and good first issue to find an opportunity to contribute and help us. The good first issue label indicates that members have committed to providing extra assistance for new contributors.
After picking an issue, read through the existing discussion, ask the maintainers if this issue is still relevant and ask all questions you need for clarification. Afterwards you can state in a comment that you intend to work on this issue and it will be assumed to be yours. We will not assign issues to non-community members who have already made contributions to the OpenTelemetry organization. After confirmation through a maintainer, plan to provide a PR shortly or let maintainers now if you run into any blockers.
Enhancements and fixes to the website are most welcome!
Before sending a new pull request (PR), take a look at existing pull requests and issues to see if the proposed change or fix has been discussed in the past, or if the change was already implemented but not yet released.
For small changes to a single file, you can edit directly in GitHub by clicking Edit this file button. After forking the repository, follow the instructions in Editing files.
For everything else, follow the instructions to setup a development environment below.
Before a PR gets merged, it will sometimes require a few iterations of review-and-edit. To help us and yourself make this process as easy as possible, we ask that adhere to the following:
- If your PR isn't a quick fix, then work from a fork: Click the Fork button at the top of the repository and clone the fork locally. When you are ready, raise a PR with the upstream repository.
- Do not work from the
main
branch of your fork, but create a PR-specific branch. - Ensure that maintainers are allowed to apply changes to your pull request.
- No “changes requested” reviews by approvers, maintainers, technical committee members, or subject matter experts
- No unresolved conversations
- Approved by at least one approver
- No failing PR checks
- PR branch is up-to-date with the base branch
Important
Do not worry too much about failing PR checks! Community members will help you to get them fixed, by either providing you with instructions how to fix them or by fixing them on your behave.
The following instructions will help you to setup a development environment of the https://opentelemetry.io/ website.
These instructions are for Gitpod.io, adjust as needed for your favorite cloud IDE:
-
Fork this repository. For help, see Fork a repository.
-
From gitpod.io/workspaces, create a new workspace (do this only once) or open an existing workspace over your fork. You can also visit a link of the form: https://gitpod.io#https://github.com/YOUR_GITHUB_ID/opentelemetry.io.
Note: If you have the necessary permissions to work from this repository, or just want to look around, open https://gitpod.io/#https://github.com/open-telemetry/opentelemetry.io.
Gitpod will automatically install the repo-specific packages for you. You're now ready to build, serve and/or make updates to the website files.
-
Change to the repository directory.
-
Install or upgrade to the active LTS release of Node.js. We recommend using nvm to manage your Node installation. Under Linux, run the following command (which will install/upgrade to the version specified in .nvmrc):
nvm install
To install under Windows, use nvm-windows:
> nvm install lts && nvm use lts
-
Get npm packages and other prerequisites:
npm install
You're now ready to build, serve and/or make updates to the website files.
To build the site run:
npm run build
You'll find the generated site files under public
.
To serve the site run:
npm run serve
The site will be served at localhost:1313.
If you need to test Netlify redirects, use the following command, and visit the site at localhost:8888:
npm run serve:netlify
Note 1: The serve command serves files from memory, not from disk.
Note 2: See an error like
too many open files
orpipe failed
under macOS? You may need to increase the file descriptor limit. See Hugo issue #6109.
The website is built from the following content:
- Files under
content/
,static/
, etc. per Hugo defaults. - Mount points, defined in hugo.yaml under
mounts
. Mounts are either directly from git submodules under content-modules, or preprocessed content fromcontent-modules
(placed undertmp/
), and no where else.
Before submitting a to the repository, run the following command and address any
reported issues. Also commit any files changed by the fix
script:
npm run test-and-fix
To separately test and fix issues with your files, run:
npm run test # checks but does not update any files
npm run fix # may update files
To list available NPM scripts, run npm run
.
If you change any content inside of a content-modules submodule, then you'll need to first submit a PR (containing the submodule changes) to the submodule's repository. Only after the submodule PR has been accepted, can you update the submodule and have the changes appear in this website.
It is easiest to manage your content-modules
changes by working with the
repository that the corresponding submodule is linked to, rather than inside the
submodule itself.
For expert contributors, you can work directly in the submodule. You'll then be able to directly build and serve your (submodule) changes. By default, the CI scripts get submodules on every invocation. To prevent this behavior while you work within a submodule, set the environment variable
GET=no
. You'll also need togit fetch --unshallow
the submodule before you can submit a PR. Alternatively, setDEPTH=100
and re-fetch submodules.
If you submit a PR, Netlify will create a deploy preview so that you can review your changes. Once your PR is merged, Netlify deploys the updated site to the production server.
Note: PR previews include draft pages, but production builds do not.
To see deploy logs and more, visit project's dashboard -- Netlify login required.