Haskell-jpのGitHub Organizationや、Slack Workspaceなどに適用されるCode of Conduct

[igrep]

背景🖼

現在、Haskell-jpとは別に「Haskell-jp Admins（日本語名: 日本Haskellユーザーグループ管理委員会）」という一般社団法人を設立しようと動いています。その活動の一環として、Haskell-jpのGitHub Organizationや、Slack Workspace、主催するイベントなどにおけるトラブル対応を円滑に行えるよう、Code of Conductを策定させていただきたいと思います。

そもそもなぜ法人を作るか？🤔

日本Haskellユーザーグループ（愛称: Haskell-jp）は、特に明確な参加資格のない任意団体（趣旨に沿っていれば誰が公式面しても 🆗 ）なので、法律上保護されず、例えば以下の問題があります。

• haskell.jp ドメインなど、共有財産を保有できない
  • 現状は @nobsun が個人で所有していますので、万が一の場合、ドメインを失うことになってしまいます。関連: 法人作成・ドメインの管理 · Issue #26
  • 他にも、各種ウェブサービスの法人向けアカウントを持つ場合や、大きなイベント会場を借りる場合などにおいても、法人格があった方がやりやすいでしょう
• 大きなイベントを運営する場合に、（例えば、プライバシーポリシーのような）定義した規約について法的な責任を主張できない
• Slack Workspaceなどの場でトラブルが発生した際の相談窓口が明確でない
  • 現状実態としては私 @igrep が一手に引き受けていますが、個人で長期間続けるのは好ましくないでしょう

これらの問題を解決するために、新たに法人を作ろうと思います。

これまでの議論の議事録📝

• 2020-09-22-Haskell-jp Administration Committee（仮）キックオフ - Google ドキュメント
• 2020-10-04-Haskell-jp Admins設立に向けた会議 - Google ドキュメント

みなさんにしていただきたいこと🙏

このPull requestがマージされ次第、このリポジトリーを含めたhttps://github.com/haskell-jp/ が保有しているリポジトリーでの議論や、Haskell-jpのSlack Workspace、すべてにこのCode of Conductを適用し、（まだ正式に設立されていませんが）Haskell-jp Adminsが運営することになるので、参加する多くのみなさんに確認いただき、意見を募りたいです。

なお、レビューの際は各コミットの情報も細かい変更の経緯として参考になるかと思いますので、併せてご覧ください。

しばらく意見を集めて修正したところでマージします。

だれが「Haskell-jp Admins」のメンバーか👨‍👨‍👦‍👦

このPull requestを送った時点で以下のGitHubアカウントの持ち主がHaskell-jp Adminsのメンバーです。

• 代表理事: @igrep
• 監事: @nakaji-dayo
  • 法律上監事が必要なことを前提に進めてましたが、よく調べてみたら実際には一般社団法人には不要なことが発覚したので、監事は設けないことにしました。
• @nobsun
• @kakkun61
• @fumieval
• @lotz84

[igrep]

後ほどSlackで全体にアナウンスしますが、念のため、Haskell-jpが始まって以来際だったcontributionをいただいたみなさん（うち、まだメンションしてない人）にGitHubアカウントが分かる範囲でメンション致します。
（もし漏れがあったらごめんなさい...）

@takenobu-hs @minoki @matsubara0507 @mizunashi-mana @waddlaw @y-taka-23 @kayhide @cdepillabout @gksato @aruneko @khibino @eliza0x @haru2036 @as-capabl @maoe @YoshikuniJujo @Tatsuki-I @konn @egisatoshi @aiya000 @syocy

[aiya000]

わーい🤤👍️

「どこかまずいところはないかな」みたいなスタンスで、COC読みました！
とてもいいと思います :D

[ncaq]

ものすごい重箱の隅なんですが、

Haskell-jp は

みたいに英単語と日本語の間にスペースが空いてたり、

以下のCode of Conductは

みたいに空いてなかったりするのが気になります。

固有名詞かどうかで分けている感じですかね?

[igrep]

💡 なるほど。特に意識してませんでした。 スペースを空ける方向に統一します。

すみません、やっぱり空けない方向にした方が修正が楽だったので空けないことにしました。

[maoe]

Haskell.org committeeでもCoCを策定する流れになっています。適用するルールはGHCと同じGRCです。なぜSPJが既存のCoCではなくGRCを採用したかは ghc-proposals/ghc-proposals@373044b#commitcomment-31627522 あたりに書かれています。Haskell-cafeかどこかのメーリングリストにも長い議論があったような記憶があります。

