新たにQiitaに参加された方も、Qiitaのご意見募集中の場所で意見して見ると、記事書き込みの敷居が低くなるかもしれない。
あるいは、意見募集中の技術内容に関しtえ、この記事のように、何か記事を書いて見るといいかもしれない。
新人プログラマ応援 あちらのDiscussionで、「タグの名寄せ」ご意見募集中らしいから意見をDiscussionに書いてみよう。
or
新人プログラマ応援 あちらのDiscussionで、「タグの名寄せ」ご意見募集中らしいから自分の意見を記事として書いてみよう。
あちらのDiscussionで「タグの名寄せ」ご意見募集中
こちらのDiscussionで、タグの名寄せのリクエストをいただいています。
#80 (comment)
現在、Qiitaはタグの名寄せの明確な方針がないため、毎回どのタグをどのタグに名寄せをするのかの判断に悩んでおります。
タグについては、運営が意図的に寄せることをあまりしたくないので、方針を決めてそれに沿っていきたいと考えています。
今回、名寄せの方針を考えてみましたので、確定前に皆様にご意見をいただきたいです 🙏
前提: タグの名寄せとは
C , C言語 のようにタグが複数に分かれているものを C に統一して記事に紐付け直すことを名寄せと呼んでいます。
名寄せをすることで、タグで調べた時に見つけやすく、書き手としても見つけてもらいやすくなります。
タグの名寄せ方針
Qiitaではタグの名称を自由につけることができるので、基本的に運営主導で名寄せをすることはあまりしません。
ただし、以下のような時に名寄せをすることがあります。
明らかな誤字のとき (Rails/Ralis)
caseの違いだけのとき (common-lisp/CommonLisp)
英語と、読みをカタカナにしているだけとき (network/ネットワーク)
C#等の記号を含むとき
先頭に#や、末尾に,がつくとき
これらの時に、今までは概ね記事数の多い方に寄せていたのですが、判断が難しいものも出てきたので、今後は以下のようにしていこうと考えています。
明らかな誤字のとき (Rails/Ralis)
→ 誤字をしていないタグへの名寄せ
caseの違いだけのとき (common-lisp/CommonLisp)
→ 公式サイトを見て正しそうなもの。ただし、 Common Lispのようにスペースがあるものはスペースを削るだけの方を優先
英語と、読みをカタカナにしているだけの英語のとき (network/ネットワーク)
→ 片方があまり存在せず、記事数に大差がついているときは多い方へ揃え、どちらも多い場合は 英語 に揃える
C#等の記号を含むとき
→ csharpのように置き換える
先頭に#や、末尾に,がつくとき
→ 削除する
これは既存のタグを自動的に名寄せするというよりも、判断の軸として使う想定で、今の所既存のタグを自動ですべて名寄せする予定はありません。
ご意見をください 🙇
皆様のご意見をもとに方針を決めていきたいと思います。
もしタグを決める時に、こう考えているなどもありましたらご意見ください！🙇
経緯
現状では名寄せだけにまず絞って処理したいらしい。
ひとまず方針に沿って記述する。
＃文字のついたタグ
タグのつけ方が最初は分からず編集リクエストをいただいたことがある。
＃をつけたタグを受けつける時点で、Qiitaのシステム設計の問題だと思った。
Qiitaのシステム設計をやり直したいなと思った。
タグ事例
Wi-Fi
Wi-Fiの記事を100以上書いている。
Wi-Fi AlianceよりもIEEEの規定で仕事をしてきた。
「Wi-Fi」という表記が正式だということを意識せずに「WiFi」と書いていた。
これはまずいと、自分の記事は、本文とタグの両方を書き直した。
しかし、全体で見ると、
Wi-Fi 205
WiFi 425
どうしよう。
「Wi-Fi」の記事の「Wifi」「WiFi」綴りを訂正。無線網（Wi-Fi）空中線(antenna)(205)
自分の記事だけ直して、他の人にはコメントしないことにした。
システムによっては、Wi-Fiという変数とか、表記とか認めないことがあると、WiFiとか、Wi_Fiとかの表記を使うことがある。QiitaにはQiitaの制約があっても構わないと思う。
私はWi-Fi Allianceの回し者ではなく、IEEEの回し者で、普段はIEEE 802.11という表記で仕事をすることの方が多い。たまたま、QiitaではIEEE802.11よりもWi-Fiの方が親しんでいる人が多いという市場分析に基づいて、Wi-Fiと表現している。
ISO/IEC JTC1
情報技術の国際企画は国際標準化機構(ISO)と国際電気会議（IEC)の合同技術委員会JTC1; joint technical committee oneで行う。規格番号はISO/IEC 15504のような感じである。
/がタグとして使えない。ISOIECとするかどうか。人によってはIECを省略している人がいる。
情報技術以外だと、ISOだけでよいのだが、、、。
ISOIECという団体はない。続けてかいても見分けはつくだろう。
JTC1側の中の人です。ISOの中の人でもIECの中の人でもない。どちらかでいいという発言はできない。
意見
基本的にシステム側の提案に何も付け加えることはない。
なぜ、記事書いているかというと、一つはWi-Fiにまつわる自分の経験を記録したかった。（第一者）
もう一つは、Qiitaが、タグについて周知してもらおうとしていうのなら、記事も何かあってもいいじゃないかという趣旨。（第二者）
そして、社会全体の中で、いろいろなシステムの名札問題というのは、いろいろ起こりうる。
どういう仕組みが、世の中に有用かを考えたり、行動したりするきっかけを作れないかという意図がある。（第三者）
名前空間は設計(design)である。誰が、どういう意図で、どう作るかで、効率的にもなる。
データ中心設計の邪魔をしないようにもできるかもしれない。
どういう提案をすると、Qiitaに技術者が集まりやすいかという方針で名前空間を考えればいいかもしれない。
名寄せは原則的に賛成である。
「@torifukukaiou 【毎日自動更新】データに関する記事を書こう！ LGTMランキング！」ありがとう。
@kaizen_nagoya
で
【毎日自動更新】データに関する記事を書こう！ LGTMランキング！
への謝辞を書かせていただいた。
タグの順位をつけてくださっている。
順番に確認していったら、自分がつけたタグなのに、大量に自分がfollowしていないことに気がついた。
こりゃいかんってなった。
自分ではやらないことを、誰ががしてくださると、自分の行動の軌道修正ができる。
タグも、いろいろな使い道があり、市場分析をされている方なら、いろいろなご意見もあるだろう。
これを機に、Discussionに意見を書きにいかれるのもいいだろう。
自分の記事に意見を書くのもいいだろう。
まとめに代えて
新人プログラマ応援 - みんなで新人を育てよう！
今、Qiitaでは、「データに関する記事を書こう！」という行事をやっている。
この文章は、テーマ2『データに関する記事を書こう！』参加記事でもあります。
いくつかの事項は、データを取ってから追記できればいいかもしれない。
あるいは、お手持ちのデータがありましたらコメントいただけると幸いです。
自分の頭で考えることが大事なのではない。
何か行動すれば、必然的に、自分の頭で考えなくてはならないところに追い込まれる。
自分の頭で考えるようになるには
「自分の頭で考える」ということ。
行動して、測定すればいい。
ぼくの先生「人がやらないことをやれ」プログラマになるまで。仮説（37）
小学校の絵の先生には、色を置いてみるという試行錯誤を教わった。
中学校の技術の先生には、人がやらないことをやれと教わった。
考え方など教わらなくてもいいのだ。
行動すれば、その責任は自分で考えて、よりよくするのが試行錯誤で、人がやらないことをやった人が考えることかも。
DoCAP 芸術でも技術でも運動でも
参考文献
@kojimadev 1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開
@torifukukaiou【毎日自動更新】新人プログラマ応援 - みんなで新人を育てよう！（2022年04月） LGTMランキング！
@torifukukaiou 【毎日自動更新】データに関する記事を書こう！ LGTMランキング！
@kazuo_reve 「新人の方によく展開している有益な情報」の中で大学時代に得ておけばよかった情報
@kazuo_reve 私が集めた有益な情報・知識のまとめ
@kazuo_reve 私にとって有効だった学び方5選
@kazuo_reve 自分のQiitaの記事を分析してみた
@kazuo_reve 私が効果を確認した「小川メソッド」
@e99h2121 育児していたからこそエンジニアのお仕事に役立ったこと10選
@e99h2121「女性こそエンジニアになるべきだ？」デブサミウーマン登壇記録
@e99h2121 新人さんにすすめる有益なツール達 2022春
@e99h2121 新人さんにすすめる有益な技術書達 2022春
@ohakutsu 新卒1年目のエンジニアがQiitaの速度改善をした話
@ohakutsu 新卒2年目から見た達人プログラマーの振る舞い
自己参照
ソースコードを読むための技術: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１）
スペックアウト手法: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（２）
変更の影響範囲を特定: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（３）
質問は恥ではないし役に立つ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（4）
質問するときのパターン・ランゲージ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（5）
「できない人」ほど、人に聞けない: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（６）
分からないをすぐ伝える: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（７）
15分ルール: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（８）
検索の仕方: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（９）
エラーメッセージの読み方と対処: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（10）
Google検索のコツ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１1）
新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（12）
日報、週報、月報、年報: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１3）
新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１4）
分報（分単位報告）: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（15）
分かる: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（16）
わかったつもり: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（17）
開米瑞浩 図解: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（18）
要求仕様: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（19）
SE用語: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（20）
文章の推敲: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（21）
結城浩 数学文章: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（22）
結城浩 推敲: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（23）
あいまい表現: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（24）
やまとことば: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（25）
鍵語による見直し: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（26）
開米瑞浩 MECEとロジックツリー: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（27）
芝本秀徳 考える: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（28)
佐藤航陽 論理: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（29)
清水吉男 設計: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（30)
「@kazuo_reve 新人の方によく展開している有益な情報」はじめ記事を参照して頂いた時にしていること。
@kazuo_reve「「新人の方によく展開している有益な情報」の中で大学時代に得ておけばよかった情報」に付け加える3つのこと。
プログラマにも読んでほしい「QC検定にも役立つ！QCべからず集」
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20220410
ver. 0.02 ありがとう追記 20230504
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.