OpenTelemetry Enhancement Proposal (OTEP) #

MarkdownのスピードでOpenTelemetryを進化させる #

OpenTelemetryは、OpenTelemetry仕様への変更を提案するために「OTEP」（RFCに似たもの）プロセスを使用します。

[!NOTE] OTEPは意図の文書です。 OTEPは、その内容が実際の仕様書に統合されて初めて要求事項となります。

目次 #

• OpenTelemetry Enhancement Proposal (OTEP)
  • MarkdownのスピードでOpenTelemetryを進化させる
    • 目次
    • OTEPが必要な変更とは
      • 横断的な変化の外挿
    • OTEPの範囲
    • OTEPを書く
    • OTEPを提出する
    • OTEPを仕様に組み込む
    • OTEPの実装
  • OTEPプロセスの変更
  • OpenTelemetryのOTEPプロセスの背景

OTEPが必要な変更とは #

OpenTelemetryのOTEPプロセスは、 横断的 な変更、つまり、 言語 と 実装 にまたがって適用可能で、新しい振る舞いの導入、望ましい振る舞いの変更、あるいは 要件の変更 を意図しています。

実際には、OTEPは以下のような変更に使用されるべきです。

• 新しいトレーサー設定のオプション
• スパンデータへの追加項目
• 新しいメトリクス型
• 拡張可能性の要求事項への変更

一方、、次のような変更にはOTEPは必要ありません。

• バグ修正
• 言い換え、文法や誤字脱字の修正など
• リファクタリング
• 単一の言語や実装のみにしか影響を与えないもの

Note: 上記のリストはあくまで例であり、すべてを網羅するものではありません。変更がOTEPを必要とするかどうかわからない場合は、遠慮なく質問してください！

横断的な変化の外挿 #

ときには、単一の言語や実装の中でしか即座に関連しない変更が、仕様の上流にある問題を示している場合があります。 このようなケースに気づいたら、いつでもOTEPを追加することを推奨します。

OTEPの範囲 #

OTEPは「重要な」変更を意図していますが、各OTEPの範囲はできるだけ小さくすることを推奨します。 一般的な経験則として、もし提案されたコア機能が特定の部分なしでも価値を提供できるのであれば、その部分は提案から削除され、かわりに 例 として使用されるべきです（そして理想的には、それ自身のOTEPが与えられるべきです！）。

たとえば、設定可能なサンプリング と さまざまなサンプラーを提案するOTEPは、設定可能なサンプリングを提案するOTEPとサンプラーごとのOTEPに分割されるべきです。

OTEPを書く #

• まず、このリポジトリを フォーク します。
• 0000-template.md を 0000-my-OTEP.md としてコピーします。このとき my-OTEP はあなたが提案に関連したタイトルで、 0000 はOTEP番号です。 今のところ、この番号はそのままにしておいてください。 Pull Requestが作成されたら、PR IDに合わせてこのIDを更新してください。
• テンプレートに記入します。細部にまで気を配ってください。 説得力のある動機を提示し、設計の影響範囲を理解していることを示して、欠点や代替案の可能性を正直に評価することが重要です。

OTEPを提出する #

• OTEPはPRとして投稿することで 提案（proposed） されます。 PRが作成されたら、PR番号をOTEP番号として使用するようにOTEPファイル名を更新します。
• 4人のレビュアーがPRをGitHubで承認すると、OTEPは 承認（approved） されます。 その後、OTEPはマージされます。
• OTEPが 却下（rejected） あるいは 取り下げ（withdrawn） となった場合、そのPRはクローズされます。 GitHub は議論と提案の両方を保持しているので、たとえブランチが削除されてもOTEPの投稿は記録されます。
• もしOTEPの議論が長くなり、OTEPが大きな改訂を行った場合、OTEPの次のバージョンは、古いPRを参照する新しいPRとして投稿できます。 そして古いPRは閉じられます。 これにより、OTEPレビューのフォローと参加が容易になります。

OTEPを仕様に組み込む #

• OTEPが 承認 されると、OTEPを実際の仕様に統合するための課題がこのレポに作成されます。
• OTEPの仕様のPRをレビューする際には、仕様が明確に記述されているか、OTEPで承認された変更が反映されているかに重点を置いてください。 この段階で、承認されたOTEPの変更について再議論することは控えてください。
• OTEPは、4人のレビュアーが仕様のPRをGitHubで承認した時点で 統合（integrated） されます。 その後、PRはマージされ、仕様はバージョン管理されます。

OTEPの実装 #

• ひとたびOTEPが仕様に 統合 されると、関連する OpenTelemetry 実装のバックログに課題が作成されます。
• PRは、要求されたすべての変更が実装されるまで行われます。
• OpenTelemetry実装のステータスが更新され、新バージョンの仕様を実装していることが反映されました。

OTEPプロセスの変更 #

OTEPプロセスは、OpenTelemetryとともに 進化 していくことが望まれ、期待されています。 プロセスは決して固定されたものではありません。

ご意見、心配事、質問がありますか？ どうぞ 私たちのコミュニティチャットで問題を提起してください。 Have suggestions? Concerns? Questions? Please raise an issue or raise the matter on our community chat.

OpenTelemetry OTEPプロセスの背景 #

私たちのOTEPプロセスは、Rust RFCとKubernetes Enhancement Proposalのプロセスを借用しています。 前者は後者にも非常に影響力のあるプロセスであり、OpenTracing OTEPプロセスも同様です。 優れた先例を提供してくれたそれぞれの著者とコミュニティに多大な称賛と感謝を捧げます💖