個人的にはHaskellコミュニティが同じCoCを採用するとわかりやすくていいなと考えますが、皆さんどう思われますか？

[igrep]

うーん、翻訳を維持するコストを考えると、独自に日本語で作りたいですね。
一義的には日本に住む、日本語話者中心のコミュニティーなので... 英語ネイティブの方も確かにいらっしゃいますが...

[maoe]

もちろん一字一句翻訳したものである必要があるわけはなくて、必要に応じてコミュニティごとの修正は必要かもしれません。より注目すべきポイントは、提案されたCoCとGRCには大きな違いがある点です。

• negative（してはいけない）に着目するかpositive（目指す方向はこうである）に着目するかどうか
• 適用範囲を特定のメンバーに絞るかどうか

1点目についてはこのレポートには

About the difference between rule-based and value-based phrasing of a code of conduct, interviewee B found that both have their benefits, such as signaling a safe and welcoming environment. Rule-based phrasing is more clear and allows to easily react when a conflict happens, whereas value-based phrasing is less likely to deter people from joining the com- munity, which is an advantage. Since in rule-based phrasing, misbehaviours are mentioned, they may induce to others that the related community is an environment with hostile and unfriendly issues.

という指摘もあります。

2点目については正直どちらがよいのか自分でもよくわかりません。ただSPJの言うように突然強制力のあるルールを全体に適用するのではなく、必要に応じて徐々に範囲を広げていくのも一つの手ではないかと思います。

[maoe]

ちなみに自分の立場をはっきりさせておくと、GRCが好みですがどちらのCoCが適用されても構いません。ただし長所短所は吟味してから判断して欲しいなと思いました。

[mizunashi-mana]

これって、Haskell-jp コミュニティ参加者が守る CoC で、Haskell-jp Admins の CoC は別に作るという理解でいいんですかね？

全般的に見て、適用される範囲がかなり広いわりに、制約がかなり強い気がしていますね。特に

Haskell-jpのSlack Workspaceや各種GitHub Repositoryにおいて適用されるCode of Conductです。

と

Haskell-jpは、当Code of Conductが適用されるインターネット上のコミュニティ、イベント、および関連するSNS上でのコミュニケーションの全てにおいて、参加者、イベントにおける発表者、スポンサーなど、全ての関係者の皆様に対して本Code of Conductの遵守を求めます。

の部分が競合しているのが気になります。後者が適用される前提ならば、他のイベントでの CoC との互換性が問題にならないのかも調べた方がいいかもしれません。

元になる ScalaMatsuri の CoC は、カンファレンス運営のための CoC でありコミュニティ用の CoC としては意図されてないと思うので、コミュニティの CoC としてはもうちょっと具体的なケースに絞らない指針としてのものの方がいいんじゃないかと感じました。もう少し、ScalaMatsuri 以外の、特にコミュニティ用の CoC を参考にするのがいいんじゃないかと思っています。一応、僕の思いつく CoC を上げておくと以下のものが参考になると思います:

• Ubuntu CoC: https://ubuntu.com/community/code-of-conduct (JP: https://www.ubuntulinux.jp/community/conduct)
• Eclipse Foundation CoC: https://www.eclipse.org/org/documents/Community_Code_of_Conduct.php

[mizunashi-mana]

後、内容というより CoC の構成の話になるんですが

一応 CoC はガイドラインでなく拘束力を持つものだと思っているので、その点である程度 negative な面を踏まえるのは仕方ないと思いますが、kind communication のための CoC の内容の主が negative なものというのは、心理効果を考えるとあまり良い構成の CoC とは思えないので (これは maoe さんも言及されてますが)、その点でも positive な面や動機の部分はもうちょっと拡充した方がいいと思いますね。

それから、基本的に箇条書きにするものは短い概要を付けておいた方がいいと思いますね。例えば、現状のハラスメントの例は、

• ナンパ行為: 他の参加者に対する容姿に関する発言、恋愛・性的興味を目的とした発言や不適切な身体的接触を行うこと
• 差別的な言動: ジェンダー、性自認、ジェンダーの表出、性的指向、障がい、容貎、身体の大きさ、年齢、人種、国籍、民族、宗教について、当人が不快に感じる発言や差別を助長する言動を行うこと
• 公衆猥褻: 公共の場に性的な画像を掲示したり、見せびらかしたりすること
• ストーキング: 他の参加者に対して、故意の威嚇やストーキング、つきまとい、本人が嫌がらせと感じるような写真撮影や録音録画を行うこと
• 妨害行為: イベントにおける発表や、その他のイベントの運営を CoC 違反に当たるなどの正当な理由なく継続的に妨害し続けること
• etc.

