Qiitaの記事をすこしづつ追記している理由を質問された
その答えを、少しづつ追記しながら回答。
背景、環境、原因、結果に関する資料
一つの記事を書こうとすると、その背景、環境、原因、結果について、別々の技術要素に起因することがある。
そうすると、それを一つの記事にすべて網羅するのではなく、それぞれ、背景、環境、原因、結果について、別の記事にして、相互参照する方法をとることがある。
一つの記事を書き進むと、背景、環境、原因、結果の記事にも、少し手入れが必要なことがわかる。
複数の記事を同時並行で書き進めるのに、下書きが１０だとどうしても足りない。
一旦記事として公開し、書き足す方法をとることになった。
読み手の視点での書き直し
コメントや編集リクエスト、意見、質問をもらう前に、いいねしてくれた人が、どういう人かによって、その人に必要そうな内容を書き足すことが多い。
いいねが多い記事ほど、追記回数も多くなる。
例えば、若いプログラマがいいねしてくれれば、その世代の人が知っていそうな話題がどう関係しそうかを追記する。
熟練のプログラマがいいねしてくれれば、その人が注力している技術とどう関係しそうかを追記する。
知り合いであれば、具体的にその個人の視点で見ると何が書いてないとまずいかを思い起こして、その人の視点で読みやすいように書き足す。
知らない方であれば、その方の書かれた記事とどう関係するかを考えて追記する。場合によっては参考資料に追記する。
意見、質問
コメントや編集リクエストだけでなく、直接会ったときや、Twitter, facebook, はてなブックマークなどにもらう意見にもとづいて、追記することもある。
直接いただいたコメントには、１０本くらい記事をかかないと理由が説明できそうにないことをいただくことがある。
記事をせっせと書き溜めて、あるまとまりができてからお返事を書く。早くて３週間、平均３ヶ月、長いと３年かかるかもしれない。
決して無視しているのではなく、資料集めに時間がかかっているだけ。
仕事にて
いくつかの記事は、仕事の資料で参照して、会合の際の資料につけている。
ある特定の仕事の文脈で考えると、これが書いてないとまずいという事項をその都度追記する。
そんな事情で、記事が多く、未完成で、追記が多い状況の説明になっているかどうか、
順次追記します。
著作権上
著作権上明確でない情報は、ひとまず
https://researchmap.jp/kaizen/
に掲載し、そのURLをQiitaから引用することがある。
あるいは、データでgit, dockerに掲載するほど整理できていない事項は
https://researchmap.jp/kaizen/資料公開/
に掲載してURLを引用することがある。
著作権上問題がないことが確認できたら、
Qiitaの記事への追記をすることがある。
researchmapでは、ほとんどの記事に
＜この項は描きかけです。順次追記します。＞
と記載している。Qiitaではときどき。
参考資料(reference)
アウトプットの媒体としてQiitaを選んだ理由
https://qiita.com/nanaki11/items/7775447f6e296f532f09
「Qiita」と「スタック・オーバーフロー」の違いを抜粋してみた
https://qiita.com/mrrclb48z/items/eabd668db78a2edab5de
スタックオーバーフローだと、ソースコードの追記などは問題ないが、内容の追記はちょっとダメかもと思いました。
問題の全体像を示さないと。段階的詳細化は可能だが、回答できる水準に達しない書き込みはご法度かも。
Qiitaは断片であっても、何人かの読者にとって有益な情報ならOKかも。
自己資料@Qiita
Qiita記事の最近の書き始め例
Qiita記事 いいね と views の関係
今年のQiita記事の目標
立ち位置記事百(100 position papers)
「絶対に見逃せない投稿が、そこにはある」か確かめてみた
出力(output)と呼ばないで。これは状態(state)です。
文書履歴
ver. 0.01 初稿 20190210 午前
ver. 0.02 著作権追記 20190210 午後
ver. 0.03 参考資料追記 20190210 夕方
ver. 0.04 タグ等追記 20221031
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.