承認者およびメンテナーのための SIG のプラクティス

承認者およびメンテナーがどのようにイシューやコントリビューションを管理するかを学びます。

このページでは、承認者およびメンテナーが使用するガイドラインと一般的なプラクティスについて説明します。

オンボーディング

コントリビューターがドキュメントに対する責任の大きい役割（承認者、メンテナー）を引き受ける場合、既存の承認者およびメンテナーによってオンボーディングが行われます。

docs-approvers（または docs-maintainers）グループに追加されます
#otel-comms、#otel-maintainers、およびチーム内のプライベート Slack チャンネルに追加されます
SIG Comm ミーティングとメンテナーミーティングのカレンダー招待への登録を求められます
SIG Comm の現在のミーティング時間が適しているかを確認し、適さない場合は既存の承認者およびメンテナーと調整して、全員に適した時間を決定します
コントリビューター向けのさまざまなリソースを確認します
- コミュニティリソース。特に、コミュニティメンバーシップとソーシャルメディアガイドに関するドキュメント
- コントリビューションガイドライン。この一環として、これらのドキュメントをレビューし、イシューやプルリクエストを通じて改善するためのフィードバックを提供します

以下は、追加で確認すると有益なリソースです。

Hugo ドキュメント
Docsy ドキュメント
マーケティングガイドライン。これは、Linux Foundation のブランドおよび商標使用ガイドライン含みます。これらは、レジストリ、インテグレーション、ベンダー、導入事例、ディストリビューションのエントリーをレビューする際に特に重要です

承認者およびメンテナーは、それぞれ異なる勤務時間や状況です。そのため、すべてのコミュニケーションは非同期とみなされ、通常のスケジュール外で返信する義務はありません
承認者またはメンテナーが長期間（数日または1週間以上）不在となる場合は、 #otel-comms チャンネルでの通知や GitHub ステータスの更新を行います。
承認者およびメンテナーは、OTel 行動規範とコミュニティの価値観に従います。彼らはコントリビューターに対して親切かつ協力的であり、何らかの対立や誤解、不快になるような状況が承認者またはメンテナーに生じた場合は、会話、イシューまたは PR から一歩引いて別の承認者やメンテナーに対応を依頼できます

PR のブランチが out-of-date with the base branch（ベースブランチと同期していない）場合、継続的に更新する必要はありません。各更新ごとに CI チェックが再実行されます！マージ前に更新すれば十分です
非メンテナーによる PR で git サブモジュールを決して更新しないでください。これは時々誤って起こります。 PR 作成者にその必要はないことを伝えてください。マージ前にこれを修正しますが、将来的には最新のフォークから作業する必要があります
コントリビューターが CLA に署名できない場合、またはコミットの 1 つで誤って間違ったメールアドレスを使用した場合は、問題を修正するか、プルリクエストをリベースするように依頼してください。最悪の場合、PR を閉じて再度開き、新しい CLA チェックをトリガーします
cspell に未知の単語は、PR 作成者によってページごとに cspell の ignore リストに追加される必要があります。承認者とメンテナーのみが、よく使用される用語をグローバルリストに追加します

SIG が共同所有するドキュメント（コレクター、デモ、言語固有など）を変更する PR は、ドキュメント承認者による承認と SIG 承認者による承認の 2 つの承認を目指す必要があります。

ボットが作成した PR は以下の方法でマージできます。

レジストリのバージョンを自動更新する PR は、即座に修正、承認、マージ可能です
SDK、ゼロコード計装、またはコレクターのバージョンを自動更新する PR は、対応する SIG がマージを延期する必要があることを通知しない限り、承認およびマージできます
仕様のバージョンを自動更新する PR では、CI チェックに合格するためにスクリプトの更新が必要になることがよくあります。その場合は @chalin が対応します。それ以外の場合は、対応する SIG がマージを延期する必要があることを通知しない限り、それらの PR は承認され、マージされる可能性があります

翻訳の変更を含む PR は、2 人の承認を目指します。 1 人はドキュメント承認者で、1 人は翻訳承認者です。共同所有 PR の手順と同様のプラクティスが適用されます。

メンテナーは以下のワークフローを適用して PR をマージできます。

PR がすべての承認を得ており、CI チェックが通っていることを確認します
ブランチが最新でない場合、GitHub UI からリベースで更新を行います
更新により CI チェックが再実行されるため、チェックが成功するのを待つか、次のようなスクリプトを使用してバックグラウンドで実行します。
```
export PR=<PR の ID>; gh pr checks ${PR} --watch && gh pr merge ${PR} --squash
```

このページは役に立ちましたか?

Thank you. Your feedback is appreciated!

Please let us know how we can improve this page. Your feedback is appreciated!