- 公開の技術記事はコメントを避けるのではなく、事実・経験・質問を中心に設計すると、見知らぬ人たちの反応を学習可能な情報に変えられる
- コンピュータの使い方や問題解決の事例のような検証可能な事実を扱うと、似た経験、資料の推薦、抜けていた事実、注意点、質問、誤りの指摘がより集まりやすい
- 意見を求めるより、具体的な事例や経験を求めると、「DNSのWeb管理UIはひどい」という評価が「
TLSAレコードに対応していなかった」という情報に変わる
- 投稿直後の数時間は誤りを素早く直し、すでに検討した代案はあらかじめ書いておき、繰り返し起きる論争にはできるだけ引きずられないほうがよい
- TwitterやMastodonのようにフォローやブロックを管理できる場では、許容しない行動の境界を決めることで健全な技術的対話が可能になる
コメントを有益にする書き方
- 公開の場での文章ではコメントを完全に避けるのではなく、コメントがより情報的になるように題材と質問の仕方を調整する
- インターネットのコメントには無礼な反応もあるが、見知らぬ人たちのコメントから長年にわたって多くを学べた
事実と経験を中心に置く
- 技術記事では主にコンピュータに関する事実や、コンピュータを使っていて経験したことを扱う
tcpdumpの記事のように使い方と過去の利用例を一緒に扱うと、コメントの方向性が比較的具体的に定まる
- 似ている、または異なる使用経験
- 別の文書や資料の推薦
- 記事になかった関連事実
- 潜在的な問題や注意点
- 技術的な質問
- 記事の誤りの指摘
- 事実ベースのコメントはおおむね健全な流れを保ちやすい
- 否定的な反応もある
- 記事に抜けているオプションに対して無礼に反応されることがある
- たとえば
tcpdump の -n オプションは、デフォルトの逆引きDNS問い合わせを無効にしてIPアドレスを見られるようにするため便利
- 間違いに敏感に反応する人もいるので、確信がない部分は「よくわからない」と明記して対応する
問題解決の話が作る文脈
- 解決した問題についてのストーリーはよい議論を促す
- TCPを理解しなければならなかった経験を扱った記事のように、特定の問題を解決した過程を共有すると、コメントが学んだ内容をより大きな文脈に位置づける助けになる
- その問題がどれくらいよくあるのかがわかる
- 関連してよく起きる別の問題が何かがわかる
- 考慮していなかった別の解決策を知ることができる
- 難しいバグを解決できた理由も他の人が書いた記事を読んだからだったので、こうした問題解決の話は他の人にとっても重要になりうる
技術的な質問を記事の中に入れる
- 記事の中で答えがわからない技術的な質問を直接投げたり、「Xがわからない」と書いたりすると、コメントの焦点が絞られる
- 読者は質問に答えたり、わからない部分を説明したりする形で簡単に貢献できる
- 質問を入れると、コメントから実際に価値を得られる可能性が高くなる
- 人は質問に答えるのが好き
- 書き手は知りたかった答えを得られる
誤りは素早く直す
- 知識の境界にあるテーマをよく扱うため、記事にはミスがたくさん生じる
- 誰かが誤りを指摘したら、記事を編集してすぐ直すやり方を使っている
- 投稿してから数時間はコンピュータの近くにいて、入ってくる誤りの指摘を素早く反映する
- すべての修正を
errata として細かく記録する方法もあるが、時間が足りないのでたいていは記事本文を修正する
意見より事例と経験を求める
- TwitterやMastodonで記事にさまざまな意見がついたとき、その理由を尋ねると具体的な経験を得られる
- DNSの記事について、誰かがzone fileは好きだがDNSレコード管理用のWebインターフェースは嫌いだと言ったとき、理由を尋ねたところ、一部のWebインターフェースが
TLSA レコードをサポートしていないという答えを得た
- 「DNSのWeb管理インターフェースはひどい」といった意見より、「XというDNSレコード型を使いたかったが使えなかった」という経験のほうが、より有用な情報になる
- 自分の記事でも意見を述べるときは、その意見に至ったコンピュータの使用経験も一緒に説明するようにしている
短い文脈で誤解を減らす
- インターネットの見知らぬ人たちは、書き手が誰で、なぜその文章を書いているのかわからないと、妙な反応をする可能性が高くなる
- 記事の冒頭に短い執筆の文脈を入れて、誤った推測を減らす
- Macを使い始め、Linux専用ソフトウェアを実行する必要があって不便だったという文脈
- 複数のサーバをさらに運用するようになり、監視を考えるようになったという文脈
- Linuxでスキャナを初めて使う必要があり、時間がかかるのではと心配していたという文脈
退屈な論争を避ける
- 「vimを学ぶべきか」「関数型プログラミングは命令型プログラミングより優れているか」のようなプログラミング論争は退屈に感じられることがある
- 興味がない、あるいは面白いことを言えないテーマは、望まないコメントの流れを生みやすいので避ける
- 予測が常に可能なわけではないが、過去に繰り返し論争を生んだflamebait的な話題はできるだけ避ける
- 例: cryptocurrency, Tailwind, DNSSEC/DoH
- ただし本当に関心があるテーマなら、そのまま扱ってもよい
- IPv6とIPv4のように繰り返される論点が多い話題でも、サーバがIPv6をサポートすべき理由のように、扱い方によっては興味深いコメントが得られる
すでに検討した代案を先に書いておく
- すでに検討したが選ばなかった方法をコメントでまた提案されると、会話が退屈になることがある
- そのため「Xをしなかった理由はA、B、Cだから」や「ふつうはXをするが、ここでは…」のような短いメモを入れる
- Nixの記事では
nix-shell、nix flakes、home manager のように使わないことにした機能を書いて、「flakesを使うべきだ」というコメントを減らそうとした
- やらなかったことを書くのは読者にも役立つ
- Nixに初めて触れる読者が
nix flakes を知るきっかけになる
- どんな「best practice」にも例外があることを学べる
ソーシャルな場で境界を引く
- Mastodonで
dig のman pageにある「domain information groper」という表現を指摘したとき、一部の返信では元の作者に攻撃的な意図があったと証明するよう求められたり、問題ではないと説明されたりした
- その表現は性的暴行を指す言葉として広く理解されている用語に関係しており、
dig のman pageに置いておくべきではないという立場である
- 何人かをブロックし、そのような反応はこれ以上受けたくないという趣旨の短い投稿をした
- ソーシャルメディアでは、ときどきどのような行動を許容しないかというルールを決めることが重要
- 目的は一部の無礼な人たちに去ってもらうこと
- 残りの人たちがコンピュータについてより健全に話せる場を作ること
- このやり方が可能なのは、TwitterやMastodonのようにフォロー関係をある程度管理できる場所だけ
- HN、Reddit、Lobstersのような場所では、同じやり方はしようとしない
dig のメンテナたちは問題のある表現を数年前に削除したが、Mac OSにはライセンス上の理由で非常に古い版が残っている
論争せず、得るものだけを残す
- 誰かが論争を仕掛けたり、見下すようなコメントをしても返答しない
- インターネットで論争するのは嫌いで、得意でもないので、時間に見合う使い方ではない
- 予想外に否定的なコメントがたくさんついたら、その中から有用なものを取り出せるかを考える
- 80行のGo製DNSリゾルバの記事では、DNSパケットのパースを扱っていないことに不満を示すコメントが一部あった
- 最初はDNSのパースは単純で自明だと思っていた
- しかし、初めてやる人にとってはまったく自明ではないかもしれないと気づいた
- そのコメントは、パースをもっと詳しく扱う implement DNS in a weekend に一部着想を与え、結果としてよりよいDNSリゾルバの説明につながった
- 否定的な公開批判に感情的に揺さぶられないわけではないが、批判を分析して有用な部分を持ち帰ろうとするやり方が役に立つ
1件のコメント
Hacker News の意見
インターネットに文章を書く人にとって、本当に実行可能で合理的な助言であり、自分の経験とも一致している
ただ、私たちが作り出したインターネット文化のせいで、Julia のような才能ある人が自己検閲し、書く範囲を狭めなければならないのは悲しい
「同じテーマで50回目の議論を始めたくないなら触れてはいけないものの奇妙なリストが頭の中にある」というくだりのように、オンラインでは他の社会的な場なら許容されない行動が受け入れられ、報われることすらある
HN、Slashdot、Twitter、Tumblr で様相は違うが、根本的な問題はどこでも同じに見える
インターネットでは個人的な親しみ、物理的な近さ、表情や口調が消え、現実の報復への恐れもほとんど消える
引用された次の文のように、すでにあまりにも多く扱われ、人々が強い意見を持っている一方で、誰かが考えを変えたり、新しい視点を出したり、何かを学んだりするのは難しいテーマに近いものとして読めた
ただし、あるコミュニティの正統的な見解の外側や境界にある意見のように、感情的な論争・固定観念・ダウンボートを招きそうなものについては、多くの人が実際に自己検閲していると思う
例えば Tailwind でおもちゃプロジェクトをいくつか作ってみて、かなり良いと思っているが、職場で巨大な Tailwind プロジェクトをフルタイムで扱っている人たちは、私が些細なこととして流す部分にもはるかに大きな影響を受け、より多くの時間と情熱を注げる
そういう状況を繰り返し経験すれば、Tailwind の話を望んでいない会話に Tailwind を持ち込むことはしないだろうし、それを大きく悪いことだとも感じないはずだ
あるテーマは大きな集団が常に上げたり下げたりするため、そうしたテーマが出るたびに同じコメントで安定して報酬を掘れるなら、繰り返すのが合理的な行動になる
ここでの報酬が結局は自分のドーパミンの均衡調整にすぎないとしても同じだ
オフライン社会でもコメントを収益化するのはより難しいが、人気や選挙のようにまったく存在しないわけではない
「よく分からない」と言って無駄な議論を避け、有用な回答を引き出す戦術は素晴らしいが、残念ながらソフトウェア業界の多くの人には簡単ではない
ソフトウェアの人々は、かつてのように何かを完全にマスターできた時代に慣れているが、知識と世界の複雑さが増え続けている今では、創世記から存在していた超知能の個人であっても追いつくのはほぼ不可能だ
反対意見を「自分は思っていたより知らない」というシグナルとして見られないと危険になり、非常に賢い人たちが率いるプロジェクトが、特定の技術をよりよく知っている、そこまで賢くない人の重要な情報を聞かなかったために失敗するのを何度も見てきた
実際にはスキルと経験のレーダーチャートに近く、難解な知識だらけの職業では特に滑稽に感じられる
経験豊富で賢いことは大きな資産だが、ライブラリ X をよく知らないシニアより、ライブラリ X だけを掘ってきた新人がいるなら、その新人の助言を聞くべきだ
本当に賢い人は、自分が何を知っていて何を知らないかを理解し、理解を検証し続け、間違っていたことが分かれば新しく学べたということなので喜ぶ
誰もが信頼や評価を得るには何でも知っているふりをしなければならないと思っているが、実際には誠実でいれば助けはついてくる
HN での自分のルールはこうだ。返信した人は記事を読んでおらず、私のコメントもざっと流し読みしながら頭の中で自分の返答を書いていたと仮定すること。抽象的な内容は誤解されるので、具体的でありつつ曖昧に書くこと。コメントの質と反応のあいだに一貫した関係はないと考えること。返信を書いたあと送らずに消してもよく、たいていそれが最善だと思うこと。迷ったらスレッドを閉じて先へ進むこと
付け加えるなら、1人のユーザーと長くやり取りする議論はたいてい退屈で結論がないので避けること、誰かが喧嘩を売ってきても乗らないこと、否定的に見えるコメントは自分が誤解した可能性を十分に見込むこと、称賛は人の一日を良くできるので惜しまないほうがいいこと
同僚にレビューを頼んだら、「これを改善する方法は一つしかない」と言って、すぐに削除ボタンを押した
こういうリストが必要なら、より生産的な方向はたいてい自我を小さくしてオンライン言説へのレジリエンスを育てることだと思う
そうすれば、より多くのものをあるがままに受け入れられ、より多様な視点に触れられる
HN が特別なわけでもなく、私も特別ではない。見知らぬ人が手間をかけて返答を作る時間を割く義務もなく、それを期待したり要求したりすれば、たいてい失望に終わる
返事が来たら参加するつもりがある場合だけ再び見る
少しでも論争的なコメントには、相手がこちらの言っていることを理解しようとしない返答が付くことが多かったし、リンク付きのデータを1つ投稿しても、誰かはそのデータが気に入らず怒る
コメントスレッドは、せいぜい同じテーマにゆるくまたがっているだけだ
Juliaの文章には、無理にかわいく見せようとする一部のブログと違って、いい人エネルギーがあり、自分が出した分だけ返ってきているように思える
明らかにトーンの作り方を知っている熟練の書き手だ
インターネットで人々がデフォルトだと想定する口調はもっと荒く、それが不要な問題の大きな原因になっている
逆に、少しの皮肉や昔のTorvalds風の荒々しい活気も悪くはないが、そういう口調はより騒がしい群衆を引き寄せる
誰もがそうした議論のやり方をまねる必要はない
それでも自分の口調は、望んでいるものより常に講義調にずっと近い感じがする
助言がしっかりしている
似たようなことを経験した立場から付け加えると、オンラインでの会話はすべて任意なので、楽しくないやり取りを最後まで終える必要はないし、愚かな人は既読スルーしてもいい
全員を説得することはできず、一部の人はわざと反対しかしないし、多くの論争は悪意のあるものなので、挑発を議論に変えようと頑張らない方がいい
読者に借りがあるわけでもない。彼らはお金を払っていない
全体的に良い助言で、意見より経験を前面に出せというのは新鮮に感じた
「先回りして防ぐ」のは文章が退屈になりかねないので好きではなく、Juliaは熟練の書き手なので滑らかにこなすが、自分はうまくできない
「議論しない」のは良いが、よく失敗する
自分に効くコツは、いま自分は誰かを無料で訓練しているのだと自分に言い聞かせることだ
否定的なコメントの分析も苦手な方なので、ある種の認知行動療法的なテクニックが必要かもしれないし、たいていは「自分が間違っているのか？」と素早く確認して、間違っていれば直せばいいので良い結果だが、正しいのに誤解された場合は腹が立つ
なぜか分からないが、間違っていることよりも正しいのに誤解されることの方がずっともどかしい
間違っている場合は「ああ、くそ」と思いながら発見のドーパミン反応が来るが、自分が正しいのに相手が理解を拒むと、その話題をずっとつつき続けてしまう
これがTwitterでブロックする主な動機であり、理想的には自分をよく誤解する人たちも自分をブロックして、こちらが関わらずに済むといい
digのマニュアルページにある「gross terminology」への反応は、本当の誤解とコミュニケーション不全かもしれないし、もしかするとイギリス英語とアメリカ英語の違いかもしれない
「to grope around for something」は何かを手探りで探すという意味で、まったく性的な表現ではなく、通常、手探りで探す対象も電灯のスイッチのような無生物であることが多い
その用法が性暴力の比喩に由来するとも思わない
単語は複数の意味を持ち得るし、汚い使われ方をすることもあるが、それでも正当かつ自然に使える場合もある
「I coloured in a picture」が気持ち悪いわけではないし、「garden hoe」も問題ないのではないかと思う
例: https://www.dictionary.com/browse/groper
特に性的なまさぐりの一般的な対象である女性は、その意味をより意識する可能性があるので、自分の最初の連想ではなくても、女性がそう受け取るのは合理的だと思う
Juliaが言ったように、もともとの意図はそれほど重要ではなく、自分の文章が偶然一部の読者にとって問題になるなら変更する
自分の目標は要点を伝えることだからだ
歴史的に周縁化されてきた集団を不快にさせる言葉を強く擁護する姿を見ると、なぜそんな小さな変更にそこまで抵抗するのか疑問に思う
そのうえdigの管理者は2017年にすでにその変更をしているので、彼らも大して気にしていなかったようだ
ただし80年代にもそうだったのかはよく分からない
Mastodonのリンクを押して「証明しろと要求した男性たち」を見たが、問題になった返信が削除されていたことを後で知ったので、自分が見た3つの返信は実際には関係なかった
自分が見た返信はおおむね支持的で、2人は性的暴行の意味を今まで考えたことがなく、意図されていたかは分からないがそれでも削除には強く同意すると言い、1人はそういう解釈があることに驚いて追加の文脈を尋ねていた
その後、投稿者はあらゆる場合に悪意を仮定した非常に対立的な返答を多く付けていて、Juliaは素晴らしい技術文章の書き手で今後も読み続けるが、今回の様子は良く見えなかった
マニュアルページの変更要求は完全に合理的だが、個人攻撃は必要なかった
その表現の問題を提起した男性たちの何人かは、「groping」の削除に完全に同意すると明確にしていたが、その時点では著者はすでにその説明を見られなかったのだろう
人それぞれが境界線を引き、虐待的な行動を遮断する選択は全面的に支持するが、「あなたの言うことに同意しないので即座にブロックし、釈明の機会も与えない」という態度は、オンライン言論の壊れ方のど真ん中にあるように見える
ただし、周囲の女性たちがオンラインでの虐待を受けているのを見てきたので、敏感な引き金も理解できる
正しいバランスは分からないし、非常に個人的かつ文脈依存だろうが、自分は明白な虐待を除き、予想可能な応答カテゴリを引き受ける意志があるときだけ会話に参加し始めるようになった
同意しなければブロックするやり方は分極化を強め、長期的には逆効果のように見えるし、たとえ時々自分が「正しい」場合があっても、自分の盲点を強化しやすいように思える
期待と違う形で書かれた文を見て顔面蒼白になり、もしかして二重の意味があるのではないかと苦しむ人たちには疲れた
たとえば「Smoking a fag」は完全にイギリス式の表現だが、教養のないアメリカ人は真珠のネックレスを握りしめ、ダウンボートや通報ボタンを手探りで探すかもしれない
怖いなら何も読むべきではない
読むことは怖くて危険だ
自分の言葉を聞く人たちを気にかけるなら、彼らが「あなたの使った言葉は否定的な影響を与えた」と言ったときに、「申し訳ない、そう感じさせたいわけではないので言葉を変える」と言って先に進むのは、とても自然で難しくない
あるいは一日中、自分はそういう意味で言ったのではないと意図について議論し、実際の影響を完全に無視して、相手に自分の感情など気にしていないのだという印象を残すこともできる
特に個人的な関係では、謝るときに意図よりも影響に集中することを強く勧める
この記事はあまりにも自意識とポリティカル・コレクトネスに満ちているように見える
筆者は政策提言や社会・文化的な洞察を自己検閲しているが、個人的にはそういうもの、特に変化を生み出すような奇妙な視点を書いたり読んだりするのは興味深い
dig に関するブロックもかなり気になり、筆者があまりに早く引き金を引く人のように見えてしまう
このスレッドで少しでも批判的なコメントがすべて 0 未満に下がっているのも見た
私のコメントもそうだし、HN では批判的なコメントが無視されて支持票を得られないのはよくあるが、少しでも批判的なものを全部 0 未満に下げるのは HN 基準でも珍しい
自己検閲に関する記事は、誰もが互いにうなずき合わなければならないような、奇妙な新しい自意識の世界を望む読者を引き寄せるようだ
優れた書き手は常に、言葉選びが読者にどんな影響を与えるかを考える
それが悪いことだと言っているのか？
あなたとは関心が違うだけだ
dig の例で引き金が早いという点こそがまさに要点だ
筆者は、私たちは何を見るかをコントロールでき、そのコントロール権を使うべきだと思い出させている
たいていの人には、建設的に議論へ参加するのが難しい話題があり、それは問題ない
そうした話題ではエネルギーを温存し、うまく使える話題に投稿し続けるほうがよいと思う
賛成票は同意、反対票は不同意として使われがちだ
投票が何を意味すべきかについて別の考え方もあり得るが、投票システムの性質上、そう流れやすい
人々がデフォルトで 5/5 ではなく 3/5 を付けてくれればいいのにと思っても、実際には IMDb くらいでしかそうなっていないのと似ている
恥ずかしながら、今日になってようやく dig が略語で、何の略なのかを知った
名前が明確でないほぼすべてのコマンドラインツールは、grep、cd、pwd、dd、yacc のように略語だ
厳密に専門的な話題だけを書く個人ブログがあり、人に嫌われるかもしれない意見はペンネームで書く別のブログに書いている
影のアイデンティティがあると、必要なときに「間違える」ことができる場所ができる