ネットコミュニティ設計「適切なスコープを作る」
日本人においてインターネットを使う「ふつうな人」と「ふつうな人ではない人」の違いは、インターネットに対して「反応してくれる人への期待値」の差ではないかと思う。 最近話題の例だと、クローズドなLINEにタイムラインがついて不要と言う人は、そこに期待する抽象的なサークルがないからだけだし、逆に、LINE上に本人にとって不特定に近いサークルができてくれば、あいまいなコミュニケーションのためにタイムラインは必要になっても良いだろう。（LINEのタイムラインの難しさはパーソナルとグローバルの両方が混在してしまうことなんだろうけど。フォーマルとカジュアルというか） メッセンジャーというのは、特定の人への連絡手段なので、基本的に返信を期待しているし、目的も明確だ。だからユーザーにハマると強固なアクティブ率を誇るわけだが、タイムラインというのは、もう少し不明瞭なコミュニケーションのバッファ的役割になる。
コミュニティに非協力的な人への向きあい方 - 科学と非科学の迷宮
あけましておめでとうございます。 一昨年は大晦日の夜は一人で過ごしながら hadoop のパッチを書いていましたが、昨年末は大晦日はおろか新年の元旦含めて年末年始ぶっ通しで仕事に追われてました。 そんなわけでコミケもネットで眺めてひっそり楽しむ程度だったわけですが、一つ非常に印象に残ったツイートがありました。 「 「コミケ来場者は客」 みたいな奴マジ来るな死ね！」とスタッフ暦＝半生の先輩に言うと決まって帰ってくる言葉は 「教育して、仲間にする。新兵はいずれ古参兵になる。そうやってコミケは歴史を積み重ねて来たんだよ。」と言われます。 スタッフは皆が思っている以上に寛容で大きいぞ。 2012-12-30 16:03:53 via web 真偽のほどは分かりませんが、こうしたポリシーはコミュニティを長生きさせる上で非常に重要です。 コミュニティが小さいうちは、お互いをきちんと理解している仲間だけ
Big Sky :: 個々の作業はチームを作る事で効率を上げられる
先日、vim-jpがオープンした訳だけど、これの真の意味はバラバラだったユーザや開発者を1ヶ所に集めるのが目的。まぁVim-users.jpもあって良いし、各々でやったらいいと思うけど僕が求めていたのは開発側。 vim-jpを作って良かったと思った。 githubのIssueトラッカーを使ってvim_devにパッチを放流するまでのワークフローが出来上がりつつある。 不具合報告 皆で再現確認 修正方法の提案そして議論 修正担当者をアサイン パッチを仮で書いて貼り付ける レビューしてもらって提出 突然、有識者がパッチ書いてvim_dev投げるとツメも甘かったりしますし、第一に新しい開発メンバが増えない。仕事でも同じだな。不具合が出たら修正者にすぐ直させるものいいんだけど、どう直すのかを予めレクチャーさせると不具合の認識が共有出来る。 後からそういう修正じゃなかったんだけど...って事がなくなる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
