Chienomiに「記事フラグ」を追加
開発::website
序
Chienomiはリセット後(現在記事が残ってる範囲)だけでももう10年になるサイトだ。
このため、シェアされたリンクを見て過去の記事を確認すると「あ、この記事間違ってるんだよな……」とか、「今この記事参考にされるとまずいかも」みたいなことが増えてきた。
これまではわざわざXやFediverse上で訂正を入れたりしていたのだけど、そんな記事はどんどん増えていくため、Chienomi側で対応することにした。
対応内容は、記事にメタデータでフラグを立てることができるようにし、フラグが立っている記事には注意書きを入れるようにするというものだ。
この対応は、テンプレートと記事のメタデータを更新することで実現している。
追加されたフラグ
outofdate
outofdateが設定されている場合、その記事の内容が現在は適用できないことをnoticeする。
up2date
up2dateが設定されている場合、その記事は継続的に更新されることを示す。
unsolved
unsolvedが設定されている場合、その記事には未解決の問題が残されていることを示す。
revise
reviseが設定されている場合、訂正記事が存在することをnoticeすると共に、訂正記事へのリンクを掲載する。
updates
updatesが設定されている場合、更新が存在することをnoticeすると共に、更新へのリンクを掲載する。
mistake
reviseが設定されておらず、かつmistakeが設定されている場合、この記事の内容が間違っていることを確認済みであることをnoticeする。
pointout
reviseおよびmistakeが設定されておらず、かつpointoutが設定されている場合、この記事の内容が誤っているという指摘があることをnoticeする。
このnoticeはあくまで「指摘がある」という事実を述べているだけであり、実際に誤っていることが確認された場合はmistakeフラグを利用する。
従来からあったもの
インポート (wpimported)
この記事がWordPressからインポートされたものであることをnoticeする。
内容・データともに古い可能性があることを示す。
関連記事 (relates)
過去の記事の続きになるような記事を書いた場合、「後に書かれた記事に」関連記事として記載するようにしている。
なるべく古いほうの記事にも書くようにしているが、そうすると関連記事が増えてくると更新しなければならない量が増えていくため、難しいとろこ。
更新 (changes)
記事そのものを更新した場合に、いつ、何を更新したかを記載する。
pointout/mistake/updatesの基準
この3つのフラグはupdates > mistake > pointoutとなっており、排他である。
まずはpointout起点のケースから。
指摘を受けた場合、原則として指摘内容を検証している。
検証する前にpointoutフラグをつけることはない。
検証して誤りが確認できた場合、mistakeフラグをつけるか、記事を訂正するか、更新記事を書いた上でupdatesフラグをつける。
問題は指摘が正しいか誤りかを判定することができないほど難解であるか、検証が困難である場合だ。
このような場合、記事が誤っていると断定することはできないし、かといって指摘を無視することもできないため、pointout、つまり「未検証の指摘」のフラグがつく。
次はmistake起点のケースから。
記事公開後に誤っていることに気づいた場合、あるいは指摘に対する検証の結果誤っていることがわかった場合で、かつ訂正をすぐに行うことが難しい場合にmistakeフラグがつけられる。
そして、最後に、更新された内容の記事(誤りに限らない)がある場合はupdatesがつけられる。
対応は逐次
全記事を確認してメタデータをつけ直したわけではなく、今後気づいたときに記事にフラグを立てていく方針である。
そのため、現時点でフラグが立っているものはほとんどない。
余談: なぜそうしたか
Chienomiは「人々にとって有用な」情報ソースであることを目指している。 これは万人にとって有用であろうという意味ではなく、その情報を必要としている人にとって有用、という意味だ。
だからこそ、Chienomiの執筆はちゃんと裏取りを行っている。 場合によっては24時間以上裏取りにかけることもあるし、その結果書いていた内容の正しさを裏付けできず、記事を捨てることだってある。
しかし、そうしているうちに気づいたのだ。 ――大抵の情報には賞味期限がある。
Chienomiは私にとって最初の技術サイトではなく、技術サイトはすでに存在した上で「時と共に風化するブログ版」として立ち上げられたものの流れをくんでいる。
そして、なぜブログのほうだけが残っているのかといえば、「この情報は普遍性があるはずだ」と判断して技術サイトに書いた内容が、風化して使い物にならなくなることがあり、どちらに書くかの判断が困難であるという結論に達したからだ。
本当に、たいていの情報は風化してしまう。 情報がいつ書かれたものか、どういう背景で書かれたものかというのは、記事を読む上で不可欠な注意点なのだ。
一時は、ライブでない記事を消していく、ということも考えた。 日付を見ずに勘違いしてしまう人があまりに多いからだ。
それは責めるようなことではない。誰もがいつでもそのような注意深さを持って行動するなどというのは理想論に過ぎないからだ。 だが、誤解を生むのはよくない。結果的にではあるが、古い情報によって誤解するというのは、間違った情報を記載してしまっているのと大差ない。
しかし、消すのが良いことというわけでもない。 ちゃんと日付を見た上で読んでいる人にとって、「過去のことを知る手がかりとなる情報」である可能性があり、長期的に考えた場合風化した記事が残っていることにはかなり大きな価値がある。
では、どうしたら記事を消すことなく、誤解を生じることを抑制できるだろうか、と考えた結果が、「その記事が今どういう状態にあるかを提示する」ということだった。
もちろん手間のかかることではあるが、「情報の信頼性を保つ」ということは記事の内容に引けを取らないほど重要なことであるため、こうした対応を行うことにした。