🍣

公開記事やソースコードを書く際 [revision.4]

2020.12.31に公開2021.08.17に更新

ブログ

規約、ガイドライン

Qiita - コミュニティガイドライン - Qiita:Support
Zenn - Modern Knowledge Base for Developers
note ご利用規約

記事をどこに書くべきか、何を書くべきか、どう書くべきか、の問題
引用：ブログに書くか、Qiitaに書くか（技術系のネタを）

上の観点で一番重要なのは「自分の庭」vs「みんなの公園」という考え方かもしれません。
Qiitaは「みんなの公園」なので、ルールやマナーに従ってみんなが気持ちよく使えるようにしなければなりません。Qiitaのルールやマナーについては以下のページに詳しく書いてあります。最低限、ここに書いてあるガイドラインは守るべきです。

Qiitaは技術が主語の技術記事
Zennは「人が主語の技術記事とアイディアノート」も許容する場合もある
noteは「クリエイター」の発表の場

Qiitaがふさわしい

技術系オンリー
コードの割合が多い技術ネタ
Qiitaは「みんなの公園」で、主役は技術
いわゆるテクニカルライティング的文章

Qiitaコミュニティガイドライン詳細

プログラミングに関する再利用性・汎用性の高い情報が集まる場をつくろう
「プログラマーが興味を持つものではなく、プログラミングに関する記事を投稿しましょう。」、この表現は結構難しい。

ソースコードの割合が多ければわかりやすいが以下例はどうか

ソースコードの読み方
レビューの仕方
チームビルディング
読書記録
動画の視聴記録
イベントの開催報告

このあたりになるとどこまでが許容範囲でどこからがアウトかが結局の所、読み手次第にもなってくる。そうした場合、よりどころとすべきは、どこまで自分がこのガイドラインを「誠実」に考えて記事を書いたか、説明できるかになってくる。

「コミュニティガイドライン」

エンジニアにとって再利用性・汎用性の高い情報が集まる場をつくろう

Qiitaを利用する際には「HRT」を大切にしよう

エンジニアにとって再利用性・汎用性の高い記事を書こう

Qiitaで記事を公開するときに気を付けるべきマナーについて〜無断でネットや書籍の内容を丸写しするのはやめよう〜も一読。

個人ブログがふさわしい

noteやzennというサイトもあるので厳密には区別しづらいが、一旦Qiita以外とする

まったく技術系でない話（子育ての話とか音楽の話とか）
技術系だけどコードの割合が少ない話
ブログは「自分の庭」なので、主役は自分自身
PV（閲覧数）の面では若干不利（めちゃくちゃ有名なブロガーでない限り）
いわゆるクリエイティブライティング的文章

まよったら

Qiitaのいろいろランキング2020 等、いい記事とは何なのかを見る。
Difference between Technical Writing and Creative Writing
事実を書いているか、意見を書いているか、というところで自己批判してみる。

GitHub規約、注意点

ライセンス・著作権

著作権に気をつける
 著書や人のブログにまつわる記事を書くと著作権違反になる？
ライセンスをつけないとどうなるの？ (Github)

翻訳

記事作成に翻訳ツールを利用する際の注意
海外サイトの無断翻訳時に想定されるトラブル

を考えたときに、ご本人の許可を尋ねるならこのような感じ。

Hello!
I find your article very interesting.
Could I translate it into Japanese and post it on Qiita (https://qiita.com/(My ID or someURL))?
It is one of the most popular platform for Japanese developers (over 7 million users per month).
I will link to your article/profile page too.

本の要約

宣伝行為

宣伝行為、記事の線引きなど、コミュニティガイドラインについての補足説明
 LGTMについて

その他話題の、開発が知っておくと良い知識

Fork

fork する意味

貢献を意図していないにもかかわらず、オリジナル・リポジトリを fork した場合、オリジナルの開発者に貢献の意思があると誤解されることがある。注意が必要だ。

リポジトリが削除されたり可視性が変更されたりするとフォークはどうなりますか？

パブリックリポジトリをプライベートリポジトリに変更する
パブリックリポジトリを非公開にすると、そのパブリックフォークは新しいネットワークに分割されます。パブリックリポジトリの削除と同様に、既存のパブリックフォークの 1 つが新しい親リポジトリとして選択され、他のすべてのリポジトリはこの新しい親から分岐されます。後続のプルリクエストは、この新しい親に行きます。

言い換えれば、パブリックリポジトリのフォークは、親リポジトリが非公開にされた後も、独自の別のリポジトリネットワークで公開されたままになります。これにより、フォークオーナーは作業を中断せずに作業を継続できます。このようにパブリックフォークが別のネットワークに移動されなかった場合、それらのフォークのオーナーは適切なアクセス許可を取得してプルする必要があります。以前はこれらのアクセス権が必要ではなかったとしても、(現在はプライベートになっている) 親リポジトリからの変更を取得して送信します。