├── .cspell.yaml ├── .github ├── ISSUE_TEMPLATE │ ├── credentials-access.md │ ├── donation.yml │ ├── gc_member_onboarding.md │ ├── general-support.md │ ├── membership.md │ ├── repo-permissions.md │ └── stabilization-review.md ├── renovate.json5 ├── repository-settings.md └── workflows │ ├── build.yml │ ├── fossa.yml │ ├── issue-management-feedback-label.yml │ ├── issue-management-stale-action.yml │ ├── ossf-scorecard.yml │ ├── reusable-markdown-link-check.yml │ ├── spell-check.yml │ ├── table-check.yml │ └── toc-check.yml ├── .gitignore ├── .lychee.toml ├── ADOPTERS.md ├── CODEOWNERS ├── COMMUNICATION.md ├── CONTRIBUTING.md ├── LICENSE ├── Makefile ├── README.md ├── areas-of-interest.md ├── assets.md ├── code-of-conduct.md ├── community-members.md ├── community-membership.md ├── docs ├── how-meeting-recordings-upload-works.md ├── how-to-configure-new-repository.md ├── how-to-handle-public-calendar.md ├── how-to-setup-new-slack-channel.md ├── images │ └── google-calendar-colors.png └── using-github-extensions.md ├── elections ├── 2019 │ ├── governance-committee-candidates.md │ ├── governance-committee-election.md │ └── static │ │ ├── constance-caramanolis.jpg │ │ ├── kchu.jpeg │ │ ├── liz_headshot.jpg │ │ ├── luis-mineiro_mugshot.jpg │ │ ├── morgan-james-mclean.jpg │ │ ├── steven-le-roux.jpg │ │ └── ted-young.jpg ├── 2020 │ ├── governance-committee-candidates.md │ ├── governance-committee-election.md │ └── static │ │ ├── alolita-sharma.png │ │ ├── ann-example.png │ │ ├── daniel-dyla.jpg │ │ ├── ilan-rabinovitch.jpg │ │ ├── lizf.jpg │ │ ├── morgan-mclean.png │ │ └── tyler-yahn.jpeg ├── 2021 │ ├── governance-committee-candidates.md │ ├── governance-committee-election.md │ └── static │ │ ├── bhs.jpg │ │ ├── bogdan-drutu.jpg │ │ ├── csuzhang.jpg │ │ ├── ilan-rabinovitch.jpeg │ │ ├── jpkroehling.jpg │ │ ├── punya-biswal.jpg │ │ ├── sergeykanzhelev.jpeg │ │ ├── sharr-creeden.jpg │ │ ├── steve-flanders.jpg │ │ └── ted-young.jpg ├── 2022 │ ├── governance-committee-candidates.md │ ├── governance-committee-election.md │ └── static │ │ ├── Reese-Lee.jpg │ │ ├── alolita-sharma-picture.png │ │ ├── daniel-dyla.jpg │ │ ├── kenfinnigan.png │ │ ├── mhausenblas.png │ │ ├── morgan-mclean.png │ │ ├── pavolloffay.jpeg │ │ ├── phillip-carter.jpeg │ │ ├── reiley-yang.jpeg │ │ ├── seanmarciniak.jpg │ │ ├── severin-neumann.jpg │ │ ├── trask-stalnaker.png │ │ ├── tyler-yahn.jpeg │ │ └── vijay-samuel.jpg ├── 2023 │ ├── governance-committee-candidates.md │ ├── governance-committee-election.md │ └── static │ │ ├── austin-parker.jpg │ │ ├── daniel-gomezblanco.png │ │ ├── eric-sirianni.jpg │ │ ├── johannes-tax.gif │ │ ├── jpkroehling.webp │ │ ├── severin-neumann.jpg │ │ ├── steve-flanders.jpg │ │ ├── ted-young.jpg │ │ └── vijay-samuel.jpg └── 2024 │ ├── governance-committee-candidates.md │ ├── governance-committee-election.md │ ├── static │ ├── Adriana Villela - 2024-06-20 - smaller.jpeg │ ├── alolita-sharma-picture.png │ ├── daniel-dyla.jpg │ ├── jamie-danielson.png │ ├── maryliag.png │ ├── pablo-baeyens.jpg │ └── trask-stalnaker.png │ └── voters-roll.csv ├── gc-check-ins.md ├── governance-charter.md ├── guides ├── README.md ├── contributor │ ├── CLA.md │ ├── README.md │ ├── donations.md │ ├── genai.md │ ├── membership.md │ └── processes.md └── maintainer │ ├── README.md │ └── conflict-resolution.md ├── marketing-guidelines.md ├── maturity-matrix.yaml ├── mission-vision-values.md ├── package-lock.json ├── package.json ├── project-management.md ├── project-template.md ├── projects ├── README.md ├── ci-cd.md ├── client-instrumentation.md ├── collector-v1.md ├── completed-projects │ ├── README.md │ ├── database-client-semconv.md │ └── one-logging-bridge-per-language.md ├── config.md ├── contributor-experience.md ├── currently-inactive │ └── messaging-semconv.md ├── developer_experience.md ├── event-api.md ├── faas.md ├── feature-flag.md ├── gen-ai.md ├── go-compile-instrumentation.md ├── http.md ├── k8s-semconv.md ├── mainframe.md ├── new-getting-started-docs-and-reference-application.md ├── otelarrow.md ├── project-infrastructure.md ├── resources-and-entities.md ├── sampling.md ├── security-semconv.md └── system-semconv.md ├── reports ├── ADA_Logics-collector-fuzzing-audit-2024.pdf └── compliance.md ├── roadmap.md ├── scripts ├── gc-elections │ ├── README.md │ ├── convert-voter-roll-to-helios.py │ ├── create-gihub-comments.sh │ └── generate-voters-roll.py ├── update-sig-tables.py └── validate-sigs.py ├── sigs.yml ├── social-media-guide.md ├── tech-committee-charter.md └── tools └── github └── README.md /.cspell.yaml: -------------------------------------------------------------------------------- 1 | version: 0.2 2 | ignorePaths: 3 | ["elections/**/*", "tools/github/*", "scripts/**/*.py", "scripts/**/*.sh"] 4 | # Ignore certain patterns in the sigs.yml file 5 | patterns: 6 | - name: Slack Channel ID 7 | pattern: "id: [A-Z0-9]{11}" 8 | - name: Google Docs ID 9 | pattern: "value: [a-zA-Z0-9-_]+" 10 | - name: "GitHub Handle" 11 | pattern: "@[a-zA-Z0-9-_]+\\b" 12 | - name: "GitHub Handle in YML" 13 | pattern: "github: [a-zA-Z0-9-_]+" 14 | ignoreRegExpList: 15 | - Slack Channel ID 16 | - Google Docs ID 17 | - GitHub Handle 18 | - GitHub Handle in YML 19 | words: 20 | - Alff 21 | - Arize 22 | - Ashpole 23 | - Baeyens 24 | - calendar-localization-ptbr 25 | - Collibra 26 | - Coralogix 27 | - DASD 28 | - Docu 29 | - Dosu 30 | - datadog 31 | - devex 32 | - devstats 33 | - dynatrace 34 | - easycla 35 | - eiffel 36 | - elastic 37 | - emea 38 | - faas 39 | - gitter 40 | - grafana 41 | - Hostmetrics 42 | - hostmetricsreceiver 43 | - Instrgen 44 | - jemmic 45 | - keptn 46 | - kubecon 47 | - k8sclusterreceiver 48 | - Langfuse 49 | - Langtrace 50 | - liatrio 51 | - lightstep 52 | - logz 53 | - maintainership 54 | - observiq 55 | - opentelemetry 56 | - opentelemetrybot 57 | - otel 58 | - otel-localization-ptbr 59 | - otel-localization-zhcn 60 | - otep 61 | - otlp 62 | - passcodes 63 | - proto 64 | - pytest 65 | - isovalent 66 | - labs 67 | - Liudmila 68 | - Nale 69 | - REXX 70 | - scaphandre 71 | - Sysplex 72 | - acramsay 73 | - adot 74 | - agentmanwg 75 | - alolita 76 | - amye 77 | - andré 78 | - aniszczyk 79 | - apac 80 | - anoshin 81 | - armin 82 | - beedgen 83 | - beemer 84 | - bertysentry 85 | - blanco 86 | - bogdan 87 | - boten 88 | - calendar-agent-mgmt 89 | - calendar-ebpf 90 | - caramanolis 91 | - cdevents 92 | - chrs 93 | - cicd 94 | - cijo 95 | - cncf 96 | - codeboten 97 | - codecentric 98 | - codecov 99 | - codeowners 100 | - comms 101 | - credly 102 | - danielgblanco 103 | - darren17082 104 | - davdai 105 | - denisivan 106 | - dennisme 107 | - dineshg 108 | - dmitrii 109 | - dmitryax 110 | - dpauls 111 | - dnsmichi 112 | - dpauls 113 | - drewby 114 | - drutu 115 | - dyla 116 | - dynatrace 117 | - easycla 118 | - ebpf 119 | - eiffel 120 | - emea 121 | - endsigs 122 | - faas 123 | - fong 124 | - frzifus 125 | - gbbr 126 | - genai 127 | - gitter 128 | - gitdm 129 | - henrikrexed 130 | - heptio 131 | - hongalex 132 | - horovits 133 | - instrgen 134 | - jackjia 135 | - jaglowski 136 | - javaagent 137 | - jemmic 138 | - juraci 139 | - kaiyan-sheng 140 | - kamphaus 141 | - kanzhelev 142 | - kelnage 143 | - keptn 144 | - krzko 145 | - kröhling 146 | - kubecon 147 | - kuisathaverat 148 | - lalitb 149 | - lambdanis 150 | - lexis 151 | - liatrio 152 | - lightstep 153 | - logz 154 | - lucavallin 155 | - lukas 156 | - lycheeverse 157 | - magnusbaeck 158 | - maintainership 159 | - mancuso 160 | - marceloamaral 161 | - martinkuba 162 | - mateuszrzeszutek 163 | - mayur 164 | - mayurkale 165 | - Metry 166 | - mdelfabro 167 | - mhausenblas 168 | - mirabella 169 | - mjwolf 170 | - mkorbi 171 | - molkova 172 | - msomasu 173 | - MSYS 174 | - PATHCONV 175 | - mtwo 176 | - mwear 177 | - najaryan 178 | - nakamura 179 | - neumann 180 | - neumüller 181 | - nexis 182 | - nirga 183 | - nikimanoledaki 184 | - novotny 185 | - observiq 186 | - Olly 187 | - opamp 188 | - OpenLIT 189 | - opentelemetry 190 | - opentelemetrybot 191 | - ossf 192 | - otel 193 | - otel-agentmanwg 194 | - otel-comms 195 | - otel-ebpf 196 | - otelbot 197 | - otep 198 | - otlp 199 | - OTAP 200 | - OTTL 201 | - outreachy 202 | - Packagist 203 | - Prometheus 204 | - paixão 205 | - pająk 206 | - passcodes 207 | - poncelow 208 | - proto 209 | - protos 210 | - pytest 211 | - Quesma 212 | - raesene 213 | - reiley 214 | - roadmaps 215 | - rolldice 216 | - ruech 217 | - runtimes 218 | - rynn 219 | - rossf7 220 | - salnikov 221 | - sallyom 222 | - sarif 223 | - scavarda 224 | - semconv 225 | - sergey 226 | - severin 227 | - sguyon 228 | - sharma 229 | - shkuro 230 | - sigelman 231 | - signup 232 | - skyscanner 233 | - sloughter 234 | - snyk 235 | - splk 236 | - stalnaker 237 | - subdir 238 | - subproject 239 | - subprojects 240 | - subrepository 241 | - sudivate 242 | - suereth 243 | - supermajority 244 | - Traceloop 245 | - tarnovski 246 | - tekton 247 | - thisthat 248 | - tiebreaking 249 | - tigran 250 | - timebox 251 | - timeboxing 252 | - timeslot 253 | - tocstop 254 | - trask 255 | - trendable 256 | - triager 257 | - triagers 258 | - teamcity 259 | - uninstrumented 260 | - vtex 261 | - yahn 262 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/credentials-access.md: -------------------------------------------------------------------------------- 1 | -- 2 | name: Credential Store Access Request 3 | about: Request access to the OpenTelemetry credential store 4 | title: 'REQUEST: Credential Store Access for ' 5 | labels: area/repo-maintenance 6 | assignees: '' 7 | --- 8 | 9 | 11 | 12 | ### Repository Vault Requested 13 | 14 | e.g. https://github.com/open-telemetry/opentelemetry-collector 15 | 16 | ### Sponsors 17 | 18 | Access to shared repository vaults requires a maintainer 19 | from the requested vault to sponsor the request 20 | 21 | ### Repository Maintainers 22 | 23 | 24 | 25 | - @open-telemetry/xxx-maintainers 26 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/donation.yml: -------------------------------------------------------------------------------- 1 | name: Donation Proposal 2 | description: Propose to donate a preexisting project to the OpenTelemetry organization 3 | title: "[Donation Proposal]: " 4 | labels: ["donation"] 5 | body: 6 | - type: markdown 7 | attributes: 8 | value: | 9 | Welcome to the OpenTelemetry project! 👋🎉 10 | Please review the [Donation Guidelines](https://github.com/open-telemetry/community/blob/main/guides/contributor/donations.md) before submitting this form. 11 | - type: textarea 12 | id: description 13 | attributes: 14 | label: Description 15 | description: Please describe the project you want to donate. 16 | validations: 17 | required: true 18 | - type: textarea 19 | id: benefits 20 | attributes: 21 | label: Benefits to the OpenTelemetry community 22 | description: How may this project benefit the OpenTelemetry community? 23 | validations: 24 | required: true 25 | - type: textarea 26 | id: reasons 27 | attributes: 28 | label: Reasons for donation 29 | description: | 30 | Please explain why an OpenTelemetry donation is necessary to realize these benefits. 31 | validations: 32 | required: true 33 | - type: input 34 | id: repo 35 | attributes: 36 | label: Repository 37 | description: Where is the project currently hosted? 38 | validations: 39 | required: true 40 | - type: textarea 41 | id: usage 42 | attributes: 43 | label: Existing usage 44 | description: Summary of existing usage of donated project. 45 | validations: 46 | required: true 47 | - type: textarea 48 | id: maintenance 49 | attributes: 50 | label: Maintenance 51 | description: Please explain how the project is going to be maintained if the donation is accepted. 52 | validations: 53 | required: true 54 | - type: textarea 55 | id: license 56 | attributes: 57 | label: Licenses 58 | description: How is the project's code currently licensed? 59 | validations: 60 | required: true 61 | - type: textarea 62 | id: trademarks 63 | attributes: 64 | label: Trademarks 65 | description: List of trademarks 66 | validations: 67 | required: true 68 | - type: textarea 69 | id: other 70 | attributes: 71 | label: Other notes 72 | description: Other things that the OpenTelemetry Technical or Governance committees should know. 73 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/general-support.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: General Issue 3 | about: Open a general issue in the open-telemetry/community repo 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/membership.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Organization Membership Request 3 | about: Request membership in a OpenTelemetry Org 4 | title: 'REQUEST: New membership for ' 5 | labels: area/github-membership 6 | assignees: '' 7 | 8 | --- 9 | 10 | 12 | 13 | ### GitHub Username 14 | 15 | e.g. (at)example_user 16 | 17 | ### Requirements 18 | 19 | - [ ] I have reviewed the community membership guidelines (https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md) 20 | - [ ] I have enabled 2FA on my GitHub account. See https://github.com/settings/security 21 | - [ ] I have subscribed to the [Slack channel](https://cloud-native.slack.com/archives/CJFCJHG4Q) (use https://slack.cncf.io/ to get an invite) 22 | - [ ] I am actively contributing to 1 or more OpenTelemetry subprojects 23 | - [ ] I have two sponsors that meet the sponsor requirements listed in the community membership guidelines. Among other requirements, sponsors must be approvers or maintainers of at least one repository in the organization and not both affiliated with the same company 24 | - [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application 25 | 26 | ### Sponsors 27 | 28 | 29 | 30 | - (at)sponsor-1 31 | - (at)sponsor-2 32 | 33 | Each sponsor should reply to this issue with the comment "*I support*". 34 | Please remember, it is an applicant's responsibility to get their sponsors' confirmation before submitting the request. 35 | 36 | ### List of contributions to the OpenTelemetry project 37 | 38 | - PRs reviewed / authored 39 | - Issues responded to 40 | - Community activities I organized/ran 41 | - SIG projects I am involved with 42 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/repo-permissions.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Repository Maintenance Request 3 | about: Request changes on an existing OpenTelemetry repository 4 | title: 'REQUEST: Repository maintenance on ' 5 | labels: area/repo-maintenance 6 | assignees: '' 7 | --- 8 | 9 | 11 | 12 | ### Affected Repository 13 | 14 | e.g. https://github.com/open-telemetry/community 15 | 16 | ### Requested changes 17 | 18 | e.g. "Give 'Admin' permissions to `@username`" or "Enable branch protection rules for `release-*`" 19 | 20 | 22 | 23 | ### Purpose 24 | 25 | e.g. "We are setting up a new release management tool (link) and need to adapt our required merge checks for this." 26 | 27 | ### Expected Duration 28 | 29 | e.g. "1-2 weeks. We'll comment again on this issue once we are done so the permissions can be reverted." or "permanently" 30 | 31 | ### Repository Maintainers 32 | 33 | 34 | 35 | - @open-telemetry/xxx-maintainers 36 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/stabilization-review.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: TC Review Request 3 | about: Request a Technical Committee stability review (promotion to Stable) 4 | title: "TC Review Request: " 5 | labels: "area/stability" 6 | assignees: "" 7 | --- 8 | 9 | 12 | 13 | # TC Review Request: (API / SDK / Collector-module) 14 | 15 | ## 1. Review scope 16 | | Signal | Part of project | Current maturity | Target maturity | 17 | | ------ | --------------- | ---------------- | --------------- | 18 | | | | experimental / beta | **stable** | 19 | 20 | ## 2. Motivation 21 | 22 | 23 | ## 3. Target version / tag 24 | `/@` – commit `` 25 | 26 | ## 4. Links for reviewers 27 | * **Spec compliance matrix:** 28 | 42 | * **Public docs / getting-started sample:** 43 | * **CHANGELOG draft:** 44 | 45 | 50 | 51 | ## 5. Self-checklist 52 | - [ ] All **MUST / MUST NOT** requirements implemented 53 | - [ ] [Spec compliance matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md) populated and up-to-date 54 | - [ ] Docs & examples updated 55 | - [ ] Test suites passing 56 | - [ ] CHANGELOG prepared 57 | 58 | ## 6. Maintainer points-of-contact 59 | - @ – SIG lead / primary contact 60 | - @ – backup 61 | 62 | ## 7. Requested reviewer expertise 63 | 64 | 65 | /cc @open-telemetry/technical-committee 66 | -------------------------------------------------------------------------------- /.github/renovate.json5: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "https://docs.renovatebot.com/renovate-schema.json", 3 | "extends": [ 4 | "config:recommended", 5 | "docker:pinDigests", 6 | "helpers:pinGitHubActionDigestsToSemver" 7 | ], 8 | "packageRules": [ 9 | { 10 | // reduces the number of Renovate PRs 11 | // (patch updates are typically non-breaking) 12 | "groupName": "all patch versions", 13 | "matchUpdateTypes": ["patch"], 14 | "schedule": ["before 8am every weekday"] 15 | }, 16 | { 17 | // avoids these Renovate PRs from trickling in throughout the week 18 | // (consolidating the review process) 19 | "matchUpdateTypes": ["minor", "major"], 20 | "schedule": ["before 8am on Monday"] 21 | } 22 | ], 23 | "labels": [ 24 | "dependencies" 25 | ] 26 | } 27 | -------------------------------------------------------------------------------- /.github/repository-settings.md: -------------------------------------------------------------------------------- 1 | # Repository settings 2 | 3 | This document describes any changes that have been made to the 4 | settings for this repository beyond the [OpenTelemetry default repository 5 | settings](../docs/how-to-configure-new-repository.md#repository-settings). 6 | 7 | ## General > Pull Requests 8 | 9 | * Allow auto-merge 10 | 11 | ## Branch protections 12 | 13 | ### `main` 14 | 15 | * Required number of approvals before merging: `2` 16 | * Require conversation resolution before merging: :heavy_check_mark: 17 | * Status checks that are required: 18 | * EasyCLA 19 | * spelling-check 20 | * table-check 21 | * toc-check 22 | 23 | ### `**/**` 24 | 25 | * Allow deletions: :heavy_check_mark: 26 | -------------------------------------------------------------------------------- /.github/workflows/build.yml: -------------------------------------------------------------------------------- 1 | name: Build 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | pull_request: 8 | merge_group: 9 | workflow_dispatch: 10 | 11 | concurrency: 12 | group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }} 13 | cancel-in-progress: true 14 | 15 | jobs: 16 | markdown-link-check: 17 | uses: ./.github/workflows/reusable-markdown-link-check.yml 18 | -------------------------------------------------------------------------------- /.github/workflows/fossa.yml: -------------------------------------------------------------------------------- 1 | name: FOSSA scanning 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | 8 | permissions: 9 | contents: read 10 | 11 | jobs: 12 | fossa: 13 | runs-on: ubuntu-latest 14 | steps: 15 | - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 16 | 17 | - uses: fossas/fossa-action@3ebcea1862c6ffbd5cf1b4d0bd6b3fe7bd6f2cac # v1.7.0 18 | with: 19 | api-key: ${{secrets.FOSSA_API_KEY}} 20 | team: OpenTelemetry 21 | -------------------------------------------------------------------------------- /.github/workflows/issue-management-feedback-label.yml: -------------------------------------------------------------------------------- 1 | name: Issue management - remove needs feedback label 2 | 3 | on: 4 | issue_comment: 5 | types: [created] 6 | 7 | jobs: 8 | issue_comment: 9 | if: > 10 | contains(github.event.issue.labels.*.name, 'needs author feedback') && 11 | github.event.comment.user.login == github.event.issue.user.login 12 | runs-on: ubuntu-latest 13 | steps: 14 | - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 15 | 16 | - name: Remove label 17 | env: 18 | ISSUE_NUMBER: ${{ github.event.issue.number }} 19 | GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} 20 | run: | 21 | gh issue edit --remove-label "needs author feedback" $ISSUE_NUMBER 22 | -------------------------------------------------------------------------------- /.github/workflows/issue-management-stale-action.yml: -------------------------------------------------------------------------------- 1 | name: Issue management - run stale action 2 | 3 | on: 4 | schedule: 5 | # Hourly at minute 23 6 | - cron: "23 * * * *" 7 | 8 | jobs: 9 | stale: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - uses: actions/stale@5bef64f19d7facfb25b37b414482c7164d639639 # v9.1.0 13 | with: 14 | repo-token: ${{ secrets.GITHUB_TOKEN }} 15 | days-before-stale: 7 16 | days-before-close: 7 17 | only-labels: "needs author feedback" 18 | stale-issue-message: > 19 | This has been automatically marked as stale because it has been marked 20 | as needing author feedback and has not had any activity for 7 days. 21 | It will be closed if no further activity occurs within 7 days of this comment. 22 | stale-pr-message: > 23 | This has been automatically marked as stale because it has been marked 24 | as needing author feedback and has not had any activity for 7 days. 25 | It will be closed if no further activity occurs within 7 days of this comment. 26 | -------------------------------------------------------------------------------- /.github/workflows/ossf-scorecard.yml: -------------------------------------------------------------------------------- 1 | name: OSSF Scorecard 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | schedule: 8 | - cron: "5 16 * * 1" # once a week 9 | workflow_dispatch: 10 | 11 | permissions: read-all 12 | 13 | jobs: 14 | analysis: 15 | runs-on: ubuntu-latest 16 | permissions: 17 | # Needed for Code scanning upload 18 | security-events: write 19 | # Needed for GitHub OIDC token if publish_results is true 20 | id-token: write 21 | steps: 22 | - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 23 | with: 24 | persist-credentials: false 25 | 26 | - uses: ossf/scorecard-action@05b42c624433fc40578a4040d5cf5e36ddca8cde # v2.4.2 27 | with: 28 | results_file: results.sarif 29 | results_format: sarif 30 | publish_results: true 31 | 32 | # Upload the results as artifacts (optional). Commenting out will disable 33 | # uploads of run results in SARIF format to the repository Actions tab. 34 | # https://docs.github.com/en/actions/advanced-guides/storing-workflow-data-as-artifacts 35 | - name: "Upload artifact" 36 | uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2 37 | with: 38 | name: SARIF file 39 | path: results.sarif 40 | retention-days: 5 41 | 42 | # Upload the results to GitHub's code scanning dashboard (optional). 43 | # Commenting out will disable upload of results to your repo's Code Scanning dashboard 44 | - name: "Upload to code-scanning" 45 | uses: github/codeql-action/upload-sarif@fca7ace96b7d713c7035871441bd52efbe39e27e # v3.28.19 46 | with: 47 | sarif_file: results.sarif 48 | -------------------------------------------------------------------------------- /.github/workflows/reusable-markdown-link-check.yml: -------------------------------------------------------------------------------- 1 | name: Reusable - Markdown link check 2 | 3 | on: 4 | workflow_call: 5 | 6 | jobs: 7 | markdown-link-check: 8 | runs-on: ubuntu-latest 9 | steps: 10 | - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 11 | 12 | - name: Run markdown-link-check 13 | run: make markdown-link-check 14 | -------------------------------------------------------------------------------- /.github/workflows/spell-check.yml: -------------------------------------------------------------------------------- 1 | name: Spell checking 2 | 3 | on: 4 | pull_request: 5 | merge_group: 6 | 7 | jobs: 8 | spelling-check: 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 12 | - uses: streetsidesoftware/cspell-action@69543c3f9f14d4fcc6004c7bee03c4d366f11d64 # v7.0.1 13 | with: 14 | config: .cspell.yaml 15 | -------------------------------------------------------------------------------- /.github/workflows/table-check.yml: -------------------------------------------------------------------------------- 1 | name: SIG Table checking 2 | 3 | on: 4 | pull_request: 5 | merge_group: 6 | 7 | jobs: 8 | table-check: 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 12 | - name: verify SIG tables in README.md 13 | run: make table-check 14 | -------------------------------------------------------------------------------- /.github/workflows/toc-check.yml: -------------------------------------------------------------------------------- 1 | name: Table of contents checking 2 | 3 | on: 4 | pull_request: 5 | merge_group: 6 | 7 | jobs: 8 | toc-check: 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 12 | 13 | - name: check TOC in assets.md 14 | run: make markdown-toc-check 15 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | ## Ignore Visual Studio temporary files, build results, and 2 | ## files generated by popular Visual Studio add-ons. 3 | ## 4 | ## Get latest from https://github.com/github/gitignore/blob/master/VisualStudio.gitignore 5 | 6 | # User-specific files 7 | *.suo 8 | *.user 9 | *.userosscache 10 | *.sln.docstates 11 | .vscode/solution-explorer 12 | 13 | # User-specific files (MonoDevelop/Xamarin Studio) 14 | *.userprefs 15 | 16 | # Build results 17 | [Dd]ebug/ 18 | [Dd]ebugPublic/ 19 | [Rr]elease/ 20 | [Rr]eleases/ 21 | x64/ 22 | x86/ 23 | bld/ 24 | [Bb]in/ 25 | [Oo]bj/ 26 | [Ll]og/ 27 | 28 | # DocFx output 29 | _api/ 30 | _site/ 31 | 32 | # Visual Studio 2015/2017 cache/options directory 33 | .vs/ 34 | # Uncomment if you have tasks that create the project's static files in wwwroot 35 | #wwwroot/ 36 | 37 | # Visual Studio 2017 auto generated files 38 | Generated\ Files/ 39 | 40 | # MSTest test Results 41 | [Tt]est[Rr]esult*/ 42 | [Bb]uild[Ll]og.* 43 | 44 | # NUNIT 45 | *.VisualState.xml 46 | TestResult.xml 47 | 48 | # Build Results of an ATL Project 49 | [Dd]ebugPS/ 50 | [Rr]eleasePS/ 51 | dlldata.c 52 | 53 | # Benchmark Results 54 | BenchmarkDotNet.Artifacts/ 55 | 56 | # .NET Core 57 | project.lock.json 58 | project.fragment.lock.json 59 | artifacts/ 60 | **/Properties/launchSettings.json 61 | 62 | # StyleCop 63 | StyleCopReport.xml 64 | 65 | # Files built by Visual Studio 66 | *_i.c 67 | *_p.c 68 | *_i.h 69 | *.ilk 70 | *.meta 71 | *.obj 72 | *.iobj 73 | *.pch 74 | *.pdb 75 | *.ipdb 76 | *.pgc 77 | *.pgd 78 | *.rsp 79 | *.sbr 80 | *.tlb 81 | *.tli 82 | *.tlh 83 | *.tmp 84 | *.tmp_proj 85 | *.log 86 | *.vspscc 87 | *.vssscc 88 | .builds 89 | *.pidb 90 | *.svclog 91 | *.scc 92 | 93 | # Chutzpah Test files 94 | _Chutzpah* 95 | 96 | # Visual C++ cache files 97 | ipch/ 98 | *.aps 99 | *.ncb 100 | *.opendb 101 | *.opensdf 102 | *.sdf 103 | *.cachefile 104 | *.VC.db 105 | *.VC.VC.opendb 106 | 107 | # Visual Studio profiler 108 | *.psess 109 | *.vsp 110 | *.vspx 111 | *.sap 112 | 113 | # Visual Studio Trace Files 114 | *.e2e 115 | 116 | # TFS 2012 Local Workspace 117 | $tf/ 118 | 119 | # Guidance Automation Toolkit 120 | *.gpState 121 | 122 | # ReSharper is a .NET coding add-in 123 | _ReSharper*/ 124 | *.[Rr]e[Ss]harper 125 | *.DotSettings.user 126 | 127 | # JustCode is a .NET coding add-in 128 | .JustCode 129 | 130 | # TeamCity is a build add-in 131 | _TeamCity* 132 | 133 | # DotCover is a Code Coverage Tool 134 | *.dotCover 135 | 136 | # AxoCover is a Code Coverage Tool 137 | .axoCover/* 138 | !.axoCover/settings.json 139 | 140 | # Visual Studio code coverage results 141 | *.coverage 142 | *.coveragexml 143 | 144 | # NCrunch 145 | _NCrunch_* 146 | .*crunch*.local.xml 147 | nCrunchTemp_* 148 | 149 | # MightyMoose 150 | *.mm.* 151 | AutoTest.Net/ 152 | 153 | # Web workbench (sass) 154 | .sass-cache/ 155 | 156 | # Installshield output folder 157 | [Ee]xpress/ 158 | 159 | # DocProject is a documentation generator add-in 160 | DocProject/buildhelp/ 161 | DocProject/Help/*.HxT 162 | DocProject/Help/*.HxC 163 | DocProject/Help/*.hhc 164 | DocProject/Help/*.hhk 165 | DocProject/Help/*.hhp 166 | DocProject/Help/Html2 167 | DocProject/Help/html 168 | 169 | # Click-Once directory 170 | publish/ 171 | 172 | # Publish Web Output 173 | *.[Pp]ublish.xml 174 | *.azurePubxml 175 | # Note: Comment the next line if you want to checkin your web deploy settings, 176 | # but database connection strings (with potential passwords) will be unencrypted 177 | *.pubxml 178 | *.publishproj 179 | 180 | # Microsoft Azure Web App publish settings. Comment the next line if you want to 181 | # checkin your Azure Web App publish settings, but sensitive information contained 182 | # in these scripts will be unencrypted 183 | PublishScripts/ 184 | 185 | # NuGet Packages 186 | *.nupkg 187 | # The packages folder can be ignored because of Package Restore 188 | **/[Pp]ackages/* 189 | # except build/, which is used as an MSBuild target. 190 | !**/[Pp]ackages/build/ 191 | # Uncomment if necessary however generally it will be regenerated when needed 192 | #!**/[Pp]ackages/repositories.config 193 | # NuGet v3's project.json files produces more ignorable files 194 | *.nuget.props 195 | *.nuget.targets 196 | 197 | # Microsoft Azure Build Output 198 | csx/ 199 | *.build.csdef 200 | 201 | # Microsoft Azure Emulator 202 | ecf/ 203 | rcf/ 204 | 205 | # Windows Store app package directories and files 206 | AppPackages/ 207 | BundleArtifacts/ 208 | Package.StoreAssociation.xml 209 | _pkginfo.txt 210 | *.appx 211 | 212 | # Visual Studio cache files 213 | # files ending in .cache can be ignored 214 | *.[Cc]ache 215 | # but keep track of directories ending in .cache 216 | !*.[Cc]ache/ 217 | 218 | # Others 219 | ClientBin/ 220 | ~$* 221 | *~ 222 | *.dbmdl 223 | *.dbproj.schemaview 224 | *.jfm 225 | *.pfx 226 | *.publishsettings 227 | orleans.codegen.cs 228 | 229 | # Including strong name files can present a security risk 230 | # (https://github.com/github/gitignore/pull/2483#issue-259490424) 231 | #*.snk 232 | 233 | # Since there are multiple workflows, uncomment next line to ignore bower_components 234 | # (https://github.com/github/gitignore/pull/1529#issuecomment-104372622) 235 | #bower_components/ 236 | 237 | # RIA/Silverlight projects 238 | Generated_Code/ 239 | 240 | # Backup & report files from converting an old project file 241 | # to a newer Visual Studio version. Backup files are not needed, 242 | # because we have git ;-) 243 | _UpgradeReport_Files/ 244 | Backup*/ 245 | UpgradeLog*.XML 246 | UpgradeLog*.htm 247 | ServiceFabricBackup/ 248 | *.rptproj.bak 249 | 250 | # SQL Server files 251 | *.mdf 252 | *.ldf 253 | *.ndf 254 | 255 | # Business Intelligence projects 256 | *.rdl.data 257 | *.bim.layout 258 | *.bim_*.settings 259 | *.rptproj.rsuser 260 | 261 | # Microsoft Fakes 262 | FakesAssemblies/ 263 | 264 | # GhostDoc plugin setting file 265 | *.GhostDoc.xml 266 | 267 | # Node.js Tools for Visual Studio 268 | .ntvs_analysis.dat 269 | node_modules/ 270 | 271 | # Visual Studio 6 build log 272 | *.plg 273 | 274 | # Visual Studio 6 workspace options file 275 | *.opt 276 | 277 | # Visual Studio 6 auto-generated workspace file (contains which files were open etc.) 278 | *.vbw 279 | 280 | # Visual Studio LightSwitch build output 281 | **/*.HTMLClient/GeneratedArtifacts 282 | **/*.DesktopClient/GeneratedArtifacts 283 | **/*.DesktopClient/ModelManifest.xml 284 | **/*.Server/GeneratedArtifacts 285 | **/*.Server/ModelManifest.xml 286 | _Pvt_Extensions 287 | 288 | # Paket dependency manager 289 | .paket/paket.exe 290 | paket-files/ 291 | 292 | # FAKE - F# Make 293 | .fake/ 294 | 295 | # JetBrains Rider 296 | .idea/ 297 | *.sln.iml 298 | 299 | # macOS 300 | .DS_Store 301 | 302 | # CodeRush 303 | .cr/ 304 | 305 | # Python Tools for Visual Studio (PTVS) 306 | __pycache__/ 307 | *.pyc 308 | 309 | # Cake - Uncomment if you are using it 310 | # tools/** 311 | # !tools/packages.config 312 | 313 | # Tabs Studio 314 | *.tss 315 | 316 | # Telerik's JustMock configuration file 317 | *.jmconfig 318 | 319 | # BizTalk build output 320 | *.btp.cs 321 | *.btm.cs 322 | *.odx.cs 323 | *.xsd.cs 324 | 325 | # OpenCover UI analysis results 326 | OpenCover/ 327 | 328 | # Azure Stream Analytics local run output 329 | ASALocalRun/ 330 | 331 | # MSBuild Binary and Structured Log 332 | *.binlog 333 | 334 | # NVidia Nsight GPU debugger configuration file 335 | *.nvuser 336 | 337 | # MFractors (Xamarin productivity tool) working folder 338 | .mfractor/ 339 | -------------------------------------------------------------------------------- /.lychee.toml: -------------------------------------------------------------------------------- 1 | include_fragments = true 2 | 3 | # Accept 429 (rate limiting) to prevent failures 4 | accept = ["200..=299", "401", "403", "429"] 5 | 6 | exclude = [ 7 | # excluding links to user profiles is done for performance 8 | # because there are a lot of links to user profiles in this repository 9 | # and GitHub extra throttles access to user profile pages 10 | "^https://github.com/[^/]+$", 11 | ] 12 | 13 | exclude_path = [ 14 | # regular expressions aren't supported: https://github.com/lycheeverse/lychee/issues/1608 15 | "/home/repo/elections/2019/governance-committee-candidates.md", 16 | "/home/repo/elections/2019/governance-committee-election.md", 17 | "/home/repo/elections/2020/governance-committee-candidates.md", 18 | "/home/repo/elections/2020/governance-committee-election.md", 19 | "/home/repo/elections/2021/governance-committee-candidates.md", 20 | "/home/repo/elections/2021/governance-committee-election.md", 21 | "/home/repo/elections/2022/governance-committee-candidates.md", 22 | "/home/repo/elections/2022/governance-committee-election.md", 23 | "/home/repo/elections/2023/governance-committee-candidates.md", 24 | "/home/repo/elections/2023/governance-committee-election.md", 25 | "/home/repo/elections/2024/governance-committee-candidates.md", 26 | "/home/repo/elections/2024/governance-committee-election.md", 27 | ] 28 | 29 | # Retry configuration with more reasonable timeout values 30 | max_retries = 3 31 | # Wait time (in seconds) between retries with exponential backoff 32 | retry_wait_time = 1 33 | # Reduce number of concurrent requests to avoid triggering rate limits 34 | max_concurrency = 75 35 | -------------------------------------------------------------------------------- /ADOPTERS.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry Adopters 2 | 3 | This page has moved to [opentelemetry.io], see [Adopters]. 4 | 5 | [adopters]: https://opentelemetry.io/ecosystem/adopters/ 6 | [opentelemetry.io]: https://opentelemetry.io 7 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | ##################################################### 2 | # 3 | # List of approvers for OpenTelemetry Community repository 4 | # 5 | ##################################################### 6 | # 7 | # Learn about membership in OpenTelemetry community: 8 | # https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md 9 | # 10 | # 11 | # Learn about CODEOWNERS file format: 12 | # https://help.github.com/en/articles/about-code-owners 13 | # 14 | 15 | * @alolita @austinlparker @danielgblanco @jpkrohling @mtwo @mx-psi @svrnm @tedsuo @trask @open-telemetry/technical-committee 16 | -------------------------------------------------------------------------------- /COMMUNICATION.md: -------------------------------------------------------------------------------- 1 | # Communication within the OpenTelemetry Project 2 | 3 | ## Document purpose 4 | 5 | OpenTelemetry has a [Code of Conduct](./code-of-conduct.md) 6 | where maintainers and community members pledge to foster a welcoming and open 7 | community. The code of conduct cites examples of unacceptable behavior by 8 | participants – like harassment, trolling or personal attacks – that would lead to 9 | removal, revision, or rejection of contributions to the project. 10 | 11 | And while we all deserve to collaborate without fear of overt harassment and 12 | personal attacks, that is a very low bar! This document is aspirational, it 13 | describes **how we wish to communicate with each other** and **how we aspire to 14 | create an environment that cultivates trust**, even in the face of inevitable 15 | technical and organizational disagreements. 16 | 17 | Finally, this is **a living document** and should adapted over time as the 18 | OpenTelemetry project evolves and we face new challenges. At any time, there are 19 | certainly errors of omissions or even simple clarifications we can make to the 20 | wording here, and any and all are welcome to propose such changes. 21 | 22 | ## Communication guidelines 23 | 24 | What follows are an unordered list of principles that guide our communication 25 | with each other – both active community members as well as those who may just be 26 | "passing through" to file an issue or suggest an improvement. 27 | 28 | * **Critique ideas, not people:** It's fine and expected to disagree about 29 | technology and project direction. Even when those disagreements are 30 | significant or frustrating, though, it isn't acceptable to criticize the 31 | participants as people. In fact, it's usually a sign that there's no strong 32 | technical argument being made. (More specifically, see [this 33 | post](https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/) 34 | for tips about code reviews in particular) 35 | * **Be welcoming:** By nature, OpenTelemetry touches a lot of other projects and 36 | will thus have a larger-than-normal ratio of casual committers and passers-by. 37 | For this reason, it's especially important to be welcoming to newcomers. This 38 | means thanking people for their interest and contributions, and being patient 39 | with misunderstandings, especially by newcomers. In fact, newcomers points of 40 | confusion are a valuable signal pointing towards documentation gaps. 41 | * **Adjust your expectations** Not every part of the project has a maintainer 42 | available for quick support or bug fix. For some people this project is a full 43 | time job, for others is a weekend project. Don't get frustrated when you don't 44 | get response fast as you expected, find the way to escalate your issue to the 45 | right people's attention. 46 | * **Try to keep conversations in the open:** Where possible, try to have 47 | conversations in async formats like GitHub issues, PRs, and emails. If 48 | resolution requires a call or video conference, try to make a recording and 49 | notes available and discoverable to keep our community as accessible as 50 | possible across distant timezones. 51 | * **Strive for consensus, but don't require it:** Of course it's great when we 52 | can get everyone to agree. And certainly everyone should be – and should feel 53 | heard. As a rule of thumb, if there is a lone dissenter (or three) in any 54 | given discussion, their points should be clearly addressed: not just with a 55 | simplistic "Sorry, I disagree," but with a principled counterargument. 56 | Finally, our formal process for escalation and decision-making is a matter of 57 | policy, not just a matter of communication; as such, it is out of scope for 58 | this document. 59 | 60 | _Additional guidelines, edits, or other improvements to the above are always 61 | welcome._ 62 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | Welcome to OpenTelemetry community repository! 4 | 5 | Before you start - see OpenTelemetry general [contributing](guides/contributor/README.md) 6 | requirements and recommendations. 7 | 8 | ## Updating SIG information on the README.md 9 | 10 | The SIG tables on the [README.md](README.md) page are generated from [`sigs.yml`](sigs.yml). 11 | 12 | To regenerate those tables after updating any `sigs.yml` content, run: 13 | 14 | ```bash 15 | make table-generation 16 | ``` 17 | 18 | ## Updating the assets.md page 19 | 20 | The [`assets.md`](assets.md) page has an auto-generated table of contents. 21 | To regenerate the table of contents after updating any headings on that page, run: 22 | 23 | ```bash 24 | make markdown-toc 25 | ``` 26 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | # All documents to be used in spell check. 2 | ALL_DOCS := $(shell find . -type f -name '*.md' -not -path './.github/*' -not -path './node_modules/*' | sort) 3 | 4 | # This is needed to make the /repo paths below work in Windows Git Bash 5 | export MSYS_NO_PATHCONV=1 6 | 7 | .PHONY: table-generation 8 | table-generation: 9 | docker run --rm -v ${PWD}:/repo -w /repo python:3-alpine python ./scripts/update-sig-tables.py --install; 10 | 11 | validate-sigs: 12 | docker run --rm -v ${PWD}:/repo -w /repo python:3-alpine python ./scripts/validate-sigs.py --install; 13 | 14 | table-check: 15 | docker run --rm -v ${PWD}:/repo -w /repo python:3-alpine python ./scripts/update-sig-tables.py --install --check; 16 | 17 | .PHONY: markdown-link-check 18 | markdown-link-check: 19 | docker run --rm \ 20 | --mount 'type=bind,source=$(PWD),target=/home/repo' \ 21 | lycheeverse/lychee@sha256:2e3786630482c41f9f2dd081e06d7da1c36d66996e8cf6573409b8bc418d48c4 \ 22 | --config home/repo/.lychee.toml \ 23 | --root-dir /home/repo \ 24 | --verbose \ 25 | home/repo 26 | 27 | # This target runs markdown-toc on all files that contain 28 | # a pair of comments and . 29 | .PHONY: markdown-toc 30 | markdown-toc: 31 | @if ! npm ls markdown-toc; then npm install; fi 32 | @for f in $(ALL_DOCS); do \ 33 | if grep -q '' $$f; then \ 34 | echo markdown-toc: processing $$f; \ 35 | npx --no -- markdown-toc --no-first-h1 --no-stripHeadingTags -i $$f || exit 1; \ 36 | else \ 37 | echo markdown-toc: no TOC markers, skipping $$f; \ 38 | fi; \ 39 | done 40 | 41 | markdown-toc-check: markdown-toc 42 | git diff --exit-code ':*.md' || (echo 'Generated markdown Table of Contents is out of date, please run "make markdown-toc" and commit the changes in this PR.' && exit 1) 43 | -------------------------------------------------------------------------------- /areas-of-interest.md: -------------------------------------------------------------------------------- 1 | # Member areas of interest 2 | 3 | OpenTelemetry technical committee members, maintainers, and approvers 4 | may list their areas of interest below, to help the community to find 5 | good points of contact for topics of interest across the project. 6 | 7 | Technical committee members are required to list these areas of 8 | interest, and this is optional for maintainers and approvers. These 9 | listings may be useful to find an appropriate person to tag on an 10 | issue, for example. 11 | 12 | Members who are specifically employed by a company to contribute to 13 | the OpenTelemetry project are recommended to list their company 14 | affiliation, so that they may be contacted with vendor-specific 15 | concerns. 16 | 17 | ## Technical committee members 18 | 19 | ### [Armin Ruech](https://github.com/arminru), Dynatrace 20 | 21 | - Trace API and SDK 22 | - Semantic conventions 23 | 24 | ### [Bogdan Drutu](https://github.com/BogdanDrutu), Splunk 25 | 26 | - OpenTelemetry protocol 27 | - OpenTelemetry collector 28 | - Metrics API and SDK 29 | 30 | ### [Carlos Alberto](https://github.com/carlosalberto), Lightstep 31 | 32 | - Trace API and SDK 33 | - OpenTracing compatibility 34 | - Semantic conventions 35 | 36 | ### [Jack Berg](https://github.com/jack-berg), New Relic 37 | 38 | - Metrics API and SDK 39 | - Logging API and SDK 40 | - SDK configuration 41 | - OpenTelemetry Java 42 | - OpenTelemetry protocol 43 | 44 | ### [Josh Suereth](https://github.com/jsuereth), Google 45 | 46 | - Metrics API and SDK 47 | - OpenTelemetry Protocol 48 | - Telemetry correlation (Trace <-> Metrics <-> Logs via Resource, Exemplars, etc.) 49 | - Protocol compatibility (OpenCensus, Prometheus, Statsd, etc.) 50 | - Semantic conventions 51 | 52 | ### [Liudmila Molkova](https://github.com/lmolkova), Microsoft 53 | 54 | - Trace API and SDK 55 | - Semantic conventions 56 | - Instrumentation 57 | 58 | ### [Reiley Yang](https://github.com/reyang), Microsoft 59 | 60 | - Logging API and SDK 61 | - Metrics API and SDK 62 | - Trace API and SDK 63 | - OpenTelemetry .NET 64 | - OpenTelemetry C++ 65 | - W3C trace context specification 66 | 67 | ### [Tigran Najaryan](https://github.com/tigrannajaryan), Splunk 68 | 69 | - OpenTelemetry protocol 70 | - OpenTelemetry schemas and versioning 71 | - Logging API and SDK 72 | - Entities 73 | - OpAMP 74 | 75 | ## Specification sponsors 76 | 77 | ### [Alex Boten](https://github.com/codeboten), Honeycomb 78 | 79 | - OpenTelemetry Collector 80 | - OpenTelemetry Python 81 | - SDK configuration 82 | 83 | ### [Christian Neumüller](https://github.com/Oberon00), Dynatrace 84 | 85 | ### [Cijo Thomas](https://github.com/cijothomas), Microsoft 86 | 87 | ### [Daniel Dyla](https://github.com/dyladan), Dynatrace 88 | 89 | - OpenTelemetry JavaScript 90 | - W3C Trace Context Specification 91 | - Trace and Metrics 92 | - Trace Sampling 93 | 94 | ### [David Ashpole](https://github.com/dashpole), Google 95 | 96 | ### [Josh MacDonald](https://github.com/jmacd), Microsoft 97 | 98 | - Metrics API and SDK and data model 99 | - Metrics collection infrastructure 100 | - Metrics protocol compatibility 101 | - OpenTelemetry protocol 102 | - Trace sampling algorithms 103 | - Trace API & SDK 104 | 105 | ### [Juraci Paixão Kröhling](https://github.com/jpkrohling), Grafana Labs 106 | 107 | - OpenTelemetry Collector 108 | - Distributed tracing 109 | - Security 110 | - Sampling 111 | 112 | ### [Leighton Chen](https://github.com/lzchen), Microsoft 113 | 114 | ### [Marc Alff](https://github.com/marcalff), Oracle 115 | 116 | - Trace API and SDK 117 | - Metrics API and SDK 118 | - SDK configuration 119 | - Security 120 | - OpenTelemetry C++ 121 | 122 | ### [Robert Pająk](https://github.com/pellared), Splunk 123 | 124 | ### [Severin Neumann](https://github.com/svrnm), Cisco 125 | 126 | ### [Ted Young](https://github.com/tedsuo), Grafana Labs 127 | 128 | ### [Tristan Sloughter](https://github.com/tsloughter), MyDecisiveAI 129 | 130 | - Trace and Metrics API & SDK 131 | - OpenTelemetry Erlang 132 | - Developer Experience 133 | - SDK configuration 134 | 135 | ### [Tyler Yahn](https://github.com/MrAlias), Splunk 136 | 137 | ## Maintainers and approvers 138 | 139 | Maintainers and approvers are invited to list their areas of interest 140 | to further assist the community in finding appropriate points of 141 | contact. 142 | 143 | ### [Dan Jaglowski](https://github.com/djaglowski), observIQ 144 | 145 | - OpenTelemetry collector 146 | - Log data model 147 | - Traditional log ingestion 148 | - Telemetry processing 149 | 150 | ### [Tom Tan](https://github.com/ThomsonTan), Microsoft 151 | 152 | - Logging API and SDK 153 | - Trace API and SDK 154 | - OpenTelemetry C++ 155 | - OpenTelemetry Protocol 156 | 157 | ### [Severin Neumann](https://github.com/svrnm/), Independent 158 | 159 | - Contributor Experience 160 | - Distributed Tracing 161 | - Documentation 162 | - Security 163 | 164 | 165 | -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry Community Code of Conduct 2 | 3 | The OpenTelemetry project aims to be a welcoming place where new and existing 4 | members feel safe to respectfully share their opinions and disagreements. We 5 | want to attract a diverse group of people to collaborate with us, which means 6 | acknowledging that people come from different backgrounds and cultures. 7 | 8 | This project is bound by and abides by the [CNCF Code of 9 | Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). 10 | Conflicts should be resolved respectfully between the involved parties, however 11 | we understand that it may not always be possible without outside help or 12 | mediation. When needed, any community member can ask for help or report a Code 13 | of Conduct violation to the Governance Committee as outlined below. The project 14 | prefers for violations to be reported first to the Governance Committee so that 15 | they may be resolved internally, however, in extreme cases code of conduct 16 | violations should be reported to the CNCF as outlined in the [CNCF Incident 17 | Resolution 18 | Procedures](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-incident-resolution-procedures.md). 19 | Anyone who is unsure if a violation should be reported to the project or the 20 | CNCF should refer to the [CNCF CoC Jurisdiction 21 | Policy](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-committee-jurisdiction-policy.md). 22 | 23 | ## Reporting violations 24 | 25 | If you have seen or experienced unacceptable behavior or anything that would 26 | make our community less welcoming, please speak up! 27 | 28 | When the Governance Committee (GC) determines that a code of conduct violation 29 | happened, it will take the actions deemed necessary and appropriate for the 30 | event. In more serious cases, the community member might be requested to depart 31 | from our communities, giving up any roles they may possess, such as the 32 | maintainership of a SIG. In extreme cases, the GC can force the departure of the 33 | member. 34 | 35 | ## Submit in writing 36 | 37 | To report a violation in writing, please email 38 | cncf-opentelemetry-governance@lists.cncf.io, which goes to all GC members. If 39 | you do not want your report to be received by all GC members, either because you 40 | want to submit a report anonymously or because one of the GC members has a 41 | conflict of interest, you may send your report directly to any individual GC 42 | member. The [current list of members](./community-members.md#governance-committee) 43 | can be found on our community repository, and you can ping any of them directly 44 | on [CNCF’s Slack](https://slack.cncf.io) 45 | 46 | ## Submit in spoken conversation 47 | 48 | If you prefer to report the violation in a spoken conversation, you may request 49 | a telephone conversation or virtual meeting with a GC member. 50 | 51 | # How to report anonymously 52 | 53 | If you desire to submit a report anonymously, please send a message directly to 54 | any individual member of our GC through the CNCF Slack and let them know you 55 | would like to submit a Code of Conduct report anonymously. If you submit your 56 | report anonymously, that member of the GC will share the contents of your report 57 | with the rest of the GC, but they will not disclose your identity as the 58 | reporter to the other members of the GC (unless such disclosure is necessary to 59 | comply with applicable laws or a court order, or to protect you or someone else 60 | from imminent danger). 61 | -------------------------------------------------------------------------------- /community-membership.md: -------------------------------------------------------------------------------- 1 | This document was moved here: 2 | 3 | https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md 4 | -------------------------------------------------------------------------------- /docs/how-meeting-recordings-upload-works.md: -------------------------------------------------------------------------------- 1 | # How automatic video upload works 2 | 3 | Videos are being recorded using one of [zoom accounts](../assets.md#zoom-accounts) used by OpenTelemetry. OpenTelemetry zoom accounts are paid for and owned by CNCF. 4 | 5 | ## Video upload process 6 | 7 | - All meetings are configured for automatic recording start. No host present necessary. 8 | - Once meeting is concluded, all participants need to leave the meeting room so the recording will be uploaded to zoom cloud. 9 | - Every recorded meeting (of length 1 minute or longer) is picked up by 10 | [Zapier](../assets.md#zapier-account) (https://zapier.com). 11 | Zapier is configured to automatically post links of the Zoom cloud recordings 12 | (along with the meeting name, start time and duration) to a 13 | [publicly viewable Google spreadsheet](https://docs.google.com/spreadsheets/d/1SYKfjYhZdm2Wh2Cl6KVQalKg_m4NhTPZqq-8SzEVO6s). 14 | - It typically takes an hour for the video to be processed by Zapier. 15 | 16 | ## Video archival process 17 | 18 | - Meetings older than 6 months are manually removed from the publicly viewable spreadsheet. Direct links to the recordings will still work after this. Follow these steps to archive links: 19 | 1. Add any entries on the public spreadsheet to the ['Zoom recordings archive' spreadsheet](https://docs.google.com/spreadsheets/d/1U34Ae4D8EMhMbrFujdSRjoHBae3o9pvptLO1c6X4RPI/edit?usp=sharing). This spreadsheet is only viewable by the admin GSuite account. 20 | 2. Remove the entries from the public spreadsheet. 21 | 22 | ## Video is missing or no longer available in spreadsheet - what to do 23 | 24 | - Post an [issue](https://github.com/open-telemetry/community/issues/new) with the following information: 25 | - meeting name (e.g. Java SIG) 26 | - exact datetime with the timezone of the meeting 27 | - zoom link used 28 | - duration (as you remember it), approx 30 min, approx 1 hour, etc. 29 | - any details like meeting was back to back with other meeting and people joined for the next meeting before this one concluded. Or meeting had some strange accounts joining and zoom bombing, etc. 30 | - If older than 6 months, provide a rationale for requesting the meeting recording (e.g. what topic you are interested in learning more about). 31 | 32 | ### Steps to find the missing video 33 | 34 | - If older than 6 months, check the ['Zoom recordings archive' spreadsheet](https://docs.google.com/spreadsheets/d/1U34Ae4D8EMhMbrFujdSRjoHBae3o9pvptLO1c6X4RPI/edit?usp=sharing) for the meeting link. 35 | - Otherwise 36 | - Find the zoom account corresponding to the meeting link. Mapping from static rooms to the account may be found in the zoom bombing document referred from [this page](../docs/how-to-handle-public-calendar.md#zoom-bombing-prevention). 37 | - If non OpenTelemetry zoom account was used, there will be no recording available. Please contact the owner of the zoom account linked from the event. 38 | - In the zoom account, check if the meeting recording present. If recording is there, it is a Zapier integration issue. 39 | - If recording is missing in zoom account, check the meeting room settings. Make sure that automatic meeting recording is enabled. 40 | - If setting is set, likely the meeting recording was stopped using the host key and the recording doesn't exist. 41 | -------------------------------------------------------------------------------- /docs/how-to-handle-public-calendar.md: -------------------------------------------------------------------------------- 1 | # How to create and configure meetings 2 | 3 | In OpenTelemetry we are using the CNCF's Zoom accounts. We currently own five 4 | identical zoom accounts. 5 | 6 | All rooms are configured the same way. Some notes on meetings configuration: 7 | 8 | - **The host is not required** to join the meeting. Anybody can join the meeting. 9 | - **There is no time limit on the length of the meeting**. Please make sure nobody is 10 | using this room for another meeting on the calendar when meeting is going long 11 | over time. 12 | - **Auto-recording is enabled for all meetings**. All OpenTelemetry public meetings are recorded automatically 13 | and [available on Zoom cloud](https://docs.google.com/spreadsheets/d/1SYKfjYhZdm2Wh2Cl6KVQalKg_m4NhTPZqq-8SzEVO6s). 14 | 15 | Every meeting must contain a link to the meeting notes. The meeting notes 16 | document must be shared with write or commenting permissions. If giving edit permissions to everyone, 17 | go into the document share settings and uncheck "Editors can change permissions and share". 18 | 19 | All meetings should invite a publicly joinable google group `calendar-...@opentelemetry.io` which is specific to the meeting series 20 | and also the global [calendar-all@opentelemetry.io](https://groups.google.com/a/opentelemetry.io/g/calendar-all). 21 | This way anyone who wants to receive up-to-date invites can join one of those groups 22 | (see [Inviting attendees](#inviting-attendees) below). 23 | 24 | ## Steps 25 | 26 | To create or edit a meeting, you need to have access to the Public OpenTelemetry calendar (a shared Google calendar) and you must add a Zoom meeting link. 27 | 28 | ### Gaining Calendar Permissions 29 | 30 | All SIG maintainers can get access to edit the public OpenTelemetry calendar 31 | by submitting a request to join the google group 32 | [calendar-edit-permission@opentelemetry.io](https://groups.google.com/a/opentelemetry.io/g/calendar-edit-permission). 33 | If your identity is not recognizable from the e-mail you are using to request joining the group, please 34 | request to be added to this Google Group by creating an issue in this repository. 35 | 36 | Please keep the membership of this group up to date and accurate. 37 | 38 | ### Create the meeting 39 | 40 | :warning: The meeting must initially be created by the account, 41 | otherwise synchronization to external calendars via the `calendar-*@opentelemetry.io` groups may not work. 42 | 43 | The following details need to be set properly: 44 | 45 | - Title 46 | - Timeslot, using one of the following timezones: 47 | - Pacific Time (PT), with Daylight Saving Time. 48 | - UTC+8, without Daylight Saving Time. 49 | - Recurrence pattern (usually weekly or bi-weekly) 50 | - Location (see below for the Zoom links) 51 | - Description 52 | - A brief description on the scope of the meeting 53 | - A link to the meeting notes 54 | - The meeting notes should be owned by the shared Governance Committee Google account. 55 | Having a document created can be requested from the GC via opening an issue in this repository. 56 | The document permissions should be set so that anyone with the link can edit. 57 | Under advanced permissions, "Editors can change permissions and share" should be unchecked. 58 | - Invited attendees (see below) 59 | - Guest permissions: 60 | - Modify event: no 61 | - Invite others: no 62 | - See guest list: yes 63 | 64 | ### Adding a Zoom link to a meeting 65 | 66 | Open an issue in the community repository, requesting a new Zoom link. 67 | By requesting a new Zoom link that is only associated with a single meeting series, the meeting recordings 68 | can be associated with a meeting name. 69 | The Zoom link will be created in one of the 5 OpenTelemetry Zoom account. 70 | A single Zoom account should not be used for back-to-back meetings or for more than two meetings at the same time. 71 | You can see which Zoom account any potentially conflicting meetings are using in the meeting descriptions. 72 | (Note: posting the URLs publicly on GitHub leads to Zoom bombing by random bots). 73 | 74 | #### Zoom link generation process 75 | 76 | _This is the process that the person responding to Zoom link creation issues will follow. The instructions under this heading are for project admins (Governance Committee members) who have access to OpenTelemetry's Zoom account credentials._ 77 | 78 | 1. View the OpenTelemetry meeting calendar, and find your desired time slot, along with the meetings that occur immediately before, during, and after it. 79 | 2. See which OpenTelemetry Zoom accounts are being used for the meetings immediately before, during, and after your desired time. The Zoom account name / number is typically listed in the description of each meeting; if it isn't, you can join a meeting (even if it isn't occurring now), click on the green shield icon in the top left, and see the account name / number in the 'host' field. 80 | 3. Choose a Zoom account that isn't already being used for one of the meetings immediately before, during, or after your desired time slot. You may also choose a Zoom account that is being used *exactly* once immediately before, during, or after (we can run a maximum of two concurrent meetings with each account). 81 | 4. Log into that Zoom account, click "Schedule a meeting" 82 | - Set the topic (this is what will show up in the 83 | [meeting recording sheet](https://docs.google.com/spreadsheets/d/1SYKfjYhZdm2Wh2Cl6KVQalKg_m4NhTPZqq-8SzEVO6s/edit)) 84 | - Set recurrence to "No fixed time" 85 | - Save 86 | 5. Copy the newly generated unique Zoom link and paste it into the calendar event's description and location. 87 | 88 | ### Inviting attendees 89 | 90 | All meetings should invite a publicly joinable google group `calendar-...@opentelemetry.io` which is specific to the meeting series. 91 | The google group should be set up as follows: 92 | 93 | - Who can search for group: Anyone on the web 94 | - Who can join group: Anyone can join 95 | - Who can view conversations: Group members 96 | - Who can post: Group members 97 | - Who can view members: Group managers 98 | 99 | And set admin@opentelemetry.io's own subscription to "No email" under the membership settings for that google group. 100 | 101 | This allows anyone to subscribe to this specific meeting series by joining that google group. 102 | Please open a community issue to request the creation of a `calendar-...@opentelemetry.io` google group. 103 | 104 | ### Update the meetings overview 105 | 106 | All recurring meetings are listed in the [Community repo's README](../README.md#special-interest-groups), make sure to add/update the respective entry there. 107 | 108 | ## Zoom bombing prevention 109 | 110 | All meetings are created by Zoom with randomized passcodes, which are embedded into the shared calendar links. 111 | All members of [calendar-edit-permission@opentelemetry.io](https://groups.google.com/a/opentelemetry.io/g/calendar-edit-permission) 112 | have access to [this document](https://docs.google.com/document/d/1gt9ctxKGPrM_XTINqLgkSxYypdrczHkt2znjwgBU4UU/edit#) 113 | listing the host keys for our meetings and explaining how to deal with inappropriate behavior in Zoom. 114 | -------------------------------------------------------------------------------- /docs/how-to-setup-new-slack-channel.md: -------------------------------------------------------------------------------- 1 | # How we setup new Slack channels 2 | 3 | ## Naming 4 | 5 | Most channels have a name pattern like `#otel-*`. We recommend that pattern 6 | for consistency. 7 | 8 | ## Channel Settings 9 | 10 | The following channel settings help users to understand what a channel is 11 | for and how to quickly access common resources. 12 | 13 | ### Topic 14 | 15 | Describe in a few words what the purpose of this channel is. Assume that end users might not be aware that 16 | `#otel-foo` is the channel of the OpenTelemetry Foo SIG, or what this SIG is doing. A few examples: 17 | 18 | - `Discussion of the Java implementation of OpenTelemetry, including the javaagent and instrumentation` 19 | - `Discussion of the OpenTelemetry specification` 20 | - `OpenTelemetry semantic conventions in the security domain` 21 | - `OpenTelemetry Contributor Experience SIG: Improving the experience for those who contribute to OpenTelemetry` 22 | 23 | ### Description 24 | 25 | If the topic field does not provide enough space to write out what your channel is about, you can provide 26 | a more detailed description, otherwise leave it empty. 27 | 28 | ### Channel Manager 29 | 30 | Make sure that all maintainers of your SIG are set as [Channel Managers](https://slack.com/help/articles/8328303095443-Understand-Channel-Managers-in-Slack). 31 | The person who creates the channel, will be a Channel Manager by default and can invite the maintainers. 32 | 33 | Do also make the [`OpenTelemetry Admin`](https://cloud-native.slack.com/archives/D07EGBA9V6E) user a Channel Manager. 34 | [The Governance Committee manages this shared account](../assets.md#slack). 35 | 36 | ### Bookmarks 37 | 38 | If the channel is for a specific SIG add bookmarks for the following resources: 39 | 40 | - Meeting Notes (Google Docs, `https://docs.google.com/document/d/`) 41 | - Project Board (GitHub, `https://github.com/orgs/open-telemetry/projects/`) 42 | - Get Meeting Invites (Google group for calendar invites, `https://groups.google.com/a/opentelemetry.io/g/calendar-`) 43 | - Issue Tracker (GitHub, `https://github.com/open-telemetry//issues`) 44 | 45 | Feel free to add any other link you think is helpful for users to interact with 46 | your SIG, or links that help your triagers, approvers and maintainers for quick access. 47 | 48 | ### Workflows 49 | 50 | You can add workflows to your channel, e.g. 51 | 52 | - A reminder for an upcoming SIG meeting 53 | - A welcome message to new users 54 | -------------------------------------------------------------------------------- /docs/images/google-calendar-colors.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/docs/images/google-calendar-colors.png -------------------------------------------------------------------------------- /docs/using-github-extensions.md: -------------------------------------------------------------------------------- 1 | # Using GitHub Apps, Extensions, and bots 2 | 3 | In OpenTelemetry it is critically important to preserve code integrity, including copyright. 4 | 5 | Extensions, apps, or bots that can **arbitrarily modify code are NOT allowed**. Read-only code access, opening pull requests from another fork, or bug triage bots can be considered to be installed. 6 | 7 | ## Requesting installing of Apps, Extensions, or bots 8 | 9 | - The default answer for installing third party tools in the org is "NO". Justification needs to be provided and supported by multiple org members. 10 | - Open an issue at https://github.com/open-telemetry/community/issues 11 | - Include reasoning and SIG(s) requesting this 12 | - List permissions required by this extension, app, or bot. 13 | - If possible: point to other uses of this extensions in OSS. 14 | - Requests from maintainers typically carry higher weight; please make sure to discuss in the SIG you participate. 15 | - If a third-party tool is requested for a specific repository, it is recommended to tag that repository's maintainers and ask them to +1 the request, such that there is a consensus among the majority of maintainers on adding the tool. 16 | - GC member needs to approve with no other GC members raising concerns. It is recommended to discuss each extension, app, or bot that is about to be installed at GC meeting for awareness. 17 | - Once GC approval received, TC member will install the extension. 18 | 19 | ## Writing your GitHub Action workflows 20 | 21 | Many GitHub Action workflows do not require a dedicated GitHub account. Good examples are stale PR checks such as [the one used in semantic convention repo](https://github.com/open-telemetry/semantic-conventions/blob/main/.github/workflows/stale-pr.yml). 22 | 23 | If your workflow does require a dedicated GitHub account, you should use [@opentelemetrybot](https://github.com/opentelemetrybot). 24 | See [OpenTelemetry Bot documentation](../assets.md#opentelemetry-bot) for more details. 25 | 26 | ## Creating your own GitHub extensions for OpenTelemetry 27 | 28 | We didn't encounter these requests yet. The policy will be created once it will become a problem. 29 | -------------------------------------------------------------------------------- /elections/2019/static/constance-caramanolis.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2019/static/constance-caramanolis.jpg -------------------------------------------------------------------------------- /elections/2019/static/kchu.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2019/static/kchu.jpeg -------------------------------------------------------------------------------- /elections/2019/static/liz_headshot.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2019/static/liz_headshot.jpg -------------------------------------------------------------------------------- /elections/2019/static/luis-mineiro_mugshot.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2019/static/luis-mineiro_mugshot.jpg -------------------------------------------------------------------------------- /elections/2019/static/morgan-james-mclean.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2019/static/morgan-james-mclean.jpg -------------------------------------------------------------------------------- /elections/2019/static/steven-le-roux.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2019/static/steven-le-roux.jpg -------------------------------------------------------------------------------- /elections/2019/static/ted-young.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2019/static/ted-young.jpg -------------------------------------------------------------------------------- /elections/2020/governance-committee-candidates.md: -------------------------------------------------------------------------------- 1 | # 2020 OpenTelemetry Governance Committee Candidates 2 | 3 | ## List of candidates 4 | 5 | In alphabetical order: 6 | 7 | - [2020 OpenTelemetry Governance Committee Candidates](#2020-opentelemetry-governance-committee-candidates) 8 | - [List of candidates](#list-of-candidates) 9 | - [Alolita Sharma](#alolita-sharma) 10 | - [Daniel Dyla](#daniel-dyla) 11 | - [Ilan Rabinovitch](#ilan-rabinovitch) 12 | - [Liz Fong-Jones](#liz-fong-jones) 13 | - [Morgan McLean](#morgan-mclean) 14 | - [Tyler Yahn (He/Him)](#tyler-yahn-hehim) 15 | 16 | --- 17 | 18 | ### Alolita Sharma 19 | 20 | ![Alolita Sharma](static/alolita-sharma.png) 21 | 22 | - Company: Amazon Web Services (AWS) 23 | - GitHub: [alolita](https://github.com/alolita) 24 | 25 | I am a [Principal Technologist](https://www.linkedin.com/in/alolita/) at AWS where I lead development of OpenTelemetry components focused on metrics and log based observability and where I collaborate with Microsoft, Google, LightStep, Splunk, RedHat and others. I [speak](https://alolitasharma.com/my-talks-and-presentations/) at open source conferences such as the Linux Foundation Open Source Summit, ATO, OSCON, FOSDEM and Unicode where I have addressed the challenges of building large scale open source projects, collaborating on open standards and accelerating technology innovation. I have been [Director of Engineering](https://www.mediawiki.org/wiki/User:Alolitas) at the Wikimedia Foundation and served as an Officer and [Board Member](https://en.wikipedia.org/wiki/Open_Source_Initiative) of the Open Source Initiative (OSI). I currently serve as a [Board Director](https://unicode.org/consortium/directors.html) of the Unicode Consortium. At Wikimedia, I increased the ease-of-use and accessibility of Wikipedia by adding multilingual editing and internationalization tools. At the OSI, I helped reduce open source license proliferation and created the OSI education outreach program. At the Unicode Consortium, I am serving on the Governance and Infrastructure Committees to help create the 2020-21 operating plan. I also contribute to the Unicode Technical Committee and W3C on language standardization. I have designed and implemented governance policies and processes for a variety of open source projects including those at Wikimedia, OSI and AWS. Enhancing accessibility, expanding standardization, encouraging education outreach and facilitating broad collaboration are vital for the success of OpenTelemetry. As a Governance Committee member, I would like to use the lessons I have learned to benefit the OpenTelemetry project and help unlock the full potential of open source observability. 26 | 27 | --- 28 | 29 | ### Daniel Dyla 30 | 31 | ![Daniel Dyla](static/daniel-dyla.jpg) 32 | 33 | - Company: Dynatrace 34 | - GitHub: [dyladan](https://github.com/dyladan) 35 | 36 | Daniel is an Open Source Architect at Dynatrace where he works on OpenTelemetry and related topics. He is a maintainer of the OpenTelemetry JS SIG and a contributor to the specification, as well as a regular specification meeting attendee. He is a member of the W3C Distributed Tracing Working Group where he works on the Trace Context and Baggage standards. Daniel has spoken at [Observe 2020](https://observe2020.io/) and participated as a panelist discussing observability and how it drives value for teams and customers. As a governance committee member, Daniel is interested in leveraging his experience and enthusiasm to drive the OpenTelemetry project forward and ensure it is a safe, inclusive, and rewarding experience for contributors, maintainers, and users. 37 | 38 | --- 39 | 40 | ### Ilan Rabinovitch 41 | 42 | ![Ilan Rabinovitch](static/ilan-rabinovitch.jpg) 43 | 44 | - Company: Datadog 45 | - GitHub: [@irabinovitch](https://github.com/irabinovitch) 46 | 47 | Ilan Rabinovitch leads the community and product teams at Datadog. He spends his days diving into monitoring best practices, collaborating with Datadog's open source community and evangelizing observability best practices. Over the last year, he has collaborated with the OTel governance board and SIGs to arrange the contribution of Datadog's tracing libraries and auto-instrumentation support to OpenTelemetry. Prior to joining Datadog, Ilan spent a number of years leading infrastructure and reliability engineering teams at organizations such as Ooyala and Edmunds.com. He's active in the wider open source and DevOps communities, including co-founding events such as SCALE, Texas Linux Fest, and various DevOpsDays events. 48 | 49 | --- 50 | 51 | ### Liz Fong-Jones 52 | 53 | Liz Fong-Jones profile image 54 | 55 | - Company: Honeycomb.io 56 | - GitHub: [lizthegrey](https://github.com/lizthegrey) 57 | 58 | Liz is Principal Developer Advocate at honeycomb.io, and previously worked at 59 | Google as a Staff Developer Advocate & Site Reliability Engineer. She's spent 60 | her career helping engineers improve the operability and observability of 61 | their systems. She is an approver for the OpenTelemetry Go SIG, wrote vendor 62 | exporters for Go and Python, and has contributed to the OpenTelemetry 63 | Collector. She has co-authored training & workshops to encourage OpenTelemetry 64 | adoption, and presented on OpenTelemetry's behalf at KubeCon/CloudNativeCon 65 | 2019. She co-hosts the biweekly OpenTelemetry Tuesdays livestreamed podcast. 66 | 67 | She has served an initial one-year term on the OpenTelemetry Governance 68 | Committee and is standing for re-election. 69 | 70 | --- 71 | 72 | ### Morgan McLean 73 | 74 | ![Morgan McLean](static/morgan-mclean.png) 75 | 76 | - Company: Google 77 | - GitHub: [mtwo](https://github.com/mtwo) 78 | 79 | Morgan is one of the co-founders of OpenTelemetry and currently serves on the 80 | Governance Committee. His accomplishments in the open source observability space include: 81 | 82 | - Co-creating OpenCensus at Google, defining its roadmap and release to customers, and growing the community 83 | - Orchestrating the merger of OpenCensus and OpenTracing into OpenTelemetry, defining the OpenTelemetry governance structure, etc. 84 | - Drafting the HTTP header specification that became W3C Trace Context, which he co-chairs 85 | - Organizing OpenTelemetry's beta, release candidate, and GA requirements, driving towards these releases, and shipping them 86 | - Speaking at the Kubecon and Next keynotes, and presenting OpenTelemetry in sessions at Kubecon, Next, Velocity, Monitorama, Perform, etc. 87 | - Growing the community and bringing in new partners like Microsoft, Dynatrace, etc. 88 | 89 | At Google, Morgan is responsible for all data ingestion into the Cloud Operations suite, 90 | APM tools, and the VM logging experience. 91 | Morgan's past roles include developing and operating high-scale services at Microsoft and 92 | developing high-performance client code at Microsoft and BioWare. 93 | 94 | --- 95 | 96 | ### Tyler Yahn (He/Him) 97 | 98 | ![Tyler Yahn](static/tyler-yahn.jpeg) 99 | 100 | - Company: New Relic 101 | - GitHub: [@MrAlias](https://github.com/MrAlias) 102 | 103 | Tyler has been an active contributor to the OpenTelemetry project for almost a 104 | full year. During that time Tyler has served as an Approver and then a Maintainer 105 | of the OpenTelemetry Go SIG and actively participated in the Specification SIG 106 | including taking on the role of a Metrics Approver. As OpenTelemetry moves into 107 | the future it has the potential to greatly help the technology community at large. 108 | Tyler is excited to help cultivate and promote the growth of the OpenTelemetry 109 | community and help ensure its success. 110 | -------------------------------------------------------------------------------- /elections/2020/static/alolita-sharma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2020/static/alolita-sharma.png -------------------------------------------------------------------------------- /elections/2020/static/ann-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2020/static/ann-example.png -------------------------------------------------------------------------------- /elections/2020/static/daniel-dyla.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2020/static/daniel-dyla.jpg -------------------------------------------------------------------------------- /elections/2020/static/ilan-rabinovitch.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2020/static/ilan-rabinovitch.jpg -------------------------------------------------------------------------------- /elections/2020/static/lizf.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2020/static/lizf.jpg -------------------------------------------------------------------------------- /elections/2020/static/morgan-mclean.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2020/static/morgan-mclean.png -------------------------------------------------------------------------------- /elections/2020/static/tyler-yahn.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2020/static/tyler-yahn.jpeg -------------------------------------------------------------------------------- /elections/2021/static/bhs.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/bhs.jpg -------------------------------------------------------------------------------- /elections/2021/static/bogdan-drutu.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/bogdan-drutu.jpg -------------------------------------------------------------------------------- /elections/2021/static/csuzhang.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/csuzhang.jpg -------------------------------------------------------------------------------- /elections/2021/static/ilan-rabinovitch.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/ilan-rabinovitch.jpeg -------------------------------------------------------------------------------- /elections/2021/static/jpkroehling.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/jpkroehling.jpg -------------------------------------------------------------------------------- /elections/2021/static/punya-biswal.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/punya-biswal.jpg -------------------------------------------------------------------------------- /elections/2021/static/sergeykanzhelev.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/sergeykanzhelev.jpeg -------------------------------------------------------------------------------- /elections/2021/static/sharr-creeden.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/sharr-creeden.jpg -------------------------------------------------------------------------------- /elections/2021/static/steve-flanders.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/steve-flanders.jpg -------------------------------------------------------------------------------- /elections/2021/static/ted-young.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2021/static/ted-young.jpg -------------------------------------------------------------------------------- /elections/2022/static/Reese-Lee.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/Reese-Lee.jpg -------------------------------------------------------------------------------- /elections/2022/static/alolita-sharma-picture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/alolita-sharma-picture.png -------------------------------------------------------------------------------- /elections/2022/static/daniel-dyla.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/daniel-dyla.jpg -------------------------------------------------------------------------------- /elections/2022/static/kenfinnigan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/kenfinnigan.png -------------------------------------------------------------------------------- /elections/2022/static/mhausenblas.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/mhausenblas.png -------------------------------------------------------------------------------- /elections/2022/static/morgan-mclean.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/morgan-mclean.png -------------------------------------------------------------------------------- /elections/2022/static/pavolloffay.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/pavolloffay.jpeg -------------------------------------------------------------------------------- /elections/2022/static/phillip-carter.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/phillip-carter.jpeg -------------------------------------------------------------------------------- /elections/2022/static/reiley-yang.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/reiley-yang.jpeg -------------------------------------------------------------------------------- /elections/2022/static/seanmarciniak.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/seanmarciniak.jpg -------------------------------------------------------------------------------- /elections/2022/static/severin-neumann.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/severin-neumann.jpg -------------------------------------------------------------------------------- /elections/2022/static/trask-stalnaker.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/trask-stalnaker.png -------------------------------------------------------------------------------- /elections/2022/static/tyler-yahn.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/tyler-yahn.jpeg -------------------------------------------------------------------------------- /elections/2022/static/vijay-samuel.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2022/static/vijay-samuel.jpg -------------------------------------------------------------------------------- /elections/2023/static/austin-parker.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/austin-parker.jpg -------------------------------------------------------------------------------- /elections/2023/static/daniel-gomezblanco.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/daniel-gomezblanco.png -------------------------------------------------------------------------------- /elections/2023/static/eric-sirianni.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/eric-sirianni.jpg -------------------------------------------------------------------------------- /elections/2023/static/johannes-tax.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/johannes-tax.gif -------------------------------------------------------------------------------- /elections/2023/static/jpkroehling.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/jpkroehling.webp -------------------------------------------------------------------------------- /elections/2023/static/severin-neumann.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/severin-neumann.jpg -------------------------------------------------------------------------------- /elections/2023/static/steve-flanders.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/steve-flanders.jpg -------------------------------------------------------------------------------- /elections/2023/static/ted-young.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/ted-young.jpg -------------------------------------------------------------------------------- /elections/2023/static/vijay-samuel.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2023/static/vijay-samuel.jpg -------------------------------------------------------------------------------- /elections/2024/static/Adriana Villela - 2024-06-20 - smaller.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2024/static/Adriana Villela - 2024-06-20 - smaller.jpeg -------------------------------------------------------------------------------- /elections/2024/static/alolita-sharma-picture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2024/static/alolita-sharma-picture.png -------------------------------------------------------------------------------- /elections/2024/static/daniel-dyla.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2024/static/daniel-dyla.jpg -------------------------------------------------------------------------------- /elections/2024/static/jamie-danielson.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2024/static/jamie-danielson.png -------------------------------------------------------------------------------- /elections/2024/static/maryliag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2024/static/maryliag.png -------------------------------------------------------------------------------- /elections/2024/static/pablo-baeyens.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2024/static/pablo-baeyens.jpg -------------------------------------------------------------------------------- /elections/2024/static/trask-stalnaker.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/elections/2024/static/trask-stalnaker.png -------------------------------------------------------------------------------- /gc-check-ins.md: -------------------------------------------------------------------------------- 1 | # Regular check-ins with SIG leads 2 | 3 | As defined in the [charter of the GC](./governance-charter.md#regular-check-ins-with-sig-leads) the GC will check in with maintainers of all long-term and short-term SIGs on a regular basis. During this check in, 4 | 5 | * any project files or roadmap entries should be reviewed to verify that they are still accurate. 6 | * if a SIG lead has any private concerns they wish to raise with the Governance Committee, this is an opportunity to do so. 7 | * the health of the SIG will be reviewed, and what measures can be applied to help the SIG. 8 | 9 | The check in process is as follows: 10 | 11 | * For each SIG a GC member is appointed as a GC liaison. The name of that person is listed [here](https://github.com/open-telemetry/community/tree/main?tab=readme-ov-file#special-interest-groups). 12 | * If a GC member was the sponsor for [the formation of the SIG](./project-management.md), they are by default the GC liaison for this SIG. 13 | * If a GC member is the maintainer themselves, they are by default the GC liaison for this SIG. 14 | * The GC liaison is appointed for the duration of the project lifecycle, or until they do not get reelected into the GC. Outside of that regular duration, a GC liaison can resign by providing a named successor. 15 | * The GC liaison is responsible to check in with the maintainers at least once per month. This can either happen via a (private, non recorded) meeting or through a text-based conversation initiated by the GC liaison. 16 | * The GC liaison is responsible to bring the concerns of the SIG leads forward to the GC, and they are responsible for ensuring that all action items agreed upon during that check in are logged as issues on the project repository or community repository. 17 | * The GC liaison will attend the regular project meetings at least once per quarter. If this is difficult to accomplish due to timezone constraints, the GC liaison can be freed from this obligation by the GC. This exception should only rarely be approved. 18 | * The GC liaison and the maintainers are responsible to provide a quarterly health update, where they assess project health along three dimensions: 19 | * Whether the SIG is making reasonable progress, and if published "On Schedule" relative to its own roadmap 20 | * The "contributor experience": # of new contributors/triagers/maintainers, PR turnaround time, newbie-friendly issues, advancement opportunities, automation, etc 21 | * The "maintainer experience": workload, burnout, collaboration, etc. 22 | -------------------------------------------------------------------------------- /guides/README.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry Guidebooks 2 | 3 | This directory contains a collection of guides meant for contributors, 4 | maintainers, and community members. These guides are meant to help you get 5 | started, answer common questions, and provide best practices for being a part of 6 | the OpenTelemetry community. These should be considered a living resource, and 7 | everyone is welcome to contribute to them! 8 | 9 | - [Contributor Guide](./contributor/README.md) 10 | - [Policy on Generative AI Contributions](./contributor/genai.md) 11 | - [Donations of pre-existing code](./contributor/donations.md) 12 | - [Becoming a member of the OpenTelemetry project](./contributor/membership.md) 13 | - [The Contribution Lifecycle](./contributor/processes.md) 14 | - [Maintainer Guide](./maintainer/README.md) 15 | - [Resolving technical conflicts](./maintainer/conflict-resolution.md) 16 | -------------------------------------------------------------------------------- /guides/contributor/CLA.md: -------------------------------------------------------------------------------- 1 | # The Contributor License Agreement 2 | 3 | The [Cloud Native Computing Foundation](https://www.cncf.io) (CNCF) defines 4 | the legal status of the contributed code in two different types of _Contributor License Agreements_ 5 | (CLAs), [individual contributors](https://github.com/cncf/cla/blob/main/individual-cla.pdf) and [corporations](https://github.com/cncf/cla/blob/main/corporate-cla.pdf). 6 | 7 | OpenTelemetry can only accept original source code from CLA signatories. 8 | 9 | It is important to read and understand this legal agreement. 10 | 11 | ## How do I sign? 12 | 13 | After creating your first Pull Request, the linux-foundation-easycla bot will respond with information regarding your CLA status along with a link to sign the CLA. 14 | 15 | EasyCLA bot 16 | 17 | #### 1. If you are signing up as a corporate contributor, ensure that you have linked your corporate email address to your GitHub profile (it doesn't have to be your primary email address for GitHub) or else it can lead to issues with the CLA system. 18 | 19 | For more information, please see [Adding an email address to your GitHub account](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/adding-an-email-address-to-your-github-account). 20 | 21 | #### 2. Authorize EasyCLA to read some of your GitHub information 22 | 23 | GitHub EasyCLA Authorization 24 | 25 | - Click on the **Please click here to be authorized** link to navigate to the GitHub Authorize Linux Foundation: EasyCLA page. 26 | - Then click **Authorize LF-Engineering** to give the Linux Foundation read-only access to list the email addresses associated with your GitHub account. 27 | 28 | #### 3. Select from the two types of contributor 29 | 30 | EasyCLA 31 | 32 | 33 | After authorizing EasyCLA, you will be redirected to a page to identify which type of contributor you are. 34 | Select the most appropriate option: 35 | * Individual Contributor: You are contributing as yourself, and not as part of another organization. 36 | * Corporate Contributor: You are contributing on behalf of your employer or other organization. 37 | 38 | #### 4. Sign the CLA 39 | 40 | Once you select the type of contributor, proceed to Sign the CLA and follow the instructions to complete the signing process through DocuSign. 41 | 42 | After you have filled out the information, click "Finish" and you will be redirected back to your Pull Request. 43 | 44 | #### 5. Look for an email indicating successful signup. 45 | 46 | > Hello, 47 | > 48 | > This is a notification email from EasyCLA regarding the project Cloud Native Computing > Foundation (CNCF). 49 | > 50 | > The CLA has now been signed. You can download the signed CLA as a PDF here. 51 | > 52 | > If you need help or have questions about EasyCLA, you can read the documentation or reach out to us for support. 53 | > 54 | > Thanks, 55 | > EasyCLA Support Team 56 | 57 | 58 | 59 | #### 6. Validate your CLA 60 | 61 | Once you are redirected back to your GitHub Pull Request, reply with a comment `/easycla` to update the CLA status of your PR, 62 | if the bot hasn't picked up the change automatically yet. 63 | 64 | 65 | ## Changing your Affiliation 66 | 67 | If you've changed employers and still contribute to OpenTelemetry, your affiliation 68 | needs to be updated. The Cloud Native Computing Foundation uses [gitdm](https://github.com/cncf/gitdm) 69 | to track who is contributing and from where. Create a pull request on the [gitdm](https://github.com/cncf/gitdm) 70 | repository with a change to the corresponding developer affiliation text file. 71 | Your entry should look similar to this: 72 | 73 | ``` 74 | Jorge O. Castro*: jorge!heptio.com, jorge!ubuntu.com, jorge.castro!gmail.com 75 | Heptio 76 | Canonical until 2017-03-31 77 | ``` 78 | 79 | In addition, be sure to update your affiliation on [OpenProfile](https://openprofile.dev). 80 | 81 | ## Troubleshooting 82 | 83 | If you encounter any problems signing the CLA and need further assistance, log a ticket by clicking on the link 'please submit a support request ticket' from the EasyCLA bot's response. Someone from the CNCF will respond to your ticket to help. 84 | 85 | Should you have any issues using the LF Support Site, send a message to the 86 | backup email support address 87 | 88 | [Linux Foundation Support Site]: https://support.linuxfoundation.org/ 89 | -------------------------------------------------------------------------------- /guides/contributor/README.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry New Contributor Guide 2 | 3 | Welcome to OpenTelemetry! We're excited for you to join us. This guide will help 4 | you get started by providing an overview of the project, how we work together, 5 | and where to find helpful resources. 6 | 7 | ## Table of Contents 8 | 9 | - [What is OpenTelemetry?](#what-is-opentelemetry) 10 | - [Prerequisites](#prerequisites) 11 | 12 | ## What is OpenTelemetry? 13 | 14 | OpenTelemetry is a framework for application telemetry data. If you've ever 15 | checked how much memory a process is using on your computer, or looked at the 16 | size of a file, you've already interacted with telemetry! Cloud native systems 17 | create, emit, and process many millions of telemetry points every second as they 18 | run. In addition, the developers of cloud native software need to describe what 19 | their applications are doing in production in order to find bugs, optimize their 20 | system performance, and understand their applications. OpenTelemetry provides a 21 | single standard for creating and collecting this telemetry, transforming it as 22 | needed, and exporting it to dozens of analysis tools. 23 | 24 | ## Prerequisites 25 | 26 | Before you submit code to OpenTelemetry, you'll need to have a few things set 27 | up: 28 | 29 | ### Create a GitHub account 30 | 31 | Before getting started, you'll need to [sign up](http://github.com/signup) for a 32 | GitHub account. 33 | 34 | ### Sign the CLA 35 | 36 | Before we can accept your code, you'll need to sign the [Contributor License 37 | Agreement](./CLA.md). This is a one-time process. 38 | 39 | ### Code of Conduct 40 | 41 | Please make sure to read and follow our [Code of Conduct](../../code-of-conduct.md). 42 | 43 | ### Making a contribution 44 | 45 | Please see [contribution processes](./processes.md) for more information on how 46 | to make a contribution to an OpenTelemetry repository. 47 | 48 | ### Community Expectations and Roles 49 | 50 | OpenTelemetry is a community-driven project. We welcome contributions from all 51 | interested parties, regardless of affiliation. Our success is dependent on the 52 | community to provide a professional, productive, friendly, and collaborative 53 | environment. 54 | 55 | - Review the [Mission, Vision, and Values](../../mission-vision-values.md) to 56 | understand the goals of the project. 57 | - Read the [Community Membership](./membership.md) to understand 58 | the roles and responsibilities of the community. 59 | - As you gain experience, we encourage you to move up the ladder from member to 60 | triager, approver, and maintainer! 61 | 62 | ## Next Steps 63 | 64 | Now that you've read through this guide, you're ready to start contributing to 65 | the project. 66 | 67 | -------------------------------------------------------------------------------- /guides/contributor/donations.md: -------------------------------------------------------------------------------- 1 | # Donations 2 | 3 | Donations of preexisting code fall into two broad categories: 4 | 5 | * **Small donations:** Some donations only amount to a single PR and should 6 | usually just be contributed as such 7 | * **Large or complex donations:** Other donations are much larger, require 8 | ongoing maintenance of their own, and/or introduce nuanced licensing issues 9 | 10 | Large donations – or small donations that turn up complex issues during PR 11 | review – should be referred to the Technical Committee (TC) by filing an issue 12 | in this `community` repository and tagging 13 | `@open-telemetry/technical-committee`. The TC will respond to donation 14 | proposals **within two weeks** (that is, after having time to meet and discuss 15 | live). If the TC has not responded to the donation request within that 16 | interval, the donating party can and should point to this document and request 17 | guidance at the TC's earliest convenience. 18 | 19 | All donated code requires a license compatible with the Apache Software License 20 | 2.0, and donated code will require a change of copyright to reflect the 21 | OpenTelemetry Authors. The Governance Committee (GC) will also ask to review any 22 | trademarks (like the names of components) the donation can carry and make a 23 | decision to either remove those trademarks or transfer them to the CNCF. 24 | 25 | ## Donation process 26 | 27 | Broadly, these are the steps the OpenTelemetry Governance and Technical 28 | Committees follow to handle a prospective donation. 29 | 30 | 1. Per the above, the donating organization creates a GitHub issue using 31 | the "Donation Proposal" form in the `community` repository. 32 | 2. The GC will evaluate the proposal to ensure that 33 | the donation is aligned with the overall OpenTelemetry project vision 34 | and roadmap and has a balanced set of interested contributors and maintainers. 35 | The GC is also responsible for driving awareness in the community about 36 | the contribution and making sure all interested parties have a chance to 37 | object and/or contribute. The GC should work with any appropriate Special Interest 38 | Groups to evaluate the donation proposal, consider alternatives, 39 | and ensure OpenTelemetry has the resources required to support the donation. When 40 | considering alternatives, the GC should consider at least the CNCF ecosystem, 41 | and may also consider other well-known open source projects or alternatives proposed 42 | by the community. 43 | 3. If a donation proposal passes the initial GC screening, the TC 44 | will conduct due diligence to determine if the proposed donation can be effectively 45 | integrated into the OpenTelemetry project in a way that meets the quality, security, 46 | and privacy standards of the project without violating stable specification or OpenTelemetry Enhancement Proposals (OTEPs). 47 | The TC will summarize their findings, and make a recommendation to either 48 | accept or reject the proposal, conditionally or unconditionally, in a report which will 49 | be attached to the donation proposal issue. Writing the report may require meeting 50 | and discussing alternative technologies with different vendors in the community and 51 | can be a lengthy process. The TC member driving the report will post updates and time 52 | estimates to the issue. 53 | 4. The GC will consider the report and make a final decision about the donation, 54 | and document that decision on the donation proposal issue. 55 | 5. If accepted, the contributing organization – particularly if it's a 56 | commercial entity – must formally acknowledge via the GitHub issue that its 57 | respective sales and marketing departments have received, understood, and 58 | accepted the terms of the [OpenTelemetry marketing guidelines](../../marketing-guidelines.md). 59 | 6. Given all of the above, the GitHub issue is closed and the donation moves 60 | forward as agreed to by the TC and GC. -------------------------------------------------------------------------------- /guides/contributor/genai.md: -------------------------------------------------------------------------------- 1 | # Generative AI Contribution Policy 2 | 3 | This policy provides general guidance for contributors and maintainers relating 4 | to the use of Generative AI in OpenTelemetry projects. This guidance supersedes 5 | and extends the policy defined in the [Linux Foundation Generative AI 6 | Policy](https://www.linuxfoundation.org/legal/generative-ai). 7 | 8 | ## The Short Version 9 | 10 | While we welcome contributions from anyone, maintainers of individual 11 | projects may -- at their discretion -- hide or close issues, pull requests, or 12 | other contributions that are made totally or in part through generative AI 13 | tooling. 14 | 15 | ## The Long Version 16 | 17 | Increasingly, we have observed a trend of contributors who are utilizing LLMs 18 | and other generative tools to participate in issues and create pull requests. 19 | Regurgitating the output of an LLM is unlikely to be particularly helpful, or 20 | valuable, to other contributors, maintainers, and end-users for a couple of reasons. 21 | 22 | First, time is a very scarce resource for maintainers and approvers. Thoughtful, 23 | high-quality code reviews both essential to the success of OpenTelemetry, and 24 | require a significant time commitment. There is not enough time to give proper 25 | responses to low-effort pull requests without compromising our responsiveness to 26 | high-effort pull requests. Second, OpenTelemetry is a complex, fast-moving 27 | project -- LLMs will often have stale data in their training sets, and are prone 28 | to offering output that is not relevant to the current state of the project. 29 | While LLMs can be incredibly powerful coding assistants they are not a 30 | substitute for human judgement and knowledge. 31 | 32 | With proper usage, Generative AI can be a valuable tool for writing code, 33 | documentation, tests, and more. This level of usage requires enough 34 | understanding of the project to evaluate the LLM output, and to know when to 35 | accept or reject it. Therefore, we ask that contributors do not rely on LLM 36 | output as the sole basis for their contributions. 37 | 38 | Examples of this include: 39 | 40 | - Copying and pasting LLM output into issues or pull requests without any 41 | additional context or explanation. 42 | - Reviewing existing pull requests solely via 43 | LLMs, or using LLMs to respond to issues without any additional context or 44 | explanation. 45 | 46 | ## Frequently Asked Questions - Contributors 47 | 48 | _Q: Can I use LLMs to help me write code, documentation, or tests?_ 49 | 50 | Yes, this policy does not prohibit the use of LLMs to assist in writing code, 51 | documentation, or tests. However, we ask that you do not rely on LLM output as 52 | the sole basis for your contributions. 53 | 54 | _Q: Can I use LLMs to help me review pull requests, issues, or understand the code base?_ 55 | 56 | Yes, this is also allowed -- and a good idea! You should use LLMs as a tool to 57 | assist in your understanding, but not as a replacement for your own judgement 58 | and ability. 59 | 60 | _Q: How do I know the difference between allowed and disallowed usages of LLMs?_ 61 | 62 | "If you have to ask, you already know the answer." This policy is not a broad 63 | ban of LLMs, it is a request that you -- as an individual -- use them in a way 64 | that adds value to the project and respects the time of other contributors and 65 | maintainers. If you are using LLMs to help you write code, that is fine; You 66 | should be clear about this in pull requests and reviews. If you are using LLMs 67 | to understand code so that you can participate in issues or reviews, that is 68 | also fine -- but you should be clear about this as well. What is not fine is 69 | copying and pasting a GitHub issue into an LLM prompt and asking it to write the 70 | PR for you, then blindly submitting that response. You must be an active and 71 | willing participant in the process of contributing to OpenTelemetry. 72 | 73 | ## Frequently Asked Questions - Maintainers 74 | 75 | _Q: Can I close or hide issues or pull requests that are made through LLMs?_ 76 | 77 | Yes, as your discretion you may close or hide issues or pull requests that are 78 | made through LLMs. We ask that you provide a clear explanation for why you are 79 | doing so, and -- if possible -- provide guidance on how the contributor can 80 | improve their contribution. 81 | 82 | _Q: How do I address contributors who are making consistent, low-effort contributions via LLMs?_ 83 | 84 | If an individual contributor continues to engage in low-effort PRs or issues, 85 | _and_ you have exhausted other avenues of communication, please escalate the 86 | situation to the OpenTelemetry Governance Committee. Per the [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md), 87 | contributors are expected to help maintain a positive environment, which would 88 | include following guidance and published policy. 89 | 90 | _Q: Can I use LLM or Generative AI tooling to assist in my own work as a maintainer?_ 91 | 92 | In general, you should evaluate the output of LLMs -- regardless of how you use 93 | them -- in the same way you'd evaluate the output of a human contributor or 94 | non-AI tool. For example, tools like [Dosu](https://dosu.dev/) are being used in 95 | certain repositories to aid in code review and issue management. Remember that 96 | these tools can make mistakes, and use your best judgement when evaluating their 97 | output. 98 | -------------------------------------------------------------------------------- /guides/maintainer/README.md: -------------------------------------------------------------------------------- 1 | # Maintainers Guide 2 | 3 | Welcome! This guidebook is designed to collect and share best practices, 4 | processes, and other information on being a maintainer of an OpenTelemetry 5 | project. 6 | 7 | ## Table of Contents 8 | 9 | TODO 10 | 11 | ## What is a Maintainer? 12 | 13 | See [Maintainer](../contributor/membership.md) for more information. 14 | -------------------------------------------------------------------------------- /guides/maintainer/conflict-resolution.md: -------------------------------------------------------------------------------- 1 | # Resolving technical conflicts within a SIG 2 | 3 | From time to time, the Maintainers for a given OpenTelemetry SIG may be unable 4 | to reach consensus on a technical issue. While it's healthy and appropriate to 5 | make a sincere attempt to understand all points of view and consider the 6 | tradeoffs, it's also healthy to occasionally "disagree and commit." 7 | 8 | Within OpenTelemetry, SIG Maintainers are chosen specifically *because* they 9 | are domain experts, so we would like to keep as much of the decision-making 10 | authority with the SIG Maintainers rather than immediately "escalating" to the 11 | overall OpenTelemetry-wide Technical Committee (TC). As such, this is 12 | OpenTelemetry's process for resolving technical issues where Maintainers cannot 13 | reach consensus: 14 | 15 | 1. The SIG Maintainers should succinctly document the options under 16 | consideration as a GitHub issue within the SIG's respective repo (note that it 17 | is *not* required to document the complete framing and pros/cons – just the 18 | actual go-forward options themselves). 19 | 2. Each SIG Maintainer must formally vote for their choice by commenting on 20 | that issue. 21 | 3. The option receiving the most votes wins. 22 | 4. If the vote is a tie, the OpenTelemetry TC should be brought into the 23 | discussion, and the TC itself gets a (single) tiebreaking vote. 24 | 25 | While inevitably these sorts of decisions will be disappointing for somebody, 26 | it's incredibly important for the project to maintain velocity and recognize 27 | that we are all coming to these sorts of technical issues with the best of 28 | intentions and remain aligned about the overall goals of the OpenTelemetry 29 | project. 30 | -------------------------------------------------------------------------------- /marketing-guidelines.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry Marketing Guidelines for Contributing Organizations 2 | 3 | This page has moved to [opentelemetry.io], see [Marketing Guidelines]. 4 | 5 | [Marketing Guidelines]: https://opentelemetry.io/community/marketing-guidelines/ 6 | [opentelemetry.io]: https://opentelemetry.io 7 | -------------------------------------------------------------------------------- /maturity-matrix.yaml: -------------------------------------------------------------------------------- 1 | # OpenTelemetry is a complex project with many moving parts. Thankfully, we 2 | # strive to keep those parts loosely coupled where we can (this has been a goal 3 | # since the very announcement of OpenTelemetry, per this blog post: 4 | # https://medium.com/opentracing/merging-opentracing-and-opencensus-f0fe9c7ca6f0) 5 | # 6 | # This file describes the structure of the project and its sub-components, 7 | # definitions of API and stability maturity levels, and finally records the 8 | # current maturity of each component. We maintain this file as YAML in order to 9 | # make it easier to automate scripts (e.g., for the website) that present the 10 | # data to OpenTelemetry end-users. 11 | 12 | 13 | ############################################################################### 14 | # MATURITY LEVELS 15 | # 16 | # OpenTelemetry components advertise their own maturity along two axes: 17 | # - PRODUCTION MATURITY: How reliable is this component from a 18 | # production-readiness standpoint? 19 | # - API MATURITY: How stable is the component's API from a backwards- and 20 | # forwards-compatibility standpoint)? 21 | # 22 | # In some cases, for instance, OpenTelemetry components may be immature from an 23 | # API maturity standpoint, yet be nearly 100% safe from a production standpoint 24 | # – and vice versa. Similarly, end-users may have more tolerance for lost 25 | # development time or software stability depending on their situation, so we 26 | # strive to separate self-reported maturity along these two axes. 27 | # 28 | # Needless to say, representations here are best-effort, and there is no 29 | # substitute for a mature release process. I.e., don't blindly deploy "mature" 30 | # OpenTelemetry components (or any software, for that matter!). 31 | productionMaturityLevels: 32 | # "unknown" maturity is just what it purports to be. It's reasonable to 33 | # assume "unstable", but we separate "unknown" and "unstable" to distinguish 34 | # between a lack of evidence about production maturity and actual evidence of 35 | # immaturity. 36 | - unknown 37 | 38 | # "unstable" components are not recommended for production workloads. They 39 | # may crash the process, introduce performance artifacts, or have known 40 | # security issues. 41 | - unstable 42 | 43 | # "beta" components have been used successfully in production workloads at 44 | # scale: that is, the component is used in support of well-known product 45 | # functionality at publicly-held companies. Nevertheless, either due to 46 | # the uncertainty introduced by active development or a small number of 47 | # production environments, they should still be used cautiously in new 48 | # deployments. They do not have known security issues. 49 | - beta 50 | 51 | # "stable" components are, to the best of the author's knowledge, safe for 52 | # typical production use cases. 53 | - stable 54 | 55 | # All OpenTelemetry APIs follow semver conventions (i.e., after v1.x, 56 | # backwards-incompatible changes should bump the major version number). 57 | apiMaturityLevels: 58 | # "unimplemented" APIs do not exist yet for the component/language. 59 | - unimplemented 60 | 61 | # "notApplicable" APIs do not and will never exist for the component/language 62 | # because they are, well, not applicable. For instance, a 63 | # zero-code-modification auto-instrumentation agent would be notApplicable 64 | # for C99. 65 | - notApplicable 66 | 67 | # "alpha" maturity APIs can change in incompatible ways at any time. 68 | - alpha 69 | 70 | # "beta" maturity APIs should not introduce backwards-incompatible changes 71 | # more than once every three months; and when those changes are introduced, the 72 | # authors will make a best effort to provide compatibility bridges. 73 | # 74 | # Also, for an API to be considered "beta", it must be supported by at least 75 | # two complete implementations, and at least one of those must be for a 76 | # well-known OSS project (e.g., Jaeger or Prometheus). 77 | - beta 78 | 79 | # "stable" maturity APIs should not introduce backwards-incompatible changes 80 | # more than once every twelve months, and will make every effort to provide 81 | # compatibility bridges if at all possible. 82 | - stable 83 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "devDependencies": { 3 | "markdown-link-check": "3.13.7", 4 | "markdown-toc": "^1.2.0", 5 | "markdownlint-cli": "0.45.0" 6 | } 7 | } 8 | -------------------------------------------------------------------------------- /project-management.md: -------------------------------------------------------------------------------- 1 | # Project Management 2 | 3 | The OpenTelemetry community has limited bandwidth for managing changes which expand the scope of OpenTelemetry, or impact many SIGs (Special Interest Groups) within OpenTelemetry. 4 | 5 | These are common scenarios which have this kind of impact: 6 | 7 | * Non-trivial changes to the [OpenTelemetry Specification](https://github.com/open-telemetry/opentelemetry-specification). 8 | * Non-trivial changes to the [OpenTelemetry Semantic Conventions](https://github.com/open-telemetry/semantic-conventions). 9 | * Non-trivial being: introducing new conventions, forming a new SIG around a subject, topic or technology and stabilization efforts. 10 | * A new SIG being formed. 11 | * An existing SIG taking on new work which will affect the OpenTelemetry project as a whole, and will need review from the broader community. 12 | 13 | Any changes which fall into one of the above categories must first create a project proposal and gain approval from the GC (Governance Committee) and TC (Technical Committee) before work begins. 14 | 15 | The list of current projects, along with their most recent status, is available in our [community projects](https://github.com/open-telemetry/community/projects?query=is%3Aopen) page, which the community can use to get a high-level view of the OpenTelemetry roadmap. Project proposals currently under review can be tracked via their respective [open pull requests](https://github.com/open-telemetry/community/pulls?q=is%3Aopen+is%3Apr+label%3Aarea%2Fproject-proposal). 16 | 17 | ## Project Proposal 18 | 19 | At minimum, projects require the following resources to be successful: 20 | 21 | * A clearly defined set of goals and deliverables. 22 | * Timelines for when the deliverables will be ready for review by the broader community. 23 | * Two TC/GC members, or community members delegated by them, to sponsor the project. 24 | These two sponsors should be from different companies. 25 | * A group of designers and subject matter experts, dedicating a significant amount of their work time to the project. These participants are needed to design the spec, write a set of OTEPs, and create multiple prototypes. This group needs to meet with each other (and with their sponsors) on a regular basis to develop a successful set of proposals. 26 | 27 | To propose a project, a**project document** must be created using the [project proposal template](project-template.md) as a guide. This document will be used as the initial proposal for the project. 28 | 29 | A project proposal can then be submitted by placing the project document in the [projects](projects/) folder and making a pull request against the community repo. 30 | 31 | As the project progresses, the project document should be kept up to date, and the community [README](README.md) should be updated to include any new project meeting information (see [contributing guide](https://github.com/open-telemetry/community/blob/main/CONTRIBUTING.md#updating-sig-information-on-the-readmemd)). 32 | 33 | Project leads are encouraged to define timelines for any work which will require public review, and to provide updates to the community in the form of [GitHub Project updates](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/sharing-project-updates). We have found that having scoped deliverables leads to an increased cadence in project work, and helps resolve debate. Timelines also help with getting a more coherent public review, as they allow the review community to plan on making themselves available. If timelines prove to be unrealistic, they can be always be updated. 34 | 35 | ## Project Lifecycle 36 | 37 | All projects progress through a lifecycle. Each individual project is tracked using a specific [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) created for this purpose after the proposal is approved. Project leads should use it to plan work and communicate status updates to the community. 38 | 39 | The project lifecycle is as follows: 40 | 41 | * A **Project Proposal** pull request is created, as described above. The pull request should be labeled as `area/project-proposal`, which opens it up for community review. 42 | * For a project to be approved, its pull request **must be approved by a majority of GC members**. If a project is approved, and all merge requirements are met, the pull request is merged. 43 | * One a project is **Approved**, project leads create the corresponding GitHub Project and set up meetings and other logistics as documented in the project proposal template. 44 | * For the duration of the project, project leads, along with their GC liaisons, are expected to regularly (at minimum quarterly) [share project updates](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/sharing-project-updates) to communicate the status of the project to the wider community. The list of possible statuses any given project is static, and it represents the following in OpenTelemetry projects: 45 | * **_Inactive_**: The project has been approved, but its start date is in the future and no work has commenced. Although allocating a future start date is not required, it lets potential contributors know when they need to make themselves available, and get prepared to begin their work. Subject matter experts and participants who plan to do a lot of work – such as building prototypes – benefit greatly from having a start date, as they can plan for their participation with their employers and coworkers. Projects may remain in _inactive_ state until defined start date is reached. 46 | * **_On Track_**: The project is making progress, and leads consider the timelines currently defined in the project document achievable with the current resources. Updates may contain information about recent achievements on the project. 47 | * **_At Risk_**: The project is at risk of not meeting its currently defined timelines. Leads and their GC liaison should discuss actions to bring the project back on track, which may include extending previously agreed timelines or re-scoping deliverables. 48 | * **_Off Track_**: The project does not have the necessary resources to continue to meet the desired deliverables in a timeline manner, or participation is too low to continue. Leads and their GC liaison should address the level of interest and commitment from the community to re-scope deliverables and timelines, and consider closing the project if not satisfactory, removing the project document from the list of active projects and cancelling meetings and other logistics (e.g. GitHub teams). 49 | * **_Completed_**: The project is complete. The project document is moved to the [completed projects](projects/completed-projects/) folder, meetings and other logistics are cancelled, and the corresponding GitHub project is closed. -------------------------------------------------------------------------------- /project-template.md: -------------------------------------------------------------------------------- 1 | # <> 2 | 3 | Name your project here. This should be a short, descriptive name that describes the main goal of the project, not the SIG that may be formed as part of it. For instance, if the project is aimed at the first set of deliverables for the Foo SIG, name the project "Foo SIG Bootstrap" or "Initial Foo Implementation". 4 | 5 | ## Background and description 6 | 7 | Add any background that may be needed to introduce the scope of this project. 8 | 9 | ### Current challenges 10 | List the current challenges that this project aims to solve. Focus on the problem here, how it affects users and what the downsides are if nothing is done, rather than the solution. 11 | 12 | ### Goals, objectives, and requirements 13 | Describe the aim of this project, including the goals, objectives and requirements needed to solve the challenges presented in the previous section. Include here the motivations for starting the project now, as opposed to later. Call out the benefits for the OpenTelemetry project when this project is completed. 14 | 15 | ## Deliverables 16 | 17 | A description of what this project is planning to deliver, or is in the process of delivering. This includes all OTEPs and their associated prototypes. 18 | 19 | In general, OTEPs are not accepted unless they come with working prototypes available to review in at least two languages. Please discuss these requirements with a TC member before submitting an OTEP. 20 | 21 | ## Staffing / Help Wanted 22 | 23 | Who is currently planning to work on the project? If a project requires specialized domain expertise, please list it here. If a project is missing a critical mass of people in order to begin work, please clarify. 24 | 25 | ### Industry outreach 26 | 27 | Who (people, companies) in the industry should be aware of this effort? Was there an attempt to get them onboard? What did they say? 28 | 29 | ### Required staffing 30 | 31 | Projects cannot be started until the following participants have been identified: 32 | * Every project needs a project lead, who is willing to bottom line the project and address any issues which are not handled by other project members. 33 | * At least two sponsoring [TC](community-members.md#technical-committee) or [GC](community-members.md#governance-committee) members (or [semantic convention maintainers](https://github.com/orgs/open-telemetry/teams/specs-semconv-maintainers) in the case of semantic convention SIGs), or community members delegated by them. Sponsors are dedicated to attending meetings, reviewing proposals, and in general being aware of the state of the project and its technical details. Sponsors guide the project through the spec process, keep the tracking issue up to date, and help to ensure that relevant community members provide input at the appropriate times. 34 | * A GC liaison to facilitate this SIG's health and ensure project scope remains true to the project description. If a GC member is also a sponsor for this project, they are by default the GC liaison (see [GC check-ins](./gc-check-ins.md)). 35 | * Engineers willing to write prototypes in at least two languages (if relevant to project). Languages should be fairly different from each other (for example: Java and Python). 36 | * Maintainers or approvers from those languages committed to reviewing the prototypes. 37 | 38 | ## Timeline 39 | 40 | What is the expected timeline the project will aim to adhere to, and what resources and deliverables will be needed for each portion of the timeline? If the project has not been started, please describe this timeline in relative terms (one month in, two weeks later, etc). If a project has started, please include actual dates. 41 | 42 | ## Labels 43 | 44 | Issues should be properly labeled to indicate what parts of the specification it is focused on. List here the labels applicable to this project, and consider adding them to corresponding GitHub Project automation to include them automatically into the project backlog. 45 | 46 | ## GitHub Project 47 | 48 | Once approved, a project should be managed using a GitHub project board (see [open projects](https://github.com/open-telemetry/community/projects?query=is%3Aopen)). This project board should be pre-populated with issues that cover all known deliverables, organized by timeline milestones. 49 | 50 | Any [member](./guides/contributor/membership.md) associated with the project can create the board. Please use the existing [GitHub Project template](https://github.com/orgs/open-telemetry/projects/140) to create your project, replacing `{project_name}` where appropriate. 51 | 52 | Once created, the creator of the board should: 53 | 54 | - Assign `Admin` privileges on the project to the relevant project members (using a new or existing GitHub team). 55 | - Change the visibility of the project to `Public` in order to share project status and priorities outside of the OpenTelemetry organization. 56 | - Configure project workflows to automatically add issues and PRs to the board based on repositories and labels. 57 | 58 | See [project management](project-management.md#project-lifecycle) for more information about sharing project updates and status. 59 | 60 | Once created, please add a link to the project board here. 61 | 62 | ## SIG Meetings and Other Info 63 | 64 | Once a project is started, its corresponding SIG should meet regularly for discussion. These meeting times should be posted on the [OpenTelemetry public calendar](https://github.com/open-telemetry/community#calendar) and automatically recorded. 65 | 66 | Any relevant information related to the SIG (e.g. sponsors, meeting times, Slack channels, meeting notes, etc.) must be publicly available in the [community](https://github.com/open-telemetry/community) SIG tables, which can be updated via the [sigs.yml](./sigs.yml) file and running `make table-generation`. 67 | 68 | See [How to create and configure meetings](./docs/how-to-handle-public-calendar.md) for updating the public calendar or open an issue in the community repository so it's taken care of. 69 | -------------------------------------------------------------------------------- /projects/README.md: -------------------------------------------------------------------------------- 1 | This folder contains all OpenTelemetry projects which have been approved by the GC. Please see the [list of open projects](https://github.com/open-telemetry/community/projects?query=is%3Aopen) for an overview of their current state. -------------------------------------------------------------------------------- /projects/client-instrumentation.md: -------------------------------------------------------------------------------- 1 | # Client Instrumentation 2 | 3 | ## Description 4 | 5 | We believe that in order for OpenTelemetry to be adopted across the board, it needs to have a good support for client applications. Client instrumentation has some unique challenges that are currently not well supported. 6 | 7 | Our initial goals include 8 | 9 | * define which signal(s) are used for different types of client telemetry 10 | * define semantic conventions for different types of client events 11 | * define semantic conventions for client-specific resources 12 | * define how sessions are handled in SDKs and represented across the wire 13 | 14 | Beyond these, we expect that this will be a long-term ongoing project, which might include development of client-optimized SDKs. Also, given that there are many types of client applications/environments, this group may branch into multiple groups over time. 15 | 16 | ## Project Board 17 | 18 | https://github.com/orgs/open-telemetry/projects/19/views/1 19 | 20 | ## Deliverables 21 | 22 | * Semantic conventions for (most common) client events 23 | * [draft PR for two browser events](https://github.com/martinkuba/opentelemetry-specification/pull/1) 24 | * Semantic conventions for (most common) client resources 25 | * [Ephemeral Resources OTEP](https://github.com/open-telemetry/oteps/pull/208) 26 | * Logs/Events API + SDK in the Javascript SDK 27 | * [specification PR](https://github.com/open-telemetry/opentelemetry-specification/pull/2676) 28 | * [API draft implementation in JS](https://github.com/open-telemetry/opentelemetry-js/pull/3117) 29 | * Logs/Events API + SDK for Android 30 | * Logs/Events API + SDK for Swift 31 | * Implementation of sessions in the Javascript SDK 32 | * Research + proposal for how browser SDK should be optimized 33 | * [sandbox repository for experimentation](https://github.com/open-telemetry/opentelemetry-sandbox-web-js) 34 | 35 | ## Staffing / Help Wanted 36 | 37 | Expertise required: browser instrumentation, mobile instrumentation 38 | 39 | The group currently has several regular contributors who have expertise in browser instrumentation. Most of the focus so far has been on browser and shared concerns across all types of client applications. We need more participation from mobile in order to move mobile instrumentation forward. 40 | 41 | ### Required staffing 42 | 43 | Project lead(s): @martinkuba, @scheler, @MSNev 44 | 45 | TC sponsoring members: 46 | Josh Suereth, Jack Berg 47 | 48 | ## Meeting Times 49 | 50 | SIG meeting times: Mondays 12:30am PT 51 | Secondary meeting times: Tuesdays 9am PT 52 | Timeline 53 | 54 | ## Timeline 55 | 6 - 12 months 56 | 57 | -------------------------------------------------------------------------------- /projects/collector-v1.md: -------------------------------------------------------------------------------- 1 | ## Description 2 | 3 | Quite a few of our users are happy using a non-v1 Collector, as evidenced by talks delivered by eBay or VTEX. On the other hand, other companies have internal policies forbidding the usage of software that hasn’t reached v1. 4 | 5 | Other companies, hearing the success stories of the “early adopters”, tried to use the Collector, but due to a lack of guidance, ended up using components that weren’t ready for prime time and were frustrated. 6 | 7 | Our main goal with this project is to define what's the scope for Collector v1, defining which use-cases we want to satisfy first, followed by stabilizing the components that are required for that. Once we are there, we'll focus on documentation for those components and use cases. 8 | 9 | We believe we are close to a v1 of the Collector, given that users are using it in production already. Therefore, we are confident we can deliver a v1 in 2024. 10 | 11 | Teams involved in this: 12 | 13 | * @open-telemetry/collector-approvers 14 | * @open-telemetry/collector-contrib-approvers 15 | * @open-telemetry/collector-maintainers 16 | * @open-telemetry/collector-contrib-maintainer 17 | * @open-telemetry/docs-maintainers 18 | * @open-telemetry/docs-approvers 19 | 20 | ### Project Board 21 | 22 | To be created. 23 | 24 | ### Deliverables 25 | 26 | The current goal (subject to change) is to have deliverables covering our two current distributions: core and contrib. Deliverables should be linked from the main opentelemetry.io website. 27 | 28 | #### Must-haves 29 | * Binaries for Windows, MacOS, and Linux for amd64 and x86 30 | * Multi-arch container images 31 | 32 | #### Nice to have 33 | * OS-specific packages for Linux (deb, rpm, …) and Macos (homebrew) 34 | 35 | ### Staffing / Help Wanted 36 | 37 | @jpkrohling is the GC sponsor for this and has the buy-in from other Collector leaders, including core and contrib approvers/maintainers (listed above). 38 | 39 | ### Meeting Times 40 | 41 | For the public discussions, we are using the Collector SIG meeting slot. 42 | 43 | ### Timeline 44 | 45 | To be defined, but this project should be completed in 2024. -------------------------------------------------------------------------------- /projects/completed-projects/README.md: -------------------------------------------------------------------------------- 1 | This folder contains projects which have been completed, and are no longer meeting as a group. -------------------------------------------------------------------------------- /projects/completed-projects/database-client-semconv.md: -------------------------------------------------------------------------------- 1 | # Database Client Semantic Convention Stability 2 | 3 | ## Description 4 | 5 | Get the database client semantic conventions to stability, and afterwards update existing Database instrumentation across all OpenTelemetry repositories to conform with the stable conventions. 6 | 7 | ## Deliverables 8 | 9 | * Mark the Database client semantic conventions as stable. 10 | * Update existing Database client instrumentation across all OpenTelemetry repositories to conform with the stable conventions. 11 | 12 | ## Staffing 13 | 14 | * @trask project lead / GC sponsor 15 | * @lmolkova domain expert 16 | * @jcocchi domain expert 17 | * @sourabh1007 domain expert 18 | * @alanwest prototype engineer / reviewer 19 | * @jack-berg TC sponsor / prototype engineer / reviewer 20 | 21 | ## Meeting Times 22 | 23 | 2 times per week for 6 weeks starting Feb 6, 2024. The goal will be to have all proposed changes submitted as PRs by the end of the 6 weeks. 24 | 25 | * Wed 9:30-10a Pacific Time 26 | * Fri 8:30-9a Pacific Time 27 | 28 | (and will report status weekly in the General Semantic Convention meeting Mon 8-9a Pacific Time) 29 | 30 | ## Timeline 31 | 32 | Goal is to stabilize Database client semantic conventions 3 months after the SIG kicks off. 33 | 34 | ## Project Board 35 | 36 | Once approved by TC, a project should be managed using a GitHub project board. This project board should be pre-populated with issues that cover all known deliverables, organized by timeline milestones. 37 | 38 | A [Technical Committee](../../community-members.md#technical-committee) (TC) member associated with the project can create the board, along with a new project-specific GitHub label to automatically associate issues and PRs with the project. The project lead and all other relevant project members should have edit access to the board. 39 | 40 | Once created, please link to the project board here. -------------------------------------------------------------------------------- /projects/completed-projects/one-logging-bridge-per-language.md: -------------------------------------------------------------------------------- 1 | ### Description 2 | 3 | During the joint TC/GC call on Jan 11 2024, we agreed on a few items we'd like to accomplish this year. One such item was creating at least one logging bridge per Language SIG, so that our end-users can start using OTLP Logging natively in their applications. 4 | 5 | We'll strive to get at least one logging bridge for each supported language. Language SIGs will be free to decide which bridge to implement based on the needs of their audiences. 6 | 7 | ### Project Board 8 | 9 | To be created. 10 | 11 | ### Deliverables 12 | 13 | For each one of the following languages, there should be at least one logging bridge available, either as part of their core repository or as part of their contrib repository. Usage of such bridge should be documented on opentelemetry.io's website. 14 | 15 | Languages (100% of the languages available when this issue was created): 16 | 17 | - One Logging Bridge per language - C++ [(#1900)](https://github.com/open-telemetry/community/issues/1900) 18 | - One Logging Bridge per language - .NET [(#1901)](https://github.com/open-telemetry/community/issues/1901) 19 | - One Logging Bridge per language - Erlang [(#1902)](https://github.com/open-telemetry/community/issues/1902) 20 | - One Logging Bridge per language - Go [(#1903)](https://github.com/open-telemetry/community/issues/1903) 21 | - One Logging Bridge per language - Java [(#1904)](https://github.com/open-telemetry/community/issues/1904) 22 | - One Logging Bridge per language - JavaScript [(#1905)](https://github.com/open-telemetry/community/issues/1905) 23 | - One Logging Bridge per language - PHP [(#1906)](https://github.com/open-telemetry/community/issues/1906) 24 | - One Logging Bridge per language - Python [(#1907)](https://github.com/open-telemetry/community/issues/1907) 25 | - One Logging Bridge per language - Ruby [(#1908)](https://github.com/open-telemetry/community/issues/1908) 26 | - One Logging Bridge per language - Rust [(#1909)](https://github.com/open-telemetry/community/issues/1909) 27 | - One Logging Bridge per language - Swift [(#1910)](https://github.com/open-telemetry/community/issues/1910) 28 | 29 | ### Staffing / Help Wanted 30 | 31 | We anticipate that Language SIG maintainers will share the vision that having at least one bridge, hopefully for the most used logging API for the language, is important for the SIG, and therefore, we don't anticipate new staffing requirements. However, we'll try to recruit new contributors to work on this once we have a few examples to follow. 32 | 33 | #### Required staffing 34 | 35 | @jpkrohling is the sponsor for this project and will work with the individual Language SIGs to implement this. 36 | 37 | ### Meeting Times 38 | 39 | We'll use the regular Language SIGs meetings, as well as the maintainer's meeting on Monday. 40 | 41 | ### Timeline 42 | 43 | We aim to complete this project by the end of 2024. -------------------------------------------------------------------------------- /projects/config.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry Configuration 2 | 3 | ## Description 4 | 5 | OpenTelemetry specifies code that can operate in a variety of ways based on the end-user’s desired mode of operation. This requires a configuration interface be provided to the user so they are able to communicate this information. Currently, OpenTelemetry specifies this interface in the form of environment variables. This environment variable interface is limited in the structure of information it can communicate and the primitives it can support. 6 | 7 | The configuration project intends to produce the specification around the data model for language-agnostic configuration that provides additional flexibility for the end users. 8 | 9 | ## Project Board 10 | 11 | https://github.com/orgs/open-telemetry/projects/38 12 | 13 | ## Deliverables 14 | 15 | 1. An OTEP 16 | 2. Prototypes in Java, Python, Go, Erlang 17 | 3. The specification of the configuration data model 18 | 4. A repository containing the schema and schema validation tooling 19 | 20 | ## Staffing / Help Wanted 21 | 22 | End users of OpenTelemetry to help validate the usage and configuration scenarios would be great to have participate in the discussions. 23 | 24 | ## Required staffing 25 | 26 | Project lead 27 | 28 | * @MrAlias 29 | * @jack-berg 30 | 31 | Sponsoring TC members 32 | 33 | * @carlosalberto 34 | * @jack-berg 35 | 36 | Engineers contributing to the SIG 37 | 38 | * @MrAlias 39 | * @jack-berg 40 | * @tsloughter 41 | * @MikeGoldsmith 42 | * @codeboten 43 | 44 | Maintainers and approvers 45 | 46 | * @srikanthccv (python) 47 | * @CodeBlanch (.net) 48 | * @lalitb (c++) 49 | 50 | ## Meeting Times 51 | 52 | Every 2 weeks, on Fridays at 10:30AM PT 53 | 54 | ## Timeline 55 | 56 | 3-6 months -------------------------------------------------------------------------------- /projects/contributor-experience.md: -------------------------------------------------------------------------------- 1 | # Contributor Experience 2 | 3 | ## Background and description 4 | 5 | Over the last few years the OpenTelemetry project has seen massive growth, not 6 | only in adoption and lines of code, but also in the number of individuals who 7 | contribute to this project in different ways. 8 | 9 | While in the beginning of the project contributors knew each other well and 10 | could share implicit in-group knowledge effortlessly, the project has outgrown that 11 | phase a while ago and we see different kinds of problems, that make it hard 12 | for long-term contributors to maintain the project sustainably and for new-comers 13 | to enter the project effortlessly. 14 | 15 | In this project proposal we suggest to form a cross-cutting special interest group 16 | that takes responsibility for driving contributor experience projects and that 17 | closely collaborates with all other SIGs and governing bodies to increase contributor 18 | sustainability, velocity and happiness. 19 | 20 | ### Current challenges 21 | 22 | Among others the challenges the OpenTelemetry project is facing in regards of 23 | contributor experience are: 24 | 25 | * No consistent way of moving contributors "up the ladder", e.g. from member to 26 | approver, from approver to maintainer etc, which makes those changes invisible 27 | to the larger project and opaque to project leadership on who is doing 28 | what. 29 | * No clear onboarding path for new contributors, or contributors taking on new 30 | responsibilities within the project (triagers, approvers, maintainers, committee 31 | members), which leads to friction in understanding of the overall project goals, 32 | to misalignment in implementations and the feeling of contributors being remote 33 | to other parts of the project. 34 | * No explicit contributor guidebook that helps contributors to answer common 35 | questions no matter where they are on the contributors' ladder. 36 | * No mentorship available for new contributors or contributors stepping up into new roles to 37 | make them part of the project and aware of expectations. 38 | * Only implicit and unstructured recognition for contributors, instead of explicit 39 | recognition which would help contributors to feel seen and recognized. 40 | * No structured collaboration across SIGs, especially in the case of cross-cutting 41 | concerns (Security, Docs, End-User, ...), leading to information silos and misalignment. 42 | * SIGs are short of contributors and require some help to advertise their need 43 | (blog post, social posts, etc) and to lower the barrier of entry into their 44 | sub-project. 45 | * Implicit bias towards US (and EU) working hours, rituals and modes of operation. Majority of SIG meetings occurring from early PST onward. 46 | 47 | Note that there are individuals within the project who try to tackle some of those 48 | aspects as individuals and not in a team effort, notable: 49 | 50 | * [Add skeleton for maintainer and contributor guidebooks](https://github.com/open-telemetry/community/pull/2051) 51 | * Mentorship efforts, e.g. [Outreachy](https://cloud-native.slack.com/archives/C060GFUL0P6) 52 | * Surveys by the End User SIG that aim towards contributor experience 53 | * _add more_ 54 | 55 | Also related to this initiative is the [Check-In process of the Governance Committee](../gc-check-ins.md) 56 | 57 | ### Goals, objectives, and requirements 58 | 59 | The goal of this project is to establish a cross-cutting "SIG Contributor Experience", 60 | which is "responsible for improving the experience of those who upstream contribute to 61 | the OpenTelemetry project. [They] do this by creating, and maintaining programs and processes that promote community health and reduce project friction, while retiring those programs and processes that don't. Being conscientious of our contributor base is critical to scaling the project, growing the ecosystem, and helping the project succeed". (via [K8s Contributor Experience Special Interest Group Charter](https://github.com/kubernetes/community/blob/master/sig-contributor-experience/charter.md)) 62 | 63 | While this is "yet another SIG" initiative, we believe that **not** establishing 64 | such a SIG is not an option: the problems outlined above will get bigger not 65 | smaller and while the final ownership of the health of the project is with the GC 66 | this requires a coordinated effort and more hands across the project to be addressed 67 | successfully. 68 | 69 | Note that similar to other cross-cutting SIGs (Docs, Security, End-User) this SIG will not exclusively own 70 | the domain of contributor experience, but they take responsibility to drive efforts in close collaboration 71 | with SIGs and Committees. 72 | 73 | ## Deliverables 74 | 75 | After foundation the SIG will collaborate with contributors of existing efforts 76 | (see above) and work towards establishing programs and initiatives around contributor 77 | experience, including 78 | 79 | * Onboarding rituals for members, approvers, maintainers 80 | * A contributor guidebook 81 | * Mentorship opportunities 82 | * Contributor recognition programs (e.g. via [Credly](https://credly.com) or with blog posts on the style of "here's what's happening under the hood" 83 | * Blog posts and social media posts to highlight areas where help is needed 84 | * Events targeting the Contributor Community 85 | * Consume SIG Check-In reports from the GC and use this data to improve contributor experience 86 | * Support the community of contributors to maintain the Code of Conduct (Note: this is a support function, the responsibility for the CoC and especially enforcing it lays with the Governance Committee) 87 | * Implement or suggest measures to support contributor diversity 88 | * Help SIGs to establish practices to improve contributor experience, e.g. having multiple meeting times to serve more timezones 89 | * Maintain a relationship with other Contributor Experience SIGs (e.g. from K8s) and TAG Contributor Strategy, to consult them for best practices and resources where that makes sense, as well as upstream our governance resources into their repos for other projects when that makes sense. 90 | 91 | ## Staffing / Help Wanted 92 | 93 | GC/TC sponsors: 94 | 95 | * [@jpkrohling](https://github.com/jpkrohling) 96 | * [@svrnm](https://github.com/svrnm) 97 | 98 | Maintainers, approvers, and contributors: 99 | 100 | * [@JamieDanielson](https://github.com/JamieDanielson) 101 | * [@jpkrohling](https://github.com/jpkrohling) 102 | * [@maryliag](https://github.com/maryliag) 103 | * [@musingvirtual](https://github.com/musingvirtual) 104 | * [@mx-psi](https://github.com/mx-psi) 105 | * [@svrnm](https://github.com/svrnm) 106 | * [@theletterf](https://github.com/theletterf) 107 | 108 | ## Meeting Times 109 | 110 | The SIG will meeting time will be discussed and finalized when this proposal has been merged. There will be a weekly meeting, if necessary to cater as many time zones as possible there will be bi-weekly meetings at alternating times. 111 | 112 | ## Timeline 113 | 114 | * Month 1: Establish the SIG with all required resources (repository, meeting notes, calendar, GH groups, etc) 115 | * Month 2-6: 116 | * Create a charter based on the [K8s SIG Contributors Experience Charter](https://github.com/kubernetes/community/blob/master/sig-contributor-experience/charter.md) 117 | * Tackle existing projects (contributor guide book, mentorship) 118 | * Identify high stake initiatives 119 | * Month 6: Report to GC & TC about the establishment of the SIG 120 | * Beyond that the SIG is established and will operate similar to existing SIGS. 121 | -------------------------------------------------------------------------------- /projects/currently-inactive/messaging-semconv.md: -------------------------------------------------------------------------------- 1 | # Messaging Semantic Convention Stability 2 | 3 | ## Description 4 | 5 | Get the messaging semantic conventions for metrics and traces to stability, and 6 | afterwards update existing messaging instrumentation across all OpenTelemetry 7 | repositories to conform with the stable conventions. 8 | 9 | ## Deliverables 10 | 11 | * Mark the messaging semantic conventions as stable. 12 | * Update existing messaging instrumentation across all OpenTelemetry 13 | repositories to conform with the stable conventions. 14 | 15 | ## Staffing / Help Wanted 16 | 17 | Project lead 18 | 19 | * @pyohannes 20 | 21 | GC/TC sponsors 22 | 23 | * @carlosalberto 24 | * @trask 25 | 26 | Domain experts 27 | 28 | * @alevenberg 29 | * @dpauls 30 | * @hongalex 31 | * @joaopgrassi 32 | * @lmolkova 33 | 34 | Maintainers, approvers, and engineers willing to prototype and review 35 | 36 | * TBD 37 | 38 | ## Meeting Times 39 | 40 | We will keep the [established meeting Thursdays at 8 AM PST](https://github.com/open-telemetry/community?tab=readme-ov-file#specification-sigs). 41 | 42 | ## Timeline 43 | 44 | Goal is to stabilize messaging semantic conventions in the first half of 2024. 45 | 46 | ## Project Board 47 | 48 | * [Stability blockers](https://github.com/orgs/open-telemetry/projects/20/views/1) 49 | * [Backlog](https://github.com/orgs/open-telemetry/projects/20/views/4) 50 | -------------------------------------------------------------------------------- /projects/developer_experience.md: -------------------------------------------------------------------------------- 1 | # Developer Experience Project 2 | 3 | ## Background and description 4 | 5 | Convenience as a SIG was initially proposed by [Ted 6 | Young](https://github.com/tedsuo) back in 2021. It was postponed to prioritize 7 | completion of signal specs and stabilization. A document was written at this 8 | time describing the intent to do user research and a brainstorming session, 9 | https://docs.google.com/document/d/1bjiw5L4E8FztRtfsy4Nu9A6qSP-BJlK6BBzl6Rea-Ds/edit#heading=h.b7qckyjgu28i. 10 | This brainstorm resulted in a list of some existing convenience functions 11 | languages have and proposed ones, like a `start` which takes the tracer from the 12 | active span in the current context, and proposals for defining annotations for 13 | easier instrumentation. 14 | 15 | ### Current challenges 16 | 17 | We know users can find the API and SDK to be complex and daunting, the challenge 18 | is to collect actionable feedback on this issues. That information is spread 19 | across various languages' issues, blog posts and other online commentary. 20 | Performing an end user survey will help collect some of this knowledge into a 21 | central place that is actionable. 22 | 23 | When developer experience issues are encountered and addressed they are 24 | currently done in the various language implementations individually and this can 25 | lead to drift between different implementations and with the spec. An example 26 | would be how to handle marking a code block as `untraced` which has 27 | implementations in at least Java, Ruby and Javascript, each done differently, 28 | named differently and with no specification. This means users working across 29 | languages experience different results for similar features and other language 30 | SIG's aren't necessarily even aware of the pain point that their users may 31 | actually be experiencing. 32 | 33 | ### Goals, objectives, and requirements 34 | 35 | With the 3 main signals going stable the time is right to circle back and 36 | address issues users may have faced over the years they've now been using 37 | OpenTelemetry. 38 | 39 | This project aims to identify developer experience issues with using 40 | OpenTelemetry, to select 3 that are concerns which can be addressed through 41 | updates to the specification and resolve them. 42 | 43 | ## Deliverables 44 | 45 | The first deliverable will be the collection of experience in dealing with 46 | developer experience issues by each existing language SIG. This means not only 47 | additions to the API/SDK or libraries developed to enhance the experience for 48 | users but any that may be planned or are being thought about because of a 49 | frequent request from their users. A report of the findings will be shared with 50 | the whole community. 51 | 52 | Utilizing the knowledge gained from the first deliverable on potential areas of 53 | improvement the next deliverable will be an end user survey. Assuming the agreement and 54 | participation of the End User SIG this will be done in cooperation with them. A 55 | write-up of the results will follow, along with the group's decision on the top 3 56 | issues for the group to work on. 57 | 58 | Prototypes of resolutions will be developed and, depending on the scope of the 59 | identified problem, OTEP's will be created where appropriate before opening PR's 60 | to the specification. 61 | 62 | ## Staffing / Help Wanted 63 | 64 | - Project Lead: Tristan Sloughter (MyDecisiveAI) 65 | 66 | - GC sponsors: 67 | - @austinlparker (Honeycomb) 68 | - @tedsuo (Lightstep) 69 | 70 | - TC sponsors: 71 | - @lmolkova (Microsoft) 72 | 73 | - Maintainers, approvers and contributors: 74 | - @dmathieu (Elastic) 75 | - @julianocosta89 (Datadog) 76 | - @martinjt (Honeycomb) 77 | - @samsp-msft (Microsoft) 78 | - @stevejgordon (Elastic) 79 | 80 | ## Meeting Times 81 | 82 | Wednesday 11:00 PT and 17:00 UTC+8 83 | 84 | ## Timeline 85 | 86 | Work with End User SIG: Weeks but start time of this depends on their 87 | availability. 88 | 89 | Identifying priorities: Weeks 90 | 91 | Working on priorities: Weeks to months per. 92 | 93 | ## Labels 94 | 95 | TBA 96 | 97 | ## Linked Issues and PRs 98 | 99 | TBA 100 | 101 | ## Project Board 102 | 103 | https://github.com/orgs/open-telemetry/projects/105 104 | -------------------------------------------------------------------------------- /projects/event-api.md: -------------------------------------------------------------------------------- 1 | ### Description 2 | 3 | The Client / RUM Sig is looking to finalize, complete and resolve the outstanding issues / PR's that exist around the Event API / SDK and the Semantic Conventions that defines what an "event" is. 4 | 5 | ### Project Board 6 | 7 | Project Board: https://github.com/orgs/open-telemetry/projects/65 8 | 9 | ### Deliverables 10 | 11 | Resolve the outstanding Event Issues / PR's which will define 12 | 13 | * Refine / stabilize event data model describing what an event is, the semantic meaning of event fields, and how they are sent over the network. 14 | * Pave the way for defining event semantic conventions, allowing their schemas to be described in YAML and incorporated into build-tools. 15 | * Define select event semantic conventions, establishing patterns for future event semantic conventions to follow. 16 | * Refine / stabilize event API and any associated features in the SDK. 17 | 18 | #### Required staffing 19 | 20 | * Need: more domain experts willing to define the OTel Event standard 21 | * Need: engineers willing to write prototypes in at least one more language other than JavaScript. Language should be fairly different from JavaScript. 22 | * Need: maintainers or approvers from those languages committed to reviewing the prototypes. 23 | 24 | Project lead(s): 25 | 26 | * @MSNev (JavaScript) 27 | 28 | Sponsors: 29 | 30 | * @trask 31 | * @tedsuo 32 | 33 | Contributing Engineers: 34 | 35 | * @martinkuba (JavaScript) 36 | * @scheler 37 | * @patrickhousley 38 | * @breedx-splk 39 | 40 | Implementation Engineers: 41 | * @dennisme (Golang) 42 | 43 | Implementation Maintainers / Approvers: 44 | 45 | * @MSNev 46 | * @martinkuba 47 | * @scheler 48 | 49 | ### Meeting Times 50 | 51 | SIG meeting times: Friday 10am - 11am PT 52 | 53 | ### Timeline 54 | 55 | Completed: 56 | * [Provider based EventLogger API](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.40.0/specification/logs/event-api.md) 57 | 58 | Q2 2024 59 | 60 | * Define EventLogger SDK 61 | * Deliver API & SDK prototype for Web JS 62 | * Define how the contents of the log body field are described as semantic conventions 63 | 64 | Q3 2024 65 | * Define the relationship between OTel Events and CloudEvents 66 | * Project completed, Event SIG disbanded 67 | 68 | ### Linked Issues and PRs 69 | 70 | See the project board for a collection of Issues related to the project. 71 | 72 | ### Labels 73 | 74 | The `spec:events` label is used to describe all spec Issues and PRs related to events. 75 | -------------------------------------------------------------------------------- /projects/faas.md: -------------------------------------------------------------------------------- 1 | # FAAS SIG 2 | 3 | ## Description 4 | 5 | The initial goal of this project is to put Lambda monitoring into a consistently good state. Across vendors, customers consistently struggle to instrument their Lambdas and identify the best practices way to monitor a Lambda. Lambda layer behavior differs by language, context propagation is frequently broken, and cold starts are a known issue. 6 | 7 | This SIG will also look beyond Lambdas and to more broadly Functions as a Service. 8 | 9 | We want to ensure: 10 | 11 | * The FAAS spec has been reviewed, assessed to apply generically, and stabilized 12 | * Consistent lambda layer behavior by language and uniform conformance to the spec 13 | * There is clear community guidance on how to monitor Lambdas 14 | * End to end context propagation using community protocols / propagation across typical Lambda architectures (e.g async) 15 | * Cold start data capture and submission 16 | * The new TelemetryAPI is properly integrated and utilized by OpenTelemetry 17 | 18 | **This SIG will also serve as an interest group for all FAAS topics going forward.** 19 | 20 | ## Deliverables 21 | 22 | * Stabilized FAAS semantic conventions 23 | * Updated Lambda Layer extensions that follow consistent trace propagation and have consistent behavior across languages. 24 | * Cold start processor for the collector 25 | * The first 2 language implementations will be Node.JS and Python. 26 | 27 | ## Staffing / Help Wanted 28 | 29 | The following vendors are interested in improving this area.: 30 | 31 | * Lightstep 32 | * AWS 33 | * Splunk (@tsloughter) 34 | * Cisco (@arbiv) 35 | * Honeycomb (@cartermp) 36 | 37 | While Lambdas are the focus of this effort we need other Functions As A Service (FAAS) experts to ensure we're building conventions that make sense for the stateless function space in general. GCP or Azure participation would be welcome. 38 | 39 | ## Required staffing 40 | 41 | Project Lead: 42 | @Aneurysm9 43 | 44 | Sponsoring TC Members: 45 | * @carlosalberto 46 | * TBA 47 | 48 | Implementation Engineers: 49 | * @tylerbenson 50 | * @codeboten 51 | * Cisco contributors (@arbiv) 52 | * Honeycomb contributors (@cartermp) 53 | * @tsloughter 54 | * @xoscar 55 | 56 | Implementation Maintainers or Approvers: 57 | * JavaScript - @mwear 58 | * Python - @ocelotl 59 | 60 | Lambda SME(s): 61 | @Aneurysm9 to add 62 | 63 | ## Meeting Times 64 | 65 | To deliver the improvements promptly we propose meeting at least 2 days a week for the 6 week planning cycle as specified in the new Semantic Conventions Process Doc 66 | 67 | Meeting Times: 68 | 69 | PST Option: Tuesday @ 12 pm PST 70 | CET Option: Wednesday @ 7 am PST 71 | 72 | ## Timeline 73 | 74 | 1. New SIG will be kicked off in January 75 | 2. The SIG has 6 weeks to propose improvements to the specification and solutions - Beginning of March 76 | 3. OTeps and the first implementation in JavaScript will be reviewed by the community - All of March 77 | 4. Implementation - we want to start with JavaScript and Python as our first target implementation languages - Beginning of April 78 | 79 | ## Repo 80 | 81 | https://github.com/open-telemetry/opentelemetry-lambda -------------------------------------------------------------------------------- /projects/go-compile-instrumentation.md: -------------------------------------------------------------------------------- 1 | # Bootstrap Go compile time instrumentation 2 | 3 | ## Description 4 | 5 | The primary objective of the Go Compile time Instrumentation SIG is to streamline and automate the code instrumentation process around the Go compiler. By integrating automatic instrumentation into the Go compilation process, we aim to provide developers a seamless, efficient, and safe way to instrument their Go applications for observability (and more). 6 | 7 | This SIG will focus on: 8 | 9 | - Developing compiler plugins or enhancements that inject instrumentation code automatically, ensuring minimal runtime performance overhead and compatibility with existing Go projects. 10 | - Providing standardized instrumentation patterns aligned with OpenTelemetry and other monitoring frameworks. 11 | 12 | We want to ensure: 13 | 14 | - Comprehensive Coverage: Automatic instrumentation covers common frameworks and libraries used in Go applications, fully compatible with OpenTelemetry’s APIs and SDKs. 15 | - Performance Efficiency: Instrumentation introduces minimal runtime overhead, maintaining the high-performance standards of Go applications while utilizing OpenTelemetry’s optimized data collection mechanisms. 16 | - Ease of Use: Developers can enable instrumentation with simple/zero configuration changes without manual code modifications. 17 | - Extensibility: The instrumentation framework can be extended to support new libraries and frameworks as they emerge in the Go ecosystem, ensuring ongoing compatibility with the evolving OpenTelemetry landscape. 18 | - Flexibility: Developers are enabled to control their tracing experience (i.e, specifying custom span tags in certain places; opting certain code paths or instances out of tracing, etc...), which can be delivered via a declarative/programmable scheme. 19 | 20 | By closely aligning with OpenTelemetry, the Go Compile Instrumentation SIG ensures that Go applications benefit from standardized, vendor-neutral, high-quality observability solutions that are both robust and easy to implement. Having one single, standard tool removes decision points from prospective developers, which makes the path to observability shorter & easier. 21 | 22 | ## Project Board 23 | Project Board: https://github.com/orgs/open-telemetry/projects/130 24 | 25 | ## Deliverables 26 | 27 | - A flexible and extensible instrumentation framework for Go at compile time 28 | - Out-of-box instrumentation for common libraries and frameworks in Go application. Initial support will be provided for key areas, each with one or two libraries. The proposed initial support for library instrumentation includes as follows and is subject to change: 29 | - HTTP/RPC: gin, grpc 30 | - Messaging: kafka 31 | - Database: mysql 32 | - NoSQL: redis 33 | - Comprehensive documentation that covers a wide array of topics, including how to use the framework, configuration options, advanced usage scenarios, and answers to FAQs 34 | 35 | ## Staffing/Help Wanted 36 | The following vendors are interested in improving this area: 37 | 38 | - Alibaba 39 | - Datadog 40 | - QuesmaOrg 41 | 42 | We also welcome everyone interested in this area to participate in the discussion. 43 | 44 | ### Required staffing 45 | 46 | - Project Lead: @ralf0131(Alibaba), @dineshg13(Datadog), @pdelewski(QuesmaOrg) 47 | - Sponsoring GC Members: @jpkrohling 48 | 49 | Additionally, the following people will participate in the SIG and be added as approvers once they are OpenTelemetry Github org members: 50 | 51 | - Future Approvers: @yiyang0(Alibaba), @123liuziming(Alibaba), @RomainMuller(Datadog) 52 | 53 | ## Meeting Times 54 | 55 | - Biweekly Meetings: Every Thursday 56 | - China (UTC+8): 16:00 – 17:00 57 | - Europe (UTC+2): 10:00 – 11:00 58 | - UTC: 08:00 – 09:00 59 | 60 | Note that members from UTC-5 would not be able to attend the meeting, so the project members will try and make things work asynchronously as possible. 61 | 62 | ## Timeline 63 | 64 | - Step 1: SIG Formation and Initial Setup 65 | - Step 2: Collaborative Architectural Design (1-2 months) 66 | - Step 3: Assignment of Implementation Owners 67 | - Step 4: Implementation and Integration (1-2 months) 68 | 69 | ## Repo 70 | 71 | open-telemetry/opentelemetry-go-compile-instrumentation 72 | 73 | ## Reference 74 | The project is a joint effort of donation proposal coming from Alibaba and Datadog to replace [Instrgen](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/v1.34.0/instrgen). The proposals are listed as follows: 75 | - https://github.com/open-telemetry/community/issues/2344 76 | - https://github.com/open-telemetry/community/issues/2497 77 | -------------------------------------------------------------------------------- /projects/http.md: -------------------------------------------------------------------------------- 1 | ## Description 2 | 3 | Get the HTTP semantic conventions across the finish line to stability, and afterwards update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions. 4 | 5 | ## Project Board 6 | 7 | https://github.com/orgs/open-telemetry/projects/41 8 | 9 | ## Deliverables 10 | 11 | * Mark the HTTP semantic conventions as stable. 12 | * Update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions. 13 | 14 | ## Staffing / Help Wanted 15 | 16 | The goal is to follow @tedsuo's proposed [Semantic Convention Process](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#heading=h.xc2ft2cddhny). 17 | 18 | * __Stage 1__: SIG Preparation 19 | * __Stage 2__: Specification 20 | * __Stage 3__: Implementation 21 | 22 | ### Required staffing for Stage 1 and 2 23 | 24 | * @trask project lead 25 | * @denisivan0v domain expert 26 | * @lmolkova domain expert 27 | * @mateuszrzeszutek prototyping in Java 28 | * @reyang technical committee sponsor 29 | * @jsuereth technical committee sponsor 30 | * Need: more domain experts 31 | * Need: engineers willing to write prototypes in at least one more language other than Java. Language should be fairly different from Java (for example: Python). 32 | * Need: maintainers or approvers from those languages committed to reviewing the prototypes. 33 | 34 | ### Required staffing for Stage 3 35 | 36 | * @trask project lead 37 | * @mateuszrzeszutek updating Java instrumentation 38 | * Need: engineers across all languages willing to update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions. 39 | * Need: maintainers or approvers across all languages committed to reviewing the updates. 40 | 41 | ## Meeting Times 42 | 43 | Once a project is started, the SIG should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar. 44 | 45 | ## Timeline 46 | 47 | All work has been completed. -------------------------------------------------------------------------------- /projects/k8s-semconv.md: -------------------------------------------------------------------------------- 1 | # K8s Conventions SIG 2 | 3 | ## Background and description 4 | 5 | Kubernetes is the leading platform for Opentelemetry Collector deployment (80.6%) according 6 | to a recent [survey](https://opentelemetry.io/blog/2024/otel-collector-survey/#otel-components-usage). 7 | The OpenTelemetry community would like to stabilize k8s semantic conventions including k8s/container metrics 8 | in order to help the adoption of the respective OTel Collector receivers and processors. 9 | The goal of this SIG project is to work towards this direction. 10 | 11 | ### Current challenges 12 | 13 | At the moment there is no specific effort to align the Collector's implementation with 14 | the K8s Semantic Conventions and at the same time there is no big trust that the K8s Semantic Conventions 15 | can be considered as stable. 16 | 17 | ### Goals, objectives, and requirements 18 | 19 | The primary goal of this project is to focus on the defining a solid base in the K8s Semantic Conventions 20 | and work on adopting the Collector accordingly. Some of the issues that the group will be focusing are the following: 21 | 22 | * [META: Define Semantic Conventions for k8s metrics](https://github.com/open-telemetry/semantic-conventions/issues/1032) 23 | * [Clarify the brief of container.image.id](https://github.com/open-telemetry/semantic-conventions/issues/1236) 24 | * [Define rules for Kubernetes name and uid resource attributes](https://github.com/open-telemetry/semantic-conventions/issues/430) 25 | * [Add k8s.pod.ip attribute](https://github.com/open-telemetry/semantic-conventions/issues/1160) 26 | * [k8s: add metric for pod status conditions](https://github.com/open-telemetry/semantic-conventions/issues/1398) 27 | * [Proposal: Define mapping from k8s well-known labels to semconv](https://github.com/open-telemetry/semantic-conventions/issues/236) 28 | * [k8s: new attributes: CSI driver and volume handle](https://github.com/open-telemetry/semantic-conventions/issues/1119) 29 | * [[k8sclusterreceiver] refactoring pod status phase](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/24425) 30 | * [Align K8s SemConv with Entities work](https://github.com/open-telemetry/semantic-conventions/issues/1420) 31 | * [Associate K8s metrics with resource attributes](https://github.com/open-telemetry/semantic-conventions/issues/1421) 32 | * TBA 33 | 34 | ## Deliverables 35 | 36 | * Introduce and stabilize k8s semantic conventions. 37 | * Update existing OpenTelemetry Collector components to conform with the stable conventions. 38 | 39 | ## Staffing / Help Wanted 40 | 41 | We are seeking domain experts to work on the introduction and stability of the K8s Semantic Conventions. 42 | 43 | The goal is to follow @tedsuo's proposed [Semantic Convention Process](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#heading=h.xc2ft2cddhny). 44 | 45 | - Stage 1: SIG Preparation 46 | - Stage 2: Stabilizing the Specification 47 | - Stage 3: Implementation 48 | 49 | ## Timeline 50 | 51 | Timeline 52 | Stage 1 (SIG Preparation) is happening now. 53 | 54 | Stage 2 (Stabilizing the Specification) will begin as soon as we have adequate 55 | staffing for this project, and we coordinate weekly 56 | meeting times (currently targeting X). 57 | 58 | Stage 3 (Implementation) will begin as soon as the k8s metrics and resource attributes are marked stable, 59 | and it should be relatively short we only need to update conformance to the specification for a few collector components. 60 | 61 | ## Labels 62 | 63 | * area:k8s 64 | * area:containers 65 | 66 | ### Required staffing 67 | 68 | **Project Leads:** 69 | 70 | - @ChrsMark (Elastic) 71 | - @dashpole (Google) 72 | 73 | **Domain Experts:** 74 | 75 | - @dmitryax (Splunk/Cisco) 76 | - @TylerHelmuth (Honeycomb) 77 | - @rogercoll (Elastic) 78 | - @jaronoff97 (Lightstep) 79 | - @povilasv (Coralogix) 80 | - @jinja2 (Splunk/Cisco) 81 | - ... 82 | 83 | **Sponsors:** 84 | 85 | - @jsuereth (Google) 86 | - @AlexanderWert (Elastic) 87 | 88 | **GC liaison:** 89 | 90 | - TBA 91 | 92 | **SemConv Maintainers:** 93 | 94 | - @open-telemetry/semconv-k8s-approvers 95 | 96 | **Collector's components code-owners:** 97 | 98 | - @dmitryax (Splunk/Cisco) 99 | - @TylerHelmuth (Honeycomb) 100 | - @povilasv (Coralogix) 101 | - @ChrsMark (Elastic) 102 | 103 | **Language specific maintainers:** 104 | 105 | ## Project Board 106 | 107 | [K8s SemConv SIG project board](https://github.com/orgs/open-telemetry/projects/114) 108 | 109 | ## SIG Meetings and Other Info 110 | 111 | *meeting time*: biweekly on Wednesday 8:00am PDT (+1 week offset from the SIG Prometheus Interoperability) 112 | 113 | *meeting-notes*: [Agenda](https://docs.google.com/document/d/17DqFVlLvO43neXXTwlSd1zcKjSRA8P3d0Y444QNwUTQ) 114 | 115 | *cncf-slack*: For async conversation please use [#otel-k8s-semconv-sig](https://cloud-native.slack.com/archives/C07Q1L0FGKX) slack channel from official CNCF slack workspace. 116 | -------------------------------------------------------------------------------- /projects/otelarrow.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry Protocol with Apache Arrow ("OTel-Arrow") 2 | 3 | ## Description 4 | 5 | The OpenTelemetry Protocol with Apache Arrow ("OTel-Arrow") project is 6 | currently in Phase 2. 7 | 8 | In Phase 1, we built a reference implementation for streaming 9 | OpenTelemetry data using Apache Arrow IPC between two Collectors to 10 | achieve significant network savings through a compression "bridge". 11 | The project's OpenTelemetry Collector components are maintained in the 12 | Collector-Contrib repository and are [production ready, as summarized 13 | in our blog post](https://opentelemetry.io/blog/2024/otel-arrow-production). 14 | 15 | In Phase 2, we are building a reference implementation for improving 16 | efficiency inside the Collector using Apache Arrow data frames as the 17 | pipeline data object. We aim to establish a foundation for working 18 | with OTel-Arrow data in the Collector, for access to the Arrow 19 | ecosystem. 20 | 21 | ## Project board 22 | 23 | https://github.com/orgs/open-telemetry/projects/139 24 | 25 | ## Project governance 26 | 27 | [See the success criteria, restrictions, and governance items listed in 28 | our project phases document](https://github.com/open-telemetry/otel-arrow/blob/main/docs/project-phases.md). 29 | 30 | ## Deliverables 31 | 32 | The Phase 2 deliverables are listed below: 33 | 34 | - In-process OTAP pipeline implemented as Rust libraries. We view this 35 | as an appropriate choice, as stated in the [Phase 2 design 36 | rationale](https://github.com/open-telemetry/otel-arrow/blob/main/docs/phase2-design.md#choice-of-rust) 37 | ([discussion](https://github.com/open-telemetry/otel-arrow/issues/294)). 38 | - Explore API design for column-oriented pipeline data object based on 39 | OTAP data frames. We will investigate how to work with OpenTelemetry 40 | data in a column-oriented way. 41 | - Prototype for DataFusion integration with OpenTelemetry data. We 42 | will study the feasibility of an OTTL-transform implementation in 43 | DataFusion, specifically. 44 | - Benchmarks measuring OTAP and OTLP pipelines in Rust and Golang. We 45 | aim to deliver a 2x to 10x performance improvement for OpenTelemetry 46 | processing pipelines. 47 | 48 | ## Community 49 | 50 | We welcome contributors. Users of OpenTelemetry with an interest in 51 | connection OpenTelemetry data with the Apache Arrow ecosystem are 52 | welcome to join and share their use-cases. 53 | 54 | ## Required staffing 55 | 56 | Project leads / maintainers 57 | 58 | * @jmacd 59 | * @lquerel 60 | 61 | Sponsoring TC members 62 | 63 | * @reyang 64 | 65 | Engineers contributing to the SIG 66 | 67 | * @v0y4g3r 68 | * @jaronoff97 69 | 70 | Project approvers 71 | 72 | * @drewrelmas 73 | * @moh-osman3 74 | 75 | ## Meeting times 76 | 77 | Bi-weekly Thursday at 08:00 PT. 78 | 79 | Bi-weekly Tuesday at 16:00 PT. 80 | 81 | See the [Calendar](../README.md#calendar) to find upcoming meetings. 82 | 83 | ## Timeline 84 | 85 | Starting in April 2025, the team will spend 6 months on this investigation. 86 | -------------------------------------------------------------------------------- /projects/project-infrastructure.md: -------------------------------------------------------------------------------- 1 | # Project Infrastructure SIG 2 | 3 | ## Description 4 | 5 | As OpenTelemetry grows, the need for tooling and automation around project 6 | infrastructure grows with it. This SIG is being established to create sustaining 7 | engineering efforts and best practices around both existing, and new, tools. 8 | 9 | Currently, a wide variety of tooling exists, including -- 10 | 11 | - Slack bots such as `stack-overflow-to-slack`. 12 | - GitHub tooling for issue management. 13 | - Automation for Zoom recording management. 14 | 15 | Meanwhile, new tools are being requested to address problems such as -- 16 | 17 | - Membership and group management 18 | - Repository adherence to best practices 19 | - Automated updates for cross-cutting release concerns (e.g., creating issues in 20 | repositories for new spec or semconv releases) 21 | - Package and release management 22 | - Easier access to GitHub integrations for SIGs 23 | - Improved visibility into project health 24 | 25 | This SIG will be responsible for these cross-cutting concerns, and work to 26 | build services that aid in maintainer, contributor, and community experience. 27 | 28 | ## Deliverables 29 | 30 | - Document existing tools and their purpose, along with documentation and build 31 | instructions. 32 | - Interview and collect feedback on cross-functional tooling needs (e.g., bots 33 | for GitHub issue management, IaC for organization management.) 34 | - Institute best practices for tooling development and maintenance. 35 | - Develop new tools as needed. 36 | - Establish 'tooling-as-a-service' for SIGs. 37 | 38 | The overall goal of this SIG is to remove the burden on the TC or organization 39 | owners from administrative and tooling concerns, and to provide consistent, 40 | well-documented, and useful tools for maintainers and contributors. 41 | 42 | ## Staffing 43 | 44 | GC/TC sponsors: 45 | 46 | - @austinlparker 47 | - @trask 48 | 49 | Maintainers, approvers, and contributors: 50 | 51 | - @svrnm 52 | - @jaronoff97 53 | 54 | ## Meeting Times 55 | 56 | Mostly async, with a bi-weekly meeting to coordinate and discuss progress. 57 | 58 | This time will be determined based on the availability of interested parties. 59 | 60 | ## Project Board 61 | 62 | - [Project Infrastructure SIG](https://github.com/orgs/open-telemetry/projects/91/views/1) 63 | -------------------------------------------------------------------------------- /projects/sampling.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry Sampling 2 | 3 | ## Description 4 | 5 | The OpenTelemetry Sampling project aims to improve sampling support in 6 | OpenTelemetry through protocol, API, and SDK features. This project 7 | works with the W3C trace context group to coordinate distributed 8 | tracing protocols across the observability industry. 9 | 10 | The project aims to complete the OpenTelemetry SDK specification with 11 | support for consistent probability head sampling with configurable SDK 12 | samplers. 13 | 14 | ## Project board 15 | 16 | https://github.com/orgs/open-telemetry/projects/133 17 | 18 | ## Deliverables 19 | 20 | The Sampling project has several OTEPs to develop the foundation 21 | for probability sampling in OpenTelemetry. 22 | 23 | - [OTEP 168](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/trace/0168-sampling-propagation.md) 24 | - [OTEP 170](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/trace/0170-sampling-probability.md) 25 | - [OTEP 235](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/trace/0235-sampling-threshold-in-trace-state.md) 26 | - [OTEP 250](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/trace/0250-Composite_Samplers.md) 27 | 28 | The project coordinates development of SDK and Collector prototypes 29 | and support libraries. 30 | 31 | Maintainership of [Collector-Contrib sampling package](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/sampling), [Collector-Contrib probabilistic logs/span sampler](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/probabilisticsamplerprocessor). 32 | 33 | ## Community 34 | 35 | We welcome contributors. Users of OpenTelemetry with an interest in 36 | sampling of all kinds, please join our SIG or #otel-sampling channel 37 | to discuss. 38 | 39 | ## Required staffing 40 | 41 | Sponsor 42 | 43 | * @jpkrohling 44 | 45 | Engineers contributing to the SIG 46 | 47 | * @jmacd 48 | * @oertl 49 | * @PeterF778 50 | * @kentquirk 51 | * @yuanyuanzhao3 52 | 53 | ## Meeting times 54 | 55 | Every other Thursday at 8AM PT. 56 | 57 | ## Timeline 58 | 59 | 2021-22: Experimental specification based on `p`-value and `r`-value with power-of-two support. 60 | 2023-24: Modern specification based on `th`-value and `rv`-value with 56 bit support. 61 | 2024-25: Composable sampler definition, configuration support. 62 | -------------------------------------------------------------------------------- /projects/security-semconv.md: -------------------------------------------------------------------------------- 1 | # Security Semantic Conventions 2 | 3 | ## Description 4 | 5 | The purpose of this project is to bring in the security domain for the OpenTelemetry community. 6 | 7 | As outlined in the [ECS OTEP](https://github.com/open-telemetry/oteps/blob/main/text/0199-support-elastic-common-schema-in-opentelemetry.md), the Elastic Common Schema (ECS) is currently being contributed to the semantic conventions schema. Given the significance of security within ECS, establishing this SIG is crucial as it will expedite the donation of ECS fields tailored to security use cases. Beyond expanding the schema, our aim is to craft a clear vision for the instrumentation required. 8 | 9 | ## Deliverables 10 | 11 | * Our current focus is on defining essential semantic conventions for security use cases. 12 | * This includes but is not limited to the following namespaces: 13 | * [`Code signature`](https://www.elastic.co/guide/en/ecs/current/ecs-code_signature.html) 14 | * [`DLL`](https://www.elastic.co/guide/en/ecs/current/ecs-dll.html) 15 | * [`DNS`](https://www.elastic.co/guide/en/ecs/current/ecs-dns.html) 16 | * [`File`](https://www.elastic.co/guide/en/ecs/current/ecs-file.html) 17 | * [`Group`](https://www.elastic.co/guide/en/ecs/current/ecs-group.html) 18 | * [`Hash`](https://www.elastic.co/guide/en/ecs/current/ecs-hash.html) 19 | * [`Host`](https://www.elastic.co/guide/en/ecs/current/ecs-host.html) 20 | * [`Network`](https://www.elastic.co/guide/en/ecs/current/ecs-network.html) 21 | * [`Operating System`](https://www.elastic.co/guide/en/ecs/current/ecs-os.html) 22 | * [`Package`](https://www.elastic.co/guide/en/ecs/current/ecs-package.html) 23 | * [`Process`](https://www.elastic.co/guide/en/ecs/current/ecs-process.html) 24 | * [`Registry`](https://www.elastic.co/guide/en/ecs/current/ecs-registry.html) 25 | * [`Risk information`](https://www.elastic.co/guide/en/ecs/current/ecs-risk.html) 26 | * [`Rule`](https://www.elastic.co/guide/en/ecs/current/ecs-rule.html) 27 | * [`Threat`](https://www.elastic.co/guide/en/ecs/current/ecs-threat.html) 28 | * [`TLS`](https://www.elastic.co/guide/en/ecs/current/ecs-tls.html) 29 | * [`User`](https://www.elastic.co/guide/en/ecs/current/ecs-user.html) 30 | * [`Vulnerability`](https://www.elastic.co/guide/en/ecs/current/ecs-vulnerability.html) 31 | * Please note that some of the above-mentioned namespaces are already a part of the Semantic Conventions schema. The goal is to expand these namespaces to include additional fields that are relevant to security use cases. 32 | 33 | * As new use cases and namespaces are introduced to the semantic conventions, there may be a need for additional instrumentation to accommodate them. It is anticipated that this aspect will expand through an iterative process. 34 | 35 | ## Staffing / Help Wanted 36 | 37 | We are seeking security experts to collaborate with us in expanding the security domain within the community. 38 | 39 | ### Required staffing 40 | 41 | There is an open [PR](https://github.com/open-telemetry/semantic-conventions/issues/580) to create a `semconv-security-approver` group for all PRs related to security fields. 42 | 43 | * project lead: @trisch-me (Elastic) 44 | * domain expert: @mjwolf (Elastic) 45 | * domain expert: @raesene (Datadog) 46 | * domain expert: @lambdanis (Isovalent) 47 | * domain expert: @mdelfabro (Dynatrace) 48 | * domain expert: @kelnage (Grafana Labs) 49 | * domain expert: @alexvanboxel (Collibra) 50 | 51 | * TC sponsor: @reyang 52 | * TC sponsor: @jsuereth 53 | 54 | Need more 55 | - [ ] domain experts 56 | - [ ] potentially, maintainers of language-specific instrumentation may be needed if the need arises. 57 | 58 | 59 | ## Meeting Times 60 | 61 | There is an allocated time in the Semantic Conventions SIG for this project. 62 | - Mondays at 8 AM PST 63 | 64 | For async conversation please use #otel-semconv-security slack channel from official CNCF slack workspace. 65 | 66 | ## Security dashboard 67 | 68 | [Main dashboard](https://github.com/orgs/open-telemetry/projects/104/views/1) with all the issues and PRs related to the project. 69 | 70 | ## Timeline 71 | 72 | The goal is to have the security semantic conventions implemented by the end of 2024. 73 | 74 | The timeline for this project is as follows: 75 | December 2023: Initial Draft 76 | April 2024: Review and Refinement 77 | May 2024-December 2024: Introducing the Security Semantic Conventions 78 | 79 | 80 | ## Labels 81 | 82 | * security 83 | 84 | ## Linked Issues and PRs 85 | 86 | * [Donating ECS to OpenTelemetry](https://github.com/open-telemetry/oteps/blob/main/text/0199-support-elastic-common-schema-in-opentelemetry.md) 87 | * [Creation of semconv-security-approver group](https://github.com/open-telemetry/semantic-conventions/issues/580) 88 | -------------------------------------------------------------------------------- /projects/system-semconv.md: -------------------------------------------------------------------------------- 1 | # System Semantic Conventions stability 2 | 3 | ## Description 4 | 5 | The OpenTelemetry Collector community would like to stabilize system semantic conventions including system metrics in order to help the adoption of the OTel [hostmetricsreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/65a1dea390881aad43f5252d730ece36d9c094b5/receiver/hostmetricsreceiver). 6 | 7 | ## Project Board 8 | 9 | See: 10 | 11 | ### Roadmap 12 | 13 | - 14 | - ([@ChrsMark]) 15 | - ([@mx-psi](https://github.com/mx-psi)) 16 | - ([@frzifus](https://github.com/frzifus)) 17 | - ([@dineshg13](https://github.com/dineshg13)) 18 | - 19 | - ([@braydonk](https://github.com/braydonk)) 20 | - 21 | 22 | ### done 23 | 24 | - ([@frzifus](https://github.com/frzifus)) 25 | 26 | #### Optional 27 | 28 | - 29 | - 30 | 31 | ### Finally 32 | 33 | - Stabilize existing semantic conventions (system metrics) 34 | 35 | ## Deliverables 36 | 37 | - Mark the [system semantic conventions](https://github.com/open-telemetry/opentelemetry-specification/blob/37ab6b056172ad36d31ce217927e47bbe031d831/specification/metrics/semantic_conventions/system-metrics.md#semantic-conventions-for-system-metrics) as stable. 38 | - Update existing OpenTelemetry Collector hostmetricsreceiver to conform with the stable conventions. 39 | 40 | ## Staffing / Help Wanted 41 | 42 | The goal is to follow [@tedsuo](http://github.com/tedsuo)'s proposed [Semantic Convention Process](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#heading=h.xc2ft2cddhny). 43 | 44 | - **Stage 1**: SIG Preparation 45 | - **Stage 2**: Stabilizing the Specification 46 | - **Stage 3**: Implementation 47 | 48 | ### Required staffing 49 | 50 | - [@mx-psi](https://github.com/mx-psi), [@frzifus](https://github.com/frzifus) project leads 51 | - [@jsuereth](https://github.com/jsuereth) technical committee sponsor 52 | - domain experts: 53 | - [@MovieStoreGuy](https://github.com/MovieStoreGuy) 54 | - [@dmitryax](https://github.com/dmitryax) 55 | - [@gbbr](https://github.com/gbbr) 56 | - [@sallyom](https://github.com/sallyom) 57 | - [@ChrsMark](https://github.com/ChrsMark) 58 | - [@kaiyan-sheng](https://github.com/kaiyan-sheng) 59 | - [@braydonk](https://github.com/braydonk) 60 | - [@bertysentry](https://github.com/bertysentry) 61 | - [@dineshg13](https://github.com/dineshg13) 62 | 63 | ## Meetings 64 | 65 | *cncf-slack* [#otel-system-metrics](https://cloud-native.slack.com/archives/C05CTFE9U4A) 66 | *meeting-notes* [google-doc](https://docs.google.com/document/d/1p5TH57t43XpxA48onLzX4PIr3g6ydYKCtR_AUlsCnQk) 67 | 68 | ## Timeline 69 | 70 | **Stage 1** (SIG Preparation) is happening now. 71 | 72 | **Stage 2** (Stabilizing the Specification) will begin as soon as we have adequate staffing for this project, and we coordinate a weekly meeting times (currently targeting mid-july). 73 | 74 | **Stage 3** (Implementation) will begin as soon as the system metrics are marked stable, and it should be relatively short we only need to update conformance to the specification for a single collector package. 75 | 76 | ## Labels 77 | 78 | *The tracking issue should be properly labeled to indicate what parts of the specification it is focused on.* 79 | 80 | ## Linked Issues and PRs 81 | 82 | *All PRs, Issues, and OTEPs related to the project should link back to the tracking issue, so that they can be easily found.* 83 | -------------------------------------------------------------------------------- /reports/ADA_Logics-collector-fuzzing-audit-2024.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/open-telemetry/community/8a64ef60c8a89246c6c3175118f4f96ef0360b6b/reports/ADA_Logics-collector-fuzzing-audit-2024.pdf -------------------------------------------------------------------------------- /reports/compliance.md: -------------------------------------------------------------------------------- 1 | # Compliance 2 | 3 | | Repository | OpenSSF Scorecard | FOSSA License Scan | 4 | |------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 5 | | [opentelemetry-android](https://github.com/open-telemetry/opentelemetry-android) | [![OpenSSF Scorecard for opentelemetry-android](https://api.scorecard.dev/projects/github.com/open-telemetry/opentelemetry-android/badge)](https://scorecard.dev/viewer/?uri=github.com/open-telemetry/opentelemetry-android) | | 6 | | [opentelemetry-collector](https://github.com/open-telemetry/opentelemetry-collector) | [![OpenSSF Scorecard for opentelemetry-collector](https://api.scorecard.dev/projects/github.com/open-telemetry/opentelemetry-collector/badge)](https://scorecard.dev/viewer/?uri=github.com/open-telemetry/opentelemetry-collector) | | 7 | | [opentelemetry-go](https://github.com/open-telemetry/opentelemetry-go) | [![OpenSSF Scorecard for opentelemetry-go](https://api.scorecard.dev/projects/github.com/open-telemetry/opentelemetry-go/badge)](https://scorecard.dev/viewer/?uri=github.com/open-telemetry/opentelemetry-go) | | 8 | | [opentelemetry-java](https://github.com/open-telemetry/opentelemetry-java) | [![OpenSSF Scorecard for opentelemetry-java](https://api.scorecard.dev/projects/github.com/open-telemetry/opentelemetry-java/badge)](https://scorecard.dev/viewer/?uri=github.com/open-telemetry/opentelemetry-java) | [![FOSSA Status for opentelemetry-java](https://app.fossa.com/api/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java.svg?type=shield&issueType=license)](https://app.fossa.com/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java?ref=badge_shield&issueType=license) | 9 | | [opentelemetry-java-contrib](https://github.com/open-telemetry/opentelemetry-java-contrib) | [![OpenSSF Scorecard for opentelemetry-java-contrib](https://api.scorecard.dev/projects/github.com/open-telemetry/opentelemetry-java-contrib/badge)](https://scorecard.dev/viewer/?uri=github.com/open-telemetry/opentelemetry-java-contrib) | [![FOSSA Status for opentelemetry-java-contrib](https://app.fossa.com/api/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java-contrib.svg?type=shield&issueType=license)](https://app.fossa.com/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java-contrib?ref=badge_shield&issueType=license) | 10 | | [opentelemetry-java-instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation) | [![OpenSSF Scorecard for opentelemetry-java-instrumentation](https://api.scorecard.dev/projects/github.com/open-telemetry/opentelemetry-java-instrumentation/badge)](https://scorecard.dev/viewer/?uri=github.com/open-telemetry/opentelemetry-java-instrumentation) | [![FOSSA Status for opentelemetry-java-instrumentation](https://app.fossa.com/api/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java-instrumentation.svg?type=shield&issueType=license)](https://app.fossa.com/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java-instrumentation?ref=badge_shield&issueType=license) | 11 | | [opentelemetry-proto-java](https://github.com/open-telemetry/opentelemetry-proto-java) | [![OpenSSF Scorecard for opentelemetry-proto-java](https://api.scorecard.dev/projects/github.com/open-telemetry/opentelemetry-proto-java/badge)](https://scorecard.dev/viewer/?uri=github.com/open-telemetry/opentelemetry-proto-java) | [![FOSSA Status for opentelemetry-proto-java](https://app.fossa.com/api/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-proto-java.svg?type=shield&issueType=license)](https://app.fossa.com/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-proto-java?ref=badge_shield&issueType=license) | 12 | | [semantic-conventions-java](https://github.com/open-telemetry/semantic-conventions-java) | [![OpenSSF Scorecard for semantic-conventions-java](https://api.scorecard.dev/projects/github.com/open-telemetry/semantic-conventions-java/badge)](https://scorecard.dev/viewer/?uri=github.com/open-telemetry/semantic-conventions-java) | [![FOSSA Status for semantic-conventions-java](https://app.fossa.com/api/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fsemantic-conventions-java.svg?type=shield&issueType=license)](https://app.fossa.com/projects/custom%2B162%2Fgithub.com%2Fopen-telemetry%2Fsemantic-conventions-java?ref=badge_shield&issueType=license) | 13 | -------------------------------------------------------------------------------- /scripts/gc-elections/README.md: -------------------------------------------------------------------------------- 1 | # GC Election Voter Roll Generation 2 | These helper scripts are used to generate the initial voter roll for the OpenTelemetry Governance Committee elections, before any exemptions to the automatic process are considered. 3 | 4 | Two environment variables are used across these scripts to configure output files for voters rolls: 5 | 6 | * `VOTERS_ROLL_PATH`: the path to the output CSV file with the voters roll and number of contributions (defaults to `./voters-roll.csv`). 7 | * `VOTERS_ROLL_HELIOS_PATH`: the path to the output CSV file with the voters roll in a format accepted by Helios Voting (defaults to `./voters-roll-helios.csv`). 8 | 9 | ## 1. Generate the voters roll 10 | The `generate-voters-roll.py` script generates a CSV file with the GitHub logins and contributions of the eligible voters for the upcoming elections. It queries the PostgreSQL Data Source backing `opentelemetry.devstats.cncf.io` to get the list of contributors eligible for voting. It then uses the GitHub REST API to get the GitHub login (capitalized) for each user. 11 | 12 | Although not required, it is recommended to set a `GITHUB_TOKEN` environment variable with a token with minimal permissions. This avoids GitHub's limits for unauthenticated requests. 13 | 14 | Example usage: 15 | ```bash 16 | export GITHUB_TOKEN=your_token_here 17 | python generate-voters-roll.py 18 | ``` 19 | 20 | ## 2. Create GitHub comments 21 | Using the generated voters roll file indicated by `$VOTERS_ROLL_PATH`, the `create-github-comments.sh` script tags eligible voters on a given GitHub issue, inviting them to vote in the next election. 22 | 23 | To workaround limits of mentions on a single comment, the script creates multiple comments in batches of 50 voters. 24 | 25 | This script takes two arguments: 26 | * `-i issue_url`: the GitHub issue URL to add comments to (e.g. `https://github.com/open-telemetry/community/issues/1173`) 27 | * `-d bool`: dry-run mode, which only prints the comments that would be created without actually creating them (defaults to `true`). 28 | 29 | For this script to work, you must have the GitHub CLI (`gh`) installed and authenticated. 30 | 31 | Example usage: 32 | ```bash 33 | ./create-github-comments.sh -i https://github.com/open-telemetry/community/issues/1173 -d true 34 | ``` 35 | 36 | ## 3. Convert voters roll to Helios format 37 | The `convert-voters-roll-to-helios.py` script converts the voters roll file indicated by `$VOTERS_ROLL_PATH` to a format accepted by Helios Voting. It generates a new CSV file in `$VOTERS_ROLL_HELIOS_PATH` with the GitHub logins of the eligible voters for the upcoming elections. 38 | 39 | Example usage: 40 | ```bash 41 | python convert-voters-roll-to-helios.py 42 | ``` -------------------------------------------------------------------------------- /scripts/gc-elections/convert-voter-roll-to-helios.py: -------------------------------------------------------------------------------- 1 | import csv 2 | import os 3 | 4 | VOTERS_ROLL_PATH = os.getenv('VOTERS_ROLL_PATH', './voters-roll.csv') 5 | VOTERS_ROLL_HELIOS_PATH = os.getenv('VOTERS_ROLL_HELIOS_PATH', './voters-roll-helios.csv') 6 | 7 | # Open the input and output CSV files 8 | with open(VOTERS_ROLL_PATH, mode='r') as infile, open(VOTERS_ROLL_HELIOS_PATH, mode='w', newline='') as outfile: 9 | reader = csv.reader(infile) 10 | writer = csv.writer(outfile) 11 | 12 | # Process each row in the input file 13 | for row in reader: 14 | if row is not None and len(row) > 0: 15 | writer.writerow(['github', row[0]]) 16 | 17 | print(f"Voters file for Helios Voting generated as {VOTERS_ROLL_HELIOS_PATH}") 18 | -------------------------------------------------------------------------------- /scripts/gc-elections/create-gihub-comments.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | file=${VOTERS_ROLL_PATH:-"./voters-roll.csv"} 4 | dryrun="true" 5 | 6 | command -v gh 1>/dev/null 2>&1 7 | if [ $? != 0 ]; then 8 | echo "The command 'gh' is expected to exist and be configured in order to make comments to GitHub issues." 9 | exit 1 10 | fi 11 | 12 | while getopts f:i:d: flag 13 | do 14 | case "${flag}" in 15 | i) issue=${OPTARG};; 16 | d) dryrun=${OPTARG};; 17 | esac 18 | done 19 | 20 | if [[ -z $issue ]]; then 21 | echo "Please, specify the issue URL. Ex.: $0 -i https://github.com/open-telemetry/community/issues/1173" 22 | exit 0 23 | fi 24 | 25 | if [ ! -f $file ]; then 26 | echo "Please, specify an existing input file as a VOTERS_ROLL_PATH env variable" 27 | exit 0 28 | fi 29 | 30 | header="We invite the people mentioned in this comment to vote in the OpenTelemetry Governance Committee, as they have provided more than 20 contributions to the project over the last year via GitHub. Your contributions were comments, code reviews, pull requests, among others. Thank you!\n" 31 | msg=${header} 32 | counter=0 33 | 34 | echo -e "Reading the file ${file} and creating comments for the issue ${issue}\n" 35 | while read -r line; 36 | do 37 | re="^(.+)\,(.+)$" 38 | [[ $line =~ $re ]] 39 | handle="${BASH_REMATCH[1]}" 40 | contributions="${BASH_REMATCH[2]//[$'\r\n']}" 41 | 42 | if [[ -z $handle ]]; then 43 | continue 44 | fi 45 | 46 | msg="${msg}\\n* @${handle}" 47 | ((counter++)) 48 | 49 | if (( counter >= 50 )); then 50 | # reached 50 mentions, create the comment 51 | if [ "$dryrun" = true ]; then 52 | echo -e $msg 53 | else 54 | echo -e $msg | gh issue comment "${issue}" -F - 55 | fi 56 | 57 | # reset 58 | msg=${header} 59 | counter=0 60 | fi 61 | done < ${file} 62 | 63 | if (( counter > 0 )); then 64 | if [ "$dryrun" = true ]; then 65 | echo -e $msg 66 | else 67 | echo -e $msg | gh issue comment "${issue}" -F - 68 | fi 69 | fi -------------------------------------------------------------------------------- /scripts/gc-elections/generate-voters-roll.py: -------------------------------------------------------------------------------- 1 | import csv 2 | import os 3 | import requests 4 | import time 5 | 6 | VOTERS_ROLL_PATH = os.getenv('VOTERS_ROLL_PATH', './voters-roll.csv') 7 | GH_TOKEN = os.getenv('GITHUB_TOKEN') 8 | 9 | 10 | # Get GitHub login from lowercase username 11 | def get_github_login(username): 12 | print(f"Getting GitHub login for {username}") 13 | time.sleep(0.1) # Sleep for 100ms to avoid rate limiting 14 | url = f'https://api.github.com/users/{username}' 15 | headers = {} 16 | if GH_TOKEN: 17 | headers = { 18 | 'Authorization': f'token {GH_TOKEN}' 19 | } 20 | response = requests.get(url, headers=headers) 21 | if response.status_code == 200: 22 | data = response.json() 23 | return data['login'] 24 | else: 25 | print(f"Failed to retrieve login for {username}: {response.status_code}") 26 | return None 27 | 28 | 29 | # Use devstats to get users and contributions with more than 20 contributions in the last year 30 | def get_users_and_contributions(): 31 | print("Getting contributions data from opentelemetry.devstats.cncf.io") 32 | # Define the URL and headers 33 | url = 'https://opentelemetry.devstats.cncf.io/api/ds/query' 34 | headers = { 35 | 'Accept': 'application/json', 36 | 'content-type': 'application/json' 37 | } 38 | 39 | # Define the JSON payload 40 | payload = { 41 | "queries": [ 42 | { 43 | "datasource": { 44 | "uid": "P172949F98CB31475", 45 | "type": "postgres" 46 | }, 47 | "rawSql": "select sub.name as name, sub.value as contributions from (select split_part(name, '$$$', 1) as name, sum(value) as value from shdev where series = 'hdev_contributionsallall' and period = 'y' group by split_part(name, '$$$', 1) ) sub where sub.value >= 20 order by name", 48 | "format": "table" 49 | } 50 | ], 51 | "range": { 52 | "from": "now", 53 | "to": "now" 54 | } 55 | } 56 | 57 | # Make the HTTP POST request 58 | response = requests.post(url, headers=headers, json=payload) 59 | 60 | # Check if the request was successful 61 | if response.status_code == 200: 62 | return response.json() 63 | else: 64 | print(f"Failed to retrieve contributions data: {response.status_code}") 65 | return None 66 | 67 | 68 | # Create a CSV file with the voters rolls 69 | def create_voters_rolls(data): 70 | frames = data['results']['A']['frames'] 71 | rows = [] 72 | 73 | for frame in frames: 74 | values = frame['data']['values'] 75 | names = values[0] 76 | contributions = values[1] 77 | for i in range(len(names)): 78 | login = get_github_login(names[i]) 79 | if login: 80 | rows.append([login, contributions[i]]) 81 | 82 | # Write the data to a CSV file 83 | print(f"Writing data to {VOTERS_ROLL_PATH}") 84 | with open(VOTERS_ROLL_PATH, mode='w', newline='') as file: 85 | writer = csv.writer(file) 86 | writer.writerows(rows) 87 | file.write('\n') 88 | 89 | 90 | # Call the function 91 | devstas_data = get_users_and_contributions() 92 | create_voters_rolls(devstas_data) 93 | -------------------------------------------------------------------------------- /scripts/update-sig-tables.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | import pip 3 | import sys 4 | 5 | # in the Makefile we use a unmodified python container to run this script, so we need to install pyyaml if it's not already installed 6 | if (len(sys.argv) > 1) and (sys.argv[1] == "--install"): 7 | pip.main(['install', 'pyyaml']) 8 | sys.argv = sys.argv[1:] 9 | 10 | import yaml 11 | 12 | # Do not safe the file but verify that it is different from the original one. 13 | run_in_check_mode = (len(sys.argv) > 1) and (sys.argv[1] == "--check") 14 | 15 | # Define the YAML input file and the markdown file to be updated 16 | yaml_input = "sigs.yml" 17 | markdown_file = "README.md" 18 | 19 | # Define the markers 20 | start_marker = "" 21 | end_marker = "" 22 | 23 | def format_chat(chat): 24 | if chat['type'] == 'slack': 25 | return f"[{chat['name']}](https://cloud-native.slack.com/archives/{chat['id']})" 26 | elif chat['type'] == 'other': 27 | return f"[{chat['name']}]({chat['link']})" 28 | else: 29 | return "" 30 | 31 | # Read the YAML file 32 | with open(yaml_input, 'r') as file: 33 | data = yaml.safe_load(file) 34 | 35 | # Extract the top and bottom parts of the existing markdown file 36 | with open(markdown_file, 'r') as file: 37 | content = file.read() 38 | top_part, bottom_part = content.split(start_marker, 1)[0], content.split(end_marker, 1)[1] 39 | 40 | # Generate the markdown content for each SIG group 41 | markdown_content = start_marker + '\n' 42 | for group in data: 43 | # Group heading 44 | group_name = group['name'] 45 | markdown_content += f"### {group_name}\n\n" 46 | 47 | # Table headers 48 | if group_name == "Specification SIGs": 49 | markdown_content += "| Name | Meeting Time | Meeting Notes | Slack Channel | Meeting Invites Group | [Sponsors](./project-management.md#project-proposal) | [Governance Committee](./community-members.md#governance-committee) Liaison |\n" 50 | markdown_content += "|------|--------------|---------------|---------------|-----------------|--------------------------------|--------------------------------|\n" 51 | else: 52 | markdown_content += "| Name | Meeting Time | Meeting Notes | Slack Channel | Meeting Invites Group | [Governance Committee](./community-members.md#governance-committee) Liaison |\n" 53 | markdown_content += "|------|--------------|---------------|---------------|-----------------|--------------------------------|\n" 54 | 55 | # Table rows for SIGs 56 | for sig in group['sigs']: 57 | name = sig['name'] 58 | meeting = sig.get('meeting', '') 59 | notes_type = sig['notes'].get('type', '') 60 | notes_value = sig['notes'].get('value', '') 61 | 62 | chats = " and ".join( 63 | [format_chat(chat) 64 | for chat in sig.get('chat', []) 65 | if chat.get('name') and chat.get('type')] 66 | ) 67 | 68 | short_name = None 69 | for chat in sig.get('chat', []): 70 | if chat.get('type') == 'slack': 71 | short_name = 'sig-' + chat.get('name').replace('#otel-', '').replace('sig-', '') 72 | break 73 | 74 | invites = sig.get('invites', 'none') 75 | tc_sponsors = ",
".join( 76 | [f"[{sponsor['name']}](https://github.com/{sponsor['github']})" 77 | for sponsor in sig.get('sponsors', []) 78 | if sponsor.get('name') and sponsor.get('github')] 79 | ) 80 | 81 | gc_liaison = "
".join( 82 | [f"[{liaison['name']}](https://github.com/{liaison['github']})" 83 | for liaison in sig.get('gcLiaison', []) 84 | if liaison.get('name') and liaison.get('github')] 85 | ) 86 | 87 | # Construct notes and calendar entries based on type 88 | if notes_type == "gDoc": 89 | notes = f"[Google Doc](https://docs.google.com/document/d/{notes_value})" 90 | else: 91 | notes = notes_value 92 | 93 | if invites == "none": 94 | calendar = "" 95 | else: 96 | calendar = f"[{invites}](https://groups.google.com/a/opentelemetry.io/g/{invites})" 97 | 98 | if group_name == "Specification SIGs": 99 | markdown_content += f"| {name} | {meeting} | {notes} | {chats} | {calendar} | {tc_sponsors} | {gc_liaison} | \n" 100 | else: 101 | markdown_content += f"| {name} | {meeting} | {notes} | {chats} | {calendar} | {gc_liaison} |\n" 102 | 103 | # Add a newline for spacing after the table 104 | markdown_content += "\n" 105 | 106 | markdown_content += end_marker 107 | 108 | result = top_part + markdown_content + bottom_part 109 | 110 | if run_in_check_mode: 111 | with open(markdown_file, 'r') as file: 112 | original = file.read() 113 | if original == result: 114 | sys.exit(0) 115 | else: 116 | sys.exit(1) 117 | else: 118 | # Write the updated markdown content to file 119 | with open(markdown_file, 'w') as file: 120 | file.write(top_part) 121 | file.write(markdown_content) 122 | file.write(bottom_part) 123 | 124 | # Inform the user that the markdown file has been updated 125 | print("The markdown file has been updated with the new SIG tables.") 126 | -------------------------------------------------------------------------------- /scripts/validate-sigs.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | import sys 3 | import re 4 | import pip 5 | 6 | # in the Makefile we use a unmodified python container to run this script, so we need to install pyyaml if it's not already installed 7 | if (len(sys.argv) > 1) and (sys.argv[1] == "--install"): 8 | pip.main(['install', 'pyyaml']) 9 | 10 | import yaml 11 | 12 | def validate_yaml(filename): 13 | with open(filename, 'r') as file: 14 | content = yaml.safe_load(file) 15 | 16 | invalid_items = [] 17 | 18 | for item_index, item in enumerate(content): 19 | item_prefix = f"{item.get('name', 'Unnamed')}" 20 | 21 | # Validate SIGs if they exist 22 | if 'sigs' in item: 23 | for sig_index, sig in enumerate(item['sigs']): 24 | sig_prefix = f"{item_prefix} - {sig.get('name', 'Unnamed')}:" 25 | 26 | # Check name and meeting are set for SIG 27 | if 'name' not in sig: 28 | invalid_items.append(f"{sig_prefix} Missing 'name' field.") 29 | if 'meeting' not in sig: 30 | invalid_items.append(f"{sig_prefix} Missing 'meeting' field.") 31 | 32 | # Check notes validation for SIG 33 | notes = sig.get('notes', {}) 34 | if notes.get('type') not in ('none', 'gDoc'): 35 | invalid_items.append(f"{sig_prefix} Notes type must be 'none' or 'gDoc'.") 36 | elif notes.get('type') == 'gDoc': 37 | if not re.match(r'^[\w-]+$', notes.get('value', '')): 38 | invalid_items.append(f"{sig_prefix} Invalid gDoc value.") 39 | 40 | # Check chat validation for SIG 41 | chats = sig.get('chat', []) 42 | slack_chats = [chat for chat in chats if chat.get('type') == 'slack'] 43 | if len(slack_chats) == 0: 44 | invalid_items.append(f"{sig_prefix} There must be at least one Slack chat.") 45 | else: 46 | for chat in slack_chats: 47 | if not chat.get('name', '').startswith('#otel-'): 48 | invalid_items.append(f"{sig_prefix} Chat name must start with '#otel-'.") 49 | if not re.match(r'^[A-Z0-9]{9,11}$', chat.get('id', '')): 50 | invalid_items.append(f"{sig_prefix} Invalid Slack channel ID.") 51 | 52 | # Check invites is set for SIG 53 | if 'invites' not in sig: 54 | invalid_items.append(f"{sig_prefix} Missing 'invites' field.") 55 | 56 | # Check sponsors for SIG 57 | tc_sponsors = sig.get('sponsors', []) 58 | if tc_sponsors: 59 | for sponsor in tc_sponsors: 60 | if 'name' not in sponsor or 'github' not in sponsor: 61 | invalid_items.append(f"{sig_prefix} Each tcSponsor must have a 'name' and 'github'.") 62 | 63 | # Check GC Liaison validation for SIG 64 | gc_liaisons = sig.get('gcLiaison', []) 65 | if not gc_liaisons: 66 | invalid_items.append(f"{sig_prefix} 'gcLiaison' list is missing or empty.") 67 | else: 68 | for gc_liaison in gc_liaisons: 69 | if 'name' not in gc_liaison or 'github' not in gc_liaison: 70 | invalid_items.append(f"{sig_prefix} Each GC Liaison must have a 'name' and 'github'.") 71 | 72 | return invalid_items 73 | 74 | # Replace 'your_file.yaml' with the path to your actual YAML file 75 | invalid_items = validate_yaml('sigs.yml') 76 | for invalid_item in invalid_items: 77 | print(invalid_item) 78 | -------------------------------------------------------------------------------- /social-media-guide.md: -------------------------------------------------------------------------------- 1 | # Social Media Guide 2 | 3 | This document is a loose set of policies and guidelines for social media usage 4 | by the OpenTelemetry project. It is not intended to be an exhaustive list of 5 | what and how we should post or market the project, but more a set of principles 6 | and values that we should follow in order to maintain consistency and 7 | professionalism. 8 | 9 | ## Our Goals 10 | 11 | OpenTelemetry's use of social media (Twitter, LinkedIn, YouTube, Mastodon, etc.) 12 | is intended to help us achieve the following goals: 13 | 14 | - Increase awareness of the project. 15 | - Highlight the work of contributors and maintainers. 16 | - Help educate and inform users and potential users of the project. 17 | 18 | ## Our Values 19 | 20 | OpenTelemetry is a community-driven project, and as such, our social media usage 21 | should reflect our community standards. Please familiarize yourself with our 22 | [mission, vision, and values](./mission-vision-values.md) as well as our [code 23 | of conduct](./code-of-conduct.md) as the primary reference for how we should 24 | represent ourselves and conduct ourselves on social media. 25 | 26 | ## Guidelines for Social Media Usage 27 | 28 | When creating social content, keep the following general guidelines in mind: 29 | 30 | - Be professional and courteous. 31 | - Avoid hyperbole and exaggeration, or "extremely online" references and 32 | behavior. 33 | - Do not use OpenTelemetry social accounts to promote a specific proprietary 34 | product, company, or service. 35 | - It's OK to refer to a specific product or service in the context of a 36 | technical discussion, but avoid promoting a specific product or service 37 | over others. 38 | - It's also OK to recognize and name individuals employers in the context of 39 | their contributions to the project. 40 | - Generally, avoid naming specific companies or products in a way that could 41 | be construed as an endorsement or an opposition. 42 | - Never use OpenTelemetry accounts to denigrate, demean, or otherwise make 43 | negative statements or claims about specific people, companies, products, 44 | services, or other projects. 45 | - Focus on our overall goals when creating social content. 46 | - This doesn't mean we can't be fun, or have fun, but we should try to keep 47 | social content highly relevant. 48 | - Highlight and celebrate our contributors, releases, achievements, and other 49 | 'sister' projects or initiatives in the CNCF/Open Observability world. 50 | - Strive to reflect our DEI values in our social content. 51 | 52 | An example of content we should strive to regularly post: 53 | 54 | - New blog posts, videos, or other content from the project. 55 | - New major releases, especially if accompanied by a blog. 56 | - Ecosystem developments (new exporters, new instrumentation, new tools, etc.) 57 | - New SIGs, events, or other groups. 58 | - Surveys, polls, or other community engagement activities. 59 | 60 | ## Official Social Media Accounts 61 | 62 | The following is a list of official OpenTelemetry social media accounts: 63 | 64 | - Twitter: [@opentelemetry](https://twitter.com/opentelemetry) 65 | - Mastodon: [@opentelemetry@fosstodon.org](https://fosstodon.org/@opentelemetry) 66 | - LinkedIn: [OpenTelemetry](https://www.linkedin.com/company/opentelemetry/) 67 | - YouTube: [@otel-official](https://youtube.com/@otel-official) 68 | 69 | ## Questions and Feedback 70 | 71 | If you have questions or feedback about these guidelines, please reach out to 72 | Austin Parker on the CNCF Slack or email the [comms mailing list](mailto:cncf-opentelemetry-comms@lists.cncf.io). -------------------------------------------------------------------------------- /tools/github/README.md: -------------------------------------------------------------------------------- 1 | # GitHub Applications and Integrations 2 | 3 | This document and directory contain information about all configured GitHub 4 | applications and integrations with the OpenTelemetry organization. 5 | | Name | Description | Scopes | Notes | 6 | |--------------------------------------------------------------|------------------------------------------------------|-----------------------------|------------------------------------------------------------------------| 7 | | [Allstar App](https://github.com/ossf/allstar) | Enforces security policies | TBD | TBD | 8 | | [CircleCI Checks](https://github.com/apps/circleci-checks) | Integration with CircleCI | TBD | TBD | 9 | | [Codecov](https://github.com/apps/codecov) | Integration with Codecov for PR code coverage checks | TBD | TBD | 10 | | [Forking Renovate](https://github.com/apps/forking-renovate) | Dependency updates via Renovate | TBD | TBD | 11 | | [LFX CM](https://www.crowd.dev/) | LFX Community Management | Org-wide | TBD | 12 | | [EasyCLA](https://github.com/apps/linux-foundation-easycla) | Required CLA checking from LF | Org-wide | This must be enabled for all repositories for PRs against main branch. | 13 | | [Mergify](https://github.com/apps/mergify) | TBD | TBD | TBD | 14 | | [Netlify](https://github.com/apps/netlify) | Integration with Netlify for website deployments | opentelemetry.io repository | n/a | 15 | | [Octobox](https://github.com/apps/octobox) | TBD | TBD | TBD | 16 | | [OpenShift CI ](https://github.com/apps/openshift-ci) | TBD | TBD | TBD | 17 | | [Polls](https://github.com/apps/polls) | TBD | TBD | TBD | 18 | | [project-bot](https://github.com/apps/project-bot) | TBD | TBD | TBD | 19 | | [Renovate](https://github.com/apps/renovate) | Dependency updates via Renovate | TBD | TBD | 20 | | [Scope App](https://github.com/apps/scope-app) | TBD | TBD | TBD | 21 | | [self-actuated](https://actuated.dev/) | Integration with Actuated (ARM Runners) | TBD | TBD | 22 | | [Slack](https://github.com/apps/slack) | Slack integration for GitHub | TBD | TBD | 23 | | [Stale](https://github.com/apps/stale) | Stale issue bot | Org-wide | n/a | 24 | | [Welcome](https://github.com/apps/welcome) | TBD | TBD | TBD | 25 | --------------------------------------------------------------------------------