まず、 @shinichin の今の役割を「期間限定の、コミュニティーがWordBenchの行動規範について話し合うことができる体制（スケジュールとチーム構成）を整えるための旗振り役」としたいです。 この役割を果たしている時の方針は、オープンであること、フェアであること、この議論に参加したい人たち全員を歓迎すること、とします。自分の個人の意見を言うことは控えつつ、言うべきときには個人の意見であることが分かる形で発言します。この役割をやらせてもらうにあたって、「他社やコミュニティーに対する威嚇、誹謗中傷や、差別的発言などの受け入れられないと僕が思う何かがあったときに、その行動をした人による、行動規範に関する議論への参加を禁止する権限」と「スケジュールとチーム構成がどうしても話し合いによって決まらないときに、最後に決定する権限」をください。 旗振り役の時期が終わったらまたもとに戻ります。チーム構成が確定したら、僕はもとに戻ります。
プルリクドリブンならこういうこと考えなくてもいいかなと。 プルリクやIssueは誰でもオープンすればいいんじゃないですかね。 ブランチ保護の仕組みがあってマージする際にレビューしてマージという手続きを必須にできるので最低でも3人の同意が必要。特定の誰かに絞る必要ないんじゃないですかね。
「あっ、ごめん」って戻すことに寛容になれる仕組みにしたいですね。現状はそれができないのでザワザワするわけですし。
WordCamp Tokyo 2018 のコントリビューターデイまでに、コミュニティーの意見を集約した第二版の案を作成して、その日に第二版を公開することを目標にしてみました。 以下のスケジュールとチーム構成を提案するので、これをもとに議論を進めてほしいです。
ディスカッションやアップデートのコストを下げればこんなに大きなスケジュール感で考える必要ないんじゃないかと。 ファーストリリースは2週間ぐらいで出して、プルリクやissueはいつでもウェルカムにすればよいのでは？ マージしたら即リリースして、リリースノートにその時のissueやPRにリンクを貼るというイメージでいいんじゃないかと。
別に早くなくてもいいのですが、プルリクドリブンならディスカッションとかリリースのコストが確実に下がります。
チーム構成は10日では決まらないかもしれないので、次のヒアリング時期にかぶってもよいが、6月中には決める。
プルリクドリブンならチーム構成もそれほど深く考える必要ないですね。
コミッターをどうするか決めるべきですが、それもIssueで決めたらいいんじゃないかなと。10人ぐらいいてもいいんじゃないですかね。 （どちらかというとコミッターはオペレーターとか作業者的な位置づけになりますね。） ただしアクティブではない人をいつまでもコミッターにしておくとセキュリティリスクがあるので、定期的に掃除が必要かも。（これは自動化できます。）
これから約1ヶ月間、どのようなことでもいいので、意見等、思っていることをすべて出してもらう時期。内容について、禁止項目について、進め方について、WordBenchの行動規範のあり方に係る内容であれば構わないですし、気もちみたいなことでもよいです。 #code-of-conduct があるので、そこに投稿してもらえたらいいと思います。
プルリクドリブンならこれも深く考える必要ないんじゃないかと。 Issueやプルリクはいつでもウェルカム。
aのヒアリングをもとに、2週間で素案を作成します。誰が作るのかは次の項で提案があります。
これも考える必要ないんじゃないかと。
その素案に対するフィードバックを3週間ほど集めます。
常に集めましょうｗ
cのフィードバックをもとに、RC版を作成して公開します。
これも常に。永遠に。ｗ
dが公開されて誰でも読むことができる時期です。基本的には9月のWordCamp Tokyoで公開してしまいたいと思っています。そこでも反対があればまた話し合うことになります。
同上。
「WordBench 行動規範作成グループ」として、以下の構成でのチーム形成を提案します。
- WordBench のイベントを過去3年以内に3回以上運営していて、かつ、WordCamp にスタッフとして参加する資格のある人で構成。
- 立候補制。立候補は #code-of-conduct チャンネルで教えてください。
- 人数は未定。
- 三好さんにも入ってもらいたい。
プルリクドリブンならこれも考える必要がないんじゃないかと。
上記のドラフトやフィードバックを待たず、著作権とライセンスの表示を入れられるように、独立して動きたいと思っています。
これはプルリクください。ｗ
直接のきっかけとして「SNS上でのWordBench運営者として受け入れられない行動」という言葉がありましたが、この件については私は、どういうコンタクトや話し合いが持たれてアクションが起こされたのかを知りません。また、知っていても公開するような話ではないという雰囲気を感じているので、ここにこだわるのはやめてください。
これは各個別のIssueで随時。
大きくまるまる変更するということもあると思いますが、それもプルリクでブランチで時間をかけてディスカッションしてまとまったらマージしてリリースノートを書く感じでいいんじゃないかと思います。 その間に直近の大きな問題を直してコマメにリリースでいいんじゃないですかね。
現実問題として、昨日までオッケーだったある特定の人が明日からダメということは、この文書の趣旨としてそれほどないはずなので、（もしあってもその場合はブレイキングチェンジということでリリース前に騒げばいいんじゃないかなと）こまめにリリースしてオープン性を確保することを優先すればいいんじゃないかなと思います。
必要なら毎月1日にリリースって先にルールを決めてしまうとかもありかもですが、あまり機能しない気がします。（どうせみんな飽きる。笑）
決めないといけないのはリリースまでの作業フローですね。
git tagでバージョン番号でタグ付け。（WPと連携するとこの時点で投稿される！）- リリースノートをマークダウンで書く。（自動化できます。）
- 貢献者をリストアップ。（自動化できます。）
- Releasesのところでボタンを押す。（自動化できます。）
git tagしてpushした時点でWPの特定の記事をアップデートすることは簡単です。本家のハンドブックでも使ってますね。
あと、これについて追いかけたい場合はwatchすれば通知を受け取れます。
まあ要は淡々と作業として取り組めるような仕組みにしたいのと、ディスカッションとリリースのコストを下げることでオープンな感じにすればいいんじゃないかなと。
あっ、バージョン番号はセマンティックバージョニングがいいかもですね。
WordCamp Tokyoまでは0.x.xみたいな感じで、それ以降は1.x.xで、ブレイキングチェンジ（それまで参加できてた人がこれなくなるようなケースがある場合）はメジャーバージョンをあげていく感じ。