event-code-of-conduct

イベント行動規範

単一の日程で、物理的な会場を使って開催するイベントのために、ポリシーと、それを執行する仕組みを設計します。成果物は必ず2つで、1つではありません。公開する文書と、イベント終了前に報告へ対応できる担当者を明確にした体制です。

その体制がない行動規範こそ、このスキルで防ごうとしている失敗です。掲げた価値観が単なる飾りだと示すことになり、何も応答しない窓口に報告者の信頼を託すことになります。

• 多くの技術系カンファレンスが今なおリンクしているテンプレート、confcodeofconduct.com は、自らの文書について「enforceable とみなされるべきではない」と述べており、利用するイベントには独自のポリシーを作成するよう求めています。
• opensource.guide は、この原則を明確に述べています。「執行されない（または執行できない）行動規範は、行動規範がないよりも悪い。」

これは法的助言ではありません

成果物は、ポリシー、要員配置計画、ランブックです。制裁によって有料イベントから参加者を退場させたり、報告窓口で個人を特定できる機微な情報を収集したりするため、ここには実際の法的リスクが伴う部分があります。

• 契約文言：スポンサーのスタッフを拘束する条項、払い戻しなしで退場させる権利を定めるチケット規約です。これらは弁護士に確認してもらいます。該当条項を所管する samber/dev-event-organizer-skills@event-sponsor-agreement を通じて依頼してください。
• インシデント記録の保存、アクセス、削除に関する規則は、組織のプライバシー上の責任を担う担当者に確認してください。
• 犯罪、未成年者、または差し迫った身体的危険に関わることは、まず緊急サービスと弁護士に連絡し、その後でこのプロセスに進めてください。

インタビューの前に、これを伝えてください。公開したポリシーが法的な保護になると誤解している主催者は、ポリシーがない主催者よりも危険な立場にあります。

インタビュー

一度に質問を1つずつ尋ね、可能であれば選択式にします。質問5〜7があるのは、以下の選択肢で、効果が出るまでの時間、持続性、労力が大きく異なり、デフォルトの順序をユーザーに代わって決められないためです。

1. イベントの形式（ミートアップ、ハッカソン、1日または複数日のカンファレンス）、参加者数、開催日、物理的な会場の数を教えてください。
2. チケット購入者以外に、誰がこの規範の対象になりますか。登壇者、ボランティア、スポンサーやブースのスタッフ、業務委託先、報道関係者、サテライトイベントや参加者主催の関連イベント、開催前後も稼働するオンラインチャットなどです。
3. このイベントは1つの主催団体が運営していますか。それとも、第三者の主催者を拘束するアンブレラブランドやフランチャイズ契約のもとで運営していますか。（規模よりも、この違いのほうが後の設計に大きく影響します。インタビュー後の分岐を参照してください。）
4. 報告の対象となる可能性があり、かつ主催チームの一員である、予算を管理している、またはイベントの看板となる人物は誰ですか。率直に答えてください。設計全体がここを軸に決まります。
5. ポリシーを公開しなければならない日付はいつですか。また、その日付はチケット販売開始日、スポンサー契約、チーム独自の目標のどれによって決まっていますか。（厳しい期限がある場合は、すぐに立ち上げられる段階が優先され、策定時の対応方針は簡略化されます。）
6. 今回限りの開催ですか。それとも、チームが毎年継続する予定のイベントですか。（継続的な運営が求められる場合は、耐久性の高い段階、つまり、一度だけ書かれたポリシーページよりも、訓練を積んだ常設チームや記録管理体制が優先されます。）
7. 労力の上限を教えてください。主催者が割ける時間、イベント中に窓口へ常時対応できる担当者の有無、外部支援の予算、開催回の合間にもチームがどこまで運用を続けられるかです。
8. デフォルトの順序では考慮されていない既存の仕組みはありますか。独自のインシデント対応チームを持つ親財団やアンブレラ組織、過去の開催回のポリシーと記録、社内弁護士、文化的アイデンティティや価値観に関する文書、すでに訓練を受けたボランティアチームなどです。

