通信
質問の投稿、バグの報告、機能提案、チームへの連絡先
単に私たちと会話したい場合は、Discordが最適です。 バグ、機能リクエスト、設計の議論、RFCなど、永続的な記録が必要な場合はGitHubをご利用ください。
Discord: チームに連絡を取るのに最適な場所
リアルタイムチャット。ここはメンテナーが日常的に活動している場所であり、人間からの回答を得るための最も迅速な経路です。
チャンネル:
#general: デフォルトルーム#help: 「Xが動作しない」スレッド。問題を解決する最速の方法#dev: 進行中の開発に関する議論#releases: お知らせ、リリースノート、破壊的変更の事前警告
Discordは一時的なものです: 会話の中でバグや機能のアイデアが見つかった場合は、後でGitHubのissueとして記録し、記録が残るようにしてください。Discordは会話のため、GitHubは記憶のためのものです。
Discord でプロジェクトが記憶すべき内容が生まれたときは、GitHub への引き継ぎを使用します。スレッドから再現可能なバグ、具体的な機能スコープ、アーキテクチャやガバナンスの決定、メンテナーのコミットメント、オーナーの割り当て、マイルストーンの決定、ブロッカー、回避策、検証の証跡、リリースへの影響に関する注記、または stale 除外の理由が生まれた場合は、issue、ディスカッション、PR コメント、またはメンテナードキュメントを作成または更新します。引き継ぎに必要なのは、決定内容、証跡、オーナー（存在する場合）、そして別のメンテナーがチャットを読み返さずに続行できるだけの十分なコンテキストだけです。
GitHubのイシュー
バグ、機能リクエスト、および追跡が必要な事項について。
- バグ報告: バグテンプレート（
.github/ISSUE_TEMPLATE/bug_report.yml）を使用してください。zeroclaw --version、OS、zeroclaw doctorの出力を含めてください。 - 機能リクエスト: 機能テンプレート（
.github/ISSUE_TEMPLATE/feature_request.yml）を使用してください。ユーザーにとっての価値と制約に焦点を当ててください。実装の詳細はRFCやPRでの議論で扱います。 - RFC: RFCプロセスを参照してください。
報告する前に検索してください。重複は統合されます。検索ボックスはあなたの味方です。
GitHub Discussions
Discord よりも永続性が必要だが、まだ追跡対象の作業ではないコミュニティ向けスレッドに適しています。Discussions は、Q&A、アイデア、プロジェクトのお披露目、投票、メンテナーからのアナウンス、そして Discord ではスクロールして流れてしまうような「他にもこれを見た人はいますか?」といったスレッドに最適です。
Discussions は緊急性のないコミュニティでの会話として扱います。steward またはレビューの頻度が文書化されている場合に限り、維持された受付窓口となります。メンテナーの運用手順とデフォルトの頻度については Reviewer playbook: Discussions stewardship を参照してください。
Discussions は GitHub のハンドオフシステムの一部であり、issue、RFC、PR コメント、メンテナードキュメントの代替ではありません。具体的なバグ、機能スコープ、オーナー、ブロッカー、検証エビデンス、ポリシー決定、ドキュメント要件が生じた時点で、Discussion を追跡対象のサーフェスに移行してください。
サーフェスを選択する際は、この分割を使用してください:
| Surface | それを使用する用途 | 移動するタイミング |
|---|---|---|
| Discord | 迅速なヘルプ、リアルタイムの連携、「これって問題ですか?」という早期の相談 | プロジェクトには、永続的な記録、決定事項、担当者、検証メモ、ブロッカー、またはリリースへの影響に関するメモが必要です |
| ディスカッション | 検索可能なQ&A、アイデア、show-and-tell、デモ、投票、お知らせ、幅広いフィードバック、正式な追跡の準備が整っていない探索的なアーキテクチャに関する質問 | スレッドは、具体的なバグ、機能スコープ、アーキテクチャ提案、ポリシー決定、ドキュメントの不備、オーナー、ブロッカー、または検証エビデンスを生み出します |
| 課題 | バグ、機能リクエスト、サポート/設定に関する報告、コントリビューター向けタスク、ロードマップのトラッカー、その他トリアージや追跡が必要な作業 | issue は RFC、PR、トラッカー項目、重複、サポートへのリダイレクト、またはクローズ判断のいずれかになります |
| RFC の問題 | アーキテクチャ、ガバナンス、ライフサイクル、互換性、またはプロセスに関する、正式なレビューが必要な決定事項 | RFCは承認、却下、置き換え、または実装課題に分割されます |
| PRコメント | アクティブな変更に対するレビューフィードバックと実装の詳細 | 詳細は、永続的なポリシー、再利用可能なドキュメント、フォローアップのissue、またはリリースノートになります |
ディスカッションのカテゴリは、期待される成果が明確になるようにする必要があります。回答可能な質問には Q&A、コミュニティでの形成が必要な提案には Ideas、プロジェクト関連のデモ・統合・人々が共有したいダウンストリームのフォークには Show and tell、コミュニティ投票には Polls、メンテナーからの更新情報には Announcements、そして幅広く検索可能な会話・初期のアーキテクチャ探索・まだ作業として追跡されていないダウンストリーム/フォーク/エンタープライズの連携には General を使用してください。ダウンストリームの連携が繰り返し発生し、専用の管理されたレーンが必要になるほどになった場合は、メンテナーが後から専用カテゴリを追加できます。
Discussion が移動したらループを閉じます。短いサマリーを追加し、その結果を引き継ぐ issue、RFC、PR、ドキュメントへのリンクを記載してください。カテゴリが回答の承認をサポートしている場合は、結果を正確に反映していれば、サマリーまたは追跡作業へのリンクを回答としてマークしてください。
github.com/zeroclaw-labs/zeroclaw/discussions
メンテナの連絡先
以下に挙げるすべては、FND-003で定義されているTier 3ロールであるCore Teamです。メンバーシップは§5.1に従い、招待と公開告知によって決まります。この表はそれらの決定の公開された要約であり、それらを確立する記録ではありません。この表はcore-contributorsのGitHubチームやコラボレーターのリストとは異なることが想定されます。これらはメンバーシップの記録ではなくアクセス制御であり、自動化アカウントを含み、アクセスは直接付与、継承、または保留中のいずれの場合もあります。どの記録がどの問いに答えるかについては、§5.3を参照してください。
Focus 列は各人がどこで作業しているかを示すものであり、どれだけの権限を持っているかを示すものではありません。Core Team はフラットです。日常的な判断は緩やかな合意（lazy consensus）で進められ、CODEOWNERS の変更、リリース、RFC の結果、ガバナンスの編集、および Core Team メンバーの追加は、役割にかかわらずすべて明示的な Core Team の投票を必要とします。「Project lead」は Core Team 内での調整およびエスカレーションの役割であり、それより上位の階層ではありません。
| ハンドル | 役割 | フォーカス |
|---|---|---|
| @JordanTheJet | コアチーム、プロジェクトリード | Web、プラグインとスキル、デスクトップアプリ、テストとリポジトリ用ツール、Cargo とライセンス管理 |
| @Audacity88 | コアチーム | ランタイム、エージェント、ツール、ゲートウェイ、メモリ、設定、プロバイダー、ビルドおよびリリースツール |
| @Nillth | コアチーム | Git forgeチャネル（GitHub、Gitea、Forgejo） |
| @tidux | コアチーム | プロバイダー、API、インフラ、ハードウェア、ファームウェア、チャンネル（Matrix、ACP）、認証およびレガシーの src/ ツリー、i18n、ドキュメント |
| @IftekharUddin | コアチーム | Web GUI、メンテナー向けプロセスドキュメント、ラベル、Issue テンプレート |
| @vyahhi | コアチーム | リポジトリの自動化と ZeroClaw-Bot |
| @Stalesamy | コアチーム | マーケティングとコミュニティ、加えて時折 PR |
| @perlowja | コアチーム | マーケティングとコミュニティ、加えて時折 PR |
記載されている全員がコードをレビューするわけではありません。コードレビューは、ティアではなく、Focus 列と CODEOWNERS に基づいてルーティングしてください。
重点領域は、正式な担当振り分け記録である .github/CODEOWNERS を基準とします。この表は人間が読める概要です。両者が一致しない場合は、CODEOWNERSを優先します。
@メンションは控えめに使い、メンテナーをCCするのは課題が本当に彼らの注意を必要とする場合のみにしてください。デフォルトではチームにトリアージを任せましょう。
セキュリティ上の問題
セキュリティ上の脆弱性については、公開されたイシューには記載しないでください。
GitHubのプライベート脆弱性報告（Security Advisories）を通じて非公開で報告してください。
含める:
- 影響を受けるバージョン
- 再現（最小限の例）
- 影響評価
重大な問題については、48時間以内の受領確認、1週間以内の評価、2週間以内の修正リリースを目標としています。協調的な情報開示にご協力いただけますと幸いです。
完全なポリシーについては、リポジトリのルートにある SECURITY.md を参照してください。
リリースフィード
新しいバージョンがリリースされた際に通知を受け取るために、GitHubのリリースフィードを購読してください：
https://github.com/zeroclaw-labs/zeroclaw/releases.atom
GitHub のリポジトリを監視します（Watch → Custom → Releases）。
リリースノートは Discord の #releases とコミュニティの Twitter にクロス投稿されます。
商用サポート
提供されていません。ZeroClaw はコミュニティによって維持されています。大規模なデプロイを行い、SLA を希望する場合は、メンテナに直接スポンサーシップを提供するか、コアチームを通じて専用サポートの手配に資金を提供してください。hello@zeroclaw.dev までお問い合わせください。
フィードバック
自由形式のフィードバック、「Xをやろうとしたけど、どうもしっくりこなかった」といった内容、UXに関する所感、方向性についての考えなどは、迅速なライブでの会話が必要な場合はDiscordの#generalまたは#devにスレッドを立てるのが最適です。フィードバックを検索可能な状態に保ち、非同期でのコミュニティからの意見を募りたい場合は、GitHub DiscussionsのGeneralまたはIdeasを利用してください。スレッドが具体的な内容に発展した場合は、issue、RFC、PRコメント、ドキュメントへと移行させましょう。
貢献者の表彰
PR がマージされた人は全員、リポジトリのコントリビューターリストに掲載されます。大きな貢献、機能追加、RFC、重要なバグ修正については、あなたのハンドルネームがリリースノートに掲載されます。