私案

gistfile1.md

目的

持続性がある方法を目指す。

• インフラコストがかからないこと。
• 特定の誰かに権限が集中しないこと。
• すべてが公開された場所に残ること。（たとえば閲覧する際に認証とが必要ないこと。パーマリンクがあって後から参照しやすいこと。）
• オープンソースコミュニティっぽい方法であること。「オープンソースっぽい」は毎日進化してます。

WordPress日本語コミュニティへの参加方法

GitHub Organizationへ参加することで日本語コミュニティへの参加とする。

• 所定のリポジトリにIssueを立てることで参加を表明。（サンプル）
  • レビュー機能をつかって誰かが承認したら自動的に招待。
  • Issueテンプレートで同意の旨が記載されていれば、だれでもウェルカムとする。
  • Code of Conductに対する違反があればそのユーザーアカウントをブロック。
  • コントリビューターデイで簡単に入れたら参加者さんのテンション上がりそう。

ideasリポジトリ

• なにか解決するべき課題等があれば、このリポジトリにIssueとして投稿する。
• 新規プロジェクトが必要なら。新規リポジトリを作ることもここで決める。
  • 原則として言い出しっぺがコミッターとなる。
  • コミッターは2人以上いると望ましい。ミスがあっても直せばいいという文化が大事。あとそのことでコストがかからないことも大事。

Organizationそのものの管理

• なるべく大勢が望ましい。
• 新しい管理者もIssueで。
• なるべくウェルカムに。
• アクティビティを監視して、ただ管理者であり続けることができないようにする。（過去１年以内にコミットがない場合は管理者権限を外すなど。）

その他

• Slackは最終的な意思決定の場ではない。最後はかならず認証がなくてもパーマリンク等で参照可能な場所に。
• なんらかの文書が必要であればそれもGitHub上のマークダウンで。たとえばCLIチームやREST-APIチームはハンドブックのコンテンツもGitHubで管理している。
• 解決したい課題を持ってる人間が即座に活躍できる環境を目指す。
• 持続性を確保するためにやめやすいことも大事。
• すべてのリポジトリはかならずmasterを保護してレビューを必須とすること。

個人的な補足として。

• ルールを作ったらエンジニアの負け。なるべくソリューションで解決することをこころがけたい。
• Organizationの運営で特定の誰かに依存しないこと。これもソリューションで解決したい。