このリポジトリは、コミュニティとしてのHaskell-jpを俯瞰し、また改善するための提案を管理するための場所である。
IssueまたはPull requestによって、コミュニティレベルでの提案をすることができる。 使い分けの基準は以下の通りである。
Issueを使う動機は投稿の簡単さのためで、一方Pull Requestを用いる動機はレビュー機能により議論をまとめやすくすることである。
また、このファイル自体への変更もPull requestで受け付ける。
文体は常体の口語体を推奨するが必須ではない。体言止めなどのカジュアルな表現を使っても問題はない。
Haskell-jpの存在する目的は以下の二つである。
この節では、Haskell-jpを構成するサービスなどを記述する。技術的な詳細には触れず、Haskell-jpとの関係と効果に着目する。
目標Pを達成するには、コミュニティから、潜在的なユーザーに向けて発信する手段が不可欠となる。また、目標Qを達成するには、ユーザー同士の対話の場、そしてコミュニティを維持するための管理が必要である。目的を達成するための構成要素の役割を 発信 、 対話 、 管理 の3つに分類し、各項で考察していく。
一つの要素で全ての役割を果たすことも可能だが、それが最善とは限らないことに注意すべきである。レビューなどは発信と対話を分離する好例で、発信する前に情報の質を高めることができる。
役割: 発信、対話、管理
自明ではあるがコミュニティの存在にはメンバーが不可欠である。他の構成要素を利用して役割を果たす、最も重要な要素である。
人々が単位時間当たりにこなせる仕事には限りがあるため、同じ役割を持つ要素が多すぎると労力が分散してしまい、届きうる情報が散逸してしまうリスクが生まれる。
メンバーの特殊な場合としてコアメンバーがある。コアメンバーは互いに連携を取り、コミュニティの意思決定や、構成要素の管理を行う。
役割: 発信
後述する構成要素へ案内するポータルサイト。迷ったらここを見ればよい。
役割: 対話、管理
コアメンバー以外の対話の多くはこのSlack上で行われている。いくつかの自動投稿チャンネルと、トピック別のチャンネルからなる。
いわゆる無課金のため、Slack本体から古い投稿にはアクセスできなくなってしまうが、slack-logというツールにより投稿を保存することで対処する。
randomとquestions、haskell-jp-status、event-announcementsの四つのチャンネルがよく利用されている。
役割: 管理
コミュニティのタスクを管理している。変更がリアルタイムに反映される。リアルタイムに更新が反映される、チェックリストを管理できるなど、優れた機能を持つ。編集権限を持つメンバーは一部だが、アカウントさえ持っていれば誰でもコメントを追加できる。内容(≒未消化のタスク)は充実しており、それなりに更新もされている。
役割: 発信
Twitterアカウントが存在するが、フォロワー数も発言数も少なく、火力不足が否めない。
役割: 管理、対話
Webサイト、ロゴ、教材、関連ツールを管理する場所として利用する。比較的議論も活発である。
役割: 発信
リポジトリを通して記事を投稿できる。もちろん誰でも閲覧でき、コミュニティの主要な情報発信源であると言える。
役割: 発信
Gititを利用したWiki。GitHubアカウントで認証することで編集が可能。
現在Haskellに関する日本語のリンク集とデータ構造列伝の二つが充実しているが、他の内容は少ない。編集の頻度は極めて低く(月に1件未満)、閲覧者も少ないと考えられる。
役割: 対話
外部リンクの共有と議論が可能な場所であり、コメントがリストではなく木構造をなすのが特徴であり特長である。投票システムにより、人気の投稿はよりアクセスしやすくなり、不評な投稿は隠れる。また、外部からアクセスできるのも大きな違いである。
r/haskellと比較すると投票・コメント数共に極めて少なく、特長が活かせていない。
役割: 発信、対話
主要なのはHaskell-jpが主催する定期ハッカソン、Haskell-jpもくもく会である。参加者は10〜20人ほど。コミュニティに関する議論や作業がここで行われることもある。4.5時間、おのおのが作業し、残りの30分で軽い発表をすることもある。