プロジェクト‐ノート:カテゴリ関連

このノートの過去ログ

• 過去ログの一覧
• /ログ0001 - 正規運用開始 / カテゴリ独断作成禁止提案 / ユーザーボックス提案 / 活動目標 / 作成予告 / 機能上の制約
• /ログ0002 - 削除依頼の参加者層 / 思いつきメモ / 「参加が求められている関連議論」の掲載期間 / 同節の分割提案 / ソートキーのルール / 各プロジェクトのカテゴライズルールの一覧作成提案 / カテゴリ「科学」を「学問」のサブカテゴリにする提案 / カテゴリの削除依頼を通常の削除依頼から分離する案に関する意識調査 / Catlinkテンプレートの作成 / プロジェクト名前空間の新設 / 「/カテゴリの命名規則」の新設 / 古い案件の除去 / 「参加が求められている関連議論」のサブページ化 / 「未使用のカテゴリ」の運用ルール / カテゴリの大幅改変に関する方針の修正提案 / 同方針に「告知場所」の例を追加する提案 / 建築物カテゴリ / 曖昧さ回避の括弧付き人物の冠カテゴリ名 / 英国の王族・貴族カテゴリ / 各国の男優・女優カテゴリ / LGBT作品カテゴリ / 歴史区分カテゴリ / 日本の地方区分カテゴリ / カテゴリを集めたカテゴリ / 浮世絵師カテゴリ / 美術関連カテゴリ / 「カテゴリ関連」カテゴリ / ○○別に分類したカテゴリ / 王朝カテゴリ / 自らの名を冠したカテゴリ / 「ユダヤ教・ユダヤ人を題材とした作品」カテゴリ / 目録カテゴリ / カテゴリの削除の方針 / カテゴリの方針の全面改訂 / 任意のカテゴリの「カテゴリ変更」履歴の調査方法

このノートページは、ウィキペディアのカテゴリ全般に関する議論・提案や、当プロジェクト自体に関する議論・提案などにご利用ください。特定カテゴリの個別的な議論はプロジェクト:カテゴリ関連/議論で、特定のカテゴリ系統の階層構造の整理に関する議論はプロジェクト‐ノート:カテゴリ関連/議論で、それぞれ提起するようにしてください。

カテゴリ荒し対策（井戸端の話題）

井戸端でカテゴリ荒し対策の提案が出ていますのでお知らせいたします。 Wikipedia:井戸端/subj/カテゴリ作成に一定の制限を設ける提案　--RnTkm（会話） 2023年3月3日 (金) 13:39 (UTC)

Wikipedia:井戸端/subj/カテゴリ作成に一定の制限を設ける提案 の

2番のほうは感謝の数に応じて開けるという方法を思い付きました

どうでしょうか--Knowifr（会話） 2024年3月3日 (日) 06:28 (UTC)

議論の告知: 削除を繰り返すカテゴリページの作成保護

Wikipedia‐ノート:保護の方針#削除を繰り返すカテゴリページの作成保護にて提案中です。カテゴリ全般に関わることであるため、こちらにもお知らせしておきます。--Doraemonplus（会話） 2023年4月27日 (木) 12:40 (UTC)

井戸端の話題の告知: カテゴリの提案・議論の場所を一箇所に集約しませんか？

表題のとおり、Wikipedia:井戸端/subj/カテゴリの提案・議論の場所を一箇所に集約しませんか？を立ち上げました。カテゴリに関心がある皆様のご意見・ご所感をお寄せください。--Doraemonplus（会話） 2023年6月13日 (火) 23:38 (UTC)

カテゴリの機能改良の要望を財団へ提出する案について

昨年、Wikipedia‐ノート:カテゴリの方針#方針の改定提案（2022年10月）を経て、クラスカテゴリ（オブジェクトカテゴリ）とテーマカテゴリ（トピックカテゴリ）の概念が同方針文書に導入されました（両概念の説明はリンク先を参照のこと）。これは、英語版の set category および topic category 、独語版の Objektkategorie および Themenkategorie に倣ったものです。

実際の運用例として、英語版においては、テーマカテゴリであるCategory:Operaと、クラスカテゴリであるCategory:Operasを、独語版においても、テーマカテゴリであるKategorie:Personenと、クラスカテゴリであるKategorie:Personを、各々区別しています（英語版と独語版とで、単数形・複数形カテゴリの扱いが逆になっているのが、また興味深いですね）。

しかし一方で、以前、㭍月例祭氏が示されたご見解では、ウィキペディアにおいて現在、カテゴリは事実上、分類目録（クラスカテゴリ的）と件名目録（テーマカテゴリ的）の両方の用途で利用されており、相容れない両者が、同じ「カテゴリ」という機能として同居する形で実装されたのは、MediaWikiのカテゴリシステムの設計上の欠陥なのではないかと指摘されています。

かつて私は独語版を参考に、山カテゴリを実験台として、Category:山をクラスカテゴリに、Category:山をテーマとした事項をテーマカテゴリに、それぞれ分けようとしましたが、失敗に終わりました。英語や独語とは異なり、日本語の名詞は単複同形であること、そしてクロスカテゴリの名辞に用いられやすい助詞の「の」が多義的に解釈可能な性質を持つことなどが相まって、日本語版カテゴリにおける両者の区別は非常に曖昧になっています。

たとえば、第一義的には個々の企業記事（例：トヨタ自動車）を収録するオブジェクトカテゴリとなるであろうCategory:日本の企業に、記事「若者応援企業」や「中小企業庁」のようなトピック的な項目が混じっていたりします。この場合、同カテゴリを「日本の企業」をテーマとするトピックカテゴリと捉えるならば、後者の用法も正当な範囲内です。決して間違いとはいえません。

上述したカテゴリの例から導き出される結論として、たとえクラスカテゴリとして運用することを念頭に作成された（であろう）カテゴリであっても、日本語版においては、すべてのカテゴリがテーマカテゴリの性質を帯びる可能性があるということです。さらに考察すると、カテゴリがクラス型となるかテーマ型となるかは、いちカテゴリ単位で決まることではなく、カテゴリとそれに含まれる項目との一対一の関係性で決まるということが理解されます。先ほどの例でいえば、記事「若者応援企業」から見れば、Category:日本の企業はトピックカテゴリとなるし、同様に記事「トヨタ自動車」から見れば、同時にオブジェクトカテゴリともなるわけです。

したがって、英語版や独語版のように特定のカテゴリを{{クラスカテゴリ}}と{{テーマカテゴリ}}のいずれかに規定して分けようとすること自体、ほとんど無意味なことであると気づかされます。その一方で、このままではカテゴリの運用を巡って、分類派と件名派の競合・対立が発生するおそれがあるため（既に発生しているところもあるが）、双方が納得のいく解決策を見出す努力をする必要は（長期的に見て）ありそうです。おそらく単複異形の欧米言語版のユーザー（および同言語に根差すMediaWiki関連システム開発チーム）は、この問題を認知されていないものと思われます。

この問題が日本語特有のものなのか、同じく「数の区別がない」とされる他の東アジア諸語においてもいえるのかは浅学非才にして存じ上げませんが、この件に関する問題提起と、その解決策となり得る素案を一度、ダメ元でウィキメディア財団のコミュニティ要望アンケートに提出してみようかと考えております。

解決策の一案として、まず同じカテゴリにカテゴライズする記事に対して、オブジェクト項目には青色を、トピック項目には緑色を、というふうに項目1件ごとに色分けしてカテゴライズする仕組みを作ります。そして、両者を区別した上で、色別のフィルターにより、同カテゴリの項目のうち、取り出したい方を絞り込み検索することを可能にするというアイデアを以前に考案しました（参考：過去の拙考）。他に優れたアイデアや、この問題に対するご意見がありましたら、是非ともご提案・ご発表いただきたいです。よろしくお願いいたします。--Doraemonplus（会話） 2023年6月20日 (火) 08:01 (UTC)

• コメント 「㭍月例祭が欠陥だと言った」的に言われるとオドオドしてしまうのですが・・・まあともかく、予てからご指摘のように、「クラス」「テーマ」の2系統（？）が併存しているというあたりに課題がある、と思うんですよねえ。そして現行のシステム的にはそこが解決不能だとも。（私は以前から、ツリー状のカテゴリと、不定形のタグの2種類があればよかったのでは、と考えています。）
• 単数形複数形のところに帰趨するというのは、正直よくわかりませんが、なるほどそういう考え方もあるかと思いました。
• 日本語の「の」の多義性というのも、予てからあった話と思います。「学校of東京都」（性質として東京都に属している＝東京都立の学校）と「学校in東京都」（場所として東京都内に位置している学校）のどちらもが「東京都の学校」になってしまうということ。
• あとは実際問題、多くの利用者（とLTA）が、あまり難しいこと・全体像を考えずにカテゴリを弄っているというのもあるんだろうなあと思います。
• 非現実的でほとんど冗談みたいな話ですが、「カテゴリ編集者」みたいな権限を持たない人はカテゴリを触れないようにするとかね。資格がないと[[:category:○○]]部を投稿しようとするとエラーを返すとかね。--柒月例祭（会話） 2023年6月20日 (火) 09:49 (UTC)

  @㭍月例祭さん 引用の仕方が少々雑で困惑させてしまい申し訳ないです。と同時に、舌足らずを補って頂けて非常に助かります。

  • カテゴリ項目の色分けを実現するにはソフトウェアの抜本的な改修が必要で、そのコストを考慮すると、あまり現実味がなさそうです。それに、色分けによる方法では、同一カテゴリ内でオブジェクト項目とトピック項目が混ぜこぜの状態のままです。このため、特にカテゴリの階層構造に不整合が生じ、PetScanやdeepcat:の効能を十分に引き出せないのがデメリットです。
  • 他の解決策としては、Category名前空間と同等の機能を持つ名前空間を新設して件名型のカテゴリをそちらに移す方法と、システムはそのまま弄らずに分類型のカテゴリにだけ特殊な接頭辞「分類:」を与えて件名型のカテゴリと区別する方法との2パターンが考えられます。
  • 名前空間の新設に関して、カスタム名前空間は標準名前空間と同じ機能しか利用できないらしいので、必然的にグローバル仕様のCanonicalな名前空間の新設をMediaWiki側に要望する形になります。その場合、Semantic MediaWikiとの関連も考慮に入れる必要がありそうです。実現するには、色分けと同じくソフトウェアの改修が必要ですが、Category名前空間の技術を転用可能な分、技術的なハードルはさほど高くないと思われます。ただし、例示されている「東京都の学校」のような日本語の問題を英語で説明して、新名前空間設置の意義を理解してもらえるか微妙なところです。
  • もう一つの、システムを弄らない方法の場合は、たとえば、形式的には「日本の企業」を件名カテゴリとした上で「日本の企業⊃分類:日本の企業⊃トヨタ自動車」といった包含関係を取ります。システム上は、英語版や独語版において名辞の単複で区別している方法とほとんど変わりないです。ただし、システムの改修が全く不要な反面、従来Wikipedia:カテゴリの方針が「分類」を第一義としてきた方針を「テーマ」を第一義とする方向へ大転換する必要があり、しばらくの間混乱を招きそうです。また、カテゴリ名が自然語でない点が、一般利用者にとっては取り扱いづらい気がします。
  • 名前空間を新設する場合、特定のユーザーに編集権限を与えないようにする規制は容易でしょう。しかし、私はカテゴリ編集権限の創設には消極的です。少数の人たちで管理すべきとは思わないためです。カテゴリの編集は（まともにやろうとすれば）途方もなく手数の要る作業なので、取り扱える人員は多い方が助かります。それよりも「適正な」カテゴリ利用法を啓蒙・普及させる努力が優先課題と考えます。それもプロジェクト:カテゴリ関連がトップページで掲げている役割の一つだったかと存じます。LTA対策は別途検討しましょう。

  --Doraemonplus（会話） 2023年6月21日 (水) 09:09 (UTC)

いろいろ書いていると、発散してきたので、英語版での事例の話と、提案に対するコメントの話を分けて書くことにしました。まずは、英語版のWikipediaの話です。

• 英語でも同じような問題はあります。例えば、Category:Constitutions (憲法典)には、具体的な憲法典だけでなく、en:Wiki-constitutionalism といった派生の概念の記事や、en: Constitutional amendments （憲法改正）といったカテゴリが所属しています。これらの記事やカテゴリに属する記事は憲法典の具体例ではありません。ただし、面白いところは、The main article for this category is Constitution. となっていて、このカテゴリが両者が混じっている可能性があることが想像できるというところでしょうか。おそらく、全体としての一貫性を保つためには、Constitutionというカテゴリを作って、Constitutionsをこれらのページとともに、Constitutionに所属させるのが綺麗なように思います。そうなっていない理由を想像すると、Wikipediaのページ作成に関する基準から、所属するページの少ないカテゴリは作成しないというルールが働いているのではないかと考えます。このルールはいろいろなところで適用されていて、カテゴリ周りの問題としては、例えば、Category:東京都の大学の下に、特定の大学のカテゴリが作成されずに、Category:有明教育芸術短期大学の教員‎ やCategory:有明教育芸術短期大学出身の人物‎ といった特定の大学のカテゴリのサブカテゴリとしてふさわしいようなカテゴリがつながるという例があります。整合的な分類とする場合には、有明教育芸術短期大学 というカテゴリを作ることが推奨されるのですが、カテゴリ階層の整合性を重視するのか、Wikipediaのあまり役に立たないカテゴリ、ページは作らないというルールを優先するのかで、現在のところ、後者が優先すると判断されているのだと思います。
• その他、英語でも、トヨタ自動車のようなテーマカテゴリの問題を扱っている議論がなされていた形跡を見つけました。en:Wikipedia:Category_typesというページです。ここでは、日本語のCategory:同名の記事を含むカテゴリと同様な eponymous なカテゴリをSubject Categoryとして扱う方法を2007年に提案していましたが、proposalはfailしています。今回のトピックカテゴリの議論とほぼ同じ気持ちの議論のように思いましたが、良いという人と、嫌だという人が両極端という感じの議論が行われていたようです。

--Wcontology（会話） 2023年6月29日 (木) 07:45 (UTC)

以下は、提案に対するコメントです。

• カテゴリがテーマかクラスかという話を主記事と関連づけて考えます。主記事とは、Template:Catmainの説明にあるように、当該のカテゴリに関連のある記事で、「主記事は多くの場合、カテゴリの集合全体について説明します。」と書いてあります。これは、「Category:企業」のようなクラスカテゴリに対する主記事の場合には正しいのですが、「Category:トヨタ自動車」のようなテーマカテゴリにおいては、主記事は、集合全体を説明するものではないように思います。そのため、前者では、主記事に付与して良い上位カテゴリがそのカテゴリに属する記事の集合全体に付与しても良い場合が多い（上記の憲法改正のような例外もある）のにたいし、後者では、必ずしもそうはありません。
• このことは、カテゴリ階層に大きな問題をもたらしています。基本的なポリシーとしては、カテゴリは、カテゴリの集合全体によって特徴づけられ、その包含関係で階層構造を作ることが求められていると基準が示されていますが、テーマに関するカテゴリについては、記事集合を考えるのではなく、主記事が所属するカテゴリによって、階層構造の中に配置されることになってしまっています。そのために、トヨタ自動車に所属する記事は、必ずしも主記事から考えた親カテゴリである日本の企業と包含関係が成り立っていません。よって、ご提案のように間に、「分類:日本の企業」といった概念を入れても、「日本の企業⊃分類:日本の企業」と「分類:日本の企業⊃トヨタ自動車」を同時に満たすような「分類:日本の企業」に対応する記事の集合が作れません。どちらかというと、「日本の企業」にたいして、「具体例：日本の企業」のように、カテゴリ「A」にたいして、「具体例：A」を設定し、包含関係は成り立たないが、「具体例：A」を探すのに、「A」の上位カテゴリは役立つが記事集合の包含関係は成り立たないと考える方がまだ良いかと思います。このことを表現するために、新たな関係を定義しても良いのですが、「具体例：A」と「A」の関係は、通常のサブカテゴリの関係として記述するが、PetScanやdeepcat:では、上記の包含関係が成り立たないことを前提とした処理ができれば、包含関係に起因する問題は減ると思います。ただ、テーマカテゴリ同士の関係なども現在のカテゴリの中には存在して、その中には、包含関係を持つトピック、例えば、アジア→日本→東京都、２０世紀→1980年代→1985年などが存在し、東京都（1985年）に関することは、アジア（２０世紀）などといった包含関係の推移律が成り立つものもあるかと思います。全部を解決するためには、もう少し、場合分けも必要かと思います。

やや、散漫な記述になっている部分がありますので、不明な点などは質問してください。--Wcontology（会話） 2023年6月29日 (木) 09:31 (UTC)

ご回答いただき感謝します。いただいたコメントに関連して所感を述べます。

• 英語版のCategory:Constitutions > Constitutional lawという構造を見ると、この “Constitutions” は「憲法典」ではなく「コンスティチューション」を意味しているとみられます。「コンスティチューション」は「憲法」の上位概念です。ドイツ語のKategorie:Verfassungsrecht > Verfassung、日本語のカテゴリ:憲法 > 憲法典とは言語構造が異なるので、英語独特の構造かと思われます。このようにカテゴリの名辞は各言語に依存します。Category:Constitutionsは本件の例題としては例外の部類に入るかと存じます。
• 「所属するページの少ないカテゴリは作成しないというルール」に関しては、かつて（2010年9月まで）はそのような制限を設けていましたが、現在は廃止されています。近年は、記事を数件しか含まないカテゴリもよく見かけます。有明教育芸術短期大学のカテゴリが未作成なのは、単にカテゴリの構造化が未発達なだけだと思います。利用者の関心が集まれば、いずれ作成されるでしょう。
• 英語版でも「カテゴリの類型」に相当する議論はあったのですね。その提案ページのWikipedia文書化は “failed” となっていますが、そこから派生したtopic categoryとset categoryの両テンプレートは現在運用中であるなど、提案の一部は具現化しているようです。
• カテゴリの用途は三者三様で、パッと思いつくだけでも

カテゴリを

1. 昔のYahoo!のディレクトリ検索のように使いたい（ディレクトリ派）
2. 類似する記事を分類や分野で主題検索したい（クラス＝分類派）
3. 何について書かれた記事かで主題検索したい（テーマ＝件名派）
4. 記事のメタ情報のデータベースとして使いたい（データベース派）

と、少なくとも4つの用途が想定されます。

• ディレクトリ型は、喩えるなら{{Pathnav}}のイメージに近く、

大学 > 各国の大学 > 日本の大学 > 東京都の大学

のように階層化されていますが、分類型と比べて階層構造が単純（複数の上位カテゴリを取らない）で、集合の包含関係と一貫性は意識されません（例）。よって、後述する「東京都の大学」下の「○○大学の教員」に人物記事が含まれることは問題視されません。ただし、全体の一貫性がないため、PetScanやdeepcatを利用して論理検索するには不向きです。

• 分類型は分野ごとに秩序立った階層構造を形成し、類似するページを網羅しているのが特長ですが、専門分野の知識がない人には使いこなせないのが短所です。また、件名型の用途を兼ねているカテゴリの場合、混じっているトピック項目の比率が増すほど、検索精度が低下するのが弱点です。この点において、「東京都の大学」のサブカテゴリ「○○大学の教員」に含まれる記事は「分類:人物」に属し、「親分類:大学」側から見るとノイズとなるため、一般に件名型よりも厳格な分類が要求されます。
• 件名型はテーマごとに記事を探すのに有効です。たとえば、Category:江戸文化から記事「団扇問屋」（分類:江戸時代の商人）や「隅田川花火大会」（分類:東京都の花火大会）を見つけることができます。このように、別々の分類型カテゴリに属する記事をも探し当てられますし、キーワード「江戸文化」で全文検索しても見つけにくい同テーマの記事を見つけられます。欠点は、採録の判断基準が主観的になりやすいこと、また件名は無限に作り出せてしまうため、統制語彙の仕組みが必要なこと、そして分類型を兼ねるカテゴリの場合、同じカテゴリ内で分類の邪魔をしかねない点です。
• データベース型は、極端な例を挙げれば、記事「アルベルト・アインシュタイン」の所属カテゴリのように、生没年、出身地、民族、国籍、職業、所属組織、思想・信条、受賞歴など、様々なメタデータが記録されます。この種の詳細なメタデータの登録は、現在では主にウィキデータで取り扱っています。
• 主記事カテゴリ論に関しては、分類型 (set category) では「集合全体」がカテゴリの外延的範囲を規定しますが、件名型 (topic category) では、元よりテーマの「範囲」は曖昧なものですから、集合の包含関係は成立しませんし、成立させる必要もありません。

アジア > 日本 > 東京都

20世紀 > 1980年代 > 1985年

というようなテーマカテゴリ同士の上下関係は、記事集合の包含関係ではなく、カテゴリの名辞（概念）のシソーラス関係で成り立っていると考えた方が的確であろうと思います。ゆえに、テーマカテゴリ同士は全体を意識した多階層構造を取らず、せいぜい一部の件名標目表（LCSHやNDLSHなど）で見られるような上位語・下位語・関連語のカテゴリと隣接した関係で結ばれる程度です。

• 件名型のシソーラス関係でカテゴリを構造化しようとすると、カテゴリ:トヨタ自動車に付与されている記事向けの上位カテゴリを見ても分かる通り、分類型の包含関係による階層構造が滅茶苦茶になります（例：上位カテゴリ:日本の自動車メーカー・ブランドに属するカテゴリ:トヨタ自動車に含まれる、自工程完結やリアル車将棋などの記事は、自動車メーカー・ブランド名に該当しない）。一方で、分類型の包含関係によってすべてのカテゴリを構造化しようと思っても、件名型のカテゴリは分類型のような範囲が明瞭な集合を持たないため、行き詰まることになります（例：カテゴリ:江戸文化に含まれる記事の集合全体について包含関係を見出すのは困難を極める）。
• したがって、分類（クラス）派と件名（テーマ）派が共存共栄するには、いっそのこと名前空間を分けるのが得策ではないかと考えた次第です。以前に提案した色フィルター方式や、お示しの「具体例」方式はシステム改修の開発コストが掛かりすぎることと、一般に普及させるには理論と仕組みが難解すぎることから、現実的な解決策にはなり得ないと判断します。

--Doraemonplus（会話） 2023年7月1日 (土) 02:01 (UTC)

• （感想） Doraemonplusさんの上の発言中の主要4系統をそれぞれ長短を完結にまとめた部分、「カテゴリの用途は三者三様で」から「メタデータの登録は、現在では主にウィキデータで取り扱っています。」あたりまで、Wikipediaのカテゴリの解説（入門編）としてどこかに別掲しておきたい内容ですね。（続く「主記事カテゴリ論に関しては」以降は初級編か中級編。）
• 私もこのJawpのカテゴリの話を何年かちょっぴり首をつっこんでいますが、その何年かのあいだで、もっとも簡潔端的にまとまった解説と思います。--柒月例祭（会話） 2023年7月1日 (土) 04:54 (UTC)

  • ご好評をくださり、嬉しく思います。どこにどういう形で掲載するべきかについては、追々検討したいと考えています。

  --Doraemonplus（会話） 2023年7月10日 (月) 06:06 (UTC)

いろいろ、考えている間に自分の考えも二転三転して、返事が遅くなりました。

• Constitutionsについては、私の勘違いだったと理解しました。複数形の扱いについての例を見ていて、目に止まったのですが、分類としては、ご指摘の通りの理解となると思います。
• 親子関係のあるカテゴリ間の関係についての議論が、ここ数年でだいぶ、現状に合わせる形で英語版でも議論が深まっているようですが、あいかわらず、サブカテゴリの作成基準の説明（WP:subcat）では、１段落目の最初の文で、論理的な包含関係がある場合に推移的な関係（A→B→Cのカテゴリ階層があれば、CはAのサブカテゴリでもある）ということを説明し、２段落目の真ん中の文では、多少の例外は認めるが、基本的には、上位カテゴリに属することを期待することを期待すると説明されています。
• ただ、実際のカテゴリ階層がこのような包含関係に基づくものではなく、@Doraemonplusさんが書かれているように、様々なカテゴリの用途が含まれています。これは、現状追認型の説明として非常に簡潔な説明だと思いますので、これをWikipedia全体としての共通理解にすることが、まずは出発点なのではないでしょうか。
• 歴史的な経緯は適切には把握していませんが、私の仮説は以下のようになっています。
  • Wikipedia特有の概念である分割のためのカテゴリdiffusing subcategoriesの考え方の導入が混乱の契機なのではないかと考えています。具体的には、人物や大学といった大量の記事と対応するカテゴリについては、分割されたカテゴリを統合して扱う必要がでてきました。これは、カテゴリに属している記事の閲覧性という意味では、非常に有用な考え方だったのだとは思います。
  • その影響として、本来もっと広くカテゴリを見たい人にとっては、階層関係をたどらざるを得なくなりました。PetScanやdeepcatは、そのような問題に対応するために作られたという側面もあるかと思います。
  • 副次的な影響として、この分割のための基準を導入するということが、データベース派のようなメタ情報を中心にしたカテゴリの作成を促したのだと考えています。
  • しかし、このSet and Topicの組み合わせという分割の際によく使われるカテゴリは、Topicも親カテゴリとして持って良いという本来の包含関係とやや矛盾したことを許容してしまいました。これにあわせて、Topic的なカテゴリも作られるようになり、Topic的なカテゴリが増えるだけでなく、現在のような混沌としたカテゴリ階層を生み出したのだと思っています。
• このような歴史的にねじくれてしまったカテゴリ階層を再構成するためには、細かな機能要求というのではなく、まず、Wikipediaのカテゴリ階層の問題についての現状認識を共有し、明示的にどう扱うかを議論するというのが良いように思いますが、いかがでしょうか。

--Wcontology（会話） 2023年7月7日 (金) 03:26 (UTC)

• 昨年、カテゴリの方針の改訂文案を推敲した時にも思ったのですが、カテゴリを編集する上で心得ておくべき専門用語が確立されていないことが、カテゴライズの実践上の混乱に拍車をかけているものと思われます。用語の定義が曖昧なままでは議論もままならないです。
• ご指摘にあります “diffusing subcategories” はその代表格です。 “diffusing” は「拡散」と直訳されますが、非常に曖昧な言い回しで、原文でも訳文でも、いまひとつ何を指しているのか分かりづらいです。ちなみに、改訂前の日本語版の方針文書では、「分割として機能するカテゴリ」と訳出されていました。しかし、おそらく英語版のユーザでも、用語の意味を正確に理解している方は少ないのではないでしょうか。
• 日本語版も英語版と状況は似ていて、ご明察のとおり、「分類」と「区分」と「分割」の微妙な違いを弁別しないまま、深く考えずに英語版のdiffusing subcategoriesの考え方を導入してしまったのが、マズかったのだろうと思います。私の解釈では、この3つはそれぞれ、次のようなカテゴリ操作を指します。
  • 「分類」は「博物館」を「歴史博物館」や「科学博物館」などの細分類に分けるカテゴリ操作。“classification”に相当。
  • 「区分」は同一分類「博物館」に属する記事を国別や都道府県別などに区分するカテゴリ操作。“(sub)division”に相当。
  • 「分割」は「分類」「区分」以外にも五十音別カテゴリなど、カテゴリを小分けする操作全般。“diffusing”に相当？