単一主催者イベントと複数主催者フランチャイズ

ハラスメントは、チケットを購入した人が誰であっても同じ行為であり、同じ列挙リストが必要です。以下のあらゆる仕組みを実際に左右するのは、会場にいる人々を誰が管理しているかです。

• 単一主催者イベント（PyCon US モデル）。1 つの組織が会場、ボランティア、プログラム、制裁措置をすべて運営します。ここに記載するすべてのことは、あなたが決定し、実行できます。制約は対応能力です。少人数の担当者名が公表されたチーム、短い現地対応時間、そして報告対象がチームのメンバーの場合にエスカレーションできる上位組織がありません。PyCon US は、個人名が公開された 3 人の責任者（インシデント対応担当者、PSF 運営担当ディレクター、カンファレンス議長）を置き、それぞれ別々の連絡先を公開することでこの課題に対応しています。これにより、そのうちの 1 人に関する報告でも、別の窓口に届けられます。
• 複数主催者のフランチャイズまたはアンブレラ型イベント（MLH メンバーイベントモデル）。中央組織がポリシーを所管し、会員契約によって採用が義務付けられているため、地域主催者はそれに従います。「MLH 行動規範を採用し、公開し、実施することが期待されています」。地域主催者が独自の場当たり的な手続きを行うことはできません。「主催者は、現地の MLH 担当者または MLH インシデントチームに直ちに連絡する必要があります」。ポリシー策定で主に必要なのは、文書を作成することではありません。実際にどの文書が拘束力を持つのかを確認し、中央の対応手順を把握し、公開発表の有無を決めるのは中央組織であり、地域での文言やタイミングも、まず中央で合意する必要があると理解することです。

この 2 つの中間にあたる形として、ブランド所有者も、実施を拘束する会員契約もないまま、短いマニフェストを共有する独立した地域コミュニティの自発的なピアネットワークがあります（samber/dev-event-organizer-skills@event-team-structure はこのネットワーク層を設計しています）。行動規範については、各支部を単一主催者イベントとして扱います。各支部が自らのポリシー、対応チーム、制裁措置を管理します。ネットワークでは、基本文書や対応手順を共有資産として提供できます。また、「対応チームの担当者名を明記した行動規範を公開すること」を最低限の拘束力ある項目に含めることもできます。しかし、価値観を示すマニフェストはポリシーではなく、メンバーが書面で合意していない限り、ネットワーク内の組織が各支部の事案について判断することはありません。マニフェストにおける事業上の枠組み（「事業は目的ではなく結果である」、ステージ上での商業的なデモは禁止）は、制裁措置の段階ではなく、講演ガイドラインに含めるべきです。

推奨事項がモデルによって異なる場合は、どのモデルを前提にしているのかを明記してください。ポリシーの構成要素の大半は 3 つすべてのモデルに適用できますが、対応チームの人員構成、異議申し立ての経路、公開発表を行う権限は共通ではありません。

スポンサーやブースのスタッフは、いずれのモデルでもこの境界に位置します。MLH、PyCon US、confcodeofconduct.com はいずれも、それぞれの適用範囲にスポンサーを明記しているため、スポンサーやブースのスタッフもあなたのポリシーの対象です。ただし、拘束力を持つのは本人が購入したチケットではなく、雇用主が署名した契約です。ポリシーで対象となることを明確に述べてください。条項の文言については、samber/dev-event-organizer-skills@event-sponsor-agreement に記載されています。

ワークフロー