みたいに書いておくと、どのような行為がハラスメントに当たるかが読み手側に整理しやすいと思います。後、基本的に CoC は大体似たようなことが書かれているので、多くの CoC を読んできた人にとって読むポイントがつかみやすくなると思いますね。

[takenobu-hs]

CoC, GRCのいずれをベースにしても私は構わなくて、コミュニティ運営に知見のある人の想いに合わせます。 (禁止・制約事項を明示するCoC的スタイルか、ありたい姿を書くGRCスタイルか。)

個人の好みとしては、GRCを非常に気に入っています。多様性や寛容といった、グローバルのHaskellならではの良い文化や想いが充分に込められているからです。
（但し、GRCをベースにするためには、そもそもの母集団の特性が良好な必要があると思います。）

あと関連参考として、今年のICFP2020のCoCのURLも付けておきます。
https://icfp20.sigplan.org/attending/code-of-conduct
この中で、次の一文が、FP界の良い文化っぽくて特に気に入っています。

We expect all the participants ... to gracefully accept constructive criticism

（建設的な批判を、優雅に受け入れる。）

[kakkun61]

GRC というものを maoe さんの記述で初めて知ったので訳してみようと思います

[igrep]

みなさんコメントありがとうございます！
ちょっとCoCを作るのに焦ってしまったかも知れません 💦
必要な見識が不足していました。

これって、Haskell-jp コミュニティ参加者が守る CoC で、Haskell-jp Admins の CoC は別に作るという理解でいいんですかね？

の部分が競合しているのが気になります。後者が適用される前提ならば、他のイベントでの CoC との互換性が問題にならないのかも調べた方がいいかもしれません。

この二点については、私のミスでした。適用範囲を再度以下のように見直そうと思います

• Haskell-jp Admins自身も適用対象に含める
• コミュニティとイベント双方に適用されるものであることをより明確にする
  • 具体的には、以下のコミュニティーや、そこで開催されるイベントが該当する
    • https://github.com/haskell-jp/
    • https://github.com/haskell-jp-admins/
    • https://app.slack.com/client/T4LFB6C4C/ (haskell-jp.slack.com)
    • https://techplay.jp/community/haskell-jp
    • https://haskell-jp.connpass.com/
  • ※teratailのコミュニティー https://teratail.com/communities/haskell-jp についてはちょっとちゃんと性格を把握できてないし、teratail自体の規約を適用すれば十分であろうことから、保留します。

「他のイベントでの CoC との互換性」の問題については、現状 https://techplay.jp/community/haskell-jp や https://haskell-jp.connpass.com/ で開催されるイベントで、Haskell Day 2019のものを除いてCoCが定義されたことがないので、大きな問題はないという認識です。

[igrep]

GRCかCoCか、については、個人的にはCoCはトラブルが発生した際の「緊急警報」として運用する前提でいたので、GRCではちょっと運用しにくいのかな、という印象です。ざっと見た限り通報するような仕組みはないみたいですし。

とは言え、GRCもそれはそれで魅力的なのでちゃんとチェックします。情報ありがとうございます。

[igrep]

大分日が空いてしまって申し訳ないのですが、前回のHaskell-jp Adminsの会議で、「positiveな内容を列挙するGRCをHaskell.orgのGRCを参考に（あるいはそのまま翻訳して輸入？）した上で、それに基づいて禁止事項（negativeな内容）を列挙したCoCを作ろう」というアイディアをいただいたので、その方針で進めたいと思います。GRCを憲法のように、CoCを法律のように捉えたわけです。

そもそもCoCを作ろうとした意図として、何かトラブルがあったときの「緊急警報」のような役割を期待していたので、GRCのようなアプローチはちょっとAdminsとしては運用しにくいのではないか、と考えたのが一点目の理由です。その一方で、ここでの意見を聞く限りGRCも確かに魅力的で、より支持されるだろうと考えたのが二点目の理由です。

（書いているうちに二つ作った場合にどちらをどう見せるか、といった問題が思い浮かびましたが、それはその時議論させていただきたいです 🙇 ）

いずれにしても、 @kakkun61 のGRCの翻訳に期待しつつ、一旦このCoCは取り下げたいと思います。そもそも焦る必要のなかったものなので。issueはcloseしますが、この私の意見へのコメントは歓迎します。