• 例として、Category:日本の企業は当初、企業記事を収めるCategory:企業を国別に区分したSet and Topicカテゴリだったと考えられますが、現在ではご覧のとおり、Category:日本の企業史のようなTopicサブカテゴリが含まれており、国別カテゴリの用途がSet and TopicカテゴリからTopic and Topicカテゴリに変容しています。そして、Topic and Topicサブカテゴリ:日本の企業史には、別のSet and Topicサブカテゴリ:日本の企業博物館が含まれており、分割元のSetカテゴリ:企業は企業記事を分類していたはずが、カテゴリ系統の途中に博物館記事を分類するカテゴリが紛れ込んでいるという混沌ぶりです。これにより、分割元のCategory:企業さえも、Topicカテゴリとして認識されるに至り、Category:日本の企業別の人物などの異なるSetのサブカテゴリが紛れ込むことにより、混沌度が増してしまう悪循環に陥っています。このような歪んだカテゴリ構造を持つCategory:企業をPetScan検索した場合、検索結果に企業ではない記事が大量に混入してしまい、本来ならば役に立つ階層検索ツールも役に立たなくなってしまいます。このようなカテゴリ構造の例は現在、日本語版カテゴリ名前空間のあちこちで見られます。
• 無論、ディレクトリ派やテーマ派にとっては、上記のようなカテゴリ構造は大した問題ではありませんが、それでも分類派やデータベース派が過剰にdiffusingした結果、サブカテゴリ数が膨れ上がったために、せっかく実装されたdeepcatが全く使いものにならない（検索可能なサブカテゴリ数＆階層の深さの上限値オーバー）などの弊害は生じています。このように、各派が同じ名前空間を取り合う現行のシステムでは、互いの利害調整が困難なのは確かです。解消に向けた次の一歩としては、ご提案いただきましたとおり、各派の代表的な意見を伺って、今後のカテゴリ構造をどう改善すべきかの方向性が固まってから、改めて機能改良の要望を検討するという手順で良いかと存じます。

--Doraemonplus（会話） 2023年7月10日 (月) 09:42 (UTC)

@Wcontologyさん、@㭍月例祭さん 7月1日 (土) 02:01 (UTC) 付の拙コメントのカテゴリ4類型に関連して、過去ログを漁っていたら、利用者:Clapon/カテゴリ関連文書/Category intersection#背景 (Background)という、類似する解説を見つけました。他にも、利用者‐会話:Bcjp/WPJ カテゴライズ 立ち上げ準備室#カテゴリとは!など、初期の頃の議論は、カテゴリの概要を理解するために参考になる意見がいくつかありますので、ご紹介しておきます。--Doraemonplus（会話） 2023年8月6日 (日) 01:31 (UTC)

• 「分類」「区分」「分割」といった、厳密な定義・専門用語としての訳語について、なるほどと思いました。こうした語は、厳密な定義による専門用語としてではなく、ふつうの語としても用いるので、対話のときに混乱や誤解を生じることがあるでしょう（Jawpでも、「特筆」「特筆性」という語でそれがみられます。）。なので私はいっそ、Jawpでしか見られないような語・表現にしてしまったほうが、そういう用語の解釈をめぐる齟齬みたいのを防げるのではないかなあと思います。冗談みたいですが「クラカテゴリ」「デビカテゴリ」とかね。--柒月例祭（会話） 2023年8月6日 (日) 03:53 (UTC)

  @㭍月例祭さん 用語の定義の件は全く同感です。同じ言葉でも人によって解釈が違えば議論が成立しませんものね。現在準備中のプロジェクト:カテゴリ関連/議論でも、日別ページの見出し部分に「議論で使用される用語はウィキペディア用語集で説明しています」と記載していますが、ウィキペディアのカテゴリの理解に必要な用語集をWikipedia:ウィキペディア用語集/カテゴリあたりに作成することを構想中です。言語植民地化の回避とでも呼べばいいのでしょうか、カテゴリに関する議論をすべて日本語で理解し賄えるようになれば、英語版など他言語版の動向に振り回されずに済むのではないかと思います。--Doraemonplus（会話） 2023年8月6日 (日) 04:25 (UTC)

  報告 遅れながら、去る8月14日にWikipedia:ウィキペディア用語集/カテゴリを作成したことをご報告申し上げます。特に説明を要するカテゴリ関連用語について掲載しています。--Doraemonplus（会話） 2023年8月30日 (水) 09:03 (UTC)

  作成いただいた用語集、解りやすくてとても良いです。件名カテゴリ/集合カテゴリという名称は、Wikipedia:カテゴリの方針の本文や各種テンプレートでも採用して欲しいぐらいです。--Bit（会話） 2024年3月4日 (月) 16:12 (UTC)|

  Wikipedia:カテゴリの方針#カテゴリの類型に出てきます（別名で）。--FlatLanguage（会話） 2024年3月4日 (月) 16:26 (UTC)

  というかプロジェクト:カテゴリ関連/議論/2024年/2月3日#Category:インド・ヨーロッパ語族で誘導してますね……--FlatLanguage（会話） 2024年3月4日 (月) 17:03 (UTC)

  ご好評いただき恐れ入ります。方針の改定時と用語集の作成時で、私自身のカテゴリに対する理解が変化していまして、こうした用語の乱立は理解の妨げとなるので、いずれ整理が必要かもしれませんね（どちらかというと方針側）。--Doraemonplus（会話） 2024年3月5日 (火) 12:37 (UTC)

  ちなみに、{{クラスカテゴリ}}と{{テーマカテゴリ}}も作成済みです。といっても、ほとんどのカテゴリは両者を兼ねていますので、現時点では、あまり使用されてはいませんが。--Doraemonplus（会話） 2024年3月5日 (火) 12:44 (UTC)

（半年以上前のDoraemonplusさん 2023年6月20日 (火) 08:01 (UTC)」への返信です）

システム上で名前空間のレベルで分ける、という案に賛成です。

「色で分ける」というアイデアを発展させて、以下のような案はいかがでしょうか。

案：

Category:日本の企業に貼るカテゴリのソースコードは例えば以下のような雰囲気で(※実際の記法は要検討)表記できるようにし、

• Category:relatedto:日本 とか Category:関連:日本
• Category:memberof:企業, Category:partof:企業, Category:belongto:企業 とか Category:一員:企業, Category:構成要素:企業, Category:所属:企業, Category:分類:企業など

これをソフトウェアの方で処理して、実際の表示は

• テーマ: 日本
• カテゴリ: 企業 または 分類: 企業

のようにします。（もちろん、文字での区別に加えて、色を変えても良いでしょう）

実際のリンク先カテゴリページと、その中での「日本の企業」の表示は以下のようにします。

• Category:日本 - 関連カテゴリ欄に「日本の企業」
• Category:企業 - サブカテゴリ欄に「日本の企業」

こうすることで、旧方針で作られたカテゴリのツリー構造の多くを維持したまま、完全な集合・要素(補集合)の関係が成り立つように整備が可能となるのではないかと思います。

Doraemonplusさんの仰るように、カテゴリ自体に対してテーマとかクラスという属性を持たせても効果は薄く、むしろカテゴリ-記事間、カテゴリ-カテゴリ間の関係性に対してテーマかクラスの属性を持たせる方が問題の解決には有用である、と考えての上記の案となります。--Bit（会話） 2024年3月9日 (土) 16:52 (UTC)

返信 (Bitさん宛) 「雰囲気」として、よい感じだと思います。以前、国立国会図書館の件名作業指針を参考にしたカテゴリ関係論をプロジェクト:カテゴリ関連/資料/件名語を用いたカテゴリ構造の事例集で書いたことがあります（よければご覧ください）。もちろん、ウィキペディアのカテゴリとNDLSHは取り扱っているものが異なるので、あくまで「参考」ですが。

新案については、旧来のカテゴリ体系を維持しつつシステム改良するというところがミソですね。memberof, partofなどのオントロジー関係については、私は畑でないですが、このセクションで何度も登場されている、その名もWcontology氏がお詳しいので、もしまだ氏がウィキペディアでご活動されているようでしたら、再びご参加いただけると、さらに議論が発展するのではないかと存じます。その際は（ここではなく）新規のセクションを立てて議論を行っていただくのが適切かと存じます。--Doraemonplus（会話） 2024年3月10日 (日) 07:59 (UTC)

ご提案のように、新規のセクション　プロジェクト‐ノート:カテゴリ関連#子カテゴリ・記事に対するカテゴリの役割付与について　を立てて、私の考えを記しました。コメントなどいただけると幸いです。--Wcontology（会話） 2024年3月12日 (火) 03:13 (UTC)

機能改良に頼らない解決策の再検討

上掲の議論から派生して、ソフトウェアの機能改良に頼らず、現行のシステムで実現可能な解決策を再度検討します。

Set型とTopic型の競合は、カテゴリの名辞がクラスともテーマともみなされる場合のみ発生し、テーマとしかみなされ得ない場合では発生しません（例：Category:大学はクラスともテーマとも取れる一方、Category:教育はテーマとしか取れない）。加えて、クラスに分類される記事は通例、地域区分や時代区分などで下位区分されたサブカテゴリに含められ、クラスの最上層カテゴリが直接付与されることはまずありません（例：記事「東京大学」はCategory:東京都の大学に含められ、Category:大学に直接含められることはない）。したがって、Set型とTopic型のカテゴリを弁別すべき状況は、実際のところ、Set and Topic型のクロスカテゴリの場合に限られます。つまり、Set and Topic型のクロスカテゴリの命名形式と階層構造さえ工夫すれば、競合問題に関して一定程度の解決が図れるものと見込まれます。具体的な試案は次のとおりです。

1. テーマとしかみなされ得ない名辞（例：教育）は、テーマカテゴリとして運用する（例：Category:教育）。
2. クラスともみなされる名辞（例：大学）は、親となるカテゴリ（例：Category:大学）をテーマカテゴリとし、下位階層において、個別具体の分類対象を収めるSet and Topic型のクロスカテゴリ（例：Category:日本の大学）と、関連トピックを収めるTopic and Topic型のクロスカテゴリ（例：Category:大学（日本））とを弁別する。{{クラスカテゴリ}}または{{テーマカテゴリ}}を貼り付けて、これを明示し、使い分けを促す。Topic and Topic型のクロスカテゴリは細分化しすぎないことによって統制する。
   1. Set and Topic型のカテゴリ（例：Category:日本の大学）は、同じSet型カテゴリ（例：Category:日本の国立大学、Category:東京都の大学など）のみで下位階層を構成する。
   2. Topic and Topic型のカテゴリ（例：Category:大学（日本））は、Topic型カテゴリ（例：Category:日本の大学で起きた事件）やTopic記事（例：大学全入時代）を含む。
   3. Set and Topic型のカテゴリとTopic and Topic型のカテゴリは、一方を他方のサブカテゴリとはせず、互いに関連カテゴリとしてリンクするに留める（通常は{{クラスカテゴリ}}および{{テーマカテゴリ}}を貼り付けて掲示する）。
3. （Category:各国の大学やCategory:日本の大学 (都道府県別)のようなメタカテゴリの取り扱い方法は要検討事項）

上記の試案に従えば、

• Category:大学
  • Category:各国の大学
    • Category:日本の大学
      • Category:日本の大学 (都道府県別)
        • Category:東京都の大学∋東京大学、慶應義塾大学…
• Category:大学
  • Category:大学（国毎）（仮称）
    • Category:大学（日本）∋教職課程、大学全入時代…
      • Category:大学（日本の都道府県毎）（仮称）
        • Category:大学（東京都）∋東京六大学、四大学連合…

といった階層構造になり、件名系統が分類系統と競合することなく並存可能です。試案にすぎないので穴だらけですが、たたき台として。--Doraemonplus（会話） 2023年7月11日 (火) 09:00 (UTC)

トップページの刷新と議論サブプロジェクトの開設

先般、Wikipedia:井戸端/subj/カテゴリの提案・議論の場所を一箇所に集約しませんか？で意見を募ったところ、個別カテゴリの議論場所の新設に関して賛同が得られたため、独語版de:Wikipedia:WikiProjekt Kategorienを基礎として、プロジェクト:カテゴリ関連/議論を開設すべく現在ページを準備中です。このサブプロジェクトは、プロジェクト:カテゴリ関連#プロジェクトの概要の第一項「カテゴリに関わる情報センター的役割をなし、ウィキペディアでのカテゴリ利用方針の連携を図る」の理念に根差したものです。サブプロジェクトが開設された後には、本プロジェクトのトップページもデザインを刷新することを予定しています。開設準備が一段落し、デザイン案が書き上がりましたら、追ってお知らせします。また、サブプロジェクトの内容に関するご意見・ご質問がありましたら、こちらのノートで受け付けます。--Doraemonplus（会話） 2023年7月23日 (日) 04:46 (UTC)

サブプロジェクトの開設に関連して、Wikipedia‐ノート:Bot作業依頼#「プロジェクト:カテゴリ関連/議論」の開設に伴うBot開発のご相談を持ちかけています。カテゴリ編集のBotサポートに関するアイデアをお持ちの方は、そちら#QueueBotについてへのご助言とご協力をお願いします。--Doraemonplus（会話） 2023年7月23日 (日) 05:31 (UTC) 場所の移動を反映。--Doraemonplus（会話） 2023年8月23日 (水) 14:11 (UTC)

トップページの刷新に関して、当初はデザイン案を提示し、皆様にご覧いただいた上で正式に反映するつもりでしたが、サブページが多数、参照読み込みされており、草案ページから正式ページへの移行が煩雑であるため、予定を変更し、即時正式版への反映となりました。ご了承くださいませ。新デザインに対する改善のご提案は、#トップページのデザインについてで受け付けます。--Doraemonplus（会話） 2023年7月30日 (日) 09:21 (UTC)

 お知らせ プロジェクト:カテゴリ関連/お知らせにも通知しましたが、プロジェクト:カテゴリ関連/議論の準備が大方整いましたので、明日8月1日より、試験運用を開始します。日毎の議論ページをどうぞご利用ください。もし不備・不具合を見つけられた場合は、今後の改善に生かすため、このノートにご報告いただけると大変ありがたいです。よろしくお願いいたします。--Doraemonplus（会話） 2023年7月31日 (月) 09:04 (UTC)

報告 プロジェクト:カテゴリ関連/議論の日別ページ及び今週の議論などのページにおいて，mw:Help:DiscussionTools/jaを有効にする変更を行いました. これにより，返信ボタンの表示，節単位での変更履歴の通知などを行えるようになります. --鏡華（会話） 2023年8月7日 (月) 17:31 (UTC)

報告 Wikipedia:即時削除の方針#カテゴリ6の改定を実施しました。これより、統合に伴ってできる空のカテゴリページの即時削除も可能となります。--Doraemonplus（会話） 2023年8月15日 (火) 05:39 (UTC)

正式運用の開始時期について

節を分けました。--Doraemonplus（会話） 2023年8月23日 (水) 14:05 (UTC)

 お知らせ 来月1日の正式運用開始を見込んで、MediaWiki‐ノート:Sitenotice#「プロジェクト:カテゴリ関連/議論」の告知を提起しました。--Doraemonplus（会話） 2023年8月19日 (土) 10:01 (UTC)

9月1日からの正式運用開始を予定していましたが、#「コマンド取り消しキュー」追加の予告及びテストといった試験的な機能の実装などが続き、当面は運用が安定しないことを考慮すると、期限を定めず時期を延期した方が良い気がしてきました。皆さんはどう思われますか。--Doraemonplus（会話） 2023年8月23日 (水) 10:50 (UTC)

• 関連議論を全部追い切れていなかったり、自身で提起しておきながら/原則の目的の文言を改訂していただき（遅くなりましたがどうもありがとうございました）、まだ熟読し切れず、意見が出来ていなかったりしているので、延期されればいろいろと確認し、もう少しほかの不安要素、問題点なども（あればですが）見つけて安定してから運用開始できるのではないかと思います。延期に賛成です。--柏尾菓子（会話） 2023年8月23日 (水) 12:42 (UTC)

  ご返答ありがとうございます。大事を取って、サイトノーティスの延期を表明しておきました。正式運用の開始時期についても、私の独断ではなく皆様と協議して決めたいと思います。よろしくお願いします。--Doraemonplus（会話） 2023年8月23日 (水) 13:39 (UTC)

削除提案・議論の在り方について

独立した重要な議題なので、小節に分けました。--Doraemonplus（会話） 2023年7月23日 (日) 07:04 (UTC)

（コメント）ここまでの議論を熟読したわけではないので、見当違いなことを言っていたら申し訳ないのですが、プロジェクト:カテゴリ関連/議論が開設されたら、議論の中で削除意見がついているものは、削除依頼を通さずとも削除となるのでしょうか。削除するか否かを含め、すべての提案に目を通すことになるのでしょうか。削除依頼（利用者ページやリダイレクトもそう）はすべての案件が削除か存続かの判断となるわけですが、これはそれ以外の結論の議論もあるのでしょう。すると削除権限のある者が目を通すものが増えませんか。あるいは、ある程度議論がまとまって削除を要する合意の見込みのある案件はWikipedia:管理者伝言板/削除のように、ここをみて対処すればよい、みたいな場所を作っていただけると、対処しやすいと思います。全然対処されなかったら管理者伝言板/削除に掲載する、でもよいですが。--柏尾菓子（会話） 2023年7月23日 (日) 05:44 (UTC)

• @柏尾菓子さん カテゴリの削除処理の一連の流れをどう整えるべきかは、コミュニティでも意見の分かれるところだと思います。英語版では、en:Wikipedia:Categories for discussionにカテゴリの削除処理機構が完全に組み込まれており、削除の提案、審議から削除/存続の対処までワンストップで処理されます。ドイツ語版でも、de:Wikipedia:WikiProjekt Kategorienに削除処理機構が統合されていますが、昨日提出分のde:Wikipedia:WikiProjekt Kategorien/Diskussionen/2023/Juli/22とde:Wikipedia:Löschkandidaten/22. Juli 2023#Kategorienを見比べていただくとお分かりのように、前者が後者の一セクションに組み込まれる形で参照読み込みされています。いずれの言語版も、日本語版の削除依頼のような「依頼＝Request」の形式を採っていません（それぞれ、英語版はen:Wikipedia:Deletion process#Deletion discussions、独語版もde:Wikipedia:Löschkandidaten (deletion candidate) の一部という位置づけです）。
• 管理者・削除者の方々の実務上のご負担を考慮すると、削除意見を含んでいる可能性のあるすべてのカテゴリの議論に目を通していただくのは現実的な方法でないので、日本語版の削除関連機構の歴史的経緯を鑑み、今回新設する提案・議論場所での削除提案における議論と、従来の削除依頼での審議・対処は分けて、それぞれ独立させて行う方法が穏当であろうと、個人的には思っています。いわば「二審制」といったところで、削除の判断は慎重すぎるに越したことはないという考えです。大まかな流れを説明すると、サブプロジェクトでの削除提案の結果、削除する方向で合意形成されたら、従来どおり削除依頼を提出し、再審された後に管理者・削除者が削除または存続の決定を下すという流れになります。したがって、管理者・削除者の方は、従来通り削除依頼ページだけ見張っていていただければ大丈夫かと存じます。この方式であれば、削除依頼提出前の段階で一度は合意形成が済んでいるはずなので、より削除依頼が通りやすくなることが期待できます。また、不必要な削除依頼の提出を減らす効果も少しはあるのではないかと思います。--Doraemonplus（会話） 2023年7月23日 (日) 07:04 (UTC)

  @Doraemonplus:さん なるほど、納得しました。わかりやすい説明をありがとうございます。「二審制」の方法はよいと思いました。--柏尾菓子（会話） 2023年7月23日 (日) 08:12 (UTC)

  • • （肯定的意見）「二審制」は、様々な方向からの意見を募る、審議を慎重にする、それらによって「効力の確固な合意」を形成するのに有効でしょう。デメリットは、めんどくさい・手間や時間がかかる・一審と二審の見解が分かれたときに困る、というのがありますね。まあしょうがない。
    • 「カテゴリを作る」のはあまりにも容易くできてしまうのに、それを整理統合・改名・削除しようとすると手間がかかって、作成と削除のコストが等価でない、というところが困ったところですね。だから乱造系荒らしがつけこみやすいのですが・・・
    • 私が知っている過去の事例としては、Wikipedia:削除依頼/Wikipedia日本語版のガイドラインに反する「著名な」と付くカテゴリ・そのノート・Wikipedia:削除依頼/Category:著名なクマ・Category‐ノート:クマの個体なんてのがありました。事前議論で賛成した方が、削除依頼でも揃って賛成票を投じてくれたら話がもっとスッと進捗したであろうに・・・というふうには思いましたねえ。
    • 管理者的には、削除依頼で事前議論のリンクがあると経緯がつかみやすく、判定の助けになるでしょう。最終的にはクローズする管理者によりけりと思いますけども、たとえば削除依頼では削除1票・存続ゼロだけど、事前議論で削除賛成10票あるみたいな場合では、十分な削除意見があるとして削除決定する、みたいなことはありうると思います。（もっと慎重に、削除依頼の場での意見表明しかカウントしないよという見方もあるでしょう。）--柒月例祭（会話） 2023年8月6日 (日) 07:34 (UTC)

      • 「二審制」のアイデアは元々、以前どこかで例祭さんご自身から賜ったもので、今回ちゃっかり採用させていただきました（笑）手間がかかるデメリットはありますが、一審の削除提案と二審の削除依頼では議論の目指すところが異なるため、さまざまな角度からのアイデアが期待できると思います。
      • それにしても「著名な」系カテゴリは昔からよく論争になりますね。最近でもWikipedia:削除依頼/Category:個別の物体などの例があります。そろそろWP:OCに過剰なカテゴリの事例として掲載してもよい頃ではないかと思います。個々のカテゴリの議論ログが集中的に蓄積されているのが、日本語版では削除依頼サブページくらいしかないので、これまでの議事録に詰まったカテゴリ整理・処分のノウハウが中々、現在あるカテゴリ体系の改善に生かされていないのも課題です。今回の提案でプロジェクト:カテゴリ関連/議論（のサブページ）に（できる限り）すべてのカテゴリ議論を集約しようとしているのも、そういった狙いがあります。
      • ご紹介いただいた削除依頼を拝見すると、普段あまりカテゴリに対して意見を言わない編集者と、普段からカテゴリ問題に熱心な編集者との間で、話が噛み合っていない印象を受けました。また、議論が長引くほど、話がまとまりにくくなる傾向にあるため、短期目標で（議論を）やるのも重要かと思います。カテゴリは他の名前空間ページと違って、実質的な内容が本体ページの編集履歴に残らない分、いかに現在の状態（含まれる記事やサブカテゴリの登録の状態）を常に最善の状態に保つかが非常に重要になってくる部門であると、個人的には認識しています。それゆえ、「カテゴリ関連/議論」では、1週間から1か月の比較的短い期間での合意形成を求めています（期限を迎えた議論は再提出するシステムです）。
      • ただし、「カテゴリ関連/議論」は現在、提案は1カテゴリにつき1カテゴリセクションというルールにしてあります。ご紹介いただいた事例のように、複数のカテゴリをまとめて議論したい場合、この新システムは取り扱いにくいと思われます。en:WP:CFDALLを見ますと、複数カテゴリを1提案にまとめていたりするので、そのようなシステムの方が使いやすいでしょうか。この点について、ご意見がありましたらお聞かせください。

      --Doraemonplus（会話） 2023年8月6日 (日) 14:01 (UTC) 誤記訂正。--Doraemonplus（会話） 2023年8月6日 (日) 14:06 (UTC)

QueueBotについて