1. 免責事項を伝えてから、聞き取りを始めます。
2. 最初のメニューで基本となる文面の方針を選びます。イベントがフランチャイズまたは包括契約のもとで開催される場合は、文面の作成を飛ばし、拘束力のある文書を見つけて、どのバージョンが適用されるかを確認します。
3. 適用範囲の条項を作成します。対象となる人、場所、日付、会場外での行為の扱いを定めます。references/policy-anatomy-and-scope.mdを参照してください。適用範囲の条項は、ほとんどのイベントで誤りやすい箇所であり、ポリシーに違反した人に対して制裁を執行できるかどうかを決める箇所です。
4. 2つ目のメニューで報告窓口を選びます。ポリシーに、機密保持についての二つの約束を明記します。報告内容は機密として扱い、報告者が別途指示しない限り、報告者の身元も機密として扱います。
5. 3つ目のメニューで対応チームを編成し、報告手順にメンバーの氏名を掲載します。報告先が誰なのか分かっていると、報告する人は増えます。
6. references/incident-runbook-and-response-team.mdをもとにインシデント対応手順書を作成します。受付時の案内、記録項目、エスカレーション、事前に定める判断方法、通知の4項目、クローズまでを含めます。対応期限を時間と日数で定め、公表します。
7. references/sanctions-ladder-appeals-and-transparency.mdを使って、最初のインシデントが発生する前に制裁の段階を公表します。事後に制裁を考案すると、インシデントはガバナンス上の危機に発展します。
8. 不服申し立ての手順と、どの段階の制裁が対象となるかを決めます。 すべての制裁に一律の不服申し立て権を設けるのがイベントの意図とは限りません。MLHでは、出場停止と永久追放のみが不服申し立ての対象です。違いを曖昧にせず、明記してください。
9. references/staff-guidance-geek-feminism-ada-initiative.mdをもとに、対応チームだけでなく、すべてのスタッフに説明します。スタッフなら誰でも口頭で警告できます。一度きりの軽微な行為は、その後に声をかけ、重大な行為はその場で止め、すべての警告を指定の連絡先に伝えます。
10. 開場前にリハーサルを行います。 チームとともに、練習用の事例を2、3件検討します。リハーサルをしていないチームは、インシデント発生中に判断基準を決めることになります。
11. この開催回の透明性レポートを公表すること、また、レポートに記載する内容と記載しない内容を決めます。

ハーネスに永続メモリがある場合は、適用範囲に関する決定、利益相反の申告を含む対応チームの名簿、公表した対応期限、各制裁の段階と理由を保存します。次回の開催回は、すでに存在する制裁の段階と、違反の再発を確認できる記録をもとに始められます。再発が分かることが、段階2に意味を持たせる唯一の方法です。

優先順位付きメニュー

以下の順序はすべて既定のものであり、絶対的なルールではありません。状況や実行する人によって変わります。3つのメニューを提示する前に、聞き取り内容に照らして順位を付け直し、どの回答によってどの選択肢が動いたかを説明してください。

• 公表期限が厳しい（Q5）場合は、半日で整えられる段階の優先度が上がります。
• 毎年継続する義務が積み重なる（Q6）場合は、長期的に使える選択肢の優先度が上がります。
• 既定の想定から外れていた資産（Q8）があれば、推奨される段階を覆すことがあります。独自のインシデント対応チームを持つ包括組織があるなら、3つ目のメニューの大半は不要です。既存の価値観に関する文書があるなら、1つ目のメニューで後回しになっていた選択肢はコピー編集で済みます。

ユーザーの制約によって選択肢が使えない場合は、リストの末尾に残すのではなく、計画から削除してください。対象外の選択肢をリストに残すと、T-2 weeksになって適用範囲の問題として再び浮上します。

ベーステキストの方針

効率性（推奨順）：確立されたテキストを適応する > そのまま採用する > 文化に関する前文を加えて適応する。

• 価値：文化に関する前文を加えて適応する > 適応する > そのまま採用する
• 労力：文化に関する前文を加えて適応する > 適応する > そのまま採用する
• コンプライアンスコスト：文化に関する前文を加えて適応する == 適応する > そのまま採用する

優越性チェック：3組を比較し、厳密な優越関係はゼロです。構成上の理由だけで整合しているにすぎず、構成上の整合は合格を意味しません。

• 価値と労力は同じ順序なので、1つの仕組みですべての組み合わせを阻みます。より使いやすい文書を得る方針ほど、作成に厳密に多くの労力がかかります。
• コンプライアンスコストも、どの組み合わせも区別しません。適応する2つの段階を同列にしたうえで、同じ順序を繰り返しているだけです。
• このチェックでは、ここに順序の誤りは見つかりません。順序は以下の論拠に基づいています。

そのまま採用すればほぼ手間はかかりませんが、それでも不十分です。テンプレートにはイベントに存在しない役割や連絡先が記載されており、報告に関する文言が使えなくなるうえ、confcodeofconduct.comは自らの強制力を否定しているためです。適応には1〜2時間かかりますが、まさにその問題を解決できます。コンプライアンスコストの==はごまかしではありません。どちらの適応方針でも、同じクリエイティブ・コモンズの表示義務があり、法的権限を持つ担当者による確認も同じく1回必要です。文化に関する前文を加えても、文章が増えるだけで、法的な対象範囲は広がりません。

デフォルト：確立されたテキストを適応します。 明文化されたアイデンティティや価値観の文書がすでにある場合は、文化に関する前文を加える方針に切り替えます。

そのまま採用する方法をより限定的に応用する方法として、ボランティアが運営する小規模なイベントでは、一般的なテンプレートではなく、同種イベント自身が公開し、維持管理している行動規範や価値観のページに直接リンクすると、ほぼゼロの作成コストのまま、そのイベントの文章とともに、地域での正当性や実績のある運用記録も受け継げます。この方法が妥当なのは、同じ地域またはコミュニティに適した同種イベントの文書があり、その適用範囲（対面かオンラインか、管轄区域など）が実際にこのイベントと一致する場合に限られます。また、一般的なテンプレートと同じ修正も必要です。リンク先の方針が最新で、掲載元の組織が今も存在することを確認してからリンクし、記載されている連絡先や役割をこのイベント独自のものに置き換えてください。

優先度が低い：文化に関する前文を加えて適応する — 価値と労力がともに最も高いため、効率性の観点から毎回後回しになります。

• CoCを流し読みではなく、読んでもらえる文書にできるのはこの方針です。!!Conの方針では、「多くの行動規範がハラスメントの防止だけで始まり、そこで終わるのに対し、私たちの行動規範は、!!Conのイベント文化を意図的に形作る取り組みの一部です」と述べ、参加者への期待を記したセクションには「!!Conらしくあるために」というタイトルを付けています。
• イベントですでに文化的アイデンティティの形成に取り組んでいる場合は、この方針に切り替えてください（samber/dev-event-organizer-skills@event-cultural-identityを参照）。数日かけて作成するのではなく、編集作業で済むようになります。

格下げではなく削除：ゼロから独自の文書を書くこと。 イベントに社内弁護士がおり、テンプレートが合わない具体的な理由がある場合を除き、削除してください。

• MLH、PyCon US、confcodeofconduct.comが公開している、禁止行為を列挙したリストは実質的に同じです。これは、3つの独立した流れで生まれたものではなく、JSConf US 2012とAda Initiativeのテンプレート群に共通の起源を持っています。この系譜こそが、参加者や記者が見慣れているリストである理由です。
• ゼロから草案を作ると、同じリストにたどり着くまでに1週間かかり、しかも何かを忘れる可能性があります。忘れられた項目こそ、記者が自分の事例を取り上げてもらえると確信するために、事前に明記されている必要がある内容です。

報告窓口

効率性：公開メールアドレス > 対面で確認できる現地対応者 > 利益相反がある場合の指名された代替担当者 > 匿名受付窓口 > 担当者を配置した電話または SMS ホットライン。

• 価値：対面で確認できる対応者 > 匿名窓口 > 指名された代替担当者 > 公開メールアドレス > 担当者を配置したホットライン
• 労力：担当者を配置したホットライン > 対面で確認できる対応者 > 匿名窓口 > 指名された代替担当者 > 公開メールアドレス
• コンプライアンスコスト：匿名窓口 > 担当者を配置したホットライン > 公開メールアドレス > 対面で確認できる対応者 == 指名された代替担当者

公開メールアドレスが効率性で最も優れているのは、設定に数分しかかからず、イベントの前後にも利用でき、印刷物のポリシーに記載する必要がある宛先だからです。価値では、目に見える対応者が最も優れています。苦痛を感じている人は、自分に見える人に助けを求めるからです。PyCon US では、訓練を受けた対応者が「明るい色のシャツ」を着用します。これはオンラインでは代替できない窓口です。コンプライアンスコストの == が成り立つのは、目に見える対応者も指名された代替担当者も、個人の氏名と連絡先を公開するという同じ審査を一度だけ必要とするためです。これは本人との同意に関する話し合いであり、データ処理の制度ではありません。

ここでは、コンプライアンスコストは多くの選択肢とは異なり、実際に考慮すべき軸です。各窓口には、それぞれ異なるリスクがあります。

• 匿名窓口：報告者を特定できない報告は、要請があっても訂正や削除ができない記録となり、それに基づく制裁も報告者に照らして検証できないため、この軸で最もコストが高くなります。誤った結果は後から覆せないため、最初の報告を受け取る前に、保持、アクセス、意思決定に関するルールを定めておく必要があります。
• 担当者を配置したホットライン：通話記録や、機微な個人データを含む可能性のある録音が、第三者である通信事業者の管理下に置かれます。
• 公開メールアドレス：同じデータを含む受信トレイが作られ、書面で定めたルールに従って管理、アクセス制限、保持を行う担当者が必要になります。

デフォルト：公開メールアドレス＋利益相反がある場合の指名された代替担当者＋対面で確認できる現地対応者。物理的な開催日があるすべてのイベントで、この構成を採用します。オンラインのみ、またはイベント開催前のみを対象とする場合は、公開メールアドレスと代替担当者だけにします。

後回しにされがち：匿名受付窓口 ― 他の窓口では決して届かない報告を受け付けるという点で最も価値が高く、報告者に確認を求められない状態でも機能する意思決定の慣例が必要なため、労力も大きくなります。報告者の集団内に力関係の差がある場合は、必ず優先して導入してください。たとえば、有給スタッフ、スポンサーの指示を受けるスポンサー出展ブースのスタッフ、大学主催のハッカソンに参加する学生、イベントの最上位の主催者を含む対応チームなどが該当します。PyCon US は匿名の 窓口 を設けていませんが、受付時には匿名の報告を受け付けています。CNCF では、委員会のメンバーなら誰でも報告者の氏名を伏せて報告を転送できる、文書化された中継の仕組みを運用しています（イベントではなく、プロジェクトの慣行です）。

対応チームの人員配置

効率性：名前を公表した3～6人のチーム ＞ 上位組織のインシデント対応チームへのエスカレーション ＞ 外部のトラスト＆セーフティ請負業者。

• 価値：名前を公表したチーム ＞ 上位組織のチーム ＞ 外部請負業者
• 労力：外部請負業者 ＞ 名前を公表したチーム ＞ 上位組織のチーム
• コンプライアンスコスト：外部請負業者 ＞ 上位組織のチーム ＞ 名前を公表したチーム

3～6人という規模は意図的なものです。3日間のイベントでは確実に起こることとして、その3分の1が対応できなくても機能しなければなりません。引き分けや欠席時のルールを含め、判断方法を事前に定め、行動を起こす側に傾くようにしてください。実際に多く見られる失敗は、性急な対応ではなく、有効な報告への対応を怠り、遅らせることです。

上位組織へのエスカレーションは、利用できる場合にはほとんど労力がかかりませんが、それ以外では利用できません。そのため、誰もが選べる段階の一つではなく、条件付きの選択肢として扱ってください。コンプライアンスコストとしては、提携契約により他者の手順が自分たちを拘束し、結果を覆す裁量がなくなります。

デフォルト：名前を公表した3～6人のチーム。報告手順には全員の名前を記載し、メンバーが自分に忌避ルールが適用されると気づいた時点で、そのルールが適用されるようにします。

リソースが限られる場合：外部のトラスト＆セーフティ請負業者。他の選択肢では対応できない唯一のケースで最も高い価値を発揮しますが、最も労力がかかります（調達、説明、リテイナー契約、そして参加者の個人データを外部の組織に渡すことが必要です）。イベントで最も権限のある人物が運営チームに所属し、その上位に独立した組織が存在しない場合は、この選択肢を優先してください。コミュニティで最も権限のある人々に適用されない行動規範は、そもそも採用すべきではありません。エスカレーション先となる理事会がない場合、この前提に対応できるのは請負業者だけです。

降格ではなく削除：唯一の対応者として指定された運営者1人。 その運営者がチーム内で最も上位の人物でもあるイベントでは、この選択肢を削除してください。そうしないと、この窓口では最も対応を必要とする可能性が高い報告を受け付けられず、午前2時に1人だけで下す判断はプロセスとは言えません。リストの末尾に残しておくと、開催の2週間前になって「誰かに対応してもらえばいい」という形で再び持ち出されます。

失敗パターン

• 対応フローがないまま公開されたポリシー。 最も顕著な失敗であり、テンプレートのメンテナー自身もこれを挙げています。対策：担当チーム、機能する連絡手段、対応レベルを定めるまで、ポリシーを公開しないでください。
• どこにいるのかわからない対応担当者。 PDFに連絡先が記載されていても、廊下で困っている人には役に立ちません。対策：訓練を受けた対応担当者に目立つ服装をさせ、そのことを冒頭のアナウンスで伝えてください。
• 対応チームに関する報告を受け付ける窓口がない。 対策：少なくとも2人の別の担当者の連絡先を公開し、そのうち少なくとも1人は運営チームの指揮系統の外にいる人にしてください。
• チームが意図していない一律の異議申し立て権。 対策：異議申し立てが可能な対応レベル、申し立て先、方法、期限を明記してください。MLHでは異議申し立ての対象を参加停止と追放に限定し、証拠を添付した書面のメールで申し立てることとしています。
• スポンサーやブースのスタッフがポリシーの適用対象外として扱われる。 対策：適用範囲の条項に明記し、スポンサー契約に遵守条項と返金なしの退場措置を盛り込んでください。
• 事案を完全に非公開で処理する。 誰にも知らされずに解決された事案は、適切にも、何の対応もなかったと受け取られます。記録されている失敗例では、被害を受けた人が何も起きなかったと判断して去っています。対策：違反を知っていた全員に、対応が行われたことを知らせてください。通知は非公開にしますが、対応が行われた事実は隠しません。
• ピアネットワークのマニフェストが共通ポリシーとして読まれてしまう。 各支部はネットワークが報告を処理すると思い、ネットワークは各支部が処理すると思っています。対策：すべての支部が独自のポリシーと対応チームを公開し、ネットワークはメンバーが別途合意しない限り、事案の判断を行わないことを書面に残してください。
• 現地の運営担当者が独断で声明を発表する。 対策：誰が対外声明を出す権限を持つのかを事前に定め、発言する前に、文言と発表のタイミングを中央で合意してください。
• チームが実行できない対応レベルを採用する。 チームに適用する権限のない対応レベルを公開するのは、短くても誠実な対応レベルを示すより悪いことです。対策：リーダーシップの支援を得て、チームが実際に実行できる範囲に対応レベルを絞ってください。

測定

ポリシーではなく対応フローを測定してください。報告が届くまでは、ポリシーに観測可能な成果はありません。

• 開催回ごとの、参加者100人あたりの受け付けた報告件数。 連絡手段の改善後に件数が増えるのは、悪化ではなく信頼の表れです。この割合の目標値はすべて自分たちで定めるものとし、決して減らそうとしないでください。

• 報告から受領確認までの時間、および報告から結果の通知までの時間。 公開した期限を基準に測定してください。次の2つの基準から選べます。

  • PyCon US：緊急性のない報告について、3人のリーダーが24時間以内に会合し、1週間以内に報告者へ連絡します。
  • オンラインコミュニティ向けに書かれたAuroraとGardinerのハンドブック：受領確認まで24時間、判断まで10営業日です。

  イベントの期限はイベント開催期間内に収める必要があります。そのため、プロジェクトの期限よりも短く設定します。

• 終結のメッセージを受け取った報告者の割合。 目標は100％です。これを下回る場合、報告が放置されています。

• 開場前にリハーサルを完了したか。 開催回ごとに、達成または未達成で記録します。

• 透明性レポートを公開したか。 開催回ごとに、達成または未達成で記録します。

合格基準と、達成するまでの改善：すべての報告について、公開した期限内に受領確認を行い、公開したフォローアップ期限までに、すべての報告者へ結果を伝えます。この基準は自分たちで定めるものであり、上記の2つの公開済みの基準があることで、作り上げたものではなく現実的な目標になります。

呼び出し例

• 「4 か月後に初めて 300 人規模のカンファレンスを開催する予定で、行動規範が必要です。」→ インタビューを実施し、確立された文書を自分たちに合わせて調整し、3 人の担当者からなる実名チームを編成してから公開します。
• 「1 時間前に登壇者について報告がありましたが、どうすればよいかわかりません。」→ references/incident-runbook-and-response-team.md の対応手順書にある受け付けとエスカレーションの手順に進みます。まず安全性を評価し、次に判断方法を確認します。
• 「行動規範を公開してから 2 年になりますが、一度も報告がありません。これはよいことでしょうか？」→ 2 つ目のメニューに沿って報告窓口を監査します。窓口に報告がない場合、問題のないイベントというより、利用できない窓口であることのほうがよくあります。
• 「スポンサーのブーススタッフが参加者に失礼な態度を取りました。退場させてもよいでしょうか？」→ まず適用範囲の条項を確認し、次に制裁の段階を確認します。契約上の退場権は samber/dev-event-organizer-skills@event-sponsor-agreement で定められています。

期待される成果物：

• ポリシー文書。
• 印刷プログラムとウェブサイトに掲載する、1 ページの報告カード。
• 連絡先と忌避申告を記載した対応チーム名簿。
• チームが午前 2 時にも従える対応手順書。
• 公開された制裁の段階。

参考資料

• references/staff-guidance-geek-feminism-ada-initiative.md：Geek Feminism と Ada Initiative のサンプルポリシーのうち、スタッフ向けの部分。警告、講演の中止、報告の受け付け、退場の理由について説明しています。
• samber/dev-event-organizer-skills@event-volunteers：このスキルが定める対応担当の役割に人員を採用し、シフトを組むために使います。
• samber/developer-relations-skills@developer-community-moderation：複数のイベントにまたがる常設コミュニティと、その継続的なモデレーションを担当します。このスキル独自のポリシーと対応チームが対象とするのは、開催日が特定された単一のイベントのみです。イベント終了後も続く報告、パターン、人物については、このスキルに引き継ぎます。
• samber/dev-event-organizer-skills@event-attendee-experience：この対応手順書が報告の受け付け場所として利用する静かな部屋について説明しています。
• samber/dev-event-organizer-skills@event-accessibility-inclusion：このポリシーが保護するグループに対する違反がそもそも起きにくくなるよう、イベントを設計する方法と、references/policy-anatomy-and-scope.md で写真撮影の境界を定める、やりとりへの同意を示すステッカーについて説明しています。大規模なカンファレンスでは、識別可能なインクルージョンチームも配置します。このチームは対応チームと人員やシャツを共有することがありますが、報告の受け付けは共有しません。行動規範にはこのスキルを使わないでください。代わりに説明欄のスキルを使ってください。
• samber/dev-event-organizer-skills@event-comms-channels：このポリシーの適用対象となる、参加者向けのチャットスペースとイベントアプリについて説明しています。設置するすべてのチャネルを適用範囲の条項に明記し、名簿によって規則の適用対象者とモデレーション担当者を決める必要があります。
• samber/dev-event-organizer-skills@event-cultural-identity：ポリシーの前文に盛り込める、会場で大切にする価値観について説明しています。このスキルは文化を定義し、このスキルはポリシーとその執行方法を定めます。