Doraemonplusさんが依頼されていた、カテゴリの置換等を自動化するbotについて、実装が完了したためbotフラグの申請を行っています.(Wikipedia:Bot/使用申請#QueueBot). また、現在の実装では空になったカテゴリには即時削除のテンプレートを貼り付けるようになっていますが、運用開始後安定動作を確認した後、削除者権限を取得してBot自身で即時削除を行おうかと検討しています、ご意見などあれば伺いたいです. よろしくお願いします.--鏡華（会話） 2023年7月26日 (水) 23:44 (UTC)

また、プロジェクト:カテゴリ関連/議論の日別ページ作成については既に動作を始めました.

toolforgeの負荷軽減のため、ランダムな時間に翌日分のページを生成するようにしています. --鏡華（会話） 2023年7月27日 (木) 00:13 (UTC)

日別ページ作成の件ですが、プロジェクト:カテゴリ関連/議論/見出しとプロジェクト:カテゴリ関連/議論/日付リンクを用意したことをお伝えし忘れていました。botは動作開始後ですが、まだ利用開始前ですので、今からでもこれらを利用したデザインに変更することは可能ですか？--Doraemonplus（会話） 2023年7月27日 (木) 06:19 (UTC)

まだ下書きレベルですが、サンプルページはこちらです：プロジェクト:カテゴリ関連/議論/20xx年/xx月xx日--Doraemonplus（会話） 2023年7月27日 (木) 06:27 (UTC)

Botの削除権限でカテゴリを削除する案について

別途議論が必要と思われますので、セクションを分けます。

ページの移動（改名）ついでにBotで移動元カテゴリページを削除可とするか否かは、これまでの実践上、Bot運用者によって対応が異なっています（Wikipedia:井戸端/subj/Wikipedia:カテゴリの削除依頼（仮称）について）。即時削除の方針のカテゴリ6を柔軟に適用して削除してくださった方もいれば、削除関連の方針を厳格に解釈して削除してくださらない方もいました。

今回のQueueBotは動作が完全自動化されており、通常のBot作業依頼のようにBot運用者が人の目で依頼の内容を逐一確認するわけではない点を考慮すると、全自動でページの削除まで実行してしまうのは、ちょっとマズいような気がします。他方、削除対象のカテゴリページが数多ある場合は、Botで削除していただければ削除権限保有者の負担が大幅に軽減される利点もあります。このリスクと効果のバランスをどう評価し、QueueBotをデザインするべきかは、管理者・削除者の方々に意思決定を委ねたいと思います。したがって、本件について、Wikipedia:管理者伝言板およびWikipedia‐ノート:即時削除の方針に問題提起しておきます。--Doraemonplus（会話） 2023年7月27日 (木) 07:07 (UTC)

• （コメント）「Bot運用者が人の目で依頼の内容を逐一確認するわけではない」ような運用であれば、削除権限保有者の負担がかかったとしても、「全自動でページの削除まで実行」は行わない方がよいと考えます。現状の即時削除テンプレート貼りつけでも、カテゴリ6が適用できないようなカテゴリにまで貼りつけられて却下することがあります。この依頼でも実は削除の方針に沿っていないような内容だった、というような可能性もあると思い、「Botの削除権限でカテゴリを削除」は反対します（上記「方針を厳格に解釈」寄りの考えです）。その分「削除権限保有者の負担」については、可能な限り対応を頑張りたいと考えます。--柏尾菓子（会話） 2023年7月27日 (木) 07:27 (UTC)

Botアカウントが有する機能「リダイレクトを作成せずに移動する」を使って削除（正確には未作成）されたもののことでしょうか？ この機能はまだ使い道が定まっていないためBot関連の規約に書かれていないはずです。現存の規約を集めて考えると「管理者か削除者が運用者となってBotを動かす」ということになるかと思われます。--Triglav（会話） 2023年7月27日 (木) 08:18 (UTC)

「リダイレクトを作成せずに移動」できなかった場合(移行先のカテゴリページが既に作成されていた場合)に、移行元のカテゴリが空になったらどうしましょうか？という話ですね.--鏡華（会話） 2023年7月27日 (木) 11:38 (UTC)

「Botの削除権限」とは「Botアカウントが所有する削除者権限」ということでしょうか？ であれば当該削除者が人間と同等の確認作業を責任をもってやれると宣言してくれるのなら、セミオートであろうがBotであろうが（削除者の作業という扱いで）問題ありません（もし不安があるのなら削除者申請時に審議してほしい）。削除作業の要約欄は生身同様、丁寧に書き込んでほしく思います。あと即時削除には拡大解釈という考えはないため、対象外のものは正確に取り除いて個別審議に回してください（または即時削除規約の改定。すでに指摘されていますが、WP:CSD#C6が移動機能使用可能になる以前のページも対象になるかどうかをはっきりさせておいたほうがよいと思う）。--Triglav（会話） 2023年7月27日 (木) 15:06 (UTC)

カテゴリの名称移動にこの機能（「リダイレクトを作成せずに移動する」）を適用する場合は、カテゴリページの移動からカテゴリの付け替えを一気に作業する必要が生じます。（個人的には）この機能は記事ページなどの自身が作業したまとめ移動を失敗したときのリカバリー用なのではと推察します（この場合、リンク元・カテゴリの付け替えがない）。--Triglav（会話） 2023年7月27日 (木) 08:47 (UTC) 補足--Triglav（会話） 2023年7月29日 (土) 15:54 (UTC)

反対 　削除者権限をあたえられたBotは、SeitenBot2さんのみですが「、WP:CSD#ファイル1-5による即時削除依頼が出されているファイルの削除にのみ権限を使用します」という限定条件がついています。また。Bot権限では「転送ページを作成せずにページを移動 (suppressredirect)」（赤リンクへの移動は事実上のリンク元削除）ができるとなっています。カテゴリは常に動向把握が重要な分野なのでつねに管理者を通過する手順とするのがいいと思います。--AnakaSata（会話） 2023年7月27日 (木) 10:56 (UTC)

そもそも当botは事前議論が済んだ上で、実際にカテゴリを移動するという合意が取れたもののみ実行するという前提を敷いています.

プロジェクト:カテゴリ関連/キューにて議論が行われた場所が提示されなかった場合、botはその実行をスキップするようになっています.

必然的にWP:CSD#C6が満たされるので、この項目でのみ即時削除を許可する、などの運用は考えられないでしょうか.

移動先のカテゴリが未作成の状況であれば当botは「リダイレクトを作成せずに移動」を行うので即時削除を要しませんが、既に移行先カテゴリが存在している場合は移動ができないため、カテゴリタグの張替えのみを行います.

こうなると移行元カテゴリが残ってしまうので即時削除が必要です.--鏡華（会話） 2023年7月27日 (木) 11:47 (UTC)

「既に移行先カテゴリが存在している場合」、残った移行元カテゴリは、「新しいカテゴリに移動され」（WP:CSD#C6より引用）たものではないので、カテゴリ6で即時削除できません。カテゴリ1の1-3で削除依頼を要すると考えます。--柏尾菓子（会話） 2023年7月27日 (木) 11:59 (UTC)

話を整理すると、名目上は同じ「改名」提案であっても、改名（移動）先のカテゴリページが未作成か作成済みかによって実質上、前者は「リダイレクトを作成せずに移動」による改名に含まれる事実上の削除、後者は含まれる記事とサブカテゴリの「カテゴリ変更」（甲を乙へ統合）後の削除を意味します。そして、カテゴリ6は改名に伴う削除には適用されるが、統合（カテゴリ変更）に伴う削除には適用されないということです。たとえ事前の合意があっても、です。

カテゴリページは通常、百科事典的内容を含まないため、記事ページの削除理由でよくある著作権問題やプライバシー問題で削除されることは稀です。よって、カテゴリページを急いで削除しなければならない事態はそうはありません。カテゴリ6による即時削除も、単に処理手順の簡略化が目的であると考えられます。

QueueBotの一番の目的は、ページの移動だけでは変更されない大量のカテゴリタグを一斉に書き換える単調な作業を機械の手を借りて簡便に実行することです。最初に現役管理者の柏尾菓子さんも仰っているように、ページの削除は面倒でも人の手で頑張るからBotのサポートが得られなくとも構わない、ルール上仕方ないというなら、せっかくの鏡華さんのご提案ではありますが、一般利用者が削除権限保持者にBotの使用を強く勧める動機はないと私は考えます。即時削除タグの貼付だけでも、作業の省力化に十分貢献できると思います。--Doraemonplus（会話） 2023年7月27日 (木) 15:05 (UTC)

メモ：Wikipedia:即時削除の方針のWP:CSD#C6

• 2008-04-19 カテゴリページに移動機能が使えなかった時代にCSD#C6を新設。対象は「新しいカテゴリに移行され」
• 2014-06-20 移動機能が使えるようになり、CSD#C6を廃止。
• 2014-12-07 移動機能用としてCSD#C6を復活。対象は「新しいカテゴリに移動され」。

--Triglav（会話） 2023年7月27日 (木) 16:00 (UTC)

コメント 改名の場合は移動後に{{即時削除|カテゴリ6}}のタグを貼ればよいのですが、統合の場合は現行のWP:CSDに該当する条項がないので、これに対応する何らかの即時削除の基準を新たに追加する必要がありそうです。ちなみに、英語版では、もともと空のカテゴリは即時削除の対象です（en:WP:C1）し、ドイツ語版では、カテゴリリダイレクト自体が「Unerwünschte Weiterleitungen (unwanted redirects)」として同じく即時削除の対象となっています（de:Wikipedia:Schnelllöschantrag#Sonstige Löschgründe）。--Doraemonplus（会話） 2023年7月27日 (木) 23:11 (UTC)

QueueBotが空にしたカテゴリに貼り付けることになる{{即時削除|カテゴリ6}}について、Wikipedia‐ノート:即時削除の方針#カテゴリ6の改定提案で問題提起したことをお知らせします。--Doraemonplus（会話） 2023年7月29日 (土) 00:18 (UTC)

即時削除の方針が改定されない限り{{即時削除}}を貼る挙動はまずいので、現在申請中のbot使用申請が認可された後も方針改定まで稼働開始を見送ります.--鏡華（会話） 2023年7月29日 (土) 00:26 (UTC)

ちょっと考えてみました。

• このツールはこれからのカテゴリ改名およびカテゴリ統合（記事の統合ではない）カテゴリ複製を対象にする
  • 2014年以前の残されたカテゴリは（放置を望まないのなら）別途通常審議によるまとめ削除が相応しい。
• 利用者を絞る必要がある（管理者・削除者なら問題なし。または運用者が全責任を負える範囲で個別に利用者を承認する。この際だからツール使用希望者全員が削除者になるのが一番楽。）
• ツール使用者は、CSDを行使するために事前議論を確認するなどの削除者の真似事するのだから、やはりツール使用者は削除者になっておくべき（運用者に余裕があるのなら、お試しで使わせておいて後ほど削除者になってもらうのもアリ）。

こんな感じ。--Triglav（会話） 2023年7月29日 (土) 15:54 (UTC)

> このツールはこれからのカテゴリ改名およびカテゴリ統合（記事の統合ではない）カテゴリ複製を対象にする

>> 2014年以前の残されたカテゴリは（放置を望まないのなら）別途通常審議によるまとめ削除が相応しい。

賛成 これはそうするほうが良いと思います.

カテゴリの除去については、記入漏れでしょうか、それとも機能に含めるべきでないという主張でしょうか.

> 利用者を絞る必要がある（管理者・削除者なら問題なし。または運用者が全責任を負える範囲で個別に利用者を承認する。この際だからツール使用希望者全員が削除者になるのが一番楽。）

コメント 削除権限が必要になるのは、カテゴリ統合と除去です.

単純な改名及び複製では削除権限が必要ないのに全使用者に権限を求めるのはハードルが上がりすぎる気がします.

また、当botはBot:で始まる節のみ実行するという仕様があるため、プロジェクト:カテゴリ関連/キューを編集する権限があるユーザーなら誰でも実行を止められます.

衆人環視が機能できる環境なため、運用者やキューの追加者に全責任を負わせるという方向で進めるべきかは検討が必要です.

削除に限らずですが、不適切な移動、削除、カテゴリの張替えが行われた場合、それは運用者の責任でもキューに追加した人の責任でもなく、「誰でも止めることができたのに止めなかったあらゆるユーザーの責任」ではないでしょうか.

特定の誰かに責任を負わせることになにか意味があるとは思えません.

> ツール使用者は、CSDを行使するために事前議論を確認するなどの削除者の真似事するのだから、やはりツール使用者は削除者になっておくべき（運用者に余裕があるのなら、お試しで使わせておいて後ほど削除者になってもらうのもアリ）。

コメント 上記の通り、誰でも止められるのでツール使用者が削除者になるべきかはちょっと疑問です.

確かにbotは事前議論の確認を行いますが、それは「人間は一切事前議論の確認をしなくていい」という意味ではありません.

キューに追加された瞬間実行されるならキューに追加する人間である使用者は削除者であるべきという意見もわかりますが、このbotはキューに"貯める"ため、他の人間が精査する余地があります.

(「キューが実行されたということは人間による精査が行われ、問題ないと判断された」という前提を敷きます)

提案では1日2回の実行となっていますが、2回では精査する時間が取れない、1日1回にすべきだなどの提案があればそこは要検討です.

コメントと、ここまでが私の意見ですが、これらは「Botが即時削除を執行すること」を前提としており、「そもそも即時削除をbotが執行するべきなのか」が含まれていません.

「どのようにやるのか」の前段階として「やるのか、やらないのか」の議論が必要です.

即時削除をbotで行えると嬉しいのは誰なのかと考えると管理者・削除者の方々なので、「あったら嬉しい」「なくても困らない、いらない」などの意見をお聞きしたいです.

一般的な即時削除ではCategory:即時削除対象のページから各ページに移動し即時削除の方針と照らし合わせるなど行われると思いますが、同様にプロジェクト:カテゴリ関連/キューをウォッチリストに入れていただき(ここは議論を行う場ではないのでそこまでハチャメチャに通知が飛ぶことはないはずです)、問題がないことを確認していただければ人間の目は通せると思います.--鏡華（会話） 2023年7月29日 (土) 21:43 (UTC)

ざっくりとした意見に対して詳細な解説を付けていただきありがとうございます。失礼しました「除去」機能もあるということですね。

「削除権限が必要になるのは、カテゴリ統合と除去です」に「改名」も付け加えておいてください。前にもコメントしましたがBot権限の「リダイレクトを作成せずに移動する」機能は運用が定められていないため、基本は「作成ののち削除」と同等となります。

復旧作業に対する「あらゆるユーザーの責任」は気になりますが、そこにBotの飼い主も当然含まれているわけで、その比率は最大値であるものと信じております。具体的な数値は詰めません（笑）。

エントリーページへの入力を利用者同士で確認しあう件は了解しました。チェックの具合等は実際の作業を進めて様子をみてみましょう。

利用者同士で確認しあうため、すべての利用者に削除者権限が求められるものではないことも理解しました。ただ、復旧のみならず確認においても削除版を見ることができる削除者権限は作業に有効であるため、このプロジェクトの中から幾人かを「削除者」に送り込んだほうがよいと思っています。--Triglav（会話） 2023年7月31日 (月) 05:48 (UTC)

> 削除版を見ることができる削除者権限は作業に有効であるため、このプロジェクトの中から幾人かを「削除者」に送り込んだほうがよいと思っています

これは同感です.

botのメンテナである私自身も削除版を見れないというのはちょっとまずい気がするので削除者への立候補を検討していますが、私の標準名前空間での編集が25回とコミュニティからの新任をいただくにはちょっと心もとないため、一旦編集回数を積み重ねてからになりそうです.--鏡華（会話） 2023年8月1日 (火) 08:54 (UTC)

• カテゴリ変更（カテゴリタグの付け替え）とカテゴリページの削除操作は切り分けて考えるべきです。QueueBotおよびキューは主にカテゴリ変更を手伝うツールですが、そのパターンは削除の観点から、

1. 「Bot: Cat:Name1をCat:Name2へ」はいずれも、改名・統合のどちらかの場合に該当。
   1. 改名の場合、QueueBotによる「リダイレクトを残さず移動」に伴う事実上の削除。
   2. 統合の場合、QueueBotによる{{即時削除|カテゴリ6}}（改）の貼り付け。
2. 「Bot: Cat:Name1を除去」では必ずName1が空になる。削除依頼での削除合意が適用の要件？
3. 「Bot: Cat:Name1をCat:Name2に複製」では空にならないため、削除・即時削除ともに無関係。

に場合分け可能と見えます。1.と3.は問題ないと考えますが、2.だけ異質な感じがします。

• その理由は、2.の場合、Botが空にした後のName1に削除以外の行き先がないとは限らないからかもしれません。もし削除合意済みであることを前提条件とした運用に限定するならば、このパターンだけは、キューが受理可能な「議論場所へのリンク」を[[Wikipedia:削除依頼/…]]に制限するか、削除権限保有者によって追加されたキューしか受理しない条件にするか、その両方を採用するか、キューの仕様を変更するのがよいように思います。無論、削除以外の行き先がないなら、その必要はないですが。
• この仕組みは、鏡華さんの「削除をbotで行えると嬉しいのは誰なのかと考えると管理者・削除者の方々なので」というご見解に即したものになるでしょう。他のパターンはカテゴリ変更がキューの主たる利用目的であるのに対して、この「除去」に限っては、カテゴリページの削除依頼の審議結果に基づき、削除権限者が目視でページの削除の可否を判断した後で、カテゴリの除去およびページの削除の操作をBotに依頼する、管理者・削除者専用のキューとなります。この方法を採用する場合、即時削除のカテゴリ7として、「削除依頼の審議終了後、管理者・削除者からキューを通じてQueueBotに対し、ページの削除操作の代行が要請されたもの」というような条項を追加することになるかと存じます。

--Doraemonplus（会話） 2023年7月30日 (日) 02:40 (UTC)

• あるいは、何も難しく考えず、カテゴリ除去のキューは単純にカテゴリタグの除去のみをBotに実行させ、即時削除タグ等は一切貼り付けず、ページの削除は通常の削除審議を通して処理する方法でも構いません。ただし、この方法ですと、空になったカテゴリの削除処理が滞った場合、未使用のカテゴリの増加ペースがますます加速することになるので、未使用のカテゴリのこれ以上の氾濫を阻止したい者としては、カテゴリの除去と削除はセットで処理してほしいと個人的には希望します。--Doraemonplus（会話） 2023年7月30日 (日) 03:05 (UTC)
• カテゴリ変更とページの削除は切り分けて考えろ！と言っておきながら、「除去と削除はセットで」は自己矛盾してますね。申し訳ない。頭を冷やして除去キューの主用途が何なのかを考え直すと、ページの削除を前提とした全除去以外では、対象カテゴリが大量の不適当な項目（記事およびサブカテゴリ）で埋め尽くされている場合に、それらを一旦すべて除去（リセット）した後で、改名も統合も削除もせず、適当な項目を追加し直してカテゴリを再利用する目的でも使いそうです。ページの削除が目的なら前言のとおりカテゴリ7が必要そうですが、リセットが目的なら即時削除のリクエスト自体が不要そうです。どちらをメインに運用すべきでしょうかね？--Doraemonplus（会話） 2023年7月30日 (日) 03:32 (UTC)

  デフォルトの挙動は即時削除テンプレート貼付にしたうえでオプションとして貼付しないことを選択できるようにするのはどうでしょう?リセットしたいシチュエーションはそこまで頻繁に起こらないと思います。--プログラム（会話） 2023年7月30日 (日) 06:11 (UTC)

  どちらの用途にも対応できればよいのですが。それに、キューはなるべくシンプルにしたいです。「Bot: Category:Name1を除去」では即時削除タグ付与は省略して、新しく管理者・削除者専用のキュー「Bot: Category:Name1を削除」を設けるのはどうでしょう？管理者・削除者が望めば、の話ですがね。--Doraemonplus（会話） 2023年7月30日 (日) 11:45 (UTC)

  やれと言われたら頑張りますが、特定の行を追加したのが誰なのか(=管理者・削除者によって追加されたのか)をbotが判断するのはちょっと大変なので、あまりおすすめの選択肢ではないですね.--鏡華（会話） 2023年8月1日 (火) 09:03 (UTC)

  • どの権限を持った利用者が追加した行かを判別するのは技術的に難しいとのこと、了解しました。では、削除権限者専用の削除キューの別途作成案は無しということで。ご心配をおかけしました。
  • 一方、除去キューの方の即時削除タグについては、Wikipedia‐ノート:即時削除の方針#カテゴリ6の改定提案でも「（含まれる記事・サブカテゴリの）単純（全）除去は（カテゴリ6の）対象外」と考えており、カテゴリ6での対応はないでしょう。ただし、必要とされる機能かどうかは別として、「（仮）カテゴリ7: 削除依頼で削除合意が得られ、管理者・削除者の要請で実行された除去キュー処理により空になったもの」を別に用意しておいて、除去キューでは既定で{{即時削除|カテゴリ7}}を貼付することにし、即時削除の可否を判断する管理者・削除者側で、実行するか却下するかをご判断いただくという方法ならば、機械的な判別の必要はなく、人間側による対応で実現可能ではないかと考えます（実際にカテゴリ7を執行行使するかどうかはまた別として）。要は、除去キューのみ、カテゴリ6ではなくカテゴリ7（仮）を貼付するという案です。

  --Doraemonplus（会話） 2023年8月1日 (火) 09:40 (UTC) 誤記訂正。--Doraemonplus（会話） 2023年8月1日 (火) 09:52 (UTC)

  「カテゴリの除去」キューでは即時削除タグの貼り付けなどは一切行わず、一定期間不使用のカテゴリについて即時削除の方針を定め、定期処理でそちらを削除する、などのほうが綺麗なのではと感じてきています.

  en:WP:C1、{{en:Template:Db-c1}}のイメージですね.

  > ページの削除を前提とした全除去

  全除去後一定期間中身が追加されなかったとき削除されます.

  > それらを一旦すべて除去（リセット）した後で、改名も統合も削除もせず、適当な項目を追加し直してカテゴリを再利用する目的

  除去後すぐカテゴリに中身が追加されるためカテゴリ削除は行われないです.

  中身の追加を待つまでもなく消されるべきカテゴリは削除依頼に回してもらう、という運用であれば、「全除去で合意し削除待ちだったのに中身を追加されてしまった」なども起きにくいのかな、などと考えているのですがどうでしょう.--鏡華（会話） 2023年8月1日 (火) 09:42 (UTC)

  {{en:Template:Db-c1}} は即時削除タグでした、失礼しました

  ・現在このカテゴリは空であり、このままだと削除される

  ・〇〇での議論に基づき、QueueBotがこのカテゴリを空にした

  ・議論を確認した上で、このカテゴリに追加すべき適切な記事がある場合は追加し、このメッセージを削除してほしい

  という旨のテンプレートを貼り付けることを提案しています--鏡華（会話） 2023年8月1日 (火) 09:49 (UTC)

  • カテゴリの除去キューbot処理については、全く同感です。除去キューでは、即時削除タグの貼付は一切行わない運用でよいと思います。本日09:40 (UTC)付の拙コメントは思考実験の一環として聞き流してください。
  • 一定期間不使用（空っぽの状態）のカテゴリの削除に関しては、以前Wikipedia‐ノート:即時削除の方針#カテゴリ7の新設提案（注：先述した「カテゴリ7（仮）」とは全く別個のもの）を提議したことがあるのですが、その議論を引き継いだWikipedia‐ノート:削除の方針/カテゴリを対象としたケースの追加の提案#提案：カテゴリに対する削除の方針の追加共々、根強い反対に遭い、（即時）削除の方針化には至っていません。en:WP:C1が認められているのだから、ja:でも認められてよいはずだと思うのですが…。実は、この議論サブPJの開設を思い立ったのも、放置されたまま一向に処理されず現在も増え続ける一方の未使用のカテゴリを少しでも減らしていく起爆剤にしたいという願いも動機の一つであったりします。

  --Doraemonplus（会話） 2023年8月1日 (火) 11:42 (UTC)

  「全除去で合意し削除待ち」の状態とは、「削除提案で項目の全除去が合意され、削除依頼の提出待ち」と解釈できるでしょうか。カテゴリ変更（項目の追加・除外）のフォレンジック（追跡調査）は過去30日以内が限界なので、削除依頼の審議は全除去後30日以内に済まされるべきであると思われます。未使用カテゴリの削除方針の件は、後日Wikipedia‐ノート:削除の方針で別途提案・議論しましょうか。--Doraemonplus（会話） 2023年8月2日 (水) 00:00 (UTC)

情報 WP:Bot/使用申請にて、botフラグ付与にあたってBOTによる移動機能の使用についての合意を確認されています.

議論が複雑になってきていますが、一旦

• 即時削除テンプレートの貼付け

→即時削除の方針改定まで見送り 即時削除の方針の正式改定後実装

• 「リダイレクトを使用せずに移動」

→1カテゴリ→1カテゴリの、統合などを含まない単純な改名の場合に使用

について合意を取りたいです.

「リダイレクトを作成せずに移動」について、"作成せずに移動"なので削除ログが残ることはない(削除者・管理者でないと閲覧できない削除版は存在しない)ため、プロジェクト参加者で適切に精査を行えば適切な運用ができると考えています.

削除者権限を要する即時削除や長期間未使用のカテゴリ削除などについては種別Gとなり別に申請を要するため、この部分については別で議論を続けましょう. -鏡華（会話） 2023年8月6日 (日) 06:10 (UTC)

Wikipedia‐ノート:即時削除の方針#カテゴリ6の改定提案は既に提案から1週間が過ぎ、最終コメントからも明後日で1週間が経ちます。このまま異論がなければ、今週の中頃にも即時削除の方針に正式に反映させる所存である旨、あちらのノートに予告済みです。このため、「即時削除テンプレートの貼付」については、今週末にも方針上実装可能となる運びです。--Doraemonplus（会話） 2023年8月6日 (日) 06:35 (UTC)

テンプレート貼り付けは機能種別として種別Cの範疇なので、フラグ付与後は運用者の判断で実装が可能となっています.

正式反映が近いとのことなので、反映されたら実装する、という合意の確認に変更したいと思います. --鏡華（会話） 2023年8月6日 (日) 06:43 (UTC)

カテゴリ6の改訂提案、お疲れ様です。どうもありがとうございます。

botで即時削除テンプレートの貼付けや、移動することには賛成です。しかし上でご指摘がありましたが、「リダイレクトを作成せずに移動」するのは、botの規約にはないのではないでしょうか（私はそれを知らずにできるものだと思っていたこともあり、この件のbot依頼でそういう発言をしたことがありますが）。削除権限のある利用者は「リダイレクトを作成せずに移動」ができますが、権限のない利用者がこの機能がないのは、事実上の削除だからではないでしょうか。つまり、プロジェクトの合意だけではこの機能の使用は問題があるのではないかと考えます。「リダイレクトを作成せずに移動」は、bot運用者の誰かが削除権限を取得する、あるいはbot自体が削除権限を取得するなどしてからの方がよいのではないかと考えます。--柏尾菓子（会話） 2023年8月6日 (日) 06:55 (UTC)

返信 必要があれば運用者である私が削除者権限の申請を行うことも厭わないですが、申請資格があるとはいえ私の標準名前空間の編集回数が少ないため認められるかどうか、という不安要素はちょっとあります.

この機会にWP:BOTを改正して「リダイレクトを作成せずに移動」の取り扱いをどうするか明文化したほうがいいかもしれません.--鏡華（会話） 2023年8月6日 (日) 07:01 (UTC)

不確かな記憶ですが、私も何度かBOTREQで「リダイレクトを作成せずに移動」のお世話になった経験があります。現状では、Bot運用者によって解釈や運用が異なるのでないかと思います。Bot規約の改正が必要であろうとのご意見に同意です。--Doraemonplus（会話） 2023年8月6日 (日) 07:16 (UTC)

報告 Wikipedia‐ノート:Bot#「転送ページを作成せずに移動」権限の扱いについてにて話題提起を行いました.--鏡華（会話） 2023年8月6日 (日) 07:30 (UTC)

報告 種別C(文字列置換)及び種別I(議論ページの定期作成)にてbotフラグが付与されました.

これに伴い、ページ更新の間隔を1分から5秒に短縮します. --鏡華（会話） 2023年8月11日 (金) 14:52 (UTC)

分割は即時削除カテゴリ6の条件に盛り込むべきか

削除の方針および即時削除の方針の見直しを提案していて、疑問に思ったことがあります。キューの2番目「Bot: Category:Name1をCategory:Name2とCategory:Name3へ」は、Name1をName2とName3に分割する目的で使われるものと想定されますが、即時削除カテゴリ6では現行の文書でも改定案でも「分割」は対象外とされています。たとえName1が空になったとしても、Botが即時削除タグを貼るのはまずいのではないかと考えますが、いかがでしょうか。--Doraemonplus（会話） 2023年8月7日 (月) 23:50 (UTC)

先ほど「分割を想定」と申し上げましたが、誤解でした。よくあるサブカテゴリへの分割（細分化）で親カテゴリが空になる状況は生じないですよね。となると、このキューパターンは「複数の異なる統合先への吸収合併」（統合の一形態）を想定していると考えるのが自然だと思います。例えば、Category:科学と文化がCategory:科学とCategory:文化に各々、吸収併合されるようなパターンです。カテゴリの場合、Wikipedia:ページの分割と統合にいう「分割」「統合」とはやや趣きが異なるので、カテゴリ6改定案の「統合」に注釈を付けることにします。--Doraemonplus（会話） 2023年8月8日 (火) 03:21 (UTC)

節を作るほどではないため、関連していそうなここに書きます。統合提案→合意→カテゴリ6で即時削除だと、即時削除したカテゴリが再作成されても、削除依頼を経ていないため、全般5で即時削除できないと思いました。削除依頼を経ていると、Category:大陸別の生物相の履歴のように、全般5で即時削除できます（参考・ほかに全般5で即時削除したカテゴリ列挙）。統合後、カテゴリ1-3として削除依頼を経たカテゴリなら、全般5が適用できます。つまり統合に不服だったから再作成した、とされても、カテゴリ6で即時削除したカテゴリは、まだ議論を経ないと現在の方針では削除はできないと考えます。カテゴリ系LTA対策には不向きだと考えました。--柏尾菓子（会話） 2023年8月21日 (月) 03:50 (UTC)

• なるほど、全般5の問題がありましたか。今まではカテゴリの統合に伴う統合元ページの削除は必ず削除依頼を経由していましたが、先般のカテゴリ6の改定により、即時削除が可能となったため、即時削除経由で削除されたカテゴリが仮に再作成されても、「過去に削除依頼を経て削除されたページ」を前提とするWP:CSD#全般5は適用不可ということですね。
• ただし、全般5には「再作成された項目に、この条項以外の理由による即時削除理由が存在すれば、その即時削除理由を附して、再度の即時削除を求めることはできます」とも書かれており、この場合、再度のカテゴリ6を求めるという方法で足りるのでないかと考えます。もとよりページの削除合意（統合合意）は再作成を妨げるものではなく、特にカテゴリの場合、削除合意された時点と再作成された時点では、含まれ得る記事のラインナップや周辺カテゴリの状況が大きく変化している可能性が十分に考えられます。
• LTAによる再作成だからといって全般5で問答無用で即時削除するよりは、多少面倒でも再度統合提案にかけて、なんならLTAさんの意見も伺って、再びカテゴリ6で即時削除する方が合理的な方法ではないかと存じます。全般5にせよカテゴリ6にせよ、どのみちカテゴリLTAとはイタチごっこになるのは必至ですし、もし改善なき再作成や統合提案での対話拒否の度が過ぎるようであれば、コミュニティを消耗させる利用者として投稿ブロックに処し、再作成を止めてしまえばよいのではないでしょうか。

--Doraemonplus（会話） 2023年8月21日 (月) 07:32 (UTC)

• LTAというものは、LTAになるだけの理由があります。たとえば上記に挙げた生物相関係のカテゴリですと、利用者‐会話:柏尾菓子/過去ログ2#生物相関係のカテゴリの削除について、プロジェクト‐ノート:生物#削除依頼/各国の動物および動物相のカテゴリで削除されたカテゴリの一部復活についてのように、とにかくカテゴリを作成したいようで、対話にならないのです。LTAの意見を伺うとコミュニティの皆様の疲弊が目に見えているので、それ防ぐためにも、何回も議論混込みのいたちごっこをするよりは、再作成全般5での即時削除（場合によっては作成保護）のいたちごっこの方が、コミュニティの疲弊度は減少すると考えます。これはLTA対策の話であり、一般の利用者であれば、「再作成だからといって全般5で問答無用で即時削除するよりは、多少面倒でも再度統合提案にかけて、」「再びカテゴリ6で即時削除する方が合理的」でもありだと思います。
• 「カテゴリの場合、削除合意された時点と再作成された時点では、含まれ得る記事のラインナップや周辺カテゴリの状況が大きく変化している可能性が十分に考えられます」は確かにそうですね。どこまでが「大きく変化」に該当するのか、ですね。たとえば対象が1、2記事増えたから改善なき再作成ではない、という主張もあり得ます（LTAが言いそうです）。すると全般5の適用は、困難なのではないかと思いました（微妙だと削除しにくい、あるいは削除依頼に回してくださいとします）。いくら整理しても再作成され放題のような気がします。
• 統合提案でカテゴリ6で即時削除だと、結局「即時削除」なので、削除者・管理者の裁量扱いです。判断責任は、削除対処する者に大きくかかります。削除依頼カテゴリ1-3で削除、はコミュニティの審議により削除です。判断もしますが、皆様による議論の結果、ボタン押し対処です。今日プロジェクト:カテゴリ関連/議論/2023年/8月11日でコメントして、ありがたいことに返信をいただきましたが、それがなかった場合、微妙すぎるものは対処が遅れ（裁量なので、判断が難しいものはほかの方に任せるとすることもあるからです）、ケースAで削除依頼に回すか却下するかとしたかもしれません。実際に運用し始めると、「統合」の即時削除は難しいのかもしれない、と思いました。即時削除の改訂について反対や、否定的な意見とするものではありません。個人的な感想です。--柏尾菓子（会話） 2023年8月21日 (月) 08:57 (UTC)

  この問題は結構シビアな感じがするので、後ほど即時削除の方針のノートに転記させていただきます。--Doraemonplus（会話） 2023年8月21日 (月) 09:14 (UTC)

  報告 Wikipedia‐ノート:即時削除の方針#カテゴリ6の「統合」の範疇についてに転記および問題提起しました。--Doraemonplus（会話） 2023年8月21日 (月) 09:39 (UTC)

古いキュー記録のアーカイブについて

QueueBotによるカテゴリ操作ログのアーカイブ方法について、利用者‐会話:Misato Kano#キュー提出ページのアーカイブについてで話し合い中であることをお知らせします。--Doraemonplus（会話） 2023年8月19日 (土) 02:05 (UTC)

「コマンド取り消しキュー」追加の予告及びテスト

8/23日以降に実行されるキューにはランダムな文字列がIDとして付与されるようになります. (実行報告及び編集ログの要約に記載) これは「コマンドの取り消し」キューの実装を見据えた試験的実装です. Bot操作によって行われた編集を取り消す場合、人力でやるのはあまりに大変なので、「キュー実行前の状態に戻す」方法を提供することを目的としています. なお行われる操作はいわゆるundo("取り消し"リンクから行うもの)と同等を想定しています. この件に関しての質問などはこの節にお願いします. --鏡華（会話） 2023年8月23日 (水) 03:53 (UTC)

新機能「取り消しキュー」の試験実装を歓迎します。プロジェクト:カテゴリ関連/キュー/導入文に告知しておきました。--Doraemonplus（会話） 2023年8月23日 (水) 10:45 (UTC)

トップページのデザインについて

トップページのデザインについてご意見・ご提案のある方は、こちらにお願いします。

トップページだけではない話ですがここに書きます。2022年版のベクタースキンではいくつかのページのレイアウトが崩れています。また、レベル1の見出しは使用しないこととなっているためプロジェクト:カテゴリ関連/議論/2023年/8月3日のようなページの見出しはすべて1段階レベルを下げるべきだと思います。--プログラム（会話） 2023年8月3日 (木) 15:01 (UTC)

スキン別のレイアウトの乱れは、ページの構成が更に固まってから、余裕ができれば調整を検討したいと思います。また、レベル1の見出しは使用しないルールは存じておりますが、プロジェクト:カテゴリ関連/議論/2023年/8月3日は、例えば今ならプロジェクト:カテゴリ関連/議論/今週に参照読み込みされていたり、改名・統合の合意後にキューに入れる際、レベル2の節レベルをそのままに記入できたりする簡便さは、各々1段階ずつレベルを下げると失われてしまうこともあり、どうしたものかなと悩んでおります。--Doraemonplus（会話） 2023年8月3日 (木) 15:28 (UTC)

スキン別のレイアウト調整の件については了承しました。レベル1の見出しの問題は影響を受ける全てのページ（キューを含む）で1つずつレベルを下げたうえでBotの仕様変更を行えば解決しませんか？--プログラム（会話） 2023年8月3日 (木) 15:52 (UTC)

節レベルの件ですが、{{Cfrtext}}などでは議論セクション作成のために{{Neuer Abschnitt}}を使用しており、同テンプレートでレベル3のセクションを作成させる設定方法がわからず、困っています。この問題さえクリアすれば、節レベル下げは可能かと存じます。--Doraemonplus（会話） 2023年8月3日 (木) 22:58 (UTC)

Level引数があるのでこれで行ける気がします--鏡華（会話） 2023年8月4日 (金) 01:22 (UTC)

@Misato Kanoさん Cfxtext系テンプレートに改修を施し、Level 3で投稿されるようにしました。お手数ですが、日別ページ自動作成のソースの書き換えをお願いします。--Doraemonplus（会話） 2023年8月5日 (土) 01:20 (UTC)

修正を行いました--鏡華（会話） 2023年8月6日 (日) 05:45 (UTC)

どうもありがとうございます。--Doraemonplus（会話） 2023年8月6日 (日) 05:50 (UTC)

「提案に責任を負う者」とは誰か

今日からプロジェクト:カテゴリ関連/議論の試験運用が開始されたため、改めて原則を確認したところ、#作業の流れの4番「7日後、管理者（当面は提案に責任を負う者が代行）は議論に目を通し、その時点でまだ開いている議論はすべて理由を付けて閉じます。」（引用）の、「提案に責任を負う者」とは誰を指すのか、疑問に思いました。削除依頼やブロック依頼などの依頼系では、管理者や削除者など依頼を終了する権限のある者が依頼者や参加者の場合、依頼者や参加者以外の権限のある利用者が終了します。つまり「提案に責任を負う者」とは、依頼者（提案者）やその議論に参加している利用者以外のプロジェクトに参加する者ということでしょうか。誰がプロジェクトに参加しているなどの表明もないため、いきなり現れた利用者（悪意にとるとソックパペット）が議論を終了する事態も起こりうるのではないでしょうか。（どこで提起してよいのかわからなかったため、ここに書きましたが、/原則のノートページで議論する方がよいのであれば移動します）--柏尾菓子（会話） 2023年8月1日 (火) 07:24 (UTC)

本当はすべての議論を管理者さんに閉じていただきたいのですが、元にしたドイツ語版とは違って、管理人員のリソースが全く不足している日本語版の現状では無理な注文だろうと思いまして、このような微妙な設定に変更してあります。議論のクローズ対処の部分について、どのような制度設計が最適なのか、良いアイデアを思いつきましたら、積極的に改善案をご提案いただければ、と存じます。--Doraemonplus（会話） 2023年8月1日 (火) 08:00 (UTC)

改めて原則を読み返したところ、管理者さんに閉じていただく必要があるのは「その時点でまだ開いている議論」限定のようですね。「まだ開いている議論」をプロジェクト:カテゴリ関連/議論/長期積み残し案件リストかどこかに集めておいて、それをWikipedia:管理者伝言板に掲示する方法をとれば、Wikipedia:管理者伝言板/削除#管理者・削除者対処待ちの削除依頼に似た運用は可能かもしれませんね。--Doraemonplus（会話） 2023年8月1日 (火) 08:16 (UTC)

ほかの依頼系では、管理者（や削除なら削除者）が閉じる必要があるものは、権限のない利用者が閉じません。「ある時点で明確な合意が得られた場合は、誰でも議論を打ち切ることができます」（原則の#作業の流れの3番より引用）だと、ソックパペットが次々に意見を投じ、本人だけで早期終了できると思いました。管理者が閉じるのであれば、「ある時点で明確な合意が得られた」議論やほかの議論も管理者が閉める方がよいと考えます。あるいは改名や統合や分割など、提案系は特定の権限必要なく議論提起して利用者だけで終了しています。そちらに寄せるなら、「その時点でまだ開いている議論」も管理者が閉める必要はないのでは、と考えます。どちらがよいのでしょう。前者にするなら、管理者伝言板の掲示はよい方法だと思いました。--柏尾菓子（会話） 2023年8月1日 (火) 08:34 (UTC)

なるほど、わかりやすいご説明をありがとうございます。当サブPJで取り扱う議論は全て提案系になりますので、普通に考えれば、管理者の方によるクローズは必要ないということですね。原則、議論の早期終了は無しとするのが、簡潔かつソックパペット対策にも有効でしょうか。ただし、Wikipedia:ページの改名#改名前にすべきことの例外に準じて、「明らかに、ページ名に誤字、脱字があるとき」は「直ちに改名を行ってもかまいません」との規定は設けてもよいかと思います。--Doraemonplus（会話） 2023年8月1日 (火) 09:04 (UTC)

7日を過ぎた議論の対処方針について

重要な議題ですので、節を分けます。--Doraemonplus（会話） 2023年8月2日 (水) 08:33 (UTC)

管理者の関与とはまた別の問題になりますが、提案から7日を過ぎた時点で、議論が続いていたり、対処されていなかったりした場合の議論の対処方針の基準をどうすべきかも、ここでついでにご意見をお伺いしたいと思います。--Doraemonplus（会話） 2023年8月1日 (火) 09:04 (UTC)

「明らかに〜」の規定について、賛成します。「提案から7日」について疑問、というか確認なのですが、プロジェクト:カテゴリ関連/原則の4番には7日後に「その時点でまだ開いている議論はすべて理由を付けて閉じます。」（引用）、6番に「最大7日間が過ぎた後には、終了したすべての議論が、対応するページ（プロジェクト:カテゴリ関連/議論のサブページ）にアーカイブされます。」（引用）とあります。が、プロジェクト:カテゴリ関連/議論はWikipedia:削除依頼のようなデザインなので、先週分や先々週分、長期積み残し案件があったり、#再提出に「少なくとも2週間以上新たな投稿がなく、1か月（提案日＋7日間の議論期間＋30日間の処理猶予期間）を過ぎても対処されていない議論は、中断して「再提出」のマークを付けることができます。」（#再提出より引用）とあります。「提案から7日」で閉じる方向で、/議論の記述の方が異なるという認識でよいのでしょうか。--柏尾菓子（会話） 2023年8月2日 (水) 07:49 (UTC)

お恥ずかしながら、実は私も「/原則#作業の流れ」について未だ頭の整理がついておりません。「/議論#現在審議中の提案」はWikipedia:削除依頼#現在審議が進行中の削除依頼のデザインを借用したのは事実ですが、「長期積み残し案件」と「再提出」の項は、それぞれ基礎にしたドイツ語版のde:Wikipedia:WikiProjekt Kategorien#Diskussionen, die länger als 7 Tage dauernおよびde:Wikipedia:WikiProjekt Kategorien/Wiedervorlageにも存在します（「提案に責任を負う者」は独自に改変した部分でしたが）。ドイツ語版の実際の運用を確認すると、「長期積み残し」は確かに利用されていて、あれあれ？「7日ですべて閉じる」原則はどこへ行った？と混乱しております。ドイツ語版の規定や運用と関係なく、この部分は運用の根幹に関わるため、日本語版で独自に決めるべきであろうとは考えています。以下、拙考を少しばかり開陳します。--Doraemonplus（会話） 2023年8月2日 (水) 08:33 (UTC)

コメント 実際の運用の視点から検討してみます。新規提案作成時に貼る{{Cfx}}系テンプレート（改名・統合・削除提案）のメッセージには「議論が終了するまでは、カテゴリに含まれている項目は除外せず、このメッセージも除去しないでください。」と記載されています。これは、議論の前提となる提案時点でのカテゴリの状態が、議論途中にカテゴリを弄られることで崩れてしまうことを防止するのが目的です。カテゴリの提案の議論期間が短めの7日間に設定されている理由は、意思決定の迅速化はもちろんですが、議論の長期化で「弄られること」が許されない期間が不必要に延びることを抑止する狙いもあると見ています。

提案から7日を過ぎたカテゴリの議論の対処方針については現在、/議論と/原則に説明がありますが、未だほとんど整理されていません。「7日後（8日目）の時点でまだ開いている議論はすべて理由を付けて閉じる」を原則とする一方、「長期積み残し案件」枠が用意されていたり、「少なくとも2週間以上新たな投稿がなく、1か月を過ぎても対処されていない議論は…」という「再提出」の規定があったりします。このあたりの対処方針の整理をどのようにすべきか、ご意見をお聞かせ頂ければありがたいです。

個人的には、「長期積み残し」枠に掲載することで進展する議論はあるだろうと思う一方で、たった1週間で「すべて理由を付けて閉じる」原則で本当にうまく議論が回るのか懸念しています。と、ここで、{{CfQA}}（品質保証提案）には「弄らないこと」の記載がないことに気づきまして。長期化した議論は品質保証扱いで「積み残し」枠に掲載し、さらに1か月経っても進展がなければ「再提出」としてマーキングするのはいかがかな、と思いました。--Doraemonplus（会話） 2023年8月2日 (水) 08:33 (UTC)

「たった1週間で「すべて理由を付けて閉じる」原則で本当にうまく議論が回るのか懸念」に同意です。「合理的な期間（通常は168時間程度〈約7日間=約1週間〉」（WP:CONより引用）ではありますが、無知なだけかもしれませんが、1週間きっちりで確実に終了、という運用をほかでは見かけない気がします。記事や情報を更新しているようなテンプレートなど異なり、カテゴリを頻繁に弄ることはあるのだろうか、と考えました。議論が長期化するとはいっても、再提出システムがあるなら「1か月（提案日＋7日間の議論期間＋30日間の処理猶予期間）」（再提出より引用）で済むのでしょう。「「弄られること」が許されない期間」がそのくらいかかってしまうのは仕方がないのではないかと考えました。再提出状態は弄ってもよいとかにしたらどうでしょうか。「長期化した議論は品質保証扱いで〜」で、とりあえずやってみるのでいいと思います。今のままだと混乱を招くので、再提出に寄せるのであれば、1週間ですべて閉じるの記述は変更した方がよいと思います。--柏尾菓子（会話） 2023年8月4日 (金) 13:52 (UTC)

なるほど、確かにカテゴリの場合、最長1か月程度なら「弄られ」不許容期間は過度に気にする必要はなさそうですね。「（原則1週間で）すべて理由を付けて閉じる」は無しにして、「再提出」寄りの内容に書き直してみます。「長期化した議論は品質保証扱いで〜」も手順の簡素化のため、止めにします。--Doraemonplus（会話） 2023年8月5日 (土) 03:36 (UTC)

書き直しました（差分）。--Doraemonplus（会話） 2023年8月5日 (土) 04:09 (UTC)

/原則の書き直しを拝見しました。いいと思います。どうもありがとうございます。--柏尾菓子（会話） 2023年8月5日 (土) 06:46 (UTC)

/原則の目的の文言

上でいいと思うと言ったばかりであれですが、熟読していたら、プロジェクト:カテゴリ関連/原則#目的部分について気になる文言を見つけました。「当プロジェクトの目的は、各部門の管理下にないカテゴリの保守管理（削除、作成、命名、範囲設定、構造化など）です。」（#目的より引用）という文言があります。

1. いずれ移行したら、改名提案などはここで行うようになるのでしょう。しかしこの「各部門の管理下にない」などの文言があると、例えばプロジェクト‐ノート:漫画家/カテゴリの指針のようなカテゴリの管理があるものは、ここで議論しないのだろうか、どこで改名提案すればよいのか、ノート？ と混乱を招くように感じます。
2. 「（削除、作成、命名、範囲設定、構造化など）」で、そもそも改名とは書かれていません。「など」なので間違ってはいないですし、「命名」の部分が改名に該当すると考えますが、改名という文言がないと、文書などで見かける表現が「改名」なので、初見ではわかりにくい気がしました。「命名（改名）」にしたらどうでしょうか。

何か文言を追加した方が、あるいは表現を変更した方がわかりやすいと考えたのですが、いい案がまだ浮かばないので、意見だけ失礼します。--柏尾菓子（会話） 2023年8月5日 (土) 07:17 (UTC)

ご意見ありがとうございます。一人で書いていると盲点だらけなもので。これはおそらくですが、プロジェクト:カテゴリ関連の目的とプロジェクト:カテゴリ関連/議論の目的を取り違えた感じですね。カテゴリ関連PJ本体は、確かに「各専門分野のプロジェクトの管理下にないカテゴリの保守管理」の受け皿ですが、議論サブPJは、すべての個別カテゴリの提案・議論環境の提供が目的ですので、こちらも文言を見直そうと思います。--Doraemonplus（会話） 2023年8月5日 (土) 08:26 (UTC)

先ほど改訂しました（差分）。--Doraemonplus（会話） 2023年8月6日 (日) 03:54 (UTC)

議論（提案）場所が分散している

どこに書けばよいのかわからないので、このまま失礼します（不適切であれば適当に移動していただけるとありがたいです）。プロジェクト:カテゴリ関連/議論の運用を開始しましたが、改名提案を見ると今まで通りそちらでカテゴリの改名の提案がされています。お知らせやコメント依頼で告知しているとはいえ、認知度に問題があると感じます。改名提案、統合提案、分割提案に、カテゴリについてはプロジェクト:カテゴリ関連/議論でお願いします的な、誘導するような記述を追加した方がよいのではないでしょうか。これを書いている時点でカテゴリ関連/議論に意見がついていないのも、認知度に問題があるせいもあると考えます。議論（提案）場所が分散しているという懸念、というかプロジェクトが運用できているとは言い難いのではという懸念から申しました。--柏尾菓子（会話） 2023年8月4日 (金) 13:52 (UTC)

確認ですが、Wikipedia‐ノート:即時削除の方針#カテゴリ6の改定提案を見るに、議論（提案）場所は移行でいいのですよね？ 分散ではないですよね。私の認識不足で後者だとしても、提案系ページに、カテゴリについてはプロジェクト:カテゴリ関連/議論での議論もあります的な、誘導するような記述を追加するのがよいと考えます。--柏尾菓子（会話） 2023年8月4日 (金) 14:02 (UTC)

Wikipedia:ページの改名などについても整理をする必要がありそうです.

改名の告知に用いるテンプレートや議論場所からして違うため、Wikipedia:ページの改名とWikipedia:カテゴリの改名に分割するなどしたほうがいいかもしれません.--鏡華（会話） 2023年8月4日 (金) 14:33 (UTC)

ひとまずWP:改名提案,WP:統合提案,WP:分割提案にて{{Otheruses}}での誘導を追加しました.--鏡華（会話） 2023年8月4日 (金) 14:45 (UTC)

3つの提案の方法を変更することとなりますので、まず合意が必要だと考えます。{{Otheruses}}を追加するのも、誘導してよいかの合意形成した方がよいと考えます。一度戻します。

上記合意形成前に、Wikipedia:カテゴリの改名を作成するのか確認してから、合意形成提案をします。プロジェクト:カテゴリ関連/議論で改名の議論も行う認識でいましたが（今もプロジェクト:カテゴリ関連/議論/2023年/8月2日など、行われているため）、違うのでしょうか。--柏尾菓子（会話） 2023年8月4日 (金) 14:56 (UTC)

改名の議論場所についてはプロジェクト:カテゴリ関連/議論で行う認識です.

Wikipedia:ページの改名とWikipedia:カテゴリの改名に分けるというのは議論場所をWikipedia:カテゴリの改名にしようという話ではなく、現状カテゴリと記事を区別せずにガイドライン化・ドキュメント化されている内容を分割・整理しましょうという提案ですね.--鏡華（会話） 2023年8月4日 (金) 15:07 (UTC)

補足どうもありがとうございます。納得しました。--柏尾菓子（会話） 2023年8月5日 (土) 06:11 (UTC)

プロジェクト:カテゴリ関連/議論のトップページが上記で言うWikipedia:カテゴリの改名にちょうど近い内容が書かれているため、

「具体的な改名の方法はWP:ページの改名を参照してください」的にリンクされている箇所で

「カテゴリの改名の場合はプロジェクト:カテゴリ関連/議論を参照してください」と{{Otheruses}}できるとよいなと考えています.

合意が必要という話には同意します、ちょっと急ぎすぎました. 申し訳ありません.--鏡華（会話） 2023年8月4日 (金) 15:15 (UTC)

後付けですが、WP:改名提案、WP:統合提案、WP:分割提案に対応するWikipedia:カテゴリの提案と議論（草案）を作成しました。まだ明確な用途は決まっていませんが、現在はこれらが対応している、カテゴリを対象とする同様の説明はそちらで行うことを検討中です。{{Otheruses}}による誘導は、同ページが{{draft}}を脱して、Wikipedia‐ノート:即時削除の方針#カテゴリ6の改定提案でお示しした提案場所の移行期間に入ってからでよいかと存じます。--Doraemonplus（会話） 2023年8月5日 (土) 04:42 (UTC)

• 備忘録として、アップデートが必要そうな既存の関連文書を書き出してみます。
  • Wikipedia:カテゴリの方針#カテゴリ整理の指針 （実施済）
  • Wikipedia:削除の方針#カテゴリ1: カテゴリの名称・内容・構造の3要素が整わないカテゴリ（実施済）
  • Wikipedia:即時削除の方針#カテゴリ （実施済）
  • Wikipedia:ページの改名#改名前にすべきこと（実施済）
  • Wikipedia:ページの分割と統合#ページの分割（実施済）
  • Wikipedia:ページの分割と統合#ページの統合（同上）
  • Wikipedia:依頼と提案#提案系ページ（未提案）
  • Wikipedia:Bot作業依頼#依頼する場合の手順と注意（未提案）
  • Wikipedia:統合提案#このページへの記載のガイドライン（実施済）
  • （Wikipedia:分割提案は「記事の分割」限定のため不要？）（実施済）
  • Wikipedia:改名提案#このページへの記載のガイドライン（実施済）
  • Help:カテゴリ#カテゴリページの移動（未提案）

記載漏れがありましたら、適宜追加してください。--Doraemonplus（会話） 2023年8月5日 (土) 05:35 (UTC) 進捗欄を追加。--Doraemonplus（会話） 2023年8月6日 (日) 10:01 (UTC) 進捗を更新。--Doraemonplus（会話） 2023年8月8日 (火) 08:55 (UTC) 進捗を更新。--Doraemonplus（会話） 2023年8月25日 (金) 10:54 (UTC) 進捗を更新。--Doraemonplus（会話） 2023年9月1日 (金) 12:51 (UTC)

Wikipedia:カテゴリの提案と議論の草案作成、どうもありがとうございます。もう移行期間に入っていたのかと誤解していました。誘導提案は、「移行期間に入ってから」にします。なるほど、だからまだプロジェクト:カテゴリ関連/議論/2023年/8月2日の改名提案はまだ改名提案に掲載されているのですね。--柏尾菓子（会話） 2023年8月5日 (土) 06:11 (UTC)

移行期間に入ってからでよいですが、Wikipedia:カテゴリの提案と議論を{{Navibox ウィキペディアのメンテナンス}}に追加することも考えたほうが良さそうです.--鏡華（会話） 2023年8月5日 (土) 11:28 (UTC)

@柏尾菓子さん 誤解を招いてしまい申し訳ないです。移行期間は将来の正式運用と同時に開始する予定です。移行期間の終了時期は未定です。

@鏡華さん そうですね、追加させて頂くつもりです。アップデートを必要とするページが結構多いため、正式運用開始までまだしばらく時間がかかりそうです。--Doraemonplus（会話） 2023年8月5日 (土) 12:24 (UTC)

参考情報:

Category:学校記事に含まれる学校記事の編集画面を開くと{{学校記事_editintro}}が表示される、といった機能が実装されていることを知りました.

カテゴリのノートページの編集画面を開いた際に何かしらの案内を追加表示する、といったことも技術的には可能かもしれません.--鏡華（会話） 2023年8月5日 (土) 13:05 (UTC)

Wikipedia:編集画面の注意文に情報がありました.

名前空間で出し分けをする場合はcommon.jsへの追加は必要ないようです.--鏡華（会話） 2023年8月5日 (土) 13:07 (UTC)

提案 #Category‐ノート:名前空間向けの編集画面の注意文にて、編集画面の注意文の掲示案を検討中です。遅れながら、お知らせまで。--Doraemonplus（会話） 2023年11月15日 (水) 09:32 (UTC)

返信 カテゴリノートの管理に関する参考情報をお寄せいただき、ありがとうございます。何かしらの案内があると良いだろうとは考えています。

 予告 来月1日に正式運用を開始したいと思います。正式運用の開始は、MediaWiki:Sitenoticeで全ユーザーに告知することを予定しています。正式運用開始後、しばらくの間は「移行期間」と位置づけ、前述のカテゴリノートでの提案・議論も認める形を取りたいと考えています。期限については、新システムの利用状況をみながら検討していくつもりです。--Doraemonplus（会話） 2023年8月19日 (土) 09:09 (UTC) 正式運用開始延期のため取り消し。--Doraemonplus（会話） 2023年8月25日 (金) 10:54 (UTC)

議論がない日

プロジェクト:カテゴリ関連/議論/2023年/8月4日、プロジェクト:カテゴリ関連/議論/2023年/8月6日、プロジェクト:カテゴリ関連/議論/2023年/8月7日、プロジェクト:カテゴリ関連/議論/2023年/8月8日と議論がない日が続くと、試しに覗いてみたものの、空なので、このカテゴリ関連/議論は現在運用されているのか、と思う方がいる気がします。まったく議論がなかった日のページに、この日は議論がありませんでした、みたいな文言を翌日追加したらどうか、と考えました。ほかに依頼ページが毎日作成されている削除依頼は、依頼がまったくない、という日を見たことがありません。しかしプロジェクト:カテゴリ関連/議論はカテゴリ（前者と比較して数が少ない）のみが対象という以上、今後もそういう日が出てくると思います。--柏尾菓子（会話） 2023年8月9日 (水) 01:30 (UTC)

元にしたドイツ語版でも、例えばde:Wikipedia:WikiProjekt Kategorien/Diskussionen/2023/August/7のように議論がない日のページがあるので、あまりお気になさらなくてよいと思います。--Doraemonplus（会話） 2023年8月9日 (水) 09:05 (UTC)

なるほど、そうだったのですね。教えてくださり、どうもありがとうございます。--柏尾菓子（会話） 2023年8月9日 (水) 09:11 (UTC)

編集ツールバーの署名ボタン

議論ページにコメントを投稿する際、編集ツールバーに署名アイコンが表示されないことに気づきました。下段の「マークアップ」リストから選択する方法は議論ページでも使えますが、私はよく署名アイコンを利用して署名するので、この方法が使えないのは少々不便に感じました。プロジェクト名前空間ページの編集画面のツールバーに署名アイコンを表示させる方法はないのでしょうか。--Doraemonplus（会話） 2023年8月11日 (金) 04:22 (UTC)

おそらくカスタムJSを書くしかない気がしています.

ウィキ技術部に相談してみるといいかもしれません.--鏡華（会話） 2023年8月11日 (金) 05:30 (UTC)

鏡華さん、ご助言いただき感謝します。遅くなりましたが、本日、プロジェクト‐ノート:ウィキ技術部#ノート以外のページの編集ツールバーに署名ボタンを表示させたいを提出しました。--Doraemonplus（会話） 2023年8月28日 (月) 08:00 (UTC)

報告 プロジェクト:ウィキ技術部/依頼#プロジェクト名前空間ページの編集ツールバーに署名ボタンを表示できないかを提起したところ、ログインユーザーであれば、Special:MyPage/common.jsの書き換えで対応可能との回答をいただきました。利用者を問わず、全面的に適用するには、やはりカスタムJSを用意する必要があろうと思われますが、他の利用者の方で同様のご希望があれば、それをもってカスタムJS作成の合意形成としたいと考えています。--Doraemonplus（会話） 2023年12月19日 (火) 10:37 (UTC)

即時削除カテゴリ6について確認

即時削除カテゴリ6について確認させてください。カテゴリ6は2023年8月15日 (火) 05:33(UTC)に改訂されました。しかしこのカテゴリ関連はまだ正式運用でなく、改名提案の方にカテゴリの改名はカテゴリ関連で、などの誘導などがなく（まだWikipedia‐ノート:改名提案#カテゴリページの改名についてで提案中の段階です）、このカテゴリ関連で改名が行われていることに気づいていない利用者もいるのではないかと考えるのですが、もう改名提案に告知なしで即時削除してしまってよいのでしょうか。また、改訂前（8月15日 (火) 05:33(UTC)以前）は文言が「事前に改名の議論において」だったはずですが、改名提案に告知していない状態で8月15日 (火) 05:33(UTC)以前のカテゴリ関連/議論のみで行われた提案をカテゴリ6で即時削除してしまってもよいのでしょうか。--柏尾菓子（会話） 2023年8月25日 (金) 07:42 (UTC)

（追記）Wikipedia‐ノート:改名提案#カテゴリページの改名についてで告知予定の文言を見ると「2023年9月より、カテゴリページの改名手順が変更となりました。カテゴリの改名の際は、従来の手順ではなく、カテゴリページ専用の改名手順に従ってください（ただし、年末までは従来の手順でも可とします）。」（引用）とあるということは、8月はまだ従来の改名手順であるように見え、上記にカテゴリ6を適用してもよい、と断言し難いように思えてきました。返答がなければ、「Category:図書館に関する日本の組織」（8月14日提案）などは、念のためにリダイレクトの削除依頼に回します。--柏尾菓子（会話） 2023年8月25日 (金) 07:58 (UTC)

混乱を招いてしまい申し訳ありません。即時削除の方針の趣旨からいって、「事前に」「議論（された）」「改名」を対象にすることは、文言の変更に依らず、改定の前後で首尾一貫しているものと認識しています。（追記）の告知内容は「移行期間」中に掲示することを想定したもので、正式運用開始と同時に掲出する手はずでした。しかし、準備不足で正式運用が延期されたため、掲出に至っていません。一方、改定後のカテゴリ6の「使用方法」では既に新プロジェクトページを例示していますし、同じくカテゴリ6「所定の議論」のリンク先「Wikipedia:カテゴリの提案と議論#所定の提案・議論場所」でも〈試験運用中は新システムの提案でも従来の改名提案でもどちらでも受け付けていますよ〉という趣旨の説明を実施しています。これで大意を汲んでいただけるだろうと思っていましたが、「Wikipedia:カテゴリの提案と議論」は未だリリース前の非公式文書であり、それでは不十分である、責任の所在を明らかにすべき、絶対確実な法的根拠を要求すると仰るのであれば、より明確な説明文を直接Wikipedia:改名提案に書き入れたいと思いますが、いかが致しましょうか。--Doraemonplus（会話） 2023年8月25日 (金) 09:38 (UTC)

あるいは、単にWikipedia:カテゴリの提案と議論を即正式リリースしてしまえば済むでしょうか。Wikipedia:改名提案もWikipedia:方針とガイドライン上の正式な「ガイドライン」というわけではないみたいですし。--Doraemonplus（会話） 2023年8月25日 (金) 09:48 (UTC)

返答どうもありがとうございます。改名提案の書き入れはありがたいです。「Wikipedia:カテゴリの提案と議論」を即正式リリースは1時間くらいでは即答してもよいのかまだ悩んでいます。ざっと読んだ限りでは問題はない気がするのですが。--柏尾菓子（会話） 2023年8月25日 (金) 11:28 (UTC)

（報告）8月14日提案のものは即時削除されました。方針を厳密に捉えすぎなのか、とも考えました。--柏尾菓子（会話） 2023年8月26日 (土) 03:15 (UTC)

既に別の管理者さんにより即時削除されていますね。各自のご判断で適切だと信じる方法で処理していただいてよいと思います。その上で判断に迷うことがもしあれば、都度お問い合わせいただき、必要に応じて対処を考えるということで。

ページの改名、ページの分割と統合、改名提案については、9月1日に「書き入れ」を行う予定でいます。Wikipedia:カテゴリの提案と議論も、先日は「正式リリース」と表現してしまいましたが、事実上運用に入っていることをもって、これらと同時に「脱draft化」しようと思います。--Doraemonplus（会話） 2023年8月26日 (土) 07:26 (UTC)

遅くなりましたが、「脱draft化」を確認しました。対応どうもありがとうございました。--柏尾菓子（会話） 2023年9月5日 (火) 06:48 (UTC)

{{カテゴリ新規提案作成}}について

プロジェクト:カテゴリ関連/議論内で簡易に提案を作成するためのテンプレートですが、これをそのまま使用するとDiscussion Toolsの"返信"ボタンが機能しないようです. subst展開してみたのがこれですが、表示上問題なく返信ツールも機能したためsubst展開必須にできればと考えています. なにか問題等あれば教えていただきたいです. --鏡華（会話） 2023年8月29日 (火) 15:24 (UTC)

賛成 subst展開を必須にすることに同意します。--Doraemonplus（会話） 2023年8月30日 (水) 07:27 (UTC)

提案 削除依頼を利用して思ったのですが、いっそのこと{{subst:Sakujo}}を使用したときに読み込まれるTemplate:新規削除依頼およびTemplate:新規削除依頼サブページと同等の仕組みのテンプレートに改造してはどうかと思います。そうすれば、コメントアウト部分の除去の手間を最小限にできますし、テキスト入力欄にテンプレートの使い方の説明をごちゃごちゃと記載しなくて済みます。--Doraemonplus（会話） 2023年9月1日 (金) 14:15 (UTC)

コメント 取り敢えずsandboxでsubst必須化&カテゴリの存在確認を実装しました. {{subst:Cfrtext/sandbox}}を削除依頼と同じくPreloadを使用する形式で作成したので試用いただけるとありがたいです. 鏡華（会話） 2023年9月3日 (日) 19:43 (UTC)

コメント しばらく間が空いて、この話題の存在をすっかり失念し、sandbox版の試用も飛ばして、私の独断でTemplate:カテゴリ新規提案作成とプロジェクト:カテゴリ関連/新規提案作成定型文を乱雑に弄ってしまいました。軽率な行動をお詫び申し上げます。

早速、鏡華さん作のsandbox版について、お試しページを用意して、存在しないカテゴリ名かつ移行先未記入の状態で改名提案を作成したところ、プレビューで何のエラー表示もされず、そのまま投稿できてしまいました（差分）。これは、{{subst:無しで投稿しようとしたのが原因で、subst付きでプレビューし直したら、正しくエラー表示されました。が、エラーを無視して投稿を強行することは可能なようです（差分）。なお、エラー表示自体は、すべて正常に作動することを確認しました。鏡華さんが作成くださったsandbox版の動作確認ができましたので、善は急げということで、正式版に反映させていただきました。誠にありがとうございます。

プロジェクト:カテゴリ関連/新規提案作成定型文側にテンプレートの使い方の説明がコメントアウトで残る問題に関しては、WP:EDITINTROが解決策にならないかと思案しています。日別議論ページに付与するCategory:日別のカテゴリ議論と{{CFD editintro}}を新たに作成すれば、{{BLP editintro}}と同等の機能が実現できるものと踏んでいます。--Doraemonplus（会話） 2023年10月30日 (月) 09:32 (UTC)

鏡華さん {{Cfrtext}}および{{Cfmtext}}についても本日、作成いただいたPreloadを使用する形式のテンプレートにアップデートしました。改めて鏡華さんに感謝申し上げます。{{Cfdtext}}および{{CfQAtext}}についても、テンプレートの改良にご協力いただければ、なおありがたいです。--Doraemonplus（会話） 2023年11月4日 (土) 08:32 (UTC)

（コメント）上記の変更をされてから（？）、プロジェクト:カテゴリ関連/議論の「新規提案作成」をクリックして提案しようとすると、「エラー: subst: がありません。カテゴリ新規提案作成 ではなく subst:カテゴリ新規提案作成 としてください。」と出ます。--柏尾菓子（会話） 2023年11月11日 (土) 10:37 (UTC) （追記）エラーが出た後、手動で「subst:」を追加したらエラーが消えましたが、自身で追加しなくても「subst:」が入力されているとありがたいです。よろしくお願いいたします。--柏尾菓子（会話） 2023年11月11日 (土) 10:43 (UTC)

@柏尾菓子さん 私の環境では、「新規提案作成」をクリックした先のページで自動的に読み込まれるテキストが最初から{{subst:カテゴリ新規提案作成となっています。一度、「キャッシュを破棄」していただければ直るかと存じます。--Doraemonplus（会話） 2023年11月11日 (土) 14:00 (UTC)

＠Doraemonplusさん キャッシュを破棄したらできました。どうもありがとうございました。--柏尾菓子（会話） 2023年11月11日 (土) 14:55 (UTC)

議論ページの見出しレベルについて

Phabricatorで追跡中
タスク T275943

現在、日別議論ページ（例：プロジェクト:カテゴリ関連/議論/2023年/11月11日）では、「カテゴリ」がh2レベル、各議題がh3レベルの見出しとなっています。これはMOS:HEADINGSに適うものです。しかし、議論に参加された経験のある方はご存知かと思いますが、この仕様ですと「通知」欄には〈○○ さんが「カテゴリ」で返信しました。〉と表示されてしまい、何の議題での返信であるかが一見して読み取れず、議論に不便を強いています。

もともと、この見出しは、元にしたドイツ語版（例：de:Wikipedia:WikiProjekt Kategorien/Diskussionen/2023/November/22）同様、「カテゴリ」がh1レベル、各議題がh2レベルとなっていましたが、スタイルマニュアル (MOS) に反するとの御指摘を受け、現在の仕様となった経緯があります。その時は理由について深く考えてはいなかったのですが、前述の通知面の実用性を考慮すれば、MOSに反してでも元の仕様に戻した方が便利ではないかと思えてきました。皆様はいかがお考えでしょうか。--Doraemonplus（会話） 2023年11月24日 (金) 12:40 (UTC)

通知は確かにご指摘通り、不便だと思います。ただ、このカテゴリ関連のプロジェクトだけスタイルマニュアルに反してよいのか、という観点では悩みます。現在の見出しのレベルのまま通知の仕様を変更するなどは、技術的にできないのでしょうか。見栄え的にもh1のサイズを見慣れないので違和感がありますが、技術的に無理なら、見出しレベルの変更も仕方ないかな、と思います（利便性を優先したい考えです）。--柏尾菓子（会話） 2023年11月24日 (金) 12:52 (UTC)

phab:T275943で検討されていますが、現時点ではlevel-3セクションの購読は技術的にサポートされていません。
(これは余談ですが、このノートページでも #トップページの刷新と議論サブプロジェクトの開設のサブセクションに議論を追加し続けた結果同じことが起きているので、以後はlevel-2で議論を行っていきたいですね…) --鏡華（会話） 2023年11月25日 (土) 01:16 (UTC)

私も利便性を重視したい派です。スタイルマニュアルが禁じているのはh1レベルの見出しの使用ですので、参照読み込みに利用している「カテゴリ」周りの部分をうまく工夫すれば、違反を回避できるかもしれません。すぐに思いつく原始的な方法は{{resize}}と{{anchors}}を使う方法ですが、技術方面に関しては、鏡華さんの方がずっとお詳しいでしょうから、ご教示いただければ幸甚です。（余談に関して。議論サブプロジェクトが稼働してもう結構経つので、新規の話題は今後はh2レベルで提起していこうと思います。ご指摘に感謝です）--Doraemonplus（会話） 2023年11月25日 (土) 11:53 (UTC)

返信

== {{resize|large|[[プロジェクト:カテゴリ関連/議論/2023年/11月11日|カテゴリ]]}} ==

== [[:Category:地方公務員出身の人物]] ==

みたいな想定であっています？

これはアクセシビリティ上まずいので悩ましいんですよね。

• スタイルマニュアル & アクセシビリティを守る
• 適切に通知される

の両方いいとこ取りできる方法は裏技的なのを含めても存在しないと思います。やはりどちらかを取るしかなさそうです。 鏡華（会話） 2023年11月26日 (日) 09:06 (UTC)

返信 (鏡華さん宛)

'''{{resize|xx-large|[[プロジェクト:カテゴリ関連/議論/2023年/11月11日|カテゴリ]]}}'''
----
== [[:Category:地方公務員出身の人物]] ==

== [[:Category:遊☆戯☆王GX]]を[[:Category:遊☆戯☆王]]へ ==

みたいなのをイメージしていました。こちらはアクセシビリティ上どうなのでしょうか。ちょっと妙ですが。--Doraemonplus（会話） 2023年11月26日 (日) 14:27 (UTC) コード修正。--Doraemonplus（会話） 2023年11月26日 (日) 14:29 (UTC)

気になって、de:Wikipedia:Formatierungを読んでみたのですが、日本語版のMOS同様、「レベル1の見出しはページ名のために予約されているから使用しない」「レベル2の見出しから使うこと」と記載されていました。de:Wikipedia:WikiProjekt Kategorien/Diskussionen/2023/November/25などでレベル1の見出し (h1) を使用しているような例は、きっと大目に見られているのでしょう。MOS:HEADINGSは一般的なガイドラインであり、本件のような特殊な事例については、「常識に基づいて判断し、個別の事情に応じて例外を適用してもかまいません」（WP:GUIDESより引用）に免じて、例外的にh1を使用してもかまわないかもしれませんね。--Doraemonplus（会話） 2023年11月26日 (日) 14:49 (UTC)

@柏尾菓子さん、Misato Kanoさん 本件の最終コメントから3週間以上、音沙汰ありませんが、今日も自分が参加していない議論の通知が届き、紛らわしいことこの上ないです。事実として、元のドイツ語版でもh1を使用していますし、このまま強い反対がなければ、技術的改善が実装されるまでの間の暫定的な措置として、節レベルの再引き上げを実施しようかと存じます。よろしくお願いします。--Doraemonplus（会話） 2023年12月19日 (火) 09:01 (UTC)

完全に返信忘れてました、申し訳ありません
phabricatorのほうでも「技術的に対処されるまでのワークアラウンドとしてh1が使用されることがある」と書かれていますので、暫定処置としてのh1使用に同意します鏡華（会話） 2023年12月19日 (火) 11:24 (UTC)

いえ、私も長く放置してしまい、申し訳なかったです。phabricatorでも限定的な使用について配慮されていたのですか。それなら安心ですね。合意形成後、書き換えのbot作業依頼を提出することを検討します。--Doraemonplus（会話） 2023年12月19日 (火) 12:05 (UTC)

申し訳ございません、忘れていました。暫定的にh1でよいと思います。--柏尾菓子（会話） 2023年12月19日 (火) 12:18 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ ご賛同を頂けましたので、Wikipedia:Bot作業依頼#節見出しのレベル上げ依頼を提出しましたことをお知らせします。--Doraemonplus（会話） 2023年12月26日 (火) 12:22 (UTC)

上記Bot依頼の作業後、プロジェクト:カテゴリ関連/議論の新規提案作成のひな型を使ったら、今までの節レベルになっていました。ひな型で作成しても新しい節レベルになるよう、を調整していただけるとありがたいです。--柏尾菓子（会話） 2023年12月27日 (水) 03:22 (UTC)

Template:カテゴリ新規提案作成のセクションのレベルを1段階上げれば直るはずです。なお、いま私は出先にいるため、すぐには対応いたしかねます。申し訳ございません。--Doraemonplus（会話） 2023年12月27日 (水) 03:36 (UTC)

対応しました鏡華（会話） 2023年12月27日 (水) 03:57 (UTC)

迅速な対応、どうもありがとうございました。--柏尾菓子（会話） 2023年12月27日 (水) 04:19 (UTC)

過去ログ化の提案

ページサイズが大きくなっていますので、6か月以上前の古い議論（#カテゴリ関連での削除依頼について非常に気になることから#カテゴリの方針の全面改訂について）をプロジェクト‐ノート:カテゴリ関連/過去ログ/ログ0001と同じ方式で/ログ0002に過去ログ化することを提案します。--Doraemonplus（会話） 2023年8月6日 (日) 01:08 (UTC) 訂正。--Doraemonplus（会話） 2023年8月6日 (日) 01:12 (UTC)

• （賛成）--柏尾菓子（会話） 2023年8月6日 (日) 01:32 (UTC)

賛成 --鏡華（会話） 2023年8月6日 (日) 05:46 (UTC)

対処 提案から約2週間経過し反対意見がなかったため、提案された範囲を/過去ログ/ログ0002へ過去ログ化を行いました.--鏡華（会話） 2023年8月18日 (金) 17:05 (UTC)

過去ログ化を代行していただき、ありがとうございました。過去の話題を探しやすいように、/ログ0002の見出し一覧をプロジェクト‐ノート:カテゴリ関連/過去ログに追加しておきました。--Doraemonplus（会話） 2023年8月30日 (水) 14:03 (UTC)

Botによるデフォルトソートキーの編集可能性について

表題の件について、Wikipedia‐ノート:カテゴリの方針#デフォルトソートの指定をソートキーの指針に合わせる編集は機械的に可能かで議論が提起されていることをお知らせします。--Doraemonplus（会話） 2023年8月29日 (火) 11:53 (UTC)

Category‐ノート:名前空間向けの編集画面の注意文

#議論（提案）場所が分散している節で言及された課題の続きです。プロジェクト:カテゴリ関連/議論が始動して間もなく3ヶ月が経ちますが、まだ一部の利用者に利用されているにすぎない状況です。先頃、MediaWiki‐ノート:Sitenotice#「プロジェクト:カテゴリ関連/議論」の告知を検討しましたが、サイトノーティスよりもWikipedia:編集画面の注意文（エディットノーティス）の方が適切であろうと助言をいただきました。

そこで、認知度向上と利用促進のため、Category‐ノート:名前空間全体に対して、Template:Editnotices/Namespace/Category talkに相当する注意文を導入することを提案します。Wikipedia:編集画面の注意文#編集画面の注意文を提案する手順に従って、まずは導入の是非について、皆さまのご意見を伺いたいと思います。よろしくお願いします。--Doraemonplus（会話） 2023年10月29日 (日) 14:12 (UTC)

• （賛成）エディットノーティスの導入に賛成します。改名提案はカテゴリのノートページで提起し、改名提案ページに告知の今までのやり方をまだ結構見かけます。何もせずにいたら、おそらく現状のままでしょう。その中でも、たとえば「「Category:大宮家 (小槻姓)」を「Category:大宮家 (小槻氏)」に改名するが、記事もまとめて改名提案するためノート:大宮家（記事のノートページ）で議論を行う」みたいな、記事のノートでまとめて提案スタイルも結構見かけます（改名提案の履歴で見ると、確認できます）。すると、Category‐ノート:名前空間で提起しないので、注意文が目に入りません。この場合はどうしましょう、とは思いました。--柏尾菓子（会話） 2023年10月31日 (火) 05:55 (UTC)

  記事のノートでまとめて提案していただくことは、私は全然構わないです。カテゴリ関連/議論（WP:CFD）への一本化も、カテゴリノート名前空間へのエディットノーティス導入も、なるべく人が集まりやすい場所で提案して、カテゴリの議論全体を底上げし、活性化させるのが大義であり目標です。記事のノートは特に何もしなくても人目に付きやすいため、わざわざWP:CFDへの誘導文を掲載する必要はなさそうに思います。現に柏尾菓子さんも、手続きに則って記事ノートで議論された「Category:大宮家 (小槻姓)」をカテゴリ6で即時削除対処されたわけですし、何も問題ないでしょう。--Doraemonplus（会話） 2023年11月2日 (木) 07:57 (UTC)

文案

「プロジェクト:カテゴリ関連/Editnotice文案」を参照

賛成意見が得られましたので、メッセージ原案を作成しました。上記の内容で合意形成されれば、Template:編集画面の注意文/Category‐ノートの作成を管理者の方に依頼しようと思います。よろしくお願い致します。--Doraemonplus（会話） 2023年11月15日 (水) 09:04 (UTC) 誤カテゴライズ防止のため、文案テンプレートを参照読み込みからリンクに変更。--Doraemonplus（会話） 2023年11月24日 (金) 12:07 (UTC)

（賛成）作成、どうもありがとうございます。ほどよい長さでわかりやすくて、よいと思います。--柏尾菓子（会話） 2023年11月15日 (水) 11:57 (UTC)

コメント Wikipedia:管理者伝言板/保護ページ編集#Template:編集画面の注意文/Category‐ノートを提出したことをお知らせいたします。--Doraemonplus（会話） 2023年11月23日 (木) 13:46 (UTC)

（報告）WP:AN/PE へのご依頼の件、移動によりテンプレート化しました。「影響が特に大きいテンプレート」として無期限の保護を設定していますので、編集が必要となればまた管理者伝言板へお申し付けください。ところで、このノートページが Category:編集画面の注意文 に入っているのは検討用に上に貼ってある「プロジェクト:カテゴリ関連/Editnotice文案」の影響でしょうか。--Kurihaya（会話） 2023年11月24日 (金) 07:46 (UTC)

（返信）依頼を受理して頂き、感謝申し上げます。もし変更が必要となれば、伝言板へご連絡いたします。当ページが誤ってカテゴリに入れられないよう、文案テンプレートを参照読み込み方式からリンク表示に変更しました。ご指摘ありがとうございました。--Doraemonplus（会話） 2023年11月24日 (金) 12:07 (UTC)

議論サブページでの署名忘れ対策について

プロジェクト:カテゴリ関連/議論のサブページで署名チェックが働かない問題について、Wikipedia:ガジェット/提案#日々のカテゴリ関連議論ページを署名チェックの対象ページに追加する提案を提出しました。ご賛同いただける方は、その旨あちらのページで表明していただけると大変ありがたいです。よろしくお願いします。--Doraemonplus（会話） 2023年12月19日 (火) 10:57 (UTC)

コメントが付かない場合

7日後までコメントが付かない場合の処置は、待つことでしょうか。反対無しで、最初の投稿者の意見を結論として決定することでしょうか。「7日経ってもコメントが付かない場合や結論が出ない場合は、長期積み残し案件リストに掲載して、他の利用者に意見や助言を求めることができます。」と書かれていますが、実際には7日間程度のうちに反対が無かったので単独で議論を終了し提案を実施（要は「可決」）することも多く行われています。具体例としてプロジェクト:カテゴリ関連/議論/2023年/10月18日やプロジェクト:カテゴリ関連/議論/2023年/12月2日が挙げられます。

影響が大きそうならあくまでコメントを待ち、些細なことで問題ないと自信があるなら単独でも実施するというのが穏当と思います。その判断は個人の良識に委ねられると思いますが。 --2001:240:2479:F73A:8341:3A6D:3D36:F523 2024年1月3日 (水) 11:06 (UTC)

あくまで私見ですが、7日後に…

• 提案内容から結論が明らかな場合 → 提案内容の即時実行
• コメントが付かず、引き続き他の利用者に意見を求めたい場合 → 長期リストに掲載して議論期間延長＋議論活性化のコメント依頼
• 異論が出て意思決定に慎重を要する場合 → 長期リストに掲載して継続審議＋合意形成のコメント依頼

というイメージです。どのような判断を下すかは、時と場合によりけりですね。--Doraemonplus（会話） 2024年1月12日 (金) 11:55 (UTC)

よく見るとプロジェクト:カテゴリ関連/議論/2023年/10月18日の場合は7日経過していませんでした。半日ほど足りていません。結果を左右する程のことではなかったかもしれませんが。 --2001:240:242E:A05F:AE4C:E841:5B1E:8244 2024年1月26日 (金) 08:59 (UTC)

品質保証議論のカテゴリ6について

節を設けるほどではないと思いますが。

品質保証で提案された場合、カテゴリ本体に告知（議論ページへの誘導）がされてないことがあります。そこで即時削除テンプレート（カテゴリ6）を貼られても、カテゴリ6としては提案不備と考えます。プロジェクト:カテゴリ関連/議論の「このページの使い方」の「以下の手順に従ってください。」の2番・提案「以下のテンプレートのうち、対応するものを対象のカテゴリページに貼付してください。」、「4.品質保証の場合: {{subst:CfQA}}」←この手順が抜けています。別にこのテンプレートでなくとも、{{告知}}でも、カテゴリページから「プロジェクト:カテゴリ関連/議論/2024年/〇月〇日」で議論しています、という誘導があればよいのではないかと私は思うのですが。品質保証議論でも、カテゴリ6を依頼することを視野に入れているのであれば、告知していただきたいと思います。--柏尾菓子（会話） 2024年1月9日 (火) 07:01 (UTC)

はい。プロジェクト:カテゴリ関連/議論/2024年/1月1日でやってしまいました。この場合、統合の意思が生じた時点で、対象カテゴリに別個に{{subst:cfm}}を貼り、日別ページに別途、統合提案のセクションを立ち上げるのが、Wikipedia:カテゴリの提案と議論的には“正しい”手続きです。{{告知}}等で代替する方法でも実質同等とは思いますが、下記「#キュー処理時の事前チェック」で検討されているエラーチェックは専用テンプレートの方が判定・処理しやすそうではあります。いずれにしても、ページの削除に関わる大事なことですので、カテゴリ6の提案不備の判定は厳しめにとる運用でよいと思います。--Doraemonplus（会話） 2024年1月12日 (金) 12:07 (UTC)

キュー処理時の事前チェック

カテゴリ本体への告知不備によりWP:CSD#C6での即時削除が差し戻される例をよく見かける気がします。 そこでQueueBotでの処理時に{{Cfrtext}}などの告知テンプレートがカテゴリに貼付されているかをチェックし、貼られていなかった場合はカテゴリ張り替えを行わずエラーメッセージを出して終了するようにする変更を検討しています。 賛成反対のご意見と、別の告知テンプレートを使うことが想定される場合、告知なしでカテゴリの張り替えを行う際にQueueBotを使う場合など、イレギュラーな状況について確認したいです。よろしくお願いします。--鏡華（会話） 2024年1月10日 (水) 04:38 (UTC)

コメント 議論場所・提案内容に依らず、あくまでも貼付された告知テンプレートの種類での判別が前提となると、{{Cfxtext}}系以外では、

• 従来の方式で使用された{{改名提案}}、{{統合提案}}または{{Mergefrom}}・{{Mergeto}}、{{分割提案}}が代表例です。これら従来方式の告知は、今日現在もCategory:JNN番組などで使用例が確認でき、今後も使用される可能性があります。
• 汎用的な{{告知}}の使用も時折見かけますが、こちらは用途が広すぎるため、WP:CSD#C6（カテゴリの改名・統合）の適用要件チェックに使えるかは不明です。議論場所における提案内容まで確認しないことには、どうにも判断がつきません。

記事やプロジェクトのノートなど、WP:CfDサブページ以外で提案・合意されたものを直にカテゴリキューに入力する場合、ほとんどは上記のいずれかのテンプレートで告知されているかと思います。

余談になりますが、WP:CfDサブページもカテゴリキューも現在、1セクション1カテゴリ方式となっており、多数のカテゴリを一斉に改名・統合（提案・キュー出し）するのには向いていません。先日、ノート:浜松市#行政区再編に伴うカテゴリの再編提案では、たまたま件のBot作業依頼を見かけた私が間に入って、WP:CfDへ橋渡ししてキューを出して頂きましたが、これから毎回同様の対応をするわけにもいきません。このようにカテゴリ変更を大量に伴う提案の場合、カテゴリキューよりも従来のBot作業依頼の{{リンク修正依頼/改名}}の方が便利なのは確かです。現在、WP:BOTREQではカテゴリの変更にはカテゴリキューを利用するよう案内していますが、場合によっては従来方式を勧めるべきかもしれません。--Doraemonplus（会話） 2024年1月13日 (土) 14:00 (UTC)

返信 ありがとうございます。{{改名提案}},{{統合提案}},{{Mergefrom}},{{Mergeto}},{{分割提案}}については対応できると思います。
判定しやすいテンプレート以外で告知が行われていた場合は

{{User:QueueBot/options
|skip-notice-check=true
}}

をキューのセクション内に書くことによって告知チェックをスキップできる、などはどうでしょうか。鏡華（会話） 2024年1月29日 (月) 02:58 (UTC)

よく読み返してみたら、カテゴリ6（改名・統合）の要件チェックなので、{{分割提案}}は候補から外れますね。告知チェックのスキップ機能を実装するか、指定テンプレート以外による告知は無効とするか、どちらがよいかは、これまでの実例を精査してみないことには判断できません。今はちょっと、その時間が取れません。申し訳ございません。--Doraemonplus（会話） 2024年1月31日 (水) 13:57 (UTC)

C6がきっかけではありますが、旧来の分割提案手順でも対象ページへの告知が必須なため告知がないと手順不備で分割差し戻しになる可能性があり、チェックに入れてしまって思います。
その他今思い出しましたが、削除依頼でカテゴリが削除された際の除去に使われることもあり(例)、この場合既にカテゴリページが存在しないため告知のチェックが不可能ですね。明示的なチェックスキップ機能を実装するか、ページが削除済みの場合は自動でチェックスキップするかですが、この場合は自動でスキップしていいかなと考えています。鏡華（会話） 2024年1月31日 (水) 14:16 (UTC)

なるほど、確かに{{cfQA}}相当で使われる可能性はありますね。納得しました。

ページの削除の場合、管理者か削除者の方が必ず目視でチェックされているはずなので、告知チェックは自動スキップで問題ないでしょう。--Doraemonplus（会話） 2024年1月31日 (水) 15:05 (UTC)

終了した議論

終了した議論に{{古い話題のはじめ}}と{{古い話題のおわり}}を使用し、終了したとわかりやすくされているのを見かけます。削除依頼も{{Vfd top}}などで終了をわかりやすくしているので、古い話題のテンプレートの使用を推奨した方がよいのではないかと考えました。カテゴリ6などで対処済みの議論を、かなり経ってから議論の続きをされても対応が困難なのではないかと思ったので。--柏尾菓子（会話） 2024年1月28日 (日) 03:07 (UTC)

賛成 議論アーカイブ管理の観点から、終了した議論であることをテンプレートで明示的に伝えることの推奨化に賛成します。ただ、合意形成されて 対処済みの案件は終了時点が明確ですが、議論が停滞して終了したかどうかが有耶無耶になっている議論の扱いは難しいところです。プロジェクト:カテゴリ関連/原則#作業の流れが示す通り、提案日から4週間が経過した議論は強制的に 議論終了または 自動失効とし、Botが自動的に{{古い話題のはじめ}}と{{古い話題のおわり}}を貼るという方法はいかがでしょうか。--Doraemonplus（会話） 2024年1月28日 (日) 14:32 (UTC)

よいと思います。すると、プロジェクト:カテゴリ関連/議論の「このページの使い方」の4にでも手順として説明した方がよいでしょうか。それともBot任せにするのなら、特に不要でしょうか。--柏尾菓子（会話） 2024年1月30日 (火) 12:25 (UTC)

対処済みも対処済みで、キューに追加したら対処済み？それともキューが実行されて実際にカテゴリ変更が行われたのを確認したら対処済み？など認識に揺れがある気がするので、その辺をもうちょっと詰めて「このページの使い方」などに記載しておきたいですね。
Botによる自動失効処理は合意が取れ次第QueueBotで引き受けます。鏡華（会話） 2024年1月30日 (火) 12:32 (UTC)

QueueBotでご対応いただけるのは非常にありがたいです。WP:BOTREQで長年実績のある、 確認を貼ったら{{解決済み}}になるのと同様のシステムを組めれば、自動化できてよいと思います。また、井戸端のサブページの読み込み解除ルールも参考にして、

• 対処か 確認か 終了か 取り下げが貼られたらBotが古い議論テンプレートを貼る
• 最新の投稿から10日間経過するか、最初の投稿から4週間が経過したら、Botが 自動失効と古い議論テンプレートを貼る
• （むろん、提案者自身で古い議論テンプレートを貼るのは構わない）

といったような条件設定の素案はいかがでしょうか。「対処」の時点は、

• キューを利用する場合は実行結果が 確認された時点
• 手作業の場合はカテゴリ変更作業の完了後に 対処を貼った時点

が想定されますが、作業完了後に 確認や 対処を貼り忘れて 自動失効されそうになったり、キューの実行後に手作業で微調整を加えたりするなど、実際のパターンはもう少し複雑そうです。

「推奨化に賛成」しておいて何ですが、もともとカテゴリの提案手続きを出来るだけ簡略化するのがWP:CfDの目標の一つでもあったわけで、あまり煩雑な方法になると、本プロジェクトのメリットが薄れてしまいそうで、対応の仕方が難しいところです。参考にしたドイツ語版では、アーカイブされた議論にマークを付けている様子は特になさそうですし。--Doraemonplus（会話） 2024年1月31日 (水) 14:38 (UTC)

おおよそ問題ないと思います。
確認 をキューに依頼した人のみならず第三者が行っても良いとするなら貼り忘れなども多少マシにならないでしょうか。BOTREQでもごく偶になかなか確認されない依頼をbot作業者や他の運用者が 確認する場合があります。
あまりにも確認待ちが埋もれるようなら下に挙げたような感じで確認待ち一覧のページを作るのもありかもしれません
(1議論1ページではないためCategory:版指定削除後の確認待ち案件のようにカテゴリにすると使いづらい)鏡華（会話） 2024年2月1日 (木) 00:13 (UTC)

理想は、何もしなくても「古い議論」化されるシステムです。もっと単純に、カテゴリ変更の 対処または 確認が貼られるか、最初の投稿から4週間が経過するか、だけでも要件は十分かもしれません。第三者が貼るのは平時は歓迎されますが、もし論争が発生した場合、主導権争いの道具にならないか心配です。平時は言葉のニュアンス的に「対処」はカテゴリ変更の実行者、「確認」は変更結果の確認者が貼ることになるでしょうか。--Doraemonplus（会話） 2024年2月1日 (木) 08:08 (UTC)

『何もしなくても「古い議論」化されるシステム』を突き詰めると、キューには議論場所のリンクが含まれるのでbotがその議論場所に「実行完了」とメッセージを残して自動で古い議論化するなども技術的には可能です。
確認は形式的なものなのか、それとも正しくカテゴリ変更が行われたことを人力で確認することに意味があるのかって点ははっきりしたいかもです(後者の場合「なにもしなくても」とはいかないわけで)。鏡華（会話） 2024年2月2日 (金) 23:49 (UTC)

これに関連した話としてこんなのを自動生成するbotを書いてみたんですが需要はありますか？
個人的な感覚として各日別ページを巡回して議論が終わってないものを探すのがめんどくさい、アクティブな議論一覧がほしいみたいな気持ちで作ったものです。{{古い話題のはじめ}}/{{古い話題のおわり}}を貼るようになるとここからクローズ済みの議論を除外できるのでより有用になるかな？と思います。鏡華（会話） 2024年1月31日 (水) 23:28 (UTC)

こんなことができるのですね。素晴らしいです。現在のプロジェクト:カテゴリ関連/議論/長期積み残し案件リストよりも詳細な情報が示されており、各議論の現況が一目瞭然でよいと思います。どのように運用すべきかは、鳴海さんが提起された#合意形成状態の提案の扱いについても含め、別途議論が必要そうです。

「こんなの」を拝見した感想としては、「長期積み残し案件リスト」というよりも、Wikipedia:コメント依頼の代わりになるのではないかと思いました。同依頼ページに新セクション「カテゴリの提案についてのコメント依頼」を設置して、参照読み込みさせれば、そのままカテゴリのコメント依頼として役立ちそうです（コメント依頼に載せる場合、記載事項と情報量は絞る必要がありそうですが）。--Doraemonplus（会話） 2024年2月1日 (木) 08:24 (UTC)

合意形成状態の提案の扱いについて

プロジェクト‐ノート:カテゴリ関連/議論/長期積み残し案件リストより転記しました。--Doraemonplus（会話） 2024年2月1日 (木) 07:53 (UTC)

「保守管理の目的上、提案から7日経過したカテゴリの議論は原則、終了したものとみなされます」とのことですが、Wikipedia:合意形成には最短で7日の期間が必要です。すなわち7日経過時点で終了裁定が下っていない提案を全て掲載していくと、7日以内に取り下げられたものを除き、ほぼ全ての提案を一旦はここに掲載することになります。保守管理の目的で設けられた条件が、かえってここの保守管理の手数を増やしているように感じます。7日経過時点で合意形成状態にある（反対意見が出されていない）提案についてはここに掲載しなくても良いのではないでしょうか？それ以降でも議論を継続したい方がいる場合は、その当事者が個別に掲載を行えば良いと思います。--鳴海（会話） 2024年1月31日 (水) 16:33 (UTC)

「7日経過した時点で、合意形成されていない場合」、「7日経過した時点でコメントが付かず、引き続き他の利用者に意見を求めたい場合」および「14日経過した時点で、対処されていないもの」を掲載する、というのはどうでしょうか。

--FlatLanguage（会話） 2024年2月2日 (金) 04:46 (UTC)

--(少し変更)FlatLanguage（会話） 2024年2月2日 (金) 06:19 (UTC)

• 返信 (FlatLanguageさん宛) ありがとうございます。ご提案頂いた形でも賛成します。--鳴海（会話） 2024年2月2日 (金) 11:57 (UTC)

  済 反映しました。--FlatLanguage（会話） 2024年2月4日 (日) 08:54 (UTC)

「新規提案作成」リンク関連テンプレートの半保護提案

プロジェクト:カテゴリ関連/議論のトップページやプロジェクト:カテゴリ関連/議論/見出しの「新規提案作成」リンク、および{{Cfd}}、{{Cfm}}、{{Cfr}}、{{CfQA}}の「議論セクションを作成」リンク部分で内部的に呼び出される以下のテンプレートについて、半保護の方針に基づき、影響が特に大きいテンプレートとして半永久的な半保護を適用することを提案します。

• Template:カテゴリ新規提案作成
• Template:カテゴリ新規提案作成/サブ
• Template:カテゴリ新規提案作成/Preload
• Template:カテゴリ新規提案作成/Editintro

本プロジェクトの安定的な運用に関わる重要な部分であり、そう頻繁に改変すべき性質のページではないことから、提案させていただきます。--Doraemonplus（会話） 2024年2月4日 (日) 15:51 (UTC)

• （賛成）プロジェクトにおいて重要だと思いますので、賛成します。--柏尾菓子（会話） 2024年2月6日 (火) 05:03 (UTC)

報告 賛成のみの状態が14日以上継続しましたので、半保護の合意が成立したものと判断し、Wikipedia:保護依頼#カテゴリ新規提案作成テンプレート群を提出しました。--Doraemonplus（会話） 2024年2月23日 (金) 07:48 (UTC)

「プロジェクト:カテゴリ関連/議論/見出し」の「新規提案作成」リンクの不具合

先ほど、プロジェクト:カテゴリ関連/議論/2024年/2月2日の「新規提案作成」リンクから新規提案を作成したところ、投稿日（今日＝2月11日）ではなく、プロジェクト:カテゴリ関連/議論/見出しテンプレートを参照読み込みしている日付ページ（同日＝2月2日）に新規セクションが誤って作成されてしまいました。正しくは、投稿日の日付ページにセクションが作成されるようにしたいのですが、呼び出しているプロジェクト:カテゴリ関連/議論/見出しの該当部分は問題なさそうですし、どこを修正すればよいか特定できませんでした。修正方法が分かる方がいらっしゃいましたら、ご修正いただけるとありがたいです。よろしくお願いします。--Doraemonplus（会話） 2024年2月11日 (日) 07:04 (UTC)

プロジェクト:カテゴリ関連/議論/見出しの{{{年|{{CURRENTYEAR-JST}}}}}がおかしいです。提案日を表示するところと閲覧日を表示するところは違うはずです。--FlatLanguage（会話） 2024年2月11日 (日) 08:00 (UTC)

Special:Diff/97854040/99210631でなおると思います。--FlatLanguage（会話） 2024年2月11日 (日) 08:10 (UTC)

直りました。FlatLanguageさん、ありがとうございます。--Doraemonplus（会話） 2024年2月11日 (日) 10:53 (UTC)

記事の改名に合わせたカテゴリの改名の手順 / よそで行われている議論を見守れないか

Category:東京武蔵野ユナイテッドFCの選手の即時削除をカテゴリ6で依頼したのですが、却下されました。当該議論ではカテゴリにも触れていたのですが、カテゴリページで告知されていなかったことを見逃していました。ただ、主記事名の改名に合わせたカテゴリの改名に反対する人はあまりいないのではないか、とも思います。

そもそも、記事名の改名に合わせたカテゴリの改名の手順は文書化されていないように思います。Wikipedia:カテゴリの提案と議論#所定の提案・議論場所によれば、このプロジェクトジェクトに再提出しなければならないですが、一週間の告知期間ののち記事の改名をし、それからここへ再提出すると、あわせて二週間かかってしまいます。そこで記事は通常の改名提案をし、カテゴリのほうは同時にここへ改名提案を出すと、議論場所が二つに分かれてしまいます。一番簡単なのは、記事もカテゴリも通常の改名提案にすることですが、カテゴリ6で即時削除するには、「カテゴリページに改名提案テンプレートを貼る」「議論ページでカテゴリに触れる」の両方が必要だと思います。大抵どちらかを忘れていて、リダイレクトの削除依頼行きです。

移動後にカテゴリの張り替えすら行われないケースもあって、いまだカテゴリの改名手順は周知されていないようです。うまいことこのプロジェクトから、カテゴリに関する議論を見られないかと思って利用者:FlatLanguage/sandbox/カテゴリに関する議論（過去版）なんてものを作ったりしていますが、ビミョーな感じです。

まとめると、

• 記事名と合わせた改名の提案の手順が文書化されていない
• よそで議論されると正常に改名されていなくても気づけない

という問題があるように思います。これらについて皆さんの意見を伺いたいです。--FlatLanguage（会話） 2024年2月21日 (水) 01:54 (UTC)

（コメント）ノートでは、「Category:東京武蔵野ユナイテッドFC」→「Category:横河武蔵野FC」の提案は行われていますが、「Category:東京武蔵野ユナイテッドFCの選手」→「Category:横河武蔵野FCの選手」は触れられていないため、カテゴリページの告知以前に適用できないと考えます（ので却下しました）。

「記事名と合わせた改名の提案の手順が文書化されていない」は確かに、と思いましたので、文書化するのであれば賛成します。カテゴリに限らず記事でも改名提案を経ずに改名されることがわりとあります。カテゴリも提案すらせずに改名されることは防げないと考えますが（記事が改名したから改名したとか、現実で名称が変わったから改名したとか）、文書化すればそれを指摘する側としても案内しやすくなると思います。

「よそで議論されると正常に改名されていなくても気づけない」については、カテゴリ6を対処する観点としては、10年以上前の提案だろうと履歴を遡って、適用できるか改名提案・統合提案もカテゴリページも議論場所もきちんと確認します。カテゴリに関する議論が見られたら、便利だと思います。

「リダイレクトの削除依頼行き」に関して。改名提案を経たのにもかかわらず、誤字扱いしてリダイレクト1-2で即時削除しようとする利用者が見られるのですが、それと同じで、即時削除は楽をするための手段ではありません。即時削除は誰が見ても異論が出なさそうな案件を、管理者・削除者が裁量で行うものであって、適切に議論が行われていないものは誰が見ても異論が出なさそうとはいえないと考えます（私はカテゴリ独断改名・改変で異議申し立てをしたことがあります）。ですから、リダイレクトの削除依頼の審議に回してください、とコミュニティに判断を委ねるのです。--柏尾菓子（会話） 2024年2月21日 (水) 04:54 (UTC)

確かに当該カテゴリは議論では触れられていませんでした。失礼しました。

「正常に改名されていない」というのは、（告知・議論が正しく行われたかは別として）カテゴリの貼り替えがされていない・移動元が削除されていない、というものを想定していました。つまりこれとかこれとかのことです。

--FlatLanguage（会話） 2024年2月21日 (水) 06:17 (UTC)--(蛇足をノート:即時削除の方針へ移動)FlatLanguage（会話） 2024年2月22日 (木) 00:26 (UTC)

プロジェクト:カテゴリ関連/議論は割とひっそりと始動したので、その存在をご存知ない方は未だ多くいらっしゃると思います。最近ですと、ノート:浜松市/過去ログ2#浜松市の行政区再編に関する作業についてに伴うカテゴリ変更では、Wikipedia:Bot作業依頼/過去ログ/2024年1月#浜松市の行政区再編に伴うテンプレート・カテゴリの張り替え作業が提出されていることに偶然気づいた私が間に入って対応しました。気づいていなかったらどうなっていたのか興味があります。

〈よそで行われているカテゴリ関連の議論を見守れないか〉とのことですが、カテゴリの提案・議論は、Wikipedia:カテゴリの提案と議論#所定の提案・議論場所で案内しているリンク先以外にも、各分野のウィキプロジェクトやウィキポータルのノート、記事のノート、Categoryのノート、Templateのノートなど、各所で行われる可能性があるため、そのすべてを一元的に把握するのは困難であろうと思われます。

かつて私もFlatLanguageさんと似た発想で、カテゴリの削除の事例研究のために、削除依頼サブページの中からカテゴリに関するものだけを抜粋して一箇所に集積できないかと試行錯誤したことがありますが、結局、人力では限界があり、作業は中断しています（参考：プロジェクト:カテゴリ関連/削除依頼アーカイブ）。--Doraemonplus（会話） 2024年2月22日 (木) 11:34 (UTC)

「Wikipedia:削除依頼/Category:」で始まるページの一覧だけでも4000近くあるので、さすがに無理があると思います……利用者:FlatLanguage/sandbox/カテゴリに関する議論のほうは、進行中の議論を、見つけた人がぽんぽん追加していくようなスタイルを想定していました。それでも管理が大変なのでビミョーですが。

ひとまず「記事の改名に合わせたカテゴリの改名の手順」の方に焦点を当てようかと思います。つまり、「記事とテンプレートとカテゴリはまとめて改名議論したいが、そうするとプロジェクト:カテゴリ関連から分離してしまう」という点ですね。--FlatLanguage（会話） 2024年2月22日 (木) 12:47 (UTC)

• Wikipedia:リダイレクトの削除依頼/2024年1月#RFDCategory:ヘラクレスオオカブト属
• Wikipedia:リダイレクトの削除依頼/2024年2月#RFDCategory:スペイン空軍
• プロジェクト:カテゴリ関連/議論/2024年/2月4日#Category:関ジャニ∞をCategory:SUPER_EIGHTへ

こういう例が多すぎて、いい加減あと始末も面倒ですが、放置しても未来への積み残しになってしまうので、ガイドラインを出してこれに従えで終わらせたいです。--FlatLanguage（会話） 2024年2月22日 (木) 13:33 (UTC)

管理が大変なのは、人力で回そうとするからでしょう。#終了した議論セクションで鏡華さんが試作されたこちらのリストは、カテゴリに関わる議論の現況の把握に役立てられそうです。おそらく、リストの作成作業はBotで自動化されているだろうと思います。

プロジェクト:カテゴリ関連/議論の日別議論ページは、議論場所としてだけでなく、告知場所としても利用可能です。実際、プロジェクトの立ち上げ初期には、プロジェクト:カテゴリ関連/議論/2023年/7月31日#Category:国の分類をCategory:国家の分類へのように、最初の告知と進捗報告のためだけに使う方法も試しています。必要最低限の手続きは踏むべきですが、もっと自由かつ弾力的に利用していただいて結構です。--Doraemonplus（会話） 2024年2月22日 (木) 14:51 (UTC)

上記で挙げてくださったリストはbotで生成しています。
1回生成したきりで放置していたので、1週間ほど仮運用してみたほうがいいですかね？鏡華（会話） 2024年2月22日 (木) 15:11 (UTC)

それに関してずっと思っていたのですが、{{古い話題のはじめ}}で議論を閉じると、「編集しないでください」となるので、後から誤字に気づいた場合、作業の間違いがあった場合、異議申し立てする場合、後日コメントがある場合に、編集できなくなってしまいます。削除依頼などでは管理者判断でクローズされますが、こちらでは提案者の独断でクローズされるので、終了したとは言い切れない議論を終了してしまうことがあると思います。改名・統合ならカテゴリ6の受理をもって、削除なら削除依頼の提出をもって終了ということにできるかもしれませんが、それでも後から誤字を修正したい・コメントを書きたいという場合もあると思います。ここでの議論は、統合提案を除いて不可逆性を持たない（改名は差し戻せる・削除は削除依頼で行われる・品質保証は言うまでもない）ので、そこまで厳密にアーカイブ化する必要もないと思います。

Category:話題の状態表示テンプレートや{{section resolved}}のように、議論を閉じずに議論の状態を示せるテンプレートがあったらいいと思います。ここでの議論であるとしたら、「議論中」「議論長期化 / 合意未形成」「要議論活性化」「改名で合意形成（未対処）」「統合で合意形成（未対処）」「合意形成（整理中）」「削除依頼提出済み」「改名済」「統合済」「整理済」あたりでしょうか。

--FlatLanguage（会話） 2024年2月22日 (木) 16:18 (UTC)

プロジェクト:カテゴリ関連/原則#作業の流れなどで再提出に関する規定があったりするのを見るに「今は議論終了してるけど同じ節に異議申し立てがあったら再活性化」ではなく「異議があるなら新しく議論の節を建てよう」という流れを目指しているのかなと感じました。
またキュー申請も実行前であれば異議を申し立てることができるため、議論がクローズする前に問題点についての議論に戻れると思います。
コメントは特記する必要がある場合はノートページを使うことで解決できないでしょうか。

編集できてしまうとそれこそ#トップページの斬新と議論サブプロジェクトの開設が肥大化してしまったように、あとからあとからコメントや追記といった形で議論が長大化するリスクがあるので、1つの節で1つの議論を徹底できる"終了済み議論は編集できない"という形を推したいです。鏡華（会話） 2024年2月22日 (木) 17:06 (UTC)

確かにアーカイブ化は必要かもしれません。ただ、議論の途中経過（一週間たっても議論が継続しているか）が一目で（また、Botによって）読み取れるような仕組みはあってもよさそうです。--FlatLanguage（会話） 2024年2月23日 (金) 14:22 (UTC)

その話を直上のスレッドでしていたのですが、プロジェクト:カテゴリ関連/議論/アクティブな議論一覧(上記で載せて頂いたサンドボックスをプロジェクト名前空間内に作成し直しました)などでは不足でしょうか？鏡華（会話） 2024年2月23日 (金) 14:40 (UTC)

プロジェクト:カテゴリ関連/議論/2024年/1月29日#Category:言語別のトピックスだと合意形成から作業終了まで二週間もかかってしまったので、そういう作業中のものを区別できたら、と思っていました。あるいは、プロジェクト:カテゴリ関連/議論/アクティブな議論一覧を手動編集できるようにすればいいのかもしれません。--FlatLanguage（会話） 2024年2月23日 (金) 14:47 (UTC)

ここでの議論ページは告知場所としても利用可能できる旨は理解しましたが、そのことや、カテゴリの改名の手順が周知されていなければ意味がないと思います。改名提案する方はWikipedia:ページの改名は読んでおく必要がありますが、Wikipedia:カテゴリの提案と議論・WP:MAINTAINCG・WP:CRを熟読しないと、

1. カテゴリページすべてに何らかの告知を貼る
2. Wikipedia:改名提案かプロジェクト:カテゴリ関連/議論で告知する（カテゴリについて触れる）
3. 議論ページでカテゴリについて触れる
4. 合意形成後、カテゴリページを移動する
5. 含まれていたページでカテゴリを貼りかえる
6. 移動元リダイレクトをカテゴリ6で即時削除に出す

という手順を理解できないわけで、そこまで要求するのは難しいと思います。なので、この手続きに慣れた利用者からのサポートをするための窓口が必要だと思います--FlatLanguage（会話） 2024年2月22日 (木) 16:18 (UTC)。

むしろ、今ご説明いただいた6つのプロセスをそのままWikipedia:カテゴリの提案と議論#改名提案の場合に載せてしまって、Wikipedia:ページの改名から適切に誘導すれば、最低限必要な説明は一箇所で済むのではないでしょうか。--Doraemonplus（会話） 2024年2月22日 (木) 23:58 (UTC)

Wikipedia:カテゴリの提案と議論はプロジェクト:カテゴリ関連/議論における議論の説明になっているので、議論場所によらない、カテゴリの改名で守るべきことはWikipedia:ページの改名に直接かいてあってもいいかもしれません。--FlatLanguage（会話） 2024年2月23日 (金) 14:17 (UTC)--(del)FlatLanguage（会話） 2024年2月25日 (日) 02:19 (UTC)

Wikipedia‐ノート:カテゴリの提案と議論にて、改訂を提案しました。--FlatLanguage（会話） 2024年2月25日 (日) 02:18 (UTC)

脚注

PJ参加者向けユーザーボックスの作成について

標題の件について、プロジェクト‐ノート:ユーザーボックス#プロジェクト:カテゴリ関連にて提案中ですので、お知らせします。--Doraemonplus（会話） 2024年2月22日 (木) 14:20 (UTC)

プロジェクト用ユーザーボックスの議論は各プロジェクトのノートにて行うよう指示されましたので、以下の通り転記します。--Doraemonplus（会話） 2024年2月23日 (金) 03:32 (UTC)

---

（転記ここから）

提案 プロジェクト:カテゴリ関連のスタッフである証となるユーザーボックスの作成を提案します。意匠（案）は以下の通りです。よりクールな意匠案も併せて募集します。

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

ユーザーボックスは、Template名前空間に作成の上、ユーザーボックス/ウィキプロジェクトに記載し、ユーザーボックスを貼付した利用者ページをCategory:ウィキプロジェクト カテゴリ関連に参加しているウィキペディアンに追加する仕様とします。--Doraemonplus（会話） 2024年2月22日 (木) 14:18 (UTC)

そもそもスタッフとそうでない利用者でなにか違いがあるのかというという点が気になるので「スタッフの証となる」という提案であれば 反対 寄りです。
単にウィキプロジェクトに参加・積極的に議論に参加していることを示すユーザーボックスとしての作成には 賛成 します。
アイコンはなどが個人的には好みですが、「ツリー構造を整理する」という点を重く見るならば原案にも反対しません。鏡華（会話） 2024年2月22日 (木) 14:55 (UTC)

「スタッフである証」は少し語弊がありました。もっと単純に、プロジェクトの参加者である証です。ただし、ユーザーボックスの掲示は参加者の義務ではありませんし、ユーザーボックスを掲げないからといってプロジェクトに参加してはいけないわけでもありません。--Doraemonplus（会話） 2024年2月22日 (木) 15:00 (UTC)

であれば、「スタッフ=プロジェクト参加者」ということが伝わらず語弊を生むのを防ぐためプロジェクトページ側の用語を変えたほうがいいかもしれませんね。
他の多くのウィキプロジェクトと同じように任意掲示で良いと思いますし 賛成 します。鏡華（会話） 2024年2月22日 (木) 15:02 (UTC)

他のプロジェクトを見ると、ユーザーボックス・バナー・スタブテンプレートの画像は一致していることが多いです（違うこともありますが）。{{WPJカテゴリ関連 バナー}}と異なる画像を使用しているのは意図したものなのでしょうか？せっかくなら、プロジェクト:カテゴリ関連を象徴する画像があってもよさそうですが。--FlatLanguage（会話） 2024年2月22日 (木) 16:31 (UTC)

どのような画像が適切かは思案中で、上記案もサンプル画像にすぎません。とりあえずツリー図のアイコンにしてみただけです。現在のバナーで使用されている本の画像でも構いませんが、何かもっとカテゴリPJらしい画像を見つけられたら、バナー画像ともども、そちらに変更したいです。--Doraemonplus（会話） 2024年2月22日 (木) 23:45 (UTC)

伝わらないなら伝えればよく、プロジェクト:カテゴリ関連/スタッフに新たに「参加者」節を立てて、「当プロジェクトに参加する意思を表明しているウィキペディアンです。カテゴリに関して何かお困り事がございましたら、遠慮なくお尋ねください。参加者の名簿はCategory:ウィキプロジェクト カテゴリ関連に参加しているウィキペディアンで閲覧できます。」などと説明を加える方法では何とかなりませんかね。--Doraemonplus（会話） 2024年2月22日 (木) 23:35 (UTC)

賛成

賛成しますが、各プロジェクトの参加していることを示すユーザーボックスは、そのプロジェクトのノートページで議論を行ってください。--奥園 映月（会話） 2024年2月23日 (金) 00:46 (UTC)

（賛成）ユーザーボックスの作成に賛成します。画像はこだわりがないのでお任せします。

奥園 映月さんが指摘されている件について、プロジェクト:ユーザーボックスに「例外として、他のウィキプロジェクトまたはウィキポータルのユーザーボックスを作成するときは、それぞれのノートページで提案してください。」（引用）とあり、ここで議論したら合意形成として不十分となるのであれば、プロジェクトページに転記すればよいのではないでしょうか（告知を見てきたので、誘導は十分だと思いますけれど）。

プロジェクト:カテゴリ関連/スタッフですが、管理者と削除者がスタッフとして同列に扱われているのが気になっていました。カテゴリに詳しくない管理者・削除者が、リストに載っていたからと会話ページなどで利用者に質問されても困ると思います（質問されることがよくあります）。管理者と削除者も協力しています、くらいにしておいた方がよいのではないでしょうか。--柏尾菓子（会話） 2024年2月23日 (金) 03:30 (UTC)

（転記ここまで）

---

コメント #デザイン案ギャラリーにて、ユーザーボックスのデザイン案をいくつか作成してみました。デザイン案は今月末を期限として募集し、最終的には来月あたりに投票を実施して決めようかと考えています。なお、スタッフの記述に関しては、先ほど修正しました。--Doraemonplus（会話） 2024年2月23日 (金) 09:39 (UTC)

遅くなりましたが、スタッフの修正を確認しました（議論が多くて細部まで目を通しきれておらず、今見ました）。対応してくださり、どうもありがとうございます。--柏尾菓子（会話） 2024年2月25日 (日) 06:43 (UTC)

 お知らせ 下記の通り、当プロジェクトのユーザーボックスのデザインを決める投票を実施します。奮ってご参加ください。--Doraemonplus（会話） 2024年3月1日 (金) 12:48 (UTC)

 お知らせ Template:User WikiProject Categoryにて作成しました。どうぞご利用ください。--Doraemonplus（会話） 2024年3月18日 (月) 09:59 (UTC)

デザイン投票

投票実施要項

• #デザイン案ギャラリーの8案の中から、当プロジェクト用のユーザーボックスのデザインとして好みのデザインを選択する。
• 投票場所は、#デザイン案投票所とする。
• 投票資格は、投票開始時点でアカウント作成から10日以上経っており、総編集回数が50回以上のログイン利用者とする。
• 投票期間は、2024年3月3日（日）0時0分から同3月17日（日）23時59分まで（JST）とする。
• 投票は複数選択可、持ち票は1人2票までとする。ただし、投票は1案につき1票まで可とする。
• 最終的に最多得票を獲得したデザイン案をユーザーボックスのデザインに採用する。
• 第1位の得票数が同点となった場合、1位の案のみで決選投票を実施する。決選投票は1人1票までとし、より多くの票を獲得した案を採用する。

デザイン案ギャラリー

A-1（オリジナル）

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

A-2（ドイツ語版より）

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

B-1（オリジナル）

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

B-2（英語版その1より）

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

B-3（英語版その2より）

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

C-1（フランス語版より）

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

D-1（日本語版バナーより）

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

D-2（ロシア語版より）

この利用者はウィキプロジェクト カテゴリ関連に参加しています。

デザイン案投票所

以下、投票したいデザイン案に付番および時刻付きで署名（# ~~~~）してください。

A-1

A-2

B-1

1. 柏尾菓子（会話） 2024年3月3日 (日) 09:11 (UTC)
2. Prefuture（会話） 2024年3月4日 (月) 00:34 (UTC)

B-2

B-3

1. Doraemonplus（会話） 2024年3月2日 (土) 15:11 (UTC)
2. Prefuture（会話） 2024年3月4日 (月) 00:34 (UTC)

C-1

1. Doramiso-JAWP (トーク|投稿記録|ログ|CA) 2024年3月7日 (木) 03:28 (UTC)

D-1

1. Doraemonplus（会話） 2024年3月2日 (土) 15:11 (UTC)
2. 柏尾菓子（会話） 2024年3月3日 (日) 09:11 (UTC)
3. Doramiso-JAWP (トーク|投稿記録|ログ|CA) 2024年3月7日 (木) 03:28 (UTC)

D-2

無効票

#B-1 20240302--Knowifr（会話） 2024年3月3日 (日) 00:30 (UTC)投票資格なし。アカウント作成後1日未満、編集回数3回--mametofu(会話/投稿記録) 2024年3月3日 (日) 00:35 (UTC)

投票の結果：

最多得票 3票を獲得したD-1案をユーザーボックスのデザインに採用することとします。ご投票いただいた皆様、ありがとうございました。--Doraemonplus（会話） 2024年3月18日 (月) 09:25 (UTC)

新たに分割について

カテゴリの提案と論議で、今までは改名・削除・統合・品質保証と出ましたが、新たに分割で「分割提案中のカテゴリ」はどうでしょうか。--あいさんさん（会話） 2024年2月23日 (金) 02:36 (UTC)

あいさんさんさん、貴重なご意見をありがとうございます。調べてみると、英語版のWP:CfDでは分割提案を独立した提案種別として扱っているようですが、独語版の提案種別を採用した日本語版では現在、分割提案は品質保証提案の一部となっています。それは一体なぜか。

私なりに考察すると、カテゴリの分割は結論、分割対象となる親カテゴリの内容（構成）を変更する提案であり、ある意味では、親カテゴリの分割先カテゴリの作成提案ともいえます。

通常、真っさらなカテゴリを新規作成する際には、特に提案と議論は不要である一方、既存のカテゴリ構造を変更する（即ち、既存のカテゴリの下位カテゴリとする）編集はWP:MAINTAINCG「編集者向けの注意事項」において、提案と議論に基づく合意形成が必要とされます。この意味において、カテゴリの作成提案と分割提案の差異は紙一重です。

提案の名目が分割であるにせよ作成であるにせよ、親カテゴリの内容の精査を伴う点では同じなので、諸々含めて「品質保証提案」として処理する仕様になったものと推測されます。

そういうわけで、カテゴリの分割を提案する場合は名目上、品質保証提案として提出するよう、お願いいたします。実際に品質保証提案してみて、何か不都合な点がございましたら、そのときに改めて分割提案について検討してみましょう。--Doraemonplus（会話） 2024年2月23日 (金) 06:30 (UTC)

過剰なカテゴリのガイドライン名の改名について

現在、Wikipedia‐ノート:過剰なカテゴリ#「過剰なカテゴライズ」への改名提案（再掲）にて、Wikipedia:過剰なカテゴリのWikipedia:過剰なカテゴライズ等への改名を提案中です。しかし、なかなか意見が付かないため、議論が停滞しています。簡単でも結構ですので、ご意見・ご感想をお寄せいただければ幸いです。--Doraemonplus（会話） 2024年2月23日 (金) 10:00 (UTC)

カテゴリの移動を移動依頼の対象とする提案

議論はWikipedia‐ノート:即時削除の方針#カテゴリの移動を移動依頼の対象とする提案にて--FlatLanguage（会話） 2024年2月25日 (日) 01:54 (UTC)

カテゴリページのPathnavについて

Wikipedia:井戸端/subj/カテゴリページのPathnavについてにて話題提起しました。ご意見をお寄せいただければ、ありがたいです。--Doraemonplus（会話） 2024年2月25日 (日) 05:55 (UTC)

Wikipedia:カテゴリの提案と議論

Wikipedia:カテゴリの提案と議論ですが、全くカテゴライズされていない上に、プロジェクト:プロジェクト関連文書#カテゴリ付与のガイドラインにあるリストにも掲載されていません。この文書がどういう経緯で作成されたのか分からないのですが、ちょっとまずそうです。実態からすると、Category:草案、Category:記事を執筆する、Category:ページの分割と統合、Category:カテゴリの提案を付与すれば良いところでしょうか。--FlatLanguage（会話） 2024年2月27日 (火) 05:45 (UTC)

コメント 同文書の起草者です。カテゴリに関わる提案に関して、Wikipedia:改名提案、Wikipedia:統合提案、Wikipedia:分割提案などに代わる文書として、あるいは、プロジェクト:カテゴリ関連/議論のトップページにゴチャゴチャと手順を書くよりも別文書として説明した方がすっきりする、などの理由で作成しました。「プロジェクト:カテゴリ関連/議論」の正式リリースと同時にガイドライン化を提案する予定でいましたが、正式リリースの形をとらずに来たために、ガイドライン化されることなく、現在に至っています。Wikipedia:改名提案なども、特に「方針」とも「ガイドライン」とも銘打っていないので、まあ別にいいかと思い、放置していました。文書の位置づけは、ガイドラインというよりかは、手順書といったところだと思います。Template:Category プロジェクト関連文書の「文書の位置づけ別の分類」でいうならば、ウィキペディアの解説というところでしょうか。--Doraemonplus（会話） 2024年2月27日 (火) 12:38 (UTC)

Wikipedia:ページの改名やWikipedia:ページの分割と統合などと比較するべきでは？--FlatLanguage（会話） 2024年2月27日 (火) 14:07 (UTC)

そうですね。内容的には、Wikipedia:改名提案/ヘッダ#ガイドラインに相当するので、少なくともウィキペディアのガイドラインとはいえそうです。同意します。--Doraemonplus（会話） 2024年2月27日 (火) 23:21 (UTC)

ガイドラインに格上げするにはコメント依頼の上での合意が必要でしょうし、まだ文面も練る必要があるでしょうから、それまでは{{proposed}}にすべきように思います。--FlatLanguage（会話） 2024年2月29日 (木) 09:10 (UTC)

正式リリースのタイミングでガイドライン化を検討すればよいと思い、現時点では草案でよいと思います。同意します。--柏尾菓子（会話） 2024年3月1日 (金) 09:39 (UTC)

とりあえず最初に挙げたカテゴリを付与しました。--FlatLanguage（会話） 2024年3月3日 (日) 01:31 (UTC)

カテゴリの履歴統合

リダイレクトの削除依頼にて、2024年2月26日 (月) 04:26(UTC)に依頼されたことをきっかけとして、履歴統合について提起します。

• 履歴統合は「ページの統合後にリダイレクト化された方のページが、何らかの理由で（投稿履歴と共に）削除される場合、またはその危険性が高い場合」「コピー&ペーストで移動された後に有用な投稿履歴が積み重ねられた場合」（括弧はWP:HMより引用）に検討すべき、とあり、ほとんどが履歴不継承にならないようにするために行うものです。使用してカテゴリとしての履歴があったとしても、文章としては創作性のないような定義1文くらいしかないようなものもあり、「以下に該当する場合は履歴統合をする必要はありません。」の「コピー&ペーストによる移動がされたが、それ以外の有用な履歴がない場合」（括弧はWP:HMより引用）の「有用な履歴」として見なされるか、微妙だと考えました。記事などでは創作性がない文章しかなければ、履歴統合しません。
• カテゴリでは今まで使用してきた編集履歴自体が「有用な履歴」である、というプロジェクトでの合意形成をすれば、履歴統合してもよいのではないか、と考え、提起します。合意形成がない場合、創作性のある履歴がないので履歴統合不要、という意見がついてもおかしくありません。
• たとえば「Category:エベレスト登山家」→「Category:エベレスト登頂者」ですが、前者の定義が「エベレスト登山家に関するカテゴリ。」、後者の定義が「世界最高峰エベレストを登頂した人物のカテゴリ。」で、文章が全然違います。記事の場合は、内容が異なるものは履歴統合できません（上記「コピー&ペーストで移動された」に該当しない）。記事でなくとも、ここまで異なると履歴統合できないと考えます。こういう場合はどうしましょう。

ご意見をいただけると幸いです。よろしくお願いいたします。--柏尾菓子（会話） 2024年3月1日 (金) 10:17 (UTC)

雑な依頼をしてしまってすみません。Category:コロムビアミュージックエンタテインメント（ノート / 履歴 / ログ / リンク元）のように履歴継承を主張するものもあって、判断を仰ぐという意味でも依頼しました。私としては削除依頼案件となっても反対しません。Category:ピジン英語など、初版作成者が偽装されてしまうのは悲しいですが。--FlatLanguage（会話） 2024年3月1日 (金) 11:44 (UTC)

そしたら

・移動カテゴリ違いです・

みたいなお知らせをすればどうでしょうか?(雑ですみませんが…)--Knowifr（会話） 2024年3月3日 (日) 00:38 (UTC)

@Knowifr:さん お知らせでは、お知らせをしたカテゴリは空のカテゴリ状態であることは変わらず、未使用のカテゴリになってしまいます。お知らせの上に転送記述をし、ページをリダイレクト化することもWP:CRによりできません。ので、残念ながら解決できないと考えます。--柏尾菓子（会話） 2024年3月3日 (日) 09:30 (UTC)

（追記）カテゴリ自体にお知らせするものと考えて返信しましたが、異なる想定でしたらご指摘ください。--柏尾菓子（会話） 2024年3月3日 (日) 09:33 (UTC)

記事を移動した人に

・この記事(リンク)は移動カテゴリ違いの可能性があります

推奨カテゴリはこちら(カテゴリ)です・

とお知らせして個人判断させる想定です--Knowifr（会話） 2024年3月10日 (日) 09:01 (UTC)

@FlatLanguage:さん これからのプロジェクトの方向性としてはどうしましょう。

1. 履歴統合できるならする、「Category:エベレスト登山家」のように無理なものは諦める
2. 全部履歴統合はしない

Wikipedia:リダイレクトの削除依頼/2023年9月#（履歴統合）Category:日産ディーゼル工業のように履歴統合したこともあります。この件では適切ではなかった、という意見はきていませんので、内容的に履歴統合できるものをしてはいけないことはないと考えています（ただプロジェクトの合意がないと、上記のような意見がつく可能性もあります、ということです）。--柏尾菓子（会話） 2024年3月3日 (日) 09:30 (UTC) 節ジャンプ先補正。--Triglav（会話） 2024年3月26日 (火) 14:39 (UTC)

2については、私からは賛成も反対もしません。他の方針との兼ね合い難しいところだとは思います。（2014年以前及び2023年以降の）カテゴリ6で履歴ごと即時削除できるのが、「カテゴリの履歴は有意なものではない」という認識によるものなら、一方で履歴統合の対象にはするというのはダブルスタンダードになってしまいそうです。--FlatLanguage（会話） 2024年3月3日 (日) 09:40 (UTC)

明確な結論が出ないまま削除されてしまいました。カテゴリは履歴統合できないものということで良いのでしょうか。--FlatLanguage（会話） 2024年3月22日 (金) 15:40 (UTC)

「カテゴリは履歴統合できないもの」というより、あのままリダイレクトの削除依頼に長期間放置しておくことはできないため、あの審議としての判断は「削除」だったのだと思います。いまはプロジェクトの合意がないため、リダイレクトの削除依頼での審議内容でどうするかを判断するしかありません。

1. リダイレクトの削除依頼で削除だったので、今後も履歴統合しない
2. プロジェクトでもう少し意見を募り、履歴統合するか議論する

今回のリダイレクトの削除依頼では削除となっても、その後にプロジェクトの合意として結論がでた、というのであれば、今後はそちらを優先していくと思います。正直、個人的な意見としては、今回削除だったので削除でもよいのではないかとも思いました。--柏尾菓子（会話） 2024年3月23日 (土) 04:33 (UTC)

カテゴリとしての履歴があるページをRFDで削除できてしまうというのは何かおかしい気がします。これだと削除したいカテゴリをリダイレクト化してRFDできてしまいます。--FlatLanguage（会話） 2024年3月23日 (土) 04:33 (UTC)

競合しました。確かに、その通りですね。今までは「カテゴリとしての履歴があるページ」はリダイレクトの削除依頼では削除できない、という運用だった気がしますが、今回は対処者によるなんらかの判断基準があったのかもしれません。--柏尾菓子（会話） 2024年3月23日 (土) 04:36 (UTC) 下線部追加。--柏尾菓子（会話） 2024年3月23日 (土) 04:42 (UTC)

では、悪用防止のためにも、履歴統合する、あるいは「カテゴリとしての履歴があるページ」はリダイレクトの削除依頼には提出せず、通常の削除依頼にのみ提出する、というプロジェクトの合意をしておくのはどうでしょうか（後者はわかりやすく文書化する意味で）。--柏尾菓子（会話） 2024年3月23日 (土) 04:42 (UTC)

反対しませんが、井戸端でやったほうがいい議論に思えてきました。--FlatLanguage（会話） 2024年3月23日 (土) 04:47 (UTC)

プロジェクトの合意をするのに、井戸端で議論提起してもプロジェクトで行ってください、と言われるだけだと思いますので、井戸端に告知しました。--柏尾菓子（会話） 2024年3月23日 (土) 05:01 (UTC)

執筆なしページについて 意見募集

https://ja.m.wikipedia.org/wiki/%E9%80%86%E6%88%BB%E3%82%8A

このような執筆なしページについて意見交換しましょう--Knowifr（会話） 2024年3月10日 (日) 08:58 (UTC)

このようなページを削除対象にするかどうか意見募集しています--Knowifr（会話） 2024年3月23日 (土) 04:05 (UTC)

それはカテゴリ関連のプロジェクトと活動内容が異なると思いますので、ここで議論すべきことではないと考えます。このようなページはひとつだけでなく、Category:ウィクショナリーへのソフトリダイレクトを見ると結構存在します。「ウィクショナリーへのソフトリダイレクト」がすべて不要であると考えるなら井戸端などで相談、この「逆戻り」のページだけが不要であった（誤って作成してしまった）のであれば、全般8で即時削除の依頼をしたらよいと思います。あるいは作成したものの、判断に迷っている場合はリダイレクトの削除依頼の審議に出して、ほかの方から削除存続の意見をいただくのもよいと思います。--柏尾菓子（会話） 2024年3月23日 (土) 04:14 (UTC)

そうしてみます--Knowifr（会話） 2024年3月23日 (土) 08:40 (UTC)

子カテゴリ・記事に対するカテゴリの役割付与について

プロジェクト‐ノート:カテゴリ関連#カテゴリの機能改良の要望を財団へ提出する案について　にありました記事におけるカテゴリの役割を考慮した情報付与に関するコメントです。

指名もあり、新しい節を立てさせてもらいました。

議論のポイントは、カテゴリの階層構造を考えるにあたり、個別のカテゴリの類型を考えるのではなく、『カテゴリ自体に対してテーマとかクラスという属性を持たせても効果は薄く、むしろカテゴリ-記事間、カテゴリ-カテゴリ間の関係性に対してテーマかクラスの属性を持たせる方が問題の解決には有用である』という理解のもとで、その類型を表現できるようにしましょう、という提案についてのお話です。

ここで提案されたようなカテゴリ間の関係（memberofなど）について、カテゴリ記事の包含関係において推移律（A→BとB→CならA→C）が成り立つかどうかについて分類をした試みを Wikipediaカテゴリオントロジー - Wikipediaカテゴリの知識工学的観点からの活用を目指して -という形で整理しています。このような分類を導入する際の議論の一助になればと思います。

また、Doraemonplusさんや Bit さんが指摘しているように個別のカテゴリについてテーマとクラスの分類が難しいというのは、基本的に同意します。ただ、難しいのは、「クラス」カテゴリの中に、「テーマ」的なものが混じる場合で、Category:トヨタ自動車のように「テーマ」カテゴリとして分類することが順当なカテゴリも多いようにも思います。

難しい例ですが、例えば、Category:大学はクラスの役割が想定され、多くの具体的な大学を表した記事がそのサブカテゴリに存在します。一方、このカテゴリに、直接所属している記事は、大学をテーマとして扱うような記事（大学受験）となります。このような現象は、「クラス」に属する記事の量が増えた時に、「クラス」に属する記事がCategory:コンテナカテゴリなどに属するようなカテゴリで分割される一方で、「テーマ」として扱う記事は、上位階層に残るという場合に起こることが多いのではないかと考えています。このようなカテゴリを機械的に判断することは、ある程度できるのではないかとも考えています。

一方、 Bit さんのご提案のように、個別に、カテゴリ-記事間、カテゴリ-カテゴリ間で分類すれば、このような状況を整理することはできるのかもしれませんが、一貫性を持って付与していただくのは、結構面倒かもしれません。ただ、将来的には、上記の論文で提案している人手で作成してるオントロジーをベースに自動的に関係分類を行えるようになると、細かな情報の付与も支援できるようになるかもしれません。ご意見をお聞かせください。--Wcontology（会話） 2024年3月12日 (火) 03:10 (UTC)

新しい節の立ち上げありがとうございます。論文も拝読させていただきました。正確な考察と手作業による関係性（…のことをオントロジーって言うんですかね？）の付与・分類、頭が下がります。

私の基本的な考え方は「ルールや名前や記述は、より少なくてシンプルな方が、より良い」です。現状のカテゴリの方針は以下のような複雑さを孕んでいます。

• クラスカテゴリとテーマカテゴリの区別が必須
  • クラスカテゴリの下位にテーマカテゴリを持ってきてはいけない
    • これを周知し違反を減らすため、実質的に{{クラスカテゴリ}},{{テーマカテゴリ}}の貼りつけが必須となる
  • クラスカテゴリかつテーマカテゴリのようなものがどうしても出てくる
    • そういうカテゴリは冠カテゴリとして記事とカテゴリで違う扱いをしなければならない
    • または便宜上の別名を与えて、コンテナカテゴリを1段増やし、ローカルな分類ルールを作らなければならない
      • Category:大学の例で言えば、大学受験といったテーマ的記事やカテゴリを許容する場合、個別の大学のみを入れるルールで縛ったCategory:個別の大学のようなコンテナを作らなければならない（実際にはCategory:大学種別、Category:都市別の大学などで運用している模様）
        • これはWikipediaのカテゴリの方針ルールに精通した編集者以外から見れば、やけに冗長で奇妙な表現に見える

私の提案だと、複雑さは以下のように激減する認識です。

• カテゴリ-カテゴリ間や記事-カテゴリ間に関係性「クラス」を付けるか「テーマ」を付けるかの区別が必要
  • これを守っていれば、他には特に何も要らない

また、関係性を表す記述をmemberof, partof, belongto…などと複数の自然言語でもって用意し、どれを選んでも良いようにすることで、編集のハードルを下げられるのではないかと思っています。

ご指摘のように、「一貫性を持って付与していただくのは、結構面倒かも」知れないというのは、仰る通りですが、私はある程度楽観的です。というのは、人間には類推の能力があり、他の人のやっているのを見て真似ることができるからです。この能力が働くのは当然、作業者の理解が及ぶ範囲なので、できるだけ複雑にしたくない(シンプルにしたい)という話に戻るわけです。また、カテゴリ本文にある程度の指標を記述しておくのも有効なのではないかと思います。(例：「実際に存在する/した大学そのものや複数の大学のグループの記事・カテゴリのみを分類してください。大学に関連するだけの記事・カテゴリはrelatedtoでのリンクにしてください。」等）

もちろん、Wcontologyさん作成のデータを提供いただき、bot等を使って自動で貼りつけできれば、更にやりやすくなるかと思います。--Bit（会話） 2024年3月13日 (水) 11:32 (UTC)

@Wcontologyさん 突然の一方的な指名にもかかわらず、快く応じてくださり、心より感謝申し上げます。本論に先立って、基本的な理解をいくつか共有しておきたいと思います。

• 現在では、ウィキペディアのカテゴリ以外にLinked Open Dataを提供する姉妹プロジェクト・ウィキデータが公開されています。SPARQLクエリを書くスキルがある人なら、カテゴリよりも精細なクエリ結果を利用することが可能です。今、カテゴリ体系を再考するにあたり、私が思うのは、（ウィキデータに対する）カテゴリの長所は「手軽さ」です。難解なクエリを書けなくても、長いクエリ実行時間を待たなくても、すぐに簡単にカテゴリの中身を取り出すことができるからです。本提案では、カテゴリ構造の精緻化のため、項目間の関係性を表現する、より詳細な属性を取り扱いますが、この「手軽さ」は失いたくない要素です。
• その上で、利用者の視点に立ってみると、カテゴリに期待する機能は主に、

1. 昔のYahoo!のディレクトリ検索のように使いたい（ディレクトリ派）
2. 類似する記事を分類や分野で主題検索したい（クラス＝分類派）
3. 何について書かれた記事かで主題検索したい（テーマ＝件名派）
4. 記事のメタ情報のデータベースとして使いたい（データベース派）

のいずれか（または複数）が想定されます（前回議論より引用）。ウィキデータは4.のデータベース派向けであると考えると、残りの3つがカテゴリの役割になります。現状は（Category:大学の例でも示された通り）2.と3.が混交した状態であり、全体として推移律が成立していない「近視眼的」な構造化（全体図）に陥っている点で、微視的には、1.のディレクトリ構造（図式）っぽくも見えます。カテゴリに関して最も先進的な独語版では、de:Kategorie:Universitätの上部構造の全体図はすっきりしており、体系の一貫性が高い水準で保たれています。

@Wcontologyさん、Bitさん 閑話休題。

• memberof, partofなどの属性を新たに設けるにしても、先に見たように日本語版では、元のカテゴリ-カテゴリ間を結ぶ「糸」が、「結びついている」というより「絡みついている」状態なので、付与した属性を生かしきれないのが現実であろうと認識せざるを得ません。仕様を「シンプルにしたい」のは山々ですが、今の状態のまま属性を付与しても、さらに複雑になるだけです。したがって、カテゴリ構造自体の抜本的な大改造も併せて検討していく必要があります。
• 方策としては、

1. （以前に柒月例祭さんが示唆された）分類系のカテゴリとテーマ系のカテゴリを完全に別の名前空間に分離してしまう方法
2. 分類系とテーマ系を同じ名前空間に同居させたまま、内部的にmemberof, partof, belongtoなどの属性を付与して識別する方法

のいずれかが考えられます。ただ、いずれの方法を採るにしても、実現にはMediaWikiソフトウェアの改修が必須です。それに付随して、PetScanやvCatなどの関連ツールも改修が必要でしょう。改修のコストを最小限に抑えるには、2.よりも1.の方法が、現在のCategory名前空間と同等の機能を持つ名前空間をもう一つ用意するだけで済む点で、よりシンプルだと思います。1.を採用して名前空間を分離すれば、クラスカテゴリとテーマカテゴリを区別する必要性がなくなります。

• 件名名前空間（仮称）のカテゴリでは、「記事-カテゴリ間」の「関連」を示しさえすればよく、「カテゴリ-カテゴリ間」の関係性（構造化）の明示は、そもそも構造化自体が全く不要か、構造化するとしても件名（カテゴリ名）のシソーラス構造で済ませられるので、細かな属性付与は不要です。よって、関係性の問題は、分類名前空間（仮称）のカテゴリだけの問題に帰結すると考えてよいと思います。
• プロジェクト:カテゴリ関連/資料/件名語を用いたカテゴリ構造の事例集を参考にすると、分類に関わる関係性の型は、

1. 類種関係（Category:大学⊃Category:国立大学 / Category:国立大学∋北海道大学）
2. 全体部分関係（Category:大学院⊃Category:研究科）

の2つはまず間違いないとみています。Category:北海道大学のようなカテゴリは、分類というよりはテーマを示していますので、件名名前空間に移行することになるでしょう。この点だけでも、絡まった糸を解くには十分です。たとえば、記事「北海道大学大学院工学研究院・大学院工学院・工学部」には、（大まかに）分類:大学院、分類:学部、件名:北海道大学、件名:工学が付与されるイメージです（実際の分類はサブクラス化されます）。

--Doraemonplus（会話） 2024年3月14日 (木) 14:32 (UTC)

「絡まった糸」といえば、日本語版のカテゴリはループが多いのでした。--FlatLanguage（会話） 2024年3月14日 (木) 15:25 (UTC)

ループが多い理由は、カテゴリの階層関係を微視的（直接の親子関係）にしか見ていなくて、ループ構造に気づきにくいためでしょうね。テーマ系を分離し、上から下まで一貫した分類をすれば、階層構造は自然と簡素で単純明快なものになるはずです。

名前空間を分けるアイデアの考え方は、いわば曖昧さ回避のカテゴリ版といったところで、分類派もテーマ派も満足するような仕組みにしたいです。--Doraemonplus（会話） 2024年3月14日 (木) 23:30 (UTC)

• ウィキペディア日本語版のカテゴリ構造がぐちゃぐちゃに絡み合っている件について、大学の上位の全体図を拝見する限り、単に不適切なカテゴリ分けをしてしまっている例が(残念ながら多く)あり、その整理整頓だけでもある程度改善できるのではないかと思いました。いずれにしても、システム改修と並行して行っていく必要があることに同意します。
• 一方で、現状のシステムでは対応できない類の煩雑さがあります。完全な集合・要素関係を担保するためだけのコンテナカテゴリが多すぎることで、典型的な例を挙げますとCategory:言語別にある多くのサブカテゴリです。
• 改修のコストについて、それを最小に抑えるのを第一として方針を決める必要はないと思います。各言語版Wikipedia利用者(ここでは閲覧者)の利便を最大化することをゴールとして、そのゴールを達成するための各言語版Wikipediaの編集者の労力を最小化する(混乱を収めることを含む)、そのためのシステム改修なので、改修そのもののコストに振り回されてるのは本末転倒だからです。
  • 私見ですが、ソフトウェアというものは、人間の作業を自動化して楽にすることが存在意義と思っています。
  • もちろん、コストが大きすぎて実現できないとか、運営母体を傾かせるとかは駄目ですが、今回は両案とも現実的なコストの範囲に収まっていると思います。
• 私が「関係性」の方の案を推す最大の理由は、再利用性の高さです。Wcontologyさんの論文でカテゴリの類型を考察いただいていて、Category:大学に対してCategory:アジアの大学, Category:日本の大学など制約付けでサブカテゴリが作られていきますが、注目すべきなのは、ここでは制約条件を成しているアジア・日本などの地域や国は、それ自体がまた分類構造の中にいる点です。「日本の大学」は「分類：大学」を「テーマ：日本」という制約で絞った部分集合なのですが、「日本」はいついかなる場合もテーマなわけではなく、地球 > ユーラシア大陸 > アジア > 東アジア > 日本 > ○○地方 …のごとき分類構造の途中にもいるのです。それなら、名前空間は分けないで「あっちの分類を制約とするこっちの分類の記事/カテゴリ」という表現ができる方が無駄が少ないと考える次第です。

--Bit（会話） 2024年3月23日 (土) 13:01 (UTC)

コメント コンテナカテゴリ（メタカテゴリ）が多すぎる点（特に指標別分類系）は私も同感で、ただ上位カテゴリを煩雑にするだけの「指標別」系の有用性には疑問を持っています。が、必要最小限のもの（少なくとも地域別と時代別）は有用であろうと考えています。

• 「制約付き」論に関しては、同論文によると、上位のSetカテゴリまたはTopicカテゴリからの分割が前提条件となっていますが、SetとTopicの区別が判然としないカテゴリに適用可能かどうか、やや疑問です。すなわち、「日本」による制約を受ける「日本の大学」の分割元である「大学」はSetかTopicか、ということです。現状では、同カテゴリはSetとTopicの両方の役割を兼ねています。この状況では、「制約付きSetカテゴリ」と「制約付きTopicカテゴリ」に分けるのは無理ではないかと存じます。
• そもそも当議論は、カテゴリ単位でSetかTopicかの属性を与える既存の方法論には限界があるという考えが出発点であったはずで、これを解決するには「制約付きSetカテゴリ」「制約付きTopicカテゴリ」という従来の見方からは脱却する必要があると思います。その上で、カテゴリー記事間、カテゴリーカテゴリ間に対して属性を定義するBitさんの新しい方法論の中で、Wcontologyさん発の「制約」のtypeをどのように詳細に規定していくかが求められているのだろうと理解しています。
• システム改修に関しては、新システムへの円滑な移行のためには、既存のカテゴリ資産・ソフトウェア資産との互換性の問題は重要な懸案事項の一つでしょうね。十分に実現可能な方法でなければ、ここの議論がすべて水の泡になりかねないので。また、ウィキメディアの運営・開発陣の大多数は英語圏の人々なので、英語話者にも理解できるような理論の構築と明解な説明が要求されます。
• 「関係性」の具体案については、下記の（素案）で触れていますが、不足がありましたら、適宜ご指摘・ご修正いただきたいです。「制約」関係をどのように具現化するのかも未検討事項です。私としては、論文に基づいて作成されたwcontology.orgを最大限生かしつつ、論文に書かれていない有用な方法論も取り入れて、Wcontologyさんのご提案を実現させたいと思っています。--Doraemonplus（会話） 2024年3月24日 (日) 07:56 (UTC)

  早速のコメントありがとうございます。

  • はい、コンテナカテゴリについて、もちろんご指摘のように必要なものもある認識です。システム上の都合で仕方なく作られたものではなく、閲覧者の利便性のために作られたものですよね。
  • 制約のtypeをどう決めるかとのことですが、私としては「制約である」「制約でない」だけを区別すれば良いと考えています。制約であるものは、そのカテゴリにとってテーマ/Topicです。制約でないものが、分類/Setです。その関係性を記述するという案です。
    • 制約であるかないかの基準は、「集合と要素の関係かどうか」で判断できると思います。（素案）のノートの方に図付きでコメントさせていただきましたのでご参照下さい。

  --Bit（会話） 2024年3月24日 (日) 17:12 (UTC)

（素案）どのみちソフトウェアの改修が必要になるなら、名前空間を分離せず、属性付与によってのみ項目間の関係性を表現した場合も想定してみようということで、Category:大学を例題として、Wcontologyさんの提案に沿った、新しいカテゴリページのデザイン案も利用者:Doraemonplus/新カテゴリページUI案に試作してみました。一応、

• 「下位カテゴリ」とは「クラス・サブクラス」の関係
• 「部分カテゴリ」とは「全体・部分」の関係
• 「関連カテゴリ」とは「連想」の関係
• 「カテゴリに分類されているページ」とは「クラス・インスタンス」の関係
• 「カテゴリに関連するトピック」とは「テーマ・トピック」の関係

に寄せてみたつもりです。RDFスキーマでは、より詳細に記述されることになるでしょうか。--Doraemonplus（会話） 2024年3月15日 (金) 09:44 (UTC)

技術的な話をすると、wikitextからカテゴリに関する記述を取り除き、Multi-Content Revisions (MCR)でカテゴリデータを構造化データ形式で管理するのはどうか、という提案がありましたね。(phab:T132072など)
構造化データによるカテゴリ管理が実現すればこの属性付与による関係性表現は割と現実的になります.鏡華（会話） 2024年3月18日 (月) 14:49 (UTC)

新情報ありがとうございます。ざっと拝見して、かつて記事ページ本文に記載していた言語間リンクを現在ではウィキデータで管理しているのと同様に、カテゴリも構造化データ化してページ本文とは独立させた「スロット」で版管理できるようにしようという提案だと（大づかみに）理解しました。既に拡張機能として実装されているそうですが、実際に使用しているウィキメディアがあるのか不明で、標準化されるまでには時間がかかりそうですね。--Doraemonplus（会話） 2024年3月24日 (日) 06:23 (UTC)

MCR自体は(カテゴリ管理ではないですが)commonsなどで使われていますね。
1ページ内に画像ファイルの説明(wikitext)と構造化データ(wikibase)の2つのスロットが存在します。
カテゴリのリダイレクトもこれを使ってなんとかできないか、という話をどこかで見かけた(ちょっとパッと見つけられず、すみません)ので、個人的に注視しているところです。鏡華（会話） 2024年3月24日 (日) 23:26 (UTC)

カテゴリはウィキペディア日本語版だけでなくウィキメディア・コモンズ、ウィクショナリーやウィキブックス、ウィキニュースなど他のウィキメディア・プロジェクト、さらに言えばウィキメディアと関係のない多くのMediaWikiサイトで使われているものであり、ウィキペディア日本語版だけの事情に合わせてMediaWikiソフトウェアを弄れ、テーマとクラスで名前空間ないしカテゴリページでの表示を分けろというのはウィキメディア財団 (Phabricator)も取り合ってくれないでしょう。テーマとクラスでカテゴリページの名前空間ないし表示を分けることが不都合になるウィキがある可能性も考慮しなければなりません。そうでなければ、ウィキペディア日本語版だけのために一体何百、何千のウィキに迷惑をかけるつもりなのか、という話にもなりかねません。仮に百歩譲ってテーマとクラスでカテゴリページの名前空間ないし表示を分けることが不都合になるウィキがなかったとしても、一体実際に機能変更が実現するまで何年、何十年かかるかも分かりません。MediaWikiのシステムを弄るのは夢物語と考えて、現状のシステム内でできることを地道に積み重ねる以外に方法はないでしょう。--Prefuture（会話） 2024年3月19日 (火) 01:32 (UTC)

基本的な問題としては、ソフトウェアを作成した時に想定したと思われる全てのカテゴリ階層に包含関係が成り立つように記述しようという前提が満たされなくなっている段階でどうするかというお話なのだと思います。ソフトウェアを改修するという提案は、現状のカテゴリ構造をそのまま受け入れるのではなく、新しいカテゴリ階層の作り方の議論をしましょう、という提案なのだと理解しています。

一方、Wikipediaの現状のカテゴリ階層については追認せざるを得ないという考え方も理解できます。そのような時には、カテゴリに関する付加情報(荒っぽくは、カテゴリをクラスとテーマに分ける)をCategory:ウィキペディアのカテゴリの下位に作成するとともに、PetScanやvCatなどの関連ツールがそれを参照しながら動作するように改修するというのが、現状のシステム内でできる地道な事の様に思っております。--Wcontology（会話） 2024年3月19日 (火) 06:04 (UTC)

Prefutureさん、2点誤解があると思います。

1. 日本語版以外のウィキペディアでも現状のカテゴリの実装はかなり無理がある状態で、色々と策を弄してなんとか運用で回避している状態です。これが英語やドイツ語など名詞が単複異形(単数形と複数形で形が違う)の言語では、その差を上手く使い分けられるのでたまたまなんとかなっている。日本語や中国語のような単複同形(単数形と複数形で形が同じ)の言語では、ほぼ完全に破綻しているというわけです。(このノートの2023年6月の議論でDoraemonplusさんとWcontologyさんが看破されている内容)
2. ソフトウェアのバージョンアップをする場合、ほとんどは後方互換性を保つように設計します。カテゴリ関連のソフトウェア改修についても、名前空間を増やすにしろ、関連性を指定できるようにするにしろ、「新機能」として実装され、「使うか使わないかは各言語版の管理者次第」という形になるものと考えています。(少なくとも自分が仕様を決めて設計する立場ならそうしますし、MediaWikiの優秀なエンジニア達がその辺りをケアしないことは、まずないと思います) したがって日本語版の仕様を他言語版に強制するということにはならないと思います。なお蛇足ですが、例外的に後方互換性を保たないようにする場合があるのは、ほとんど使わない機能によりそのシステムの処理速度が著しく遅くなるような場合です。

--Bit（会話） 2024年3月23日 (土) 13:27 (UTC)

@Prefutureさん

• Bitさんのご紹介にある2023年6月の議論とは、左記リンク先の議論ですので、どうぞご覧になってご意見などをお聞かせください。
• 機能改修については、（実現するとしたら）おそらく拡張機能として実装されると思いますので、有効化するかどうかは各ウィキサイトの判断に委ねられるかと存じます。
• 現状のシステムを改修せずとも可能な地道な努力については、主として{{クラスカテゴリ}}と{{テーマカテゴリ}}とに整理整頓する方法のほか、実験的な試みとしては、大規模Setカテゴリを別に作成する方法をCategory:山岳名目録などで実践して見せています。
  • 同カテゴリの使用方法の一例として、例えばカテゴリ「火山」を下位カテゴリ検索すると、検索結果には火山記事以外も多数ノイズとして載ってしまいますが、山岳名目録カテゴリと組み合わせてAND検索することで、いわゆる「火山」と呼べる記事だけを取り出すことが可能になります（厳密にいえば、「火山」には山以外（カルデラ湖などの湖）も含まれますが、それはひとまず措いておいて）。
  • ただ、これらの方法は、Bitさんのご指摘にありますように、次善の策でしかなく、2023年6月の議論で出た問題の根本的な解決にはなり得ません。大規模Setカテゴリは作成にかかる労力が大きすぎて、Category:人物名目録（日本）などは構想段階で中断しており、完成の目処が立っていません。また、単複異形の言語版においても、SetカテゴリとTopicカテゴリの整理が十分でなかったり、（理論的には禁忌とされる）Setカテゴリの下位にTopicカテゴリが置かれていたりすることが往々にしてあり、今年で導入から20周年となるMediaWikiのカテゴリ機能は、ウィキペディアの大規模化とともに、その本質的な利用価値が問われる重大な課題に直面しています。

--Doraemonplus（会話） 2024年3月24日 (日) 09:00 (UTC) リンク先変更。--Doraemonplus（会話） 2024年3月24日 (日) 09:32 (UTC)

---

当議論から派生して、利用者:Doraemonplus/新カテゴリページUI案について交わされた議論を以下に参照読み込みします。原文は利用者‐会話:Doraemonplus/新カテゴリページUI案へ。--Doraemonplus（会話） 2024年4月17日 (水) 14:30 (UTC)

「部分カテゴリ」について

関連性を実装した場合のUIの例示、どうもありがとうございます。イメージが掴みやすくなり、非常に素晴らしい仕事と思います。 その上でですが、ここで書かれている部分カテゴリは実際のところ、すべて関連カテゴリに分類されるべき内容と思います。

• 学群 … 学群は大学そのものではありません。組織運営上、各学群が各大学に所属しているだけで、実体としては「教育のコース」です。
• 学部、大学の学科、大学の研究室 … 学部・学科・研究室は大学そのものではありません。組織運営上、各学部・学科・研究室が各大学に所属しているだけで、実体としては教授らにとっての「組織」であり学生にとっての「教育のコース」です。
• キャンパス … キャンパスは大学そのものではありません。組織運営上・地理的に・および土地の権利として、各キャンパスが各大学に所属しているだけで、実体としては「キャンパス」です。(これは独自研究になるかも知れませんが、会社の「事業所」「拠点」などと等価な存在だと思います)
• 大学出版局 、大学図書館、大学博物館 … 出版局、図書館、博物館は大学そのものではありません。組織運営上、各大学出版局・図書館・博物館が各大学に所属しているだけで、実体としては「組織」であり「出版局」「図書館」「博物館」です。
• 大学別の人物 … 人物は大学ではありません。組織運営上、各人物が各大学に所属しているだけで、実体としては「人物」です。

これがクラス・テーマを分類しなければならない現在のカテゴリの方針の難しいところだと思います。「Category:大学」の子・孫…にはどこまで行っても「○○大学」しかあってはいけないので。学部・学科・キャンパス・出版局・図書館…などは実際に大学の下部組織であり、特に判断が難しいかも知れないのですが、これらは「大学」ではないです。「人物」で考えると解りやすいと思います。

同じような話が、私の主に活動している言語学関連でもありまして…。

• 語族 > ○○語族 > △△語派 > ◇◇語群 … □□語群 > ●●語 というカテゴリ・記事だけの分類にすべきなのに、「Category:ゲルマン語派」の下に「Category:ゲルマン語の姓」がある。これは「テーマ：ゲルマン語派」で実体の分類としては「名前 > 人名 > 姓」とかになる認識

などです。

--Bit（会話） 2024年3月23日 (土) 14:40 (UTC)

すみません、判断基準を示していませんでした。判断基準は「集合と要素の関係かどうか」です。以下の図を参照ください。

集合「大学」は、要素「●●大学」、要素「○○大学」…を集めたグループなので、それ以外は入りません。各学部は代わりに集合「学部」に入ります。各大学の○○学部は、集合「○○学部」に入ります。以下の図を参照ください。

--Bit（会話） 2024年3月24日 (日) 17:08 (UTC)

ありがとうございます。図解で説明していただき、たいへん分かりやすいです。部分カテゴリについては、様々な見方ができると思います。私は「大学」を構成する一部分として「学部」「キャンパス」「附属機関」「人物」を位置づけましたが、なるほど、Bitさんのお考えも理解できます。別の例で説明すると、人体の中に人体の部位（頭、手、足など）が「部分カテゴリ」として含まれるイメージです。

現行のカテゴリの技術仕様では、Objekt/Set/クラスカテゴリおよびThemen/Topic/テーマカテゴリの区別が、表現可能な知識組織化の限界かもしれません。前者は「集合と要素の関係」が基本、後者は「件名と話題の関係」が基本で、これに「全体と部分の関係」が加わります。利用者がCategory:大学にどのような内容を期待するか次第で、いずれの用途も有効な使用法ですが、三者を区別する仕組みを持たないまま、「カテゴリ」として一緒くたに実装してしまったのが、結果的に不合理を招き、ウィキペディアの大規模化とともにカテゴリ仕様の問題が顕在化した形です。

ドイツ語版では、de:Kategorie:Universitätをクラスカテゴリ、de:Kategorie:Universitätswesenをテーマカテゴリとして整理整頓を試みていますが、この "wesen" が曲者でして、無理に翻訳しようとすると、「大学制」のような、カテゴリ名として不自然な日本語となってしまいます。他方で、de:Kategorie:Staatとde:Kategorie:Staatenのように単数形と複数形で区別する方法も、無理に「国々」「諸国」と翻訳すると、ニュアンスが大きく変化してしまいます。このように、印欧語と漢語系語の間には越えられない壁があり、クラスとテーマによる区別も限界にきています。

カテゴリ名は「大学」のまま、上述した三者の関係性をカテゴリーカテゴリ間とカテゴリー記事間について適用できるように仕様変更すれば、この問題は概ね解決できるものと私は信じています。おそらく中国語や朝鮮語などでも同様の問題はあるだろうと思うので、カテゴリ事情をよく調査して、漢字圏の言語版のコミュニティの要望として、連携して提案すれば、より実現する見込みの高い、実効力のある提案となるでしょう。--Doraemonplus（会話） 2024年4月4日 (木) 11:16 (UTC)

コメントありがとうございます。ご指摘の通り、全体-部分の関係性が実態として存在していますね。人体の部位の例は私も考えながら書いていました。

以下のように関係性のデータ記述子を使い分けることで実現は可能と思います。

• 集合-要素：memberof, belongto, 一員, 所属…
• 全体-部分：partof, consistof, 構成, 構成要素…
• 関連：relatedto, 関連…

一方で、3種類の概念/記述子の使い分けという複雑な作業を、各編集者がやり切れるかという問題もあると思います。

• 2種類であれば、編集者は「Aか、Aでないか」だけの判断をすれば良く、比較的簡単な作業で済みます。
• 3種類だと「Aか、Bか、AでもBでもないか」の判断をする必要があり、難易度は一気に上がります。
• また、現状でも「クラスかテーマか」「Set or Topic」「Objekt oder Themen」という二項対立までは、WP:カテゴリの方針でお膳立てされており、これを参考に使い分けることができます。集合-要素と全体-部分を区別する場合、その指針が利用できないのが痛いです。
• ただ一方で、私が例に挙げた記述子は自然言語に近いため、実は判断の難易度は高くない…かという可能性もあります。どちらかというとシステム側が区別して表示するかしないかだけの問題かも知れません。
• 余談ですが、現在問題になっている孫以降の抱合関係の完全性の話からすると、本質は「クラスかテーマか」ではなく、「クラスであるかクラスでないか」なのではないかと思っています。それでクラスとは何かを突き詰めていったら集合-要素に行きつきました。オブジェクト指向プログラミングでいうクラス-インスタンスを想像すると更に理解しやすいかも知れません。

--Bit（会話） 2024年4月4日 (木) 15:32 (UTC)

Bitさん このところ現実世界で忙しく、間が空いてしまい、申し訳ないです。

• 本質は「クラスであるかクラスでないか」という見方に同意です。クラスでない場合、それは自動的にテーマであるとみなせます。
• 日本語版ウィキペディアの場合、Wikipedia:カテゴリの方針#カテゴリとはにおいて、カテゴリは第一義として「分類」（＝クラス）を表すとされていますが、2024年現在、（カテゴリ:大学を見てもわかるように）実態的には「テーマ」を表すカテゴリが全体の大部分を占めています。ここで仮に instanceof: なり memberof: なりを用いてクラス/非クラスを区別する場合、通常の Category: はデフォルト（既定）でテーマを表し、instanceof: や memberof: の指定でクラスを表すことになるかと思います。少なくとも現状の日本語版に合わせると、従来の Category: のデフォルト設定はテーマとするのが最適です（この場合、現行のカテゴリの方針は改定が必要です）。
• 一方、ドイツ語版では、de:Kategorie:Universitätなどの例からも窺えるように、全体としてクラス主体のカテゴリ体系となっています。この場合、クラスを Kategorie: のデフォルト設定とするのが最適であると考えられます。英語版や日本語版とは正反対です。
• このように、言語によってカテゴリの運用方針が異なるため、むしろクラスのほうをデフォルトにして subjectof: や topicof: でテーマ/非テーマを識別可能とする選択肢も用意できると、言語の多様性に配慮した、より柔軟な運用が可能になると思います。それだけシステムの仕様は複雑になりますが、現行のカテゴリ体系からの円滑な移行を考慮すると、推して残すべき選択肢ではないかと思います。
• 全体-部分関係に関しては、テーマ（連想関係）として扱うことも一つの解法であると思うので、シンプルさを求めるなら、これは無理に定義しなくてよいかもしれません（クラスやテーマに比べると、需要が少なそう）。
• 以上はカテゴリ-記事の関係性の話で、カテゴリ-カテゴリの関係性については、同じ instanceof: でも別の視点で見る必要があります。というのも、東京大学に instance:大学 を付与するのと、東京大学に instance:大学 を付与するのでは、カテゴリの中身がまるで違うためです。この問題に関しては追々。ひとまず、ここで筆をおきます。

--Doraemonplus（会話） 2024年4月17日 (水) 14:22 (UTC)

頭出しのところだけして、フォローアップがあまりできていませんでした。

上述の「孫以降の抱合関係の完全性」（カテゴリの親子関係に推移律（A→BかつB→CならA→Cと考えてよいか）が成り立つか否か）を議論する際に考える必要があるのが複合カテゴリの扱いです。

クラスのカテゴリに制約をつける形で分割していくものについては、利用者:Doraemonplus/新カテゴリページUI案で＋に分類されているように、推移律が成り立つ関係としてよいと思います。一方、制約に使われる側もサブカテゴリとして扱われています。例えば、東京大学と東京大学の人物の関係です。テーマとしては、関連しているとも考えられますが、例えば、1969年と1969年生のように、かなり関係性の薄いものまで含まれることになるかと思います。

全体を整理するためには、この複合カテゴリの扱いについても、大まかな方針を決めた萌芽良いのではないかと思いました。--Wcontology（会話） 2024年4月19日 (金) 10:54 (UTC)

後半部分、ドイツ語版に関する知見、どうもありがとうございます。Doraemonplusさんのドイツ語の理解がどの程度なのか判りませんが、wesenを付けるようなやり方がドイツ語母語話者にとってどの程度自然に感じられるのかも興味があります。もしかしたら母語話者から見ても日本語直訳の「大学制」と同じように不自然さを感じている可能性もあるのかな…と思いました。私は英語だけは仕事で使いますが、確かに英語で複数形を集合/クラス/Setとするのは自然な表現だとは感じています。ドイツ語の単数形も同じように自然な感じなのかどうなのか…。

どういうことかというと、もしかしたら印欧語でも多少の不自然さはあり、無理やり妥協して運用しているのでは…？今回の日本語版からの提案は、印欧語版でも最適化となり歓迎される可能性があるのでは…？と考えた次第です。--Bit（会話） 2024年4月4日 (木) 15:46 (UTC)

---

Category:未使用のカテゴリ の使い方

不勉強ながら、Category:未使用のカテゴリの使い方をあまり良く分かっておりません。ここに入っていない空のカテゴリを利用者:FlatLanguage/sandbox/空のカテゴリにまとめたのですが、これらを機械的に未使用カテゴリに入れていくのはやめた方が良いのでしょうか。なにか基準がある？

これらの中には空になった経緯に問題があるものが結構あり、経緯が追えたものは3月29日・3月30日に投げておいたのですが、カテゴリへの追加除去を追うのはやはり難しいです。以前からdata dumpを使えば過去に属していたページを探せるのではないかとの指摘があったと思いますが、まだ初心者-Likeな方法は実現していないということで良いのでしょうか。--FlatLanguage（会話 / 投稿） 2024年4月4日 (木) 00:58 (UTC)

Category:未使用のカテゴリのページ本文でも、いろいろと説明されていますが、守られていないのが実態であり、使い方の標準は存在していないといえます。まず、「未使用」の解釈が人それぞれで、私は空のカテゴリだと思って、項目数が0のカテゴリを次々に入れていましたが、1904年の映画の例を見るに、伏儀さんは、空でも未使用ではないカテゴリも存在し、「空のまま運用を続ければ済む」と認識されていたようです。

この認識に則る場合、問題は、空のカテゴリが未使用ではないかどうか識別する方法が非常に限られていることです。カテゴリページの本文かノートか編集履歴の要約欄に作成合意済・使用中である旨記載されていない限り、第三者には空のカテゴリが未使用か使用中かの判断がつきません。何も記録されていないと、お手上げです。

さて、機械的に未使用カテゴリに入れていくことに関して、その手間をかけられるくらいなら、一つでも多く再使用や削除を手配されるのが効果的かと存じます。私なら、Category:未使用のカテゴリ2024年4月のノートに一言添えて、利用者サブページへの参照を記載する方法を選ぶと思いますが、どうなさるかはFlatLanguageさん次第です。--Doraemonplus（会話） 2024年4月4日 (木) 09:02 (UTC)