跳转到内容

维基百科:互助客栈/方针

添加话题
维基百科,自由的百科全书

此頁面探討维基百科的方針與指引


請注重礼仪、遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 公共運輸相關指引再次討論 53 15 鐵路1 2025-06-13 18:58
2 有關申請權限與申請解除權限的方針條文與申請區的放置問題 67 6 Xiplus 2025-06-19 22:20
3 提議提升巡查員的門檻 67 22 Stang 2025-06-20 11:58
4 重提允許巡查員自我增加與移除自動巡查權/將自動巡查與巡查員權限組分離 113 17 Stang 2025-06-20 18:01
5 在人物傳記條目合理使用人物配偶的圖片 38 12 Ericliu1912 2025-06-10 23:36
6 「允许在中文段落使用斜体表示英文书名」公示通知 5 1 1F616EMO 2025-06-18 18:38
7 建議增加「姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代」去掉「姓、部、卦、母、國、朝」字之後剩下的東西的「重定向/消歧義」的方針 20 8 𠭞 2025-06-18 16:37
8 為修訂存廢覆核方針放寬臨時恢復制度事 1 1 1F616EMO 2025-06-14 22:54
9 提議修訂天體收錄標準 1 1 自由雨日 2025-06-18 14:26
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

正在廣泛徵求意見的議題

議題清單

以下討論需要社群廣泛關注:重新整理 維基百科格式與命名

Wikipedia talk:命名常规 § 重提在條目標題中正確使用書名號

因此我提议在条目标题中正确使用书名号,无论最终使用甲式还是乙式。

以上。 ——魔琴身份声明 留言 贡献 PJ:NEW23 2025年3月8日 (六) 19:53 (UTC)

Wikipedia talk:命名常规/音乐 § 提议使用拉丁原名作为歌曲的标题

理由如下:

  1. 目前流媒体收听音乐几乎碾压传统的唱片音乐,而几乎所有的流媒体服务商都主显原名。使用几个中文汉字会使人感到陌生,是“易于识别”的违反,也不符合“使用常用名称”。有一种下位法违反上位法之感。
  2. 中文用户普遍认识26个字母,即使可能无法理解其含义并朗读,但普遍有能力拼写、传递和辨别是否同一单词。
  3. 维基百科编者为了符合这一要求,不惜代价地去寻找一个中文名称,最后还弄得读者看不懂,徒劳无功,质量还不高。
  4. 大部分译文质量不高,做不到“信达雅”,可能只是一些人为了填补“译名”字段空白的草率产物,也不一定是作者原意。
  5. 一些找不到译名的条目和隔壁某百科使用原文,看上去也没什么问题,甚至更美观易懂。

--ZLin2222留言) 2025年3月17日 (一) 17:08 (UTC)

Template talk:文物保护单位 § 建議文物保護單位模板整合至Infobox historic site模板內

建議{{文物保护单位}}模板整合至{{Infobox historic site}}模板內,以便利統一維護。Sanmosa 新朝雅政 2025年4月27日 (日) 05:46 (UTC)

Wikipedia talk:格式手册/标点符号 § 提案:修訂「書1」對於软件名的规定

中华人民共和国《标点符号用法》(GB/T 15834—2011)4. 15.3.3 规定「全中文或中文在名称中占主导地位的软件名」用书名号标註,但是实际上除了电子遊戏(如「《原神》」)以外罕见。因此建议「书1」去除这项,並明確电子遊戏使用书名号标示。提案如左。

現行條文
  • 书1:标示书名、书名篇名并举、报纸名、杂志名、图表名、文件名、全中文或中文在名称中占主导地位的软件名,电影、电视、诗歌、音乐、雕塑等各类用文字、声音、图像等表现的作品名用双书名号。嵌套书名号时,外层用双书名号,内层用单书名号。
提議條文
  • 书1:标示书名、书名篇名并举、报纸名、杂志名、图表名、文件名,以及电影、电视、诗歌、音乐、雕塑、电子遊戏等各类用文字、声音、图像等表现的作品。嵌套书名号时,外层用双书名号,内层用单书名号。
    GB/T 15834—2011规定「全中文或中文在名称中占主导地位的软件名」使用书名号标示,但实际罕见。

顺便修改了行文。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年5月30日 (五) 20:47 (UTC)

Wikipedia talk:格式手冊/無障礙 § 推动将Wikipedia:格式手冊/無障礙/2025列为指引

目前需要解决的问题大致只有「文字」一章节,不知道有没有熟悉屏幕阅读器的编者,或者有家人、好友是视障人士的,能够解决标注出的问题。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年5月30日 (五) 22:52 (UTC)

Template talk:Mong § Mong模板的命名問題
有鑒於近日{{Lang-mn}}模板被刪除,因此我在思考{{Mong}}模板是否應該採納如現{{Lang-mnc}}模板一樣的命名格式,並佔用{{Lang-mn}}的名字,又或是僅簡單地將{{Lang-mn}}重新導向至{{Mong}},希望各位就此給予意見。Sanmosa 新朝雅政 2025年6月4日 (三) 03:31 (UTC)
Wikipedia talk:格式手冊/文字格式 § 公式中的斜体使用衬线字体
此討論正在公示;如有意見請儘快提出。
現行條文

公式中的变量符号 变量符号通常使用斜体(E=mc2)。例外的情况包括粗体,或者字母上方带有一个箭头用于表示向量

有些符号总是不用斜体,包括:

提議條文

公式中的变量符号

变量符号通常使用斜体(E = mc2)。例外的情况包括粗体,或者字母上方带有一个箭头用于表示向量

公式可在<math>...</math>中使用LaTeX标记来排版;对于简单的内联公式,可使用{{math}}及其相关模板。这两种方式生成衬线字体,而不同于默认的无衬线字体。这有助于区分I(大写的i)和l(小写的L),其在许多无衬线字体中几乎相同。

对于独立引用的数学变量,可使用{{mvar}},它将以斜体衬线字体呈现。对于数学方程,可使用{{math}}。在{{math}}中的变量使用双引号以使其变为斜体。

  • {{mvar|y}}的值恒为...y的值恒为...
  • {{math|''E'' {{=}} ''mc''<sup>2</sup>}}E = mc2

有些符号不使用斜体,包括:

提案内容参考了及Wikipedia:格式手册/数学。--Steven Sun留言) 2025年6月12日 (四) 03:50 (UTC)

Wikipedia talk:格式手册/标点符号 § 協調各地標點規範與實際

鑒於標點符號格式手冊多以中國大陸為中心,忽視他地、他國規範、實際乃至中國大陸實際,以及效力不清,提出以下各項修訂。各項對應意見請在各章節或此節提出,最下方或許陸續補充。— Gohan 2025年6月17日 (二) 08:51 (UTC)

Wikipedia talk:繁简处理 § 繁體模式以「臺灣台語」爲正,不受WP:臺台限制

當前,中華民國對於臺灣話的官方名稱爲「臺灣台語」,蓋該政府的刻意用字,竊以爲在繁體模式下不應受WP:臺台限制。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年6月19日 (四) 06:38 (UTC)

維基百科方針與指引

Wikipedia talk:删除 § 有關模板的刪除理由

有鑒於此前提到的部分用戶濫建模板的情形至今仍然持續(1234),再加上當時將刪除模板的要求改為“多餘無用,且影響其他模板命名或者百科運作”的討論並未有效凝聚社羣共識,因此現時中文維基百科存在客觀、迫切的必要修訂“刪除理由”第9款,以遏止濫建模板的情形。Sanmosa 新朝雅政 2025年2月1日 (六) 08:42 (UTC)

Wikipedia talk:页面评级 § 提议废除甲级、乙上级与丁级

现时本站条目质量有实质区分度的等级,是小、初、丙、优良、典范。设置没有有效差异而又没人使用的等级令人望而生畏,先不说激进的废除乙级,已经被社群冷落的甲级、乙上级与丁级诚可删除。--HoweyYuan留言) 2025年3月7日 (五) 15:22 (UTC)

Wikipedia talk:命名常规 § 重提在條目標題中正確使用書名號

因此我提议在条目标题中正确使用书名号,无论最终使用甲式还是乙式。

以上。 ——魔琴身份声明 留言 贡献 PJ:NEW23 2025年3月8日 (六) 19:53 (UTC)

Wikipedia talk:命名常规/音乐 § 提议使用拉丁原名作为歌曲的标题

理由如下:

  1. 目前流媒体收听音乐几乎碾压传统的唱片音乐,而几乎所有的流媒体服务商都主显原名。使用几个中文汉字会使人感到陌生,是“易于识别”的违反,也不符合“使用常用名称”。有一种下位法违反上位法之感。
  2. 中文用户普遍认识26个字母,即使可能无法理解其含义并朗读,但普遍有能力拼写、传递和辨别是否同一单词。
  3. 维基百科编者为了符合这一要求,不惜代价地去寻找一个中文名称,最后还弄得读者看不懂,徒劳无功,质量还不高。
  4. 大部分译文质量不高,做不到“信达雅”,可能只是一些人为了填补“译名”字段空白的草率产物,也不一定是作者原意。
  5. 一些找不到译名的条目和隔壁某百科使用原文,看上去也没什么问题,甚至更美观易懂。

--ZLin2222留言) 2025年3月17日 (一) 17:08 (UTC)

Wikipedia talk:格式手册/两岸四地用语 § 条目内文中提及“国家”的部分直接写“台湾”是否违反CS4D
死刑存廢問題#各國死刑現況中提到

根据国际特赦组织(Amnesty International)的统计……其中被自由之家(Freedom House)评比为完全民主自由的经济高度发展国家而维持死刑的仅有美国、日本及台湾。

个人认为如果前文是“国家”不可以使用“中国大陆”(包括“大陆”,惟在前文未提及“中国大陆”的情况下直接简写“大陆”已违反CS4D)和“台湾”指代两岸政权,应使用中华人民共和国中华民国完整国号(或使用模板{{PRC}}}和{{ROC}})来表述。但查阅CS4D发现并没有对该种情况做明确规定,所以我想确认上述内文是否违反CS4D?也希望在CS4D内文中对该情况做明确规定。--忒有钱 🌊塩水あります🐳留言) 2025年4月6日 (日) 18:40 (UTC)

Wikipedia talk:列明来源 § 強制列明原地更新的來源的存取時間
維基百科:可供查證規定「寫入維基百科的內容須要能被讀者在可靠來源中得到驗證」,一般而言,直接列出來源便可。惟部分資料出自隨時原地更新資訊的網站(例如MLB.com球員資訊、社交網站訂閱數資訊),若沒有列明何時存取以及提供存檔,其來源其實依然不明;若內容已更新,但來源存取日期未更新,更會造成來源和內容不符的情況,即內容無法「在可靠來源中得到驗證」。因此,我建議新增以下條文:以上,邀請社羣討論。--1F616EMO喵留言回覆請ping) 2025年5月31日 (六) 10:18 (UTC)
Wikipedia talk:討論頁指引 § 關於「維護維基百科的方針」
目前這一節翻譯自英維於2007年2月14日 (三) 07:27的修訂版本108026792,當時英維的討論頁方針只有顧及條目討論命名空間的狀況,故規定「適用於條目的政策亦同樣適用於討論頁中」。惟目前版本已經涵蓋「所有討論頁及具有討論性質的計劃頁面」,使所有討論符合WP:核心內容方針的標準尺度不切實際。(以防有人曲解我的言論,在此聲明:此處言論僅指討論內容無需死板地符合核心內容方針,惟所有討論的發言以及結果均只能夠提升其原則的應用和解釋而不能逾越之。)此外,「maintain」一詞亦有「堅持」一說,譯爲「維護」恐怕是早期的誤譯。因此,我建議翻譯自英維的版本,將之修改如下:修改後的版本更能反映其泛用性,使討論聚焦於符合維基百科宗旨的主題。以上,提請社群討論。--1F616EMO喵留言回覆請ping) 2025年6月1日 (日) 23:52 (UTC)
Wikipedia talk:收錄標準/虛構 § 提議修改WP:虛構集合規則2

目前WP:虛構集合規則2為:另外在該集合中符合收錄標準或虛構準則的子主題必須至少有一項與該集合主題有直接關聯。此規則在我看來 ① 標準不明晰——何為「直接關聯」、如何判定「直接關聯」都具有一定主觀性;② 實際操作上亦少被使用——往往被提刪的滿足規則1的虛構集合的提刪理由是WP:NOTGUIDE。規則2所附例子:例如,有尾巴的寶可夢中,皮卡丘符合收錄標準,但由於皮卡丘符合收錄標準的原因明顯與皮卡丘有尾巴無關,因此,有尾巴的寶可夢不應獨立成一個列表。——此例亦可用WP:NOTGUIDE來解釋(「有尾巴的寶可夢」已落入「攻略書」範疇,非愛好者不太會關心),而且更易於理解和執行,故在我看來,規則2不如改成:另外在該集合須符合維基百科不是手冊、攻略書、教科書

我覺得規則2與WP:NOTGUIDE雖然條文本身並無關係,但起到的範圍限制效果是類似的。而且在執行上不如WP:NOTGUIDE好用、易懂,故不妨直接按照WP:NOTGUIDE的表述。之前在存廢覆核請求,@Znppo也提出對 WP:虛構集合 的不滿;我覺得至少規則2的條文可以適當精進。而且,我覺得WP:NOTGUIDE也需要有一個「在地化」版本、適合ACG專題的版本,因此借此次修訂正好取代WP:虛構集合規則2,並附帶幾句ACG專題的操作說明為宜。

Ping「將Wikipedia:關注度 (虛構事物)立為指引」討論串參與者:@A2569875CwekEricliu1912MeritTimMilkypineSanmosaSmallTimTemp3600Viztor和平至上。--SuperGrey (留言) 2025年6月5日 (四) 01:25 (UTC)

Wikipedia talk:不要人身攻击 § 提议更改人身攻击方针中的“对事不对人”
此討論正在公示,直至2025年6月28日 (六) 05:00 (UTC)結束;如有意見請儘快提出。

由于本人认为人身攻击方针中的“对事不对人”有明显欠缺(针对条目内容显然并非“对事”),因此提议以下修改:

現行條文

條目的內容發表意見,而不是對條目的編輯者;換句話說,請對事不對人。

提議條文

發生的事實(包括但不限於条目内容、用戶行為等)发表意见,而不是对用户本身;換句話說,請對事不對人。

--WiiUf留言) 2025年6月7日 (六) 05:30 (UTC)
Wikipedia talk:中立的观点 § 对“Wikipedia:中立的观点”最近修改的异议

近日发现,Wikipedia:中立的观点最近做了一次比较大的修改,我认为此修改存在一些问题:

  1. 程序问题。说没有讨论吧,好像还讨论了;说讨论了吧,又是针对 Wikipedia:命名常规的讨论。问题是,“中立”是我们的“五大支柱”之一,但“命名常规”不是。这就好比,我们在讨论修订“刑法”的时候,发现我们打算发布的新条文跟“宪法”有矛盾,所以我们就顺便把“宪法”也改了。
  2. Wikipedia:是英文维基说的!此修改似乎是完全照搬了英维?(这个大家都懂,就不多解释了。)
  3. 重点)凌驾于“支柱”之上。此修改似乎特别拔高了“常用”的地位,特别是使其凌驾于“中立”这一“支柱”之上。“常用”本身只是一条普通方针,是需要与其它规则作平衡的,不是必须的。而支柱是必须遵守的。将任一方针凌驾于“支柱”之上,都是不可取的。
  4. 英文与中文的区别。(我英文水平有限,如果这一点说得不对,还望大家多多指教。)在中文里,“不偏向某一方观点”叫“中立”,“不褒不贬”叫“中性”;但在英文里似乎都是用的“Neutral”。所以在英维里,在讲“Neutral”的时候,似乎还包含了“不要褒也不要贬”含义。因此在所用例子中,似乎是有“把使用了贬义词(或褒义词)(而非偏向某一方观点)当作不 Neutral”的情况。如果我的理解没错,那么照搬英维就更不可取了。
  5. 晦涩难懂。不光是翻译的问题,英维本身就比较晦涩。当然,这是个次要问题,前面的问题解决了,才需要处理这个问题。

--Ma3r铁塔) 2025年6月8日 (日) 01:26 (UTC)

Wikipedia talk:維基百科政策簡報 § 關於重啓維基百科政策簡報并更名為維基百科簡報
此討論正在公示7天,直至2025年6月27日 (五) 10:16 (UTC)結束;如有意見請儘快提出。

自2023年2月維基百科政策簡報發出最後一刊以來,該報已有多年未曾更新。在這幾年間中文維基百科社群的生態已發生很大變化,與全域社群進一步對接的需求也與日俱增,由此若僅將重心放於方針未免有些不足。我希望能通過這份刊物讓大家瞭解中文維基百科的近況,並讓中維社群的用戶能大致瞭解全域社群的重大事件。以上。--人间百态,独尊变态(讨论)(签名) 2025年6月10日 (二) 14:22 (UTC)

Wikipedia talk:過濾器助理 § 授权过滤器助理与过滤器编辑者访问受保护的变量

本站计划于6月份部署临时账号,届时,IP地址将被视为敏感的个人身份信息变量abusefilter-access-protected-vars)并将仅允许管理员访问。本提案旨在建议允许过滤器助理过滤器编辑者同获得abusefilter-access-protected-vars权限,以确保在临时账号部署后,其对所有过滤器的访问仍畅通无阻。

现行过滤器助理方针

對比起一般使用者,過濾器助理可以:

  • 查看标记为非公开的滥用过滤器的过滤日志(abusefilter-log-private
  • 查看被标记为非公开的滥用过滤器(abusefilter-view-private
  • 启用双重身份验证(oathauth-enable
  • 允许移除自己账号的用户组
提議條文

對比起一般使用者,過濾器助理可以:

  • 查看标记为非公开的滥用过滤器的过滤日志(abusefilter-log-private
  • 查看被标记为非公开的滥用过滤器(abusefilter-view-private
  • 启用双重身份验证(oathauth-enable
  • 查看和创建使用受保护变量的过滤器abusefilter-access-protected-vars
  • 允许移除自己账号的用户组
现行过滤器编辑者方针

相较于一般用户,过滤器编辑者可以:

  • 创建、激活和取消激活标签managechangetags
  • 查看标记为非公开的滥用过滤器的过滤日志(abusefilter-log-private
  • 查看被标记为非公开的滥用过滤器(abusefilter-view-private
  • 启用双重身份验证(oathauth-enable
  • 创建或修改滥用过滤器(abusefilter-modify
  • 允许移除自己账号的用户组
提議條文

相较于一般用户,过滤器编辑者可以:

  • 创建、激活和取消激活标签managechangetags
  • 查看标记为非公开的滥用过滤器的过滤日志(abusefilter-log-private
  • 查看被标记为非公开的滥用过滤器(abusefilter-view-private
  • 启用双重身份验证(oathauth-enable
  • 创建或修改滥用过滤器(abusefilter-modify
  • 查看和创建使用受保护变量的过滤器abusefilter-access-protected-vars
  • 允许移除自己账号的用户组

——ZhaoFJx(Talk) 2025年6月10日 (二) 17:51 (UTC)

Wikipedia talk:快速删除 § G15的具體含義

近日的AFD使包括我在內的部分用戶想到快速刪除方針G15條第4款,但由於用戶頁指引的兩次重大修訂(12),這使“用戶討論頁”一詞在G15中的定義變得不明(WP:用戶頁#术语解释中的“用戶討論頁”自然被包括於G15的“用戶討論頁”內,但“用戶討論頁子頁面”與“用戶子頁面討論頁”是否被包括於G15的“用戶討論頁”內無從得知),從而使G15條第4款需要修改。此外,由於臨時帳戶機制的部署,G15條第5款的規定將不再適用(Mediawiki頁面稱“臨時帳戶有自己的用户页与用户讨论页”),因此G15條第5款也同樣需要修改。Sanmosa 新朝雅政 2025年6月11日 (三) 12:47 (UTC)

Wikipedia talk:用戶頁 § 關於wp:FAKEARTICLE

目前,若WP:FAKEARTICLE成立,絕大多數在用戶空間的廢棄草稿、幽默內容、久未編輯的沙盒等都應被提刪,將影響逾千頁面。因此,交予社群討論。--WiiUf留言) 2025年6月12日 (四) 04:57 (UTC)

Wikipedia talk:存廢覆核 § 為修訂存廢覆核方針放寬臨時恢復制度事

最近經Wcam提醒,我纔發現依據「存廢覆核方針」規定,臨時恢復已刪除條目供檢視之制度,係置於「處理結果」一段,僅限於管理員特別「要求(社群)介入」時始得應用。我認為這不合理,因為以實務情況而言,若干比較困難的存廢覆核請求,幾乎總是需要相當社群意見以達成共識,很少由管理員自行裁決;而已刪條目一般情況下根本難以檢閱,何況開放社群就其內容討論原始存廢決定妥適與否。是以僅允許管理員於「結案途中」恢復條目供社群討論,不免限制過度。另查英文維基百科存廢覆核請求現行規定,則明文表示:「管理員經常受托恢復已刪除頁面以供檢視,將內容替換為TempUndelete模板,同時允許所有人查閱(編輯)歷史」(Admins participating in deletion reviews are routinely requested to restore deleted pages under review and replace the content with the {{TempUndelete}} template, leaving the history for review by everyone.),並未有其他介入要件(其餘禁止恢復侵權內容等細節規定均同)。據此,本人提出「存廢覆核方針」修訂案如下:

現行條文

管理员須知

  • 鉴于维基百科:管理员对管理员行为的限制,先前曾以下述形式参与待覆核页面相关处理流程的管理员,原则上应避免处理存废覆核的提案:
    • 存廢討論的提报、投票与讨论、结束讨论及目标页面处理,以及快速刪除、修訂版本刪除的提报、提出异议、讨论和处理。

處理結果 管理員可就提案作以下回應︰

  1. 維持原決;或
  2. 發還至相關存廢討論,即重新提交討論,先恢復後提案至相關討論亦可,重新提交讨论时应于新讨论处附上存废复核存档和原讨论存档的內部連結;或
  3. 轉介至存廢討論,當閣下認為速刪決定有違快速刪除準則,並應獲得全面存廢討論時適用;或
  4. 推翻原決並代之以其他操作,唯須列明其他操作為何;或
  5. 要求介入,當管理員無法就提案下取決定,尤其涉及內容复审、方針指引規範未明或易於引發爭議之提案,管理員可作此決定,要求社群介入討論,用戶則可用上述四項回應表達自己意見。啟用此程序時,當事管理員應盡量闡明問題所在,以利討論。為使社群有足夠參與,管理員作此決定以後,須於公告欄互助客棧發出通知,亦應通知曾參與存廢討論用戶。此程序一旦展開,一般為期一週,有需要時可列明理由延長時限,唯切勿縮短期限,亦莫應超越五周之限。期屆以後,管理員應依照共識執行結果,結束提案。如果要求介入討論以後,依舊未達共識,則應以無共識結束提案。在未有新理據前,不建議再就該(等)條目提案。如條目已經刪除,管理員可臨時恢復頁面並懸掛{{Tempundelete}},以便社群討論。然而,切勿恢復任何侵犯版權、有違生者傳記方針或其他方針禁止之內容當然,即使管理員未有作此決定,用戶仍可隨時就提案發表意見。

切記覆核並非再就有問題內容發表意見之時機,而應用以糾正過程中所發生(未有重要新資料所引起)之缺失。故此,無論用戶或管理員,使用第四項回應時,“其他操作”應可確切反映共識。

提議條文

管理员須知

  • 鉴于维基百科:管理员对管理员行为的限制,先前曾以下述形式参与待覆核页面相关处理流程的管理员,原则上应避免处理存废覆核的提案:
    • 存廢討論的提报、投票与讨论、结束讨论及目标页面处理,以及快速刪除、修訂版本刪除的提报、提出异议、讨论和处理。
  • 如條目已經刪除,管理員可臨時恢復頁面並懸掛{{Tempundelete}},以便社群討論。然而,切勿恢復任何侵犯版權、有違生者傳記方針或其他方針禁止之內容

處理結果 管理員可就提案作以下回應︰

  1. 維持原決;或
  2. 發還至相關存廢討論,即重新提交討論,先恢復後提案至相關討論亦可,重新提交讨论时应于新讨论处附上存废复核存档和原讨论存档的內部連結;或
  3. 轉介至存廢討論,當閣下認為速刪決定有違快速刪除準則,並應獲得全面存廢討論時適用;或
  4. 推翻原決並代之以其他操作,唯須列明其他操作為何;或
  5. 要求介入,當管理員無法就提案下取決定,尤其涉及內容复审、方針指引規範未明或易於引發爭議之提案,管理員可作此決定,要求社群介入討論,用戶則可用上述四項回應表達自己意見。啟用此程序時,當事管理員應盡量闡明問題所在,以利討論。為使社群有足夠參與,管理員作此決定以後,須於公告欄互助客棧發出通知,亦應通知曾參與存廢討論用戶。此程序一旦展開,一般為期一週,有需要時可列明理由延長時限,唯切勿縮短期限,亦莫應超越五周之限。期屆以後,管理員應依照共識執行結果,結束提案。如果要求介入討論以後,依舊未達共識,則應以無共識結束提案。在未有新理據前,不建議再就該(等)條目提案。當然,即使管理員未有作此決定,用戶仍可隨時就提案發表意見。

切記覆核並非再就有問題內容發表意見之時機,而應用以糾正過程中所發生(未有重要新資料所引起)之缺失。故此,無論用戶或管理員,使用第四項回應時,“其他操作”應可確切反映共識。

以上,請社群討論。此處修訂案,僅涉及條文搬動,至於是否應比照英文維基百科,於懸掛模板時替換所有內容,本人則沒有特別意見。—— Eric Liu 創造は生命(留言留名學生會 2025年6月14日 (六) 12:35 (UTC)

Wikipedia talk:格式手册/标点符号 § 協調各地標點規範與實際

鑒於標點符號格式手冊多以中國大陸為中心,忽視他地、他國規範、實際乃至中國大陸實際,以及效力不清,提出以下各項修訂。各項對應意見請在各章節或此節提出,最下方或許陸續補充。— Gohan 2025年6月17日 (二) 08:51 (UTC)

Wikipedia talk:收錄標準/天體 § 提議修訂天體收錄標準

本人認為,目前的WP:收錄標準/天體對於「可見天體」的定義不甚明確,故提出以下修訂:

現行條文

一個天體應該符合《通用收錄標準》或以下任何至少一項準則,方可被收錄:

  1. 該天體可以僅憑肉眼而無需藉助任何工具直接觀測。
提議條文

一個天體應該符合《通用收錄標準》或以下任何至少一項準則,方可被收錄:

  1. 該天體可以僅憑肉眼而無需藉助任何工具直接觀測。[註 1]
  1. ^ 視星等經常(針對亮度未有顯著變化的天體)或在其最亮時刻(針對變星新星等亮度有變化的天體)亮於6.5等亮星星表所收錄的普通恆星是其中一些例子。

--WiiUf留言) 2025年6月18日 (三) 06:18 (UTC)

Wikipedia talk:快速删除 § 提案禁止一次性将大量页面提报至速删

如题,今天遭遇快速删除候选520+的「盛况」,导致快速删除候选分类难以運作;然後那一批条目又全部有争议无法快速保留,又得全部打包到AfD,浪费编者时间精力。现建议禁止一次性以同一理由将大量页面提报速删,如有需要应提报AfD。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年6月19日 (四) 13:21 (UTC)

Wikipedia talk:删除 § 在存廢討論中禁止/建議避免使用圖示標記立場

目前存廢討論使用衆多帶有圖示的表態模板,例如「(×)删除」、「(○)保留」,共同點是在表態字樣前帶有着色的文字圖示。這種圖示過分的強調了刪除/保留這種概括的立場,而非持某種立場背後的原因,容易使管理員判斷共識時側重於立場本身而非重視正當合理的意見。因此,我建議參照資訊框旗幟「不必要地分散讀者的注意力,並可能使眾多文段中的特定文段過分突出」而禁用的共識,在存廢討論中禁止/建議避免使用圖示標記立場。

英文維基百科曾經達成類似的共識,並最終刪除相關投票模板。英維在2005年對{{支持}}、{{反對}}及{{中立}}模板的存廢討論中,編者達成共識,認爲這些模板讓存廢討論傾向於成爲投票而非達成共識之處,且將注意力從編者的意見挪開後續對其他模板的存廢討論亦繼續支持此共識,亦有人指出這些模板會助長投票(而非討論)的行爲。英維社羣亦在不同的時間達成同樣的共識,供各位參考。

就中維的狀況而言,不同於英維模板的曇花一現,{{刪除}}、{{保留}}等模板歷史悠久,期望用戶突然拋棄這類用法而轉而手動使用粗體不切實際。因此,我建議在這類模板中檢查嵌入頁面是否存廢討論,並在存廢討論中隱藏圖標,僅保留粗體,例子可見{{刪除}}模板的沙盒。另提議在WP:刪除 § 存废讨论中添加以下內容:

提議條文
存废讨论是讨论页面存废的场所……

爲促進共識的建立,避免討論流爲投票,分散參與者和判斷共識的管理員的注意力,進行討論時不宜/不得用圖示強調立場(例如「(×)删除」、「(○)保留」、「(►)移动」等),但使用粗體強調意向並沒有問題。{{刪除}}、{{保留}}等曾經會輸出圖示的存廢意向模板會在存廢討論頁自動隱藏圖示,只會輸出對應的粗體,可以照常使用。

除共識相當明顯的情形……[下略]

關於應該使用「不宜」還是「不得」,私以爲兩者皆可。以上,提請社羣討論。--1F616EMO喵留言回覆請ping) 2025年6月20日 (五) 16:12 (UTC)

維基百科提議

Wikipedia talk:新条目推荐/候选 § DYK上首頁而地區詞未轉換

剛剛看首頁發現,DYK的「問題」似乎沒有要注意地區詞轉換,如現在有出現公交和高達,明顯沒有轉換。在GA和FA以及新聞動態都因上首頁需要注意手動轉換的部分,因為我很少看DYK,對於相關運作不是很理解,有疑慮所以提出。--提斯切里留言) 2025年5月28日 (三) 13:43 (UTC)

Wikipedia talk:維基百科政策簡報 § 關於重啓維基百科政策簡報并更名為維基百科簡報
此討論正在公示7天,直至2025年6月27日 (五) 10:16 (UTC)結束;如有意見請儘快提出。

自2023年2月維基百科政策簡報發出最後一刊以來,該報已有多年未曾更新。在這幾年間中文維基百科社群的生態已發生很大變化,與全域社群進一步對接的需求也與日俱增,由此若僅將重心放於方針未免有些不足。我希望能通過這份刊物讓大家瞭解中文維基百科的近況,並讓中維社群的用戶能大致瞭解全域社群的重大事件。以上。--人间百态,独尊变态(讨论)(签名) 2025年6月10日 (二) 14:22 (UTC)

公共運輸相關指引再次討論

[编辑]

近日整理交通相關條目屢遇交通迷持續加入過度著色的文字以及原創研究內容,因此在此重提建立相關指引,已知目前已有的相關草案有Wikipedia:交通車輛條目指引以及Wikipedia:公共交通路線條目指引,在此提出討論,希望這次有一個結論。相望能做個了結,拖太久了XD--🚊 鐵路Railway 2025年4月17日 (四) 04:32 (UTC)回复

邀請先前參與討論或編輯的維基人@LuciferianThomasGhrenghrenBIT0865一片枫叶心平星辰owennson台南賴哥SickManWP捷利Cdip150Olaf8940TisscherrySanmosa--🚊 鐵路Railway 2025年4月17日 (四) 04:53 (UTC)回复
一時忙碌被存檔了,再次撿回討論。--🚊 鐵路Railway 2025年6月9日 (一) 00:57 (UTC)回复

交通車輛條目指引

[编辑]
現行條文

提議條文

維基百科收錄交通車輛相關主題機動車輛鐵路等車款也能開設条目。但為交通車輛開設條目前,編者務需找出若干可靠獨立第二手来源,舉證主題具備收錄標準。一方面,收錄標準決定主題是否需要開設獨立條目;另一方面,符合收錄標準就意味著有優質來源支撐,編者能寫出全面的條目。收錄標準得證後,編者就可以編寫條目。

條目在描述車輛概況的同時,還要像可靠來源一樣介紹設計、規格、構造等內容;維基百科不歡迎交通迷內容,編者切勿沉淪於過度的細節。

以下介紹交通車輛主題可能用到的元素,撰寫條目時請按實際情況適時選用和調整。如果您有想法或疑問,請在討論頁面進行討論。除此之外,您還應該熟悉WP:更優秀條目寫作指南

信息框模板 信息框是展示主題關鍵信息的表格,桌面版瀏覽多置於條目右上角,流動版瀏覽僅次於起首段。交通車輛信息框一般包括車型名稱、製造商、首次出廠年份、圖像等資料。某些技術設定對理解車輛整體至關重要,也會記入信息框。「關鍵」的車輛信息因車種性質而不盡相同。與所有信息框一樣,交通車輛的信息框應該避免瑣碎的細節。

您可以在Category:交通信息框模板找到合適的模板使用,一般來說,鐵路車輛條目通常採用{{鐵路車輛}}{{鐵路車輛2}}等,機動車輛通常採用{{Infobox Automobile}}等,具體使用方法請見相關信息框內的文檔。 導言 導言應精要概括正文,一般來說會簡述製造商、車輛類型等,如車輛被用於公共客運服務,則車輛所屬的客運或鐵路公司、服務路線、投入服務日期等也可簡述。 背景與概述 本段應說明該型車輛出現的背景與開發緣由,例如是否為因應運量成長、汰換老舊車輛、導入新技術,或配合政府交通政策與營運策略所開發。可說明規劃與製造過程中的主要考量與階段目標。若車輛已退役,亦應交代退役決策背景,包括技術老化、維修成本、替代方案等因素。此外,也可概述該車型在所屬交通系統中的定位與功能,或介紹其在營運歷史中的角色與貢獻,例如是否為首批引進某項技術的車型,或曾參與重大路線開通。 規格與構造 介紹車輛的核心技術,詳細說明其結構、系統與外觀特徵。內容可涵蓋車體材質、設計風格、動力系統(如內燃、電動、混合動力)、機電設備與各項設備規格,並說明編組形式、定員數量及無障礙設施等乘客相關配置。車輛外觀如塗裝、標誌、顯示系統,內裝如座位配置、資訊顯示與空調等。撰寫時應依據可靠來源進行整合與概述,避免過度細節化或直接複製廠商資料,並避免使用過度細節化的術語堆砌內容。 各代歷程 若車輛型號生產超過一代,或具明確的子型號與改良版本,應在本段加以系統性地區分與說明。可依世代順序介紹各版本的開發背景、設計調整、生產時程及投入營運的情況,並指出相較前代在技術或使用層面的主要差異。若某一代僅有小幅修改,可簡要帶過,避免過度拆分。撰寫時應聚焦於型號整體演進的脈絡,避免逐輛記述個別車輛細節,以維持條目的條理性與通用性。 重大事故 若該型車輛曾涉及重大事故,尤其是造成大量人員傷亡或引發媒體廣泛關注者,應於本段簡述相關事故。敘述內容包括事故的時間與地點、涉及單位、造成的損害與影響。若事故本身已具備獨立條目,則可使用{{main}}作主條目導向,以便讀者深入閱讀。事故描述應以中立、簡潔為原則,避免渲染或情緒性文字。 車輛保存 若該型車輛已退役,並有完整保存案例,應介紹其保存狀況與保存地點,包括是否由博物館、學術單位或民間團體保存,是否對外展示,以及保存的原因或文化價值。若保存車輛為特定號碼、原型車或紀念車,也應說明其特殊性與保存背景。此段僅限於有可靠來源佐證之公開保存資訊,不應記錄私人收藏或網路傳言。 参考来源 条目必须遵循可供查证的要求,并將對應的可靠来源内文引用形式来支持条目。 分類 為方便讀者搜尋,車輛條目可按核心主題或行業元素歸類,如在新幹線行駛的車輛應歸入Category:新幹線車輛。但請注意,分類應簡明扼要地描述主題,不可過濫。以蒸汽機為動力的車輛可歸入Category:蒸汽機車或其子分類;但純粹因有明火出現而歸類則不合適(例如車輛曾發生火燒車事故而將該車輛歸入火災相關分類則不適當)。過度歸類只會淡化分類的應有效用。 應避免的事情 愛好者內容 維基百科不是不經篩選的資訊收集處,車輛車次運用、車號機務段分配、改造期程、交車期程、領牌車號、行駛路線、停靠站牌等瑣碎資訊並不適宜加入到條目內。條目不應存在任何原創研究的內容。如果有必要,可以移到維基教科書維基學院等其他維基計劃,又或者到其他專門的Wikia撰寫。 大量的短條目 通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時,請不要創建大量小條目。理想的條目是既不過大,也不過小過多的圖片 請勿於條目內放置各車號的照片,於資訊框模板一張代表即可,其他照片則放入共享資源並於底下納入共享資源連結導引 大量的粗體與文字上色 請勿於條目內為文字過多粗體與上色,行駛路線、領牌車號、特殊備註等,如路線有顏色區分需求請使用表格填色,不要為每個路線明上色。

以上條文由在下草創Cdip150君重整,在此提出討論與公示。--🚊 鐵路Railway 2025年4月17日 (四) 04:39 (UTC)回复

不是,你真確定這是寫完的草案嗎?Sanmosa 新朝雅政 2025年4月17日 (四) 05:43 (UTC)回复
還沒完成,只是全文拿出來看看各位有哪些修改意見。--🚊 鐵路Railway 2025年4月17日 (四) 06:22 (UTC)回复
背景與概述、規格與構造、車輛保存三者好歹先擴充一下才拿出來吧,不然我是真的無法給任何的意見。Sanmosa 新朝雅政 2025年4月18日 (五) 13:47 (UTC)回复
大致沒有太大意見,若有其他維基人發表看法本人會加以回應。--維基病夫❤️邊緣人小組·簽到 2025年4月18日 (五) 04:03 (UTC)回复
同Sanmosa,指引仍尚未完善。--Aqurs 2025年4月20日 (日) 14:23 (UTC)回复
@SanmosaAqurs1已擴充更新,還請指教。--🚊 鐵路Railway 2025年4月21日 (一) 08:29 (UTC)回复
(+)支持,一堆交通迷写车辆调动、编号,甚至是牵引系统、空调、电池箱的型号和种类,这些琐碎信息完全不是一般人所关心的,也没必要保留。(举例:廣州地鐵一號線列車广州地铁三号线北延段列车),我敬佩交通迷实地探访总结资料的能力和勇气,但这不适合维基百科。--自由米花🌾🌼 2025年5月2日 (五) 04:34 (UTC)回复
“这些琐碎信息完全不是一般人所关心的”,这一点我同意。但是除了维基百科,中国大陆已经没有别的地方可以放置这些琐碎信息了,这是很可怕的事情。交通爱好者群体内部也是有纷争的,写车辆调动的反感写牵引系统的,写牵引系统的反感写车辆调动的,有必要就保留哪些信息达成共识。至少我认为,空调、电池箱可写可不写,但是电机主逆辅逆这三大件要留——缺少任何一个都无法构成完整的牵引/辅助系统。BIT0865 · Discussion · 燕房线永远的神! 2025年5月8日 (四) 05:06 (UTC)回复
不同意您说的“除了維基百科,中國大陸已經沒有別的地方可以放置這些瑣碎資訊了,這是很可怕的事情。”,(►)移动维基学院是可行的选择。--自由米花🌾🌼 2025年5月10日 (六) 08:18 (UTC)回复
我在广州地铁四号线南延段列车条目那里进行过移动尝试,移动内容包括电机、主逆、辅逆的参数,乘客信息系统,以及定型编号列表。结果后来,维基主条目那里,编号表格又被别人加了回去 囧rz…… 表格现在被我改成了默认折叠状态,但是说实话,那个表格其实只要两句话就能说明清楚。BIT0865 · Discussion · 燕房线永远的神! 2025年5月10日 (六) 12:08 (UTC)回复
细化“规格与构造”部分如下:
現行條文

介绍车辆的核心技术,详细说明其结构、系统与外观特征。内容可涵盖车体材质、设计风格、动力系统、机电设备与各项设备规格,并说明编组形式、定员数量及无障碍设施等乘客相关配置。车辆外观如涂装、标志、显示系统,内装如座位配置、信息显示与空调等。撰写时应依据可靠来源进行整合与概述,避免过度细节化或直接复制厂商资料,并避免使用过度细节化的术语堆砌内容。

提議條文

介绍车辆的核心技术,详细说明其结构、系统与外观特征。内容可涵盖外观、内装、动力系统、机电设备等。
外观:包括但不限于车体材质、设计风格(含涂装)、显示系统等。
内装:以座位配置和乘客信息系统(PIDS)为主。可将编组形式、定员数量、无障碍设施等乘客相关配置以折叠表格形式列出。
动力系统:包括但不限于内燃、电动、混合动力等,仅需在 Infobox train 模板中说明,再经该处链入相关维基条目,避免条目间的同质化。
机电设备:包括车上、车下两类设备,根据关注程度分为两类。
① 必选项:牵引及辅助系统(牵引电机、牵引逆变器、辅助电源)。
② 可选项:包括但不限于空调、高压电器箱、蓄电池充电机等,在 Infobox train 模板中归为“其他电气设备”。
机电设备若确有性能优势,可在条目正文内展开说明,并配上机器外观图(若有)。
以上各项在撰写时,应依据可靠来源进行整合与概述,避免直接复制厂商资料,以及使用过度细节化的术语堆砌内容。在已有参考文献佐证的前提下,机电设备的型号若可通过 Commons 内的照片进行佐证,须将照片链接链入;对于佐证资料无法公开的可靠型号,型号提供者须在条目讨论页说明查证过程,接受条目读者监督

BIT0865 · Discussion · 燕房线永远的神! 2025年5月8日 (四) 06:17 (UTC)回复
「機電設備的型號若可通過 Commons 內的照片進行佐證,須將照片連結連入;對於佐證資料無法公開的可靠型號,型號提供者須在條目討論頁說明查證過程,接受條目讀者監督。」原創研究??🚊 鐵路Railway 2025年5月8日 (四) 06:56 (UTC)回复
前半句我说的是 A5 的 TGN51E 那种情况。后半句要不去了。BIT0865 · Discussion · 燕房线永远的神! 2025年5月8日 (四) 07:01 (UTC)回复
(!)意見:后半句不赞同(该内容发表时已划去)。现场拍摄的照片,是在案件发生现场直接拍摄而成的,它记录了案件发生时的真实情况,没有经过复制或转述,因此符合原始证据的定义。现场拍摄的照片在法律上为原始证据,即在佐证层级方面属第一手来源。依据维基百科:非原创研究:第一手来源只能用于描述性断言。若该照片反映的是一件简单事实且理性且受过教育的非专业人士能够加以验证,则不属于原创研究范畴。—— 西行寺海苔子 ハナノモトニテ 2025年5月9日 (五) 14:34 (UTC)回复
您所说的这些看似更符合在维基学院发布。个人(-)反对此案。--自由米花🌾🌼 2025年5月10日 (六) 08:23 (UTC)回复
最后一段的最后一句 —— 若其涉及的内容确实适合写入维基学院 —— 可以去掉。至于其他修改部分,我们有必要就何种信息为“琐碎信息”达成共识 —— 对普通乘客而言,确实只需要稍稍介绍外观和内装即可,但是有的爱好者可能会觉得不够。BIT0865 · Discussion · 燕房线永远的神! 2025年5月10日 (六) 12:24 (UTC)回复
在下是認為,如果是來自公開可靠來源所介紹的可以寫入,但來自非公開或原創研究的則不予收錄,就目前已查詢到的,汽車也是有介紹引擎型號等。--🚊 鐵路Railway 2025年5月13日 (二) 06:49 (UTC)回复
同意此觀點。--自由米花🌾🌼 2025年5月20日 (二) 11:39 (UTC)回复
附議,此外個人管見以為寫到系統件即可,若是仍要再往下寫到部分子型號即可,如使用引擎,不需要再對此引擎子型號介紹--消波塊留言2025年5月22日 (四) 09:55 (UTC)回复

公共交通路線條目指引

[编辑]

路線條目目前似乎還很不完善,需再仔細討論。--🚊 鐵路Railway 2025年4月17日 (四) 04:39 (UTC)回复

基本上支持沒意見。另想請問例如廉江市#交通,經常於寫入交通的條目內看到類似的連結,算是旗幟規範能否清理?--提斯切里留言2025年4月17日 (四) 14:34 (UTC)回复
不是旗幟,但是是圖標。你舉出的例子違反了WP:格式手册/图标#百科性用途,按例應當清理。Sanmosa 新朝雅政 2025年4月18日 (五) 13:48 (UTC)回复
清了。--提斯切里留言2025年4月18日 (五) 14:31 (UTC)回复
玉湛高速公路化廉高速公路,理當也要清理?--提斯切里留言2025年4月18日 (五) 14:32 (UTC)回复
這兩個例子牽涉到表格,圖標在其中能起視覺提示與改善導航功能的作用,因此這倒不是需要清理的對象了。Sanmosa 新朝雅政 2025年4月18日 (五) 14:43 (UTC)回复
了解。--提斯切里留言2025年4月18日 (五) 14:58 (UTC)回复
這樣説吧,現WP:公共交通路線條目指引的擬議規定非常生硬、僵化。比如它要求“服務時間及班次:須以表格形式展示數據”、“須以相關模板列出常規優惠”與“分段收費須以表格模式列出”,但這忽略了部分巴士路線的服務時間、班次、常規優惠與分段收費狀況較為簡單的情形(例:九龍巴士61A線在星期一至五(公眾假期除外)只開一班車,故而完全用不着表格;九龍巴士39A線的轉乘優惠只需要兩個句子就能完全説清楚,故而完全用不着模板;新大嶼山巴士36線只有一個分段收費,故而也完全用不着表格)。Sanmosa 新朝雅政 2025年4月20日 (日) 10:26 (UTC)回复
这方面确实僵化,按里程计价的多级票价线路也不一定需要表格即可直接表示,不定班的线路时刻表经常性改变也没法罗列班次时刻表。或可更改为“建议以表格形式展示数据”?--Jason2016426留言2025年4月21日 (一) 04:29 (UTC)回复
“建議”仍然有一定的約束性質。Sanmosa 新朝雅政 2025年4月25日 (五) 12:36 (UTC)回复
那不可能不要这段话的。要是删了,碰到有用新开线路条目时,将一天上百班次的线路时刻表写成一堆数字+顿号怎么办?
要么分类讨论。--Jason2016426留言2025年4月26日 (六) 03:55 (UTC)回复
我的意思是應該僅限定資料項較多時以表格表示,比如九龍巴士61M線的班次牽涉到的時段非常多,這種情況不以表格來處理是不可行的。Sanmosa 新朝雅政 2025年4月26日 (六) 08:22 (UTC)回复
如此分类规定表格使用相关内容的话,也是( ✓ )同意的。--Jason2016426留言2025年4月26日 (六) 10:00 (UTC)回复
( ✓ )同意北捷所有路線條目,內容結構至今為止仍偏向愛好者內容,主要介紹內容過於稀少。--Sinsyuan✍️ 2025年4月26日 (六) 06:12 (UTC)回复
其實現在已經有一定數量的鐵路綫GFA了(WP:优良条目/分类/交通#铁路交通WP:典范条目#交通運輸),或許可以參考現有的GFA來商討合理的結構。Sanmosa 新朝雅政 2025年4月26日 (六) 16:09 (UTC)回复
已充新編寫,故摺疊節省空間。
現行條文

提議條文

維基百科收錄交通路線相關主題,包括鐵路線、公共汽車線等公共交通路線皆可作為條目建立的對象。然而,在為交通路線建立條目前,編者應先尋找若干具可靠性、獨立性且屬於第二手来源的資料,以證明該主題符合收錄標準。一方面,收錄標準決定是否有必要為某主題設立獨立條目;另一方面,若能證明符合標準,亦代表有足夠優質來源支撐,足以撰寫出完整且具中立性的內容。確認收錄標準無虞後,即可著手撰寫條目。

條目在介紹路線時,不應僅列舉總站電話號碼與地址,而應如同可靠來源般,清楚說設開設背景、路線技術規格與路線特徵。維基百科並非交通迷的資料收集平台,應避免陷入過度細節,確保內容具有百科全書的深度與廣度。

以下介紹交通路線條目中可能使用的內容結構,請依實際情況靈活選擇與調整。如有疑問或建議,歡迎至討論頁面交流意見。編者亦可參閱WP:更優秀條目寫作指南以提升條目品質。

訊息框模板 訊息框是呈現主題關鍵資訊的表格,於桌面版多位於條目右上角,行動版則緊接導言段落之後。交通路線的訊息框通常包含路線名稱、營運商、營運里程與圖像等資訊,具體內容可依交通工具類型略有不同。與所有訊息框相同,交通路線訊息框應避免填入過於細瑣的資訊,以維持條目整潔性與可讀性。

您可以在Category:交通信息框模板找到合適的模板。鐵路路線通常使用{{Infobox rail system-route}}{{Infobox rail}},而公共汽車路線則多採用{{公共汽車路線基礎資訊}}等模板。詳細用法請參見各模板所附的文檔說明。

導言 導言應精要概括條目的核心內容,簡述營運單位、服務範圍、通車年份等基本資訊。如路線屬於某特定系統、屬延伸路段或重要支線,也可於導言中簡單交代,以利讀者快速掌握主題背景。

背景與概述 本段應簡要說明該路線的開發背景與緣由,說明其是否因應城市發展、運輸需求增加、政府政策推動或營運策略調整而規劃建設,並可補充規劃過程中的關鍵考量與階段性目標。若該路線已停止營運,亦應交代廢除決策的背景因素,如運量下滑、維護成本過高、重大災害影響或已有其他替代方案等。此外,可說明該路線在整體交通系統中的定位與功能,或其在營運歷史中的角色,例如是否為該系統首條通車路線、工程分期計畫、路線延伸計畫、改善/改建計畫,或對城市交通發展具有指標性意義。

路線與車站 本段應簡要說明該路線的起訖點、行經範圍與主要站點,並概述沿線車站的設置情形,包括總站數、平均站距,以及是否設有快慢車制度、區間運行或跳站服務等。透過這些資訊,能夠清楚展現路線的基本架構與服務方式。

使用車輛 本段應介紹該路線所使用的營運車輛,包括主要型號、現役車種與退役車輛等資訊。相關內容應依據可靠來源撰寫,不應使用私人收藏、網路傳言等未經查證的資料。為維持條目的中立性與可驗證性,應避免僅依賴營運商或監管單位的第一手來源,而應搭配其他次級來源佐證。

參考來源 條目必須遵循可供查證的要求,並將對應的可靠來源內文引用形式來支持條目。

應避免的事情 愛好者內容 維基百科不是不經篩選的資訊收集處,請勿將車牌、車隊編號、車廠等瑣碎資訊加入條目內。條目不應存在任何原創研究的內容。如果有必要,可以移到維基教科書維基學院等其他維基計劃,又或者到其他專門的Wikia撰寫。

大量的短條目 通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時,請不要創建大量小條目。理想的條目是既不過大,也不過小

過多的圖片 請勿於條目內放置各車號的照片,於資訊框模板一張代表即可,其他照片則放入共享資源並於底下納入共享資源連結導引。

大量的粗體與文字上色 請勿於條目內為文字過多粗體與上色,行駛路線、領牌車號、特殊備註等,如路線有顏色區分需求請使用表格填色,不要為每個路線名上色。

以參見幾篇優良或典範條目初步編寫,看是否還有需要修正的地方。--🚊 鐵路Railway 2025年4月30日 (三) 08:34 (UTC)回复

(+)支持目前的方針提議,以台灣捷運路線條目為例,雖然高捷黃線有稍微提供路線提案規劃等內容,但其餘路線條目大都只是寫的像一篇遊記。另外,主條目(XX地鐵/捷運)要介紹的東西一定要聚焦在類似目前為優良級的「北京地鐵」內容風格,避免讓喜歡城市軌道交通的使用者無法了解這條路線和地鐵系統的來龍去脈。--Sinsyuan✍️ 2025年4月30日 (三) 08:44 (UTC)回复
(!)意見
1.关于架构
概括起来三个字:“分情况”。
陆地公共交通无非是两大类:陆地上跑的公路交通、铁轨上跑的轨道交通。铁轨上跑的又分两种:运营意义上的线路和工程意义上的线路。对于城市轨道交通,诸如北京地铁的单条线路,工程意义上的线路与运营意义上的线路区别不大,内文也更多以运营意义上的线路为主、工程意义上的线路为辅展开叙述的。以上我都不是特别懂,所以我就不展开叙述,大体来看应适配于此方针。
但是换做是中国大陆的铁路线路来说则不然。中国大陆的铁路线路应是工程意义上的线路为主、运营意义上的线路为辅来叙述——因为中国大陆的铁路线路存在着大量跨线运营的列车,以京广铁路为例,对于运营意义上的线路,记叙应落实到具体车次条目(例如D1/2次列车)和某两地间的动车组条目(例如京广既有线动车组列车)去承担。至于“运营意义上的线路为辅”,具体措施就是应考虑以客货运概述的形式记叙(另根据经验来看,铁路干线的运输性质大多数共通,除大秦铁路这种专用性极强的线路外,往往不需要特别提及客货运情况)。因此现行条文中“使用车辆”一章、“概述沿线车站的设置情形,包括总站数、平均站距,以及是否设有快慢车制度、区间运行或跳站服务等。”云云语句不适用于中国大陆的铁路线路。
综上,我个人觉得这样一个指引应参照维基百科:格式手册/电子游戏那样,先分情况讨论布局,然后列举出什么是“必需”、什么是“不需”,什么是“值得一写”。目前的拟议内容里,必需要素的列举过于详尽且与章节布局混同,而事实上这两者在性质上本就不同;而“应避免的事情”一章又拼凑着内容、格式文风、图片等多个领域的内容,而显然这也是需要分开谈论的。
2.关于内容
第一条提及的问题不赘述。
只另说一处:“使用车辆”中为维持条目的中立性与可验证性,应避免仅依赖营运商或监管单位的第一手来源。首先不明白第一手来源与“可验证性”的联系。另外诚然,避免依赖第一手来源的原因是在于第一手来源会出现偏颇,但我不是很能理解,究竟是在什么情况下,作为与该信息联系最紧密、最直接的消息源,营运商或监管单位需要在使用车辆这一方面出现偏颇。我想这句话应该出现在历史部分和事故部分——因为这些部分才有可能出现偏颇。
我也并非是完全的专门人士,这些浅见只供参考。另邀请常在国铁领域活跃的编者@MNXANL参与讨论。-- 西行寺海苔子 ハナノモトニテ 2025年4月30日 (三) 11:17 (UTC)回复
(!)意見“铁路线”条目中,在指引中应明确line还是service:即{{Infobox rail system-route}}和{{Infobox rail service}},大部分铁路线条目反而用不到{{Infobox rail}}。line和service应该在何时可作为同一主题方面,我基本同意原作者在“关于条目撰写的主张”中的看法。
而对于其具体结构:什么是应该包含的基本要素?
  • line的基本要素:背景、建设及改建的历史、线路走向、车站布置、运营状况、影响等
  • service的基本要素:背景、规划及运营调整的历史、运营模式、使用车辆、运营状态(客流)等
  • bus route不是很了解,应该和service差不多?
因此,应该参照Wikipedia:格式手册/电子游戏#行文结构章节修改指引语言以明确不同“线路”条目(铁路line、铁路service、巴士route/service)的格式规范,然后再去规定编写风格。--MNXANL 贡献 讨论 2025年5月1日 (四) 01:13 (UTC)+11回复
(+)支持此版本的提議條文。(!)意見,小弟總覺得「大量的粗體與文字上色」的部分,可以加入範例供參考,不然大家認為路線的粗體標記與表格填色的定義很廣,到時又容易有爭議。另提議條文的第一段「然而,在為交通路線建立條目前,編者應先尋找若干具可靠性、獨立性且屬於第二手來源的資料,以證明該主題符合收錄標準。」此段雖然明確列出需有第二手來源,但還是有部分編者的認知有所不同。例如在義大客運討論頁的最新話題。感謝@鐵路1閣下的用心。--英國皇家歐拉夫王子留言2025年5月5日 (一) 02:51 (UTC)回复
@Olaf8940顏色在下是認為應全部去除,不過有愛好者會認為路線必著色才能分辨,在下是有加入範例,需討論,只是這邊受模板格式引響無法顯示,在原頁面是有加入的。--🚊 鐵路Railway 2025年6月9日 (一) 03:10 (UTC)回复
(!)意見“铁路线”方面,跨线车怎么处理?
公交/巴士线路方面,相关内容呢?我辣么(那么)大个收费、班次、行车路线呢?
实在不行可能还是得学WP:VGORDER,明确“铁路线路”、“巴士线路”两大类条目分别该怎么写吧。--Jason2016426留言2025年5月5日 (一) 12:20 (UTC)回复
(!)意見:个人觉得概述章节和序言存在一定程度的功能重复,如果明文写入格式手册会和其他适用于全站的政策相冲突。概述章节可能包含了线路走向、附属设施等内容,在二者不足以分开设置章节的情况下会合并,但应该避免使用“概述”这种命名方法。--屠麟傲血留言2025年5月5日 (一) 13:20 (UTC)回复
线路的发展历史和功能意义的重要性大于其站数及站距。参考 User_talk:Nrya#广州公交线路条目品质之探讨,提议以下两处调整:
現行條文

本段应简要说明该路线的起讫点、行经范围与主要站点,并概述沿线车站的设置情形,包括总站数、平均站距,以及是否设有快慢车制度、区间运行或跳站服务等。通过这些信息,能够清楚展现路线的基本架构与服务方式。

提議條文

本段应简要说明该路线的起讫点、行经范围与主要站点,并概述沿线车站的设置情形,以及是否设有快慢车制度、区间运行或跳站服务等。通过这些信息,能够清楚展现路线的基本架构与服务方式。

現行條文

通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時,請不要創建大量小條目。理想的條目是既不過大,也不過小

提議條文

通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時,請不要創建大量小條目。理想的條目是既不過大,也不過小撰写条目前,需审慎评估线路的有关背景资料是否足够用于创建条目。可将多条背景资料较少,但功能或走向相关联的线路合并为一个条目撰写,或整理为列表形式。

BIT0865 · Discussion · 燕房线永远的神! 2025年5月8日 (四) 06:54 (UTC)回复
明显地不是每一条公交线路都满足关注度,利用GNG评判是合理的选择。--自由米花🌾🌼 2025年5月10日 (六) 08:21 (UTC)回复
此提案文字涉及事项,铁路车站、物理线路部分业已在维基百科:收录标准/交通中有规定(尽管我个人觉得该方针有后续细化空间),直接内链反而更好。另外,正如此前讨论在下与MNXANL观点,仍呼吁此提案全文应依据依据具体类别分情况讨论。-- 西行寺海苔子 ハナノモトニテ 2025年5月10日 (六) 08:32 (UTC)回复
我早前已經在不少的港鐵路線條目和部分車站條目加入了香港舊報紙的來源。事實上,即使陳年舊事,在網上應該也能找到來源的,如有需要可以參考康文署的香港舊報紙,或是到慧科電子剪報查找。--owennson聊天室獎座櫃2025年5月29日 (四) 09:24 (UTC)回复
現行條文

提議條文

維基百科收錄交通路線相關主題,如鐵路線、公共汽車路線等公共交通系統,皆可作為條目建立的對象。為確保條目符合Wikipedia:收錄標準,編者在撰寫前應尋找若干具可靠來源獨立來源,且最好為次級來源的資料,作為條目的撰寫依據。來源充足、客觀中立的內容才能為讀者帶來有價值的資訊。

收錄標準決定是否有必要為某主題建立獨立條目。對於交通路線主題,符合標準亦代表已有足夠來源支持,得以撰寫出具有中立性與百科深度的條目。確認符合顯著性後,方可著手撰寫條目內容。

條目在介紹交通路線時,應避免僅列舉車站、營運時刻或電話號碼等淺層資訊,而是應該像編寫其他百科條目一樣,根據可靠來源梳理路線的設置背景、營運特性與發展歷程。維基百科並非交通愛好者的圖鑑或資料倉庫,因此在撰寫時應注意內容的深度與結構的邏輯性,避免過度羅列細節,失去百科全書應有的知識體例。

以下各章節介紹交通路線條目中常見的內容結構,實際撰寫時,應根據交通工具類型與可得來源的豐富程度,靈活選擇與調整。對於路線條目中所涉主體屬於鐵路系統者,應特別注意「線路(line)」與「服務(service)」的區分;例如,京廣鐵路作為中國國鐵幹線,其條目多以線路本身的工程性質為主,並不著重於個別列車班次的營運細節;而城市軌道交通如地鐵路線則多以服務為導向,條目內容則偏向於列車行駛模式與服務結構。

訊息框模板 交通路線條目通常會使用訊息框模板,以圖表形式呈現基本資訊。在桌面版中,此框多位於條目右上角,而在行動版中則緊接導言段落之後。鐵路路線條目一般使用{{Infobox rail system-route}}來描述系統中某條具體線路的技術與規劃資訊,若主題為某段列車服務則可使用{{Infobox rail service}}。公共汽車路線則較常使用{{公共汽車路線基礎資訊}}等模板。不同類型交通工具的訊息框欄位有所差異,請依主題在Category:交通信息框模板找到合適的模板。

需注意的是,訊息框僅為輔助呈現條目整體內容的摘要,其內容應保持簡潔明確,避免填入過細的資訊,如單一車號、班次細節等,以免削弱條目整體可讀性與重點聚焦。

導言 條目的導言應扼要總結主題的核心資訊,讓讀者能迅速了解路線的基本概況。通常包括營運單位、服務範圍、通車或設立時間等資訊。如果路線屬於某一交通系統,或為其支線、延伸段,亦可於導言簡要交代,幫助讀者建立主題脈絡。導言不應代替後續段落的細部描述,而應作為全條目的簡明引導。

背景與概述 本段旨在綜合說明該路線的設立背景與發展概況,包括建設動機、線路規劃、車站配置、運營模式與歷來調整等。內容可涵蓋城市發展帶動的交通需求、政府政策的推動、營運策略的改變等關鍵因素,以呈現路線誕生與演變的完整脈絡。對於尚在規劃中的路線,應說明其開發過程、決策依據與預期目標;對於已停用的路線,則應交代停駛或裁撤的背景,例如客流下滑、維修成本過高、重大災害損毀,或是已出現其他替代方案等情形。

此外,條目亦可簡要交代該路線在整體交通系統中的功能定位,例如是否為系統中首條通車的主線、是否屬於特定階段計畫,或是否具有試辦與示範性質。若條目主體屬於工程層面較為明確的幹線鐵路,亦可補充其設計規模、投資來源、工程期程,及與其他路線的連接狀況等資訊。以上內容應依據可得來源靈活編排,並與後續章節適度區分,避免重複陳述。

路線與車站 此段應針對路線的起訖點、行經範圍、服務區域及主要站點進行說明,並描述其空間走向與營運設計。對於城市捷運與部分市區巴士而言,應說明是否採用區間運行、跳站服務或快慢車制度,以幫助讀者理解其服務架構。

然而,若條目主體為幹線鐵路(例如中國大陸的京滬、京廣等),因涉及大量跨線列車與複雜的班次配置,則不宜於本段列出車站細節或車次資訊。此類內容宜另置於列車服務或列車車次條目中闡述。

使用車輛 如果交通路線具有特定之營運車輛,且具備公開、可靠來源,則可於本段簡述所使用的主要車種與列車型號,包括現役與歷史車輛。

參考來源 根據Wikipedia:可供查證的基本原則,交通路線條目中所有具體內容皆應以可公開查證的來源支持,並以內文註解或腳註方式清楚列明。內容應以可靠來源為基礎,並優先採用具出版、審查或報導機制的資料。條目應避免以網路愛好者整理的圖文資訊作為唯一來源,尤其對於技術或歷史性敘述,更應檢驗來源的完整性與公信力。

應避免的事情 愛好者內容 維基百科不是不經篩選的資訊收集處,請勿將車牌、車隊編號、車廠等瑣碎資訊加入條目內。條目不應存在任何原創研究的內容。如果有必要,可以移到維基教科書維基學院等其他維基計劃,又或者到其他專門的Wikia撰寫。

大量的短條目 通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時,請不要創建大量小條目。理想的條目是既不過大,也不過小。撰寫條目前,需審慎評估線路的有關背景資料是否足夠用於建立條目。可將多條背景資料較少,但功能或走向相關聯的線路合併為一個條目撰寫,或整理為列表形式。

圖片與圖例 請勿於條目內放置各車號的照片,於資訊框模板一張代表即可,其他照片則放入共享資源並於底下納入共享資源連結導引。

不恰當使用顏色與粗體 請勿於條目內為文字過多粗體與上色,行駛路線、領牌車號、特殊備註等,如路線有顏色區分需求請使用表格填色,不要為每個路線名上色。以下提供一個合宜範例:

備註

根據上面討論稍微整合。--🚊 鐵路Railway 2025年6月9日 (一) 01:55 (UTC)回复

邀請@BIT0865OwennsonSaigyouji-NorikoJason2016426屠麟傲血Olaf8940再次審查更新的內容,望能盡快完成指引。--🚊 鐵路Railway 2025年6月13日 (五) 10:58 (UTC)回复

有關申請權限與申請解除權限的方針條文與申請區的放置問題

[编辑]

WT:方針與指引#修訂方針與指引的命名格式曾經提到有關申請權限與申請解除權限的方針條文與申請區的放置問題,當時Ericliu1912提議WP:解除權限比照WP:權限申請的處理併入WP:申请解除权限,而我則反建議WP:權限申請比照WP:解除權限WP:申请解除权限的處理分拆方針條文與申請區的頁面。考慮到現在距離批量調整規則頁面名稱已經有一段時間,社羣或許應該探討到底要選擇哪個方案,我自己對於兩個方案均持開放態度。Sanmosa 新朝雅政 2025年4月20日 (日) 10:12 (UTC)回复

我主張合併的理由是解除權限方面的方針頁跟申請頁都比權限申請要短,而且兩者並沒有扞格問題,不必分立,也方便檢閱者一次確認有關要件。—— Eric Liu 創造は生命(留言留名學生會 2025年4月20日 (日) 12:55 (UTC)回复
然後剛剛纔注意到甚至申請頁面整段說明都是「包含引用自維基百科:解除權限方針」,沒有任何內容差異,所以實際上兩者完全可以合併在一起啊== —— Eric Liu 創造は生命(留言留名學生會 2025年4月20日 (日) 12:56 (UTC)回复
合併在同一頁不易檢視方針指引的修訂歷史。--Xiplus#Talk 2025年4月22日 (二) 15:36 (UTC)回复
如果走Ericliu1912方案的話,可以讓除權申請區改為比照現WP:權限申請的申請區處理,也就是每類除權申請一個獨立的子頁面。Sanmosa 新朝雅政 2025年4月25日 (五) 12:35 (UTC)回复
@Xiplus?還是說你比較傾向於分拆WP:權限申請頁?Sanmosa 新朝雅政 2025年4月29日 (二) 07:18 (UTC)回复
我覺得應該廢除該頁的方針地位,因為該頁面幾乎都是複述各權限方針的內容而已。如果真的有任何應該屬於方針層級的內容,應當拆分到各權限介紹頁或另立「權限申請方針」頁面。--Xiplus#Talk 2025年4月29日 (二) 14:45 (UTC)回复
@Ericliu1912Sanmosa 新朝雅政 2025年4月30日 (三) 01:58 (UTC)回复
這很值得考慮!—— Eric Liu 創造は生命(留言留名學生會 2025年4月30日 (三) 05:54 (UTC)回复
@XiplusEricliu1912如此,那WP:權限申請的版面或許需要重新設計,此外WP:申请解除权限引述現WP:解除權限方針的部分也需要作一定的調整,個人建議可以參考現WP:存廢覆核請求頂部的說明文字處理。Sanmosa 新朝雅政 2025年4月30日 (三) 14:45 (UTC)回复
改寫成最合適的說明文字當然可以,但我不認為現在兩個申請頁的說明有什麼不得不改的問題。--Xiplus#Talk 2025年5月4日 (日) 04:28 (UTC)回复
@Xiplus那我嘗試在今日稍後給一個方案出來。Sanmosa 新朝雅政 2025年5月8日 (四) 04:47 (UTC)回复
現階段擬定的方案是WP:權限申請移除“簡介”與“要求”的全部內容,WP:申请解除权限引述現WP:解除權限方針的部分代之以現WP:權限申請“解任”的內容,並將其中指向WP:申请解除权限的內部連結替換為“本頁”。另外,為確保頁面命名一致性,現建議WP:權限申請更名為“WP:申請權限”,所有子頁面同。Sanmosa 新朝雅政 2025年5月8日 (四) 23:48 (UTC)回复
會廢除方針?--Xiplus#Talk 2025年5月10日 (六) 02:55 (UTC)回复
@Xiplus會,WP:權限申請的方針地位會被廢除。Sanmosa 新朝雅政 2025年5月10日 (六) 10:01 (UTC)回复

「IP封鎖豁免權及確認使用者權限除外之權限切勿於本頁外申請」一句應修訂到各方針頁。--Xiplus#Talk 2025年5月11日 (日) 00:53 (UTC)回复

@Xiplus可,我明天再看看具體要放到哪個方針頁裏。Sanmosa 新朝雅政 2025年5月11日 (日) 12:22 (UTC)回复
所有權限的方針都要吧(這兩個除外),除非另立申請權限方針。--Xiplus#Talk 2025年5月11日 (日) 12:55 (UTC)回复
@Xiplus剛才統計了一下,理論上需要修訂的頁面應該包括WP:新頁面巡查WP:回退功能WP:巡查豁免權WP:大量訊息發送者WP:AutoWikiBrowserWP:大量帳號建立者WP:檔案移動員WP:跨維基匯入者WP:模板編輯員WP:過濾器助理WP:IP封鎖豁免權授予者WP:活动组织者WP:过滤器编辑者,然而其中大部分的頁面似乎已經有相關的描述了。此外,我留意到這些頁面雖然大多數是方針,但還是有少數幾個是指引,是否需要把那幾個指引與現非規則的WP:巡查豁免權也提升為方針?Sanmosa 新朝雅政 2025年5月12日 (一) 07:39 (UTC)回复
用詞不一樣,並沒有禁止在其他地方申請。提升方針與此無關,另案討論。--Xiplus#Talk 2025年5月12日 (一) 13:01 (UTC)回复
@Xiplus那可以調整既有條文的用詞至有禁止在其他地方申請的意思,但需要提具體方案嗎?感覺這要做比較佔這裏的版面。提升為方針的事情我打算之後才處理,我也只是詢問一下意向而已。Sanmosa 新朝雅政 2025年5月15日 (四) 13:51 (UTC)回复
(其實不用什麼東西都提去方針⋯⋯)—— Eric Liu 創造は生命(留言留名學生會 2025年5月15日 (四) 16:17 (UTC)回复
應該要提具體方案。--Xiplus#Talk 2025年5月18日 (日) 05:13 (UTC)回复
@Xiplus具體方案:
以上。Sanmosa 新朝雅政 2025年5月18日 (日) 06:38 (UTC)回复
个人支持。--自由米花🌾🌼 2025年5月22日 (四) 15:46 (UTC)回复
這部分沒有問題。--Xiplus#Talk 2025年5月24日 (六) 12:56 (UTC)回复
巡查豁免權一節有「本權限無需由申請者本人提出申請」,這是否表示其他權限必須由本人提出申請,不得提名?--Xiplus#Talk 2025年5月24日 (六) 12:59 (UTC)回复
@Xiplus按照過往的理解,確實如此(如果把IP封鎖豁免權從“其他權限”排除掉的話)。Sanmosa 新朝雅政 2025年5月24日 (六) 13:26 (UTC)回复
自動維基瀏覽器使用權 :「管理員有權在申請者申請機器人權限前拒絕其自動維基瀏覽器使用權限申請。另外,對於已獲機器人審核小組批准運作的機器人,可直接予以授權。」可能需列為方針?--Xiplus#Talk 2025年5月24日 (六) 13:02 (UTC)回复
可以列為章節方針,又或是如果合適的話,整個頁面列為方針也未嘗不可。Sanmosa 新朝雅政 2025年5月24日 (六) 13:29 (UTC)回复
解任一節「如機器人帳戶同時持有AWB使用權及機器人權限,不受此限並應該依據機器人方針活躍度要求,AWB使用權與機器人權限同步移除。」需移至Wikipedia:解除權限。--Xiplus#Talk 2025年5月24日 (六) 13:06 (UTC)回复
我無法找到這句話,還請指出出現的位置。Sanmosa 新朝雅政 2025年5月24日 (六) 13:31 (UTC)回复
應該是在Wikipedia:權限申請#解任。--Hamish T 2025年5月24日 (六) 15:16 (UTC)回复
@XiplusHamish那我更傾向於WP:權限申請#解任全段搬運。Sanmosa 新朝雅政 2025年5月24日 (六) 16:15 (UTC)回复
如果您有讀過方針,就應該知道其他的句子都已經存在於解除權限方針。--Xiplus#Talk 2025年5月25日 (日) 12:04 (UTC)回复
無論如何,這事能辦就是了。Sanmosa 新朝雅政 2025年5月26日 (一) 02:23 (UTC)回复
如果您不熟悉的話,那我直接反對這個提案,該方針沒有任何嚴重問題需要修正,不用浪費大家時間討論。--Xiplus#Talk 2025年5月30日 (五) 04:47 (UTC)回复
公示5月8日的提案5月18日的提案5月24日的提案7日。Sanmosa 新朝雅政 2025年6月9日 (一) 02:14 (UTC)回复
上面有點亂,請確定公示提案均未有明確反對?另請重新整理提案內容,感謝。—— Eric Liu 創造は生命(留言留名學生會 2025年6月9日 (一) 05:51 (UTC)回复
具體的公示內容如下:
  1. WP:權限申請廢除方針地位,移除“簡介”與“要求”的全部內容,並更名為“WP:申請權限”,所有子頁面同。
  2. WP:申请解除权限引述現WP:解除權限方針的部分代之以現WP:權限申請“解任”的內容(下條所述的部分例外),並將其中指向WP:申请解除权限的內部連結替換為“本頁”。
  3. WP:權限申請“解任”中「如機器人帳戶同時持有AWB使用權及機器人權限,不受此限並應該依據機器人方針活躍度要求,AWB使用權與機器人權限同步移除。」一句移至WP:解除權限
  4. 修改下列頁面中有關權限申請位置的規定的文字描述:
以上。整個討論串沒有任何(明確的)反對意見,Xiplus說的“如果您不熟悉的話,那我直接反對這個提案”的前提是我不熟悉相關事宜,然而這個前提並不成立。@Ericliu1912Sanmosa 新朝雅政 2025年6月9日 (一) 13:47 (UTC)回复
@Xiplus看法如何?另外他的反對並非無理,因為你針對「如果您有讀過方針」這句話的回覆,不過是繞過他的質疑而已。—— Eric Liu 創造は生命(留言留名學生會 2025年6月9日 (一) 16:04 (UTC)回复
我傾向於這只是微小的溝通問題,而不是真的有意反對。Sanmosa 新朝雅政 2025年6月10日 (二) 00:44 (UTC)回复
我想那是因為你此前不甚莊重的態度所導致。在我來看,上面逕為宣告沒有反對意見的態度,也與之差異無多。真的祇是「微小的溝通問題」嗎?—— Eric Liu 創造は生命(留言留名學生會 2025年6月10日 (二) 09:56 (UTC)回复
這也不是賭氣的理由,賭氣對於社羣協作並無任何幫助。Sanmosa 新朝雅政 2025年6月10日 (二) 14:09 (UTC)回复
一堆顯而易見的問題都是我提的,修訂方針品質這麼糟糕,怎麼讓人支持。--Xiplus#Talk 2025年6月10日 (二) 14:42 (UTC)回复
很不幸地,我相信我當時對於你說的話的具體含義出現了理解上的偏差。已停止公示程序。Sanmosa 新朝雅政 2025年6月10日 (二) 15:02 (UTC)回复
(-)反对,廢除方針部分沒有完整的配套方案,Wikipedia:AutoWikiBrowserWikipedia:巡查豁免權不是方針指引,廢除方針將導致相關資格要求被免除。--Xiplus#Talk 2025年6月10日 (二) 14:40 (UTC)回复
乾脆只拆頁面,不調整文字,這樣也不用一個字一個字讀方針。--Xiplus#Talk 2025年6月10日 (二) 14:45 (UTC)回复
@XiplusWP:巡查豁免權的情況比較特別,它本身是作為資訊頁({{Information page}})存在的,而根據WP:COVID-19條目共識的前例,如果一個資訊頁根據共識被認定為規則,那該頁面的效力會與方針、指引相當,成為既非方針又非指引的正式規則,因此我不認為廢除方針會導致巡查豁免權的資格要求會被廢除。我的建議是WP:AutoWikiBrowser也同樣列為資訊頁,這樣就能避免WP:權限申請廢除方針地位後AWB權的資格要求被廢除的問題。Sanmosa 新朝雅政 2025年6月10日 (二) 15:07 (UTC)回复
「效力會與方針、指引相當」直接就錯了,Wikipedia:方針與指引已指出方針和指引的效力差距,我同意資訊頁可能有共識、是規則,但效力也會比較低。--Xiplus#Talk 2025年6月10日 (二) 15:31 (UTC)回复
WP:權限申請對於巡查豁免者有最近一年內沒有受到封鎖的要求,(現在)這是方針層級的,這與「建議門檻為建立75個有效條目」的強制力上有差距。--Xiplus#Talk 2025年6月10日 (二) 15:43 (UTC)回复
@Xiplus那我感覺我上面提到的事情就很有必要連帶執行了,把所有現非方針的相關頁面列為方針即可。Sanmosa 新朝雅政 2025年6月11日 (三) 05:35 (UTC)回复
您可以對AWB或巡查豁免個別提案,再回來推進此案,新設立方針指引事關重大,不適合一起推動。AWB現在包含不少可能不需要立為方針指引內容,需要詳細規劃。--Xiplus#Talk 2025年6月11日 (三) 13:53 (UTC)回复
WP:AutoWikiBrowser#註冊與申請權限列為章節方針即可,“需要詳細規劃”也未免說得太誇張了。Sanmosa 新朝雅政 2025年6月12日 (四) 00:44 (UTC)回复
您有確認該章節全部都適合作為方針?沒有不合時宜的規則?--Xiplus#Talk 2025年6月12日 (四) 11:36 (UTC)回复
@Xiplus那容我確認一下,該章節第五個自然段的內容是否至今仍然適用?經查,其餘四個自然段的內容並無不合時宜與不對應現WP:權限申請的描述之處。Sanmosa 新朝雅政 2025年6月12日 (四) 14:47 (UTC)回复
第一段「由於安全原因,僅限於註冊使用者申請」到底怎麼來的,在有編輯次數作為資格限制下,這句話顯得冗餘。第三段有任何方針而生的效力?像是不允許短期且量少的申請?若沒有要強制要求的話,似乎不需要列為方針。第四段好像是機器人方針的範疇,不專屬於AWB的。第五段的審核任務是否應該改成強制要求?--Xiplus#Talk 2025年6月12日 (四) 15:47 (UTC)回复
@Xiplus第一段的歷史背景我不清楚,但考慮到現時臨時帳戶機制的存在,這句話在現在的情況下仍然是有意義的,畢竟一個臨時帳戶能維持90日,理論上還是能達到相關編輯次數的要求的。第三段在我看來屬於建議性質,至少能讓一開始打算申請權限的人三思是否真的有需要申請權限。第四段我懷疑是因為之前出過沒bot權限AWB批次添加評級模板的job引發爭議的緣故,在AWB頁面提醒一下還是好的。同意第五段的審核任務應改為強制要求。Sanmosa 新朝雅政 2025年6月14日 (六) 15:05 (UTC)回复
技術上AWB能授權給臨時帳戶?--Xiplus#Talk 2025年6月14日 (六) 15:31 (UTC)回复
@Xiplus不清楚,但可以肯定的是不能排除臨時帳戶(的持有者)真有這種想法,留住第一段好歹能避免一個潛在的問題。Sanmosa 新朝雅政 2025年6月15日 (日) 23:36 (UTC)回复
其他權限不也是有一樣的問題,那是不是應該保留權限申請方針,針對一些通用的定義進行規範?--Xiplus#Talk 2025年6月16日 (一) 12:29 (UTC)回复
@Xiplus巡查員、巡查豁免者與檔案移動員可以引入同樣的要求。其他權限中,有參與日數要求的,參與日數要求為至少90日以上,沒有參與日數要求的,臨時帳戶沒有任何申請相關權限的合理理由。Sanmosa 新朝雅政 2025年6月17日 (二) 00:27 (UTC)回复
临时用户不会有用户组。 Stang1314 2025年6月17日 (二) 02:44 (UTC)回复
如Stang所說,如果技術上就是無法授權,那就不需要另訂規則。--Xiplus#Talk 2025年6月17日 (二) 13:31 (UTC)回复
@Xiplus那AWB章節的第一段廢除掉就是了。Sanmosa 新朝雅政 2025年6月18日 (三) 07:31 (UTC)回复
第三段不反對保留。--Xiplus#Talk 2025年6月19日 (四) 14:20 (UTC)回复
第四段應搬移至Wikipedia:機械人方針#對特定工作項目的額外限制。--Xiplus#Talk 2025年6月19日 (四) 14:20 (UTC)回复

提議提升巡查員的門檻

[编辑]

因應此討論串,提議提升巡查員及回退員的門檻。--Aqurs 2025年4月26日 (六) 08:22 (UTC)回复
由於已經得知WMF不容許此等方法自動獲取「臨時IP檢視」權限,目前考慮到巡查員門檻仍然過低,繼續討論是否應該提升巡查員的門檻。註冊時間也不需要因「檢視臨時帳戶IP」而有所限制,暫且改為跟回退的90日,目前提案改為是否將巡查員門檻提升至跟回退一樣,謝謝。Aqurs 2025年4月26日 (六) 12:34 (UTC)回复

提高巡查員門檻

[编辑]
現行條文

巡查員:需編輯至少250次,自首次編輯以來參與維基百科至少30日,最近一年內沒有受到封鎖(不合理封鎖除外),且在過去三個月內(新註冊者由註冊日起計至申請當日)平均每天的編輯次數多於一次。

提議條文

巡查員:需編輯至少1000次,自首次編輯以來參與維基百科至少90日,最近一年內沒有受到封鎖(不合理封鎖除外),且在過去三個月內平均每天的編輯次數多於一次。

(-)反对:巡查回退员有需要且满足查看临时账户IP信息资格可自行申请,且目前WP:RFR未见积压。Python6345(2025年4月26日 (六) 11:24 (UTC)回复
@Python6345預見的是社群將會人手授予「檢視臨時帳戶IP」的用戶組,這樣會造成大量積壓,跟現在未見積壓有什麼關係?--Aqurs 2025年4月26日 (六) 11:41 (UTC)回复
目前有194名回退员和163名巡查员。而考虑到其中有同时持权者且查看临时账户IP权者可以提前申请并在添加用户组后由机器人一次性授予,亦难以预见积压存在。反而大幅增加巡查员门槛会加重巡查积压。Python6345(2025年4月26日 (六) 12:16 (UTC)移除于2025年4月27日 (日) 04:53 (UTC),因为提案内容改变。回复
(+)支持,加入一个月的新手显然不适合当巡查、回退员。Пусть от победык победе ведёт! 2025年4月26日 (六) 12:27 (UTC)回复
@阿南之人見上方留言,提案修改了,你可能需要再審視一下你的支持票。Aqurs 2025年4月26日 (六) 12:34 (UTC)回复
(由“180日”改为了“90日”87000812。)——自由雨日🌧️❄️ 2025年4月27日 (日) 03:17 (UTC)回复
也不一定,我印象最深刻的就是@U:Summerize在未成为延确之前就担任了巡查员,而且行事非常成熟。 ——自由雨日🌧️❄️ 2025年4月27日 (日) 03:17 (UTC)回复
虽然支持,个人在观察中发现,其实巡查员在事实操作中[來源請求]获取难度高于回退员。--花开夜 留言 ·签名 ·贡献 2025年5月5日 (一) 17:53 (UTC)回复
我个人还是建议设定更加详细的标准。比如,创建一定数量的条目和DYK,或者一定数量的WP与主条目编辑数量等。--花开夜 留言 ·签名 ·贡献 2025年5月5日 (一) 17:54 (UTC)回复
(!)意見 没有看到明显依据,个人倾向折中,至少500次、至少60日。--YFdyh000留言2025年4月26日 (六) 14:48 (UTC)回复
巡查員没必要更严格,巡查员本身没有什么高级权限--百無一用是書生 () 2025年4月27日 (日) 02:31 (UTC)回复
@Shizhao我是同意這點,不過回退員為何要求如此高?—— Eric Liu 創造は生命(留言留名學生會 2025年4月27日 (日) 05:58 (UTC)回复
WP:ROLL#回退功能的优点也可用于在编辑战中占据优势,此外回退员可以访问私有过滤器的日志。Python6345(2025年4月27日 (日) 06:39 (UTC)回复
1000次确实有些多,另外是否可以增加豁免项,比如老用户以新账号开始、在其他维基有相当权限或者比较多的经验。--Kethyga留言2025年4月27日 (日) 03:12 (UTC)回复
“老用户以新账号开始”应该视为一个全新的账户,不应进行豁免;其他站点的情况确实可以作为一些参考来稍微降低一些标准,但是不能达到完全“进行豁免”的程度。 Stang1364 2025年4月27日 (日) 07:04 (UTC)回复
(+)支持提升到與回退員相同。August討論簽名回復請ping 2025年4月27日 (日) 04:23 (UTC)回复
(-)傾向反對:目前巡查员申请需要有巡查记录证实能力,且巡查有问题者会在申请阶段被拒绝,不认为有提升门槛之必要。Python6345(2025年4月27日 (日) 04:53 (UTC)回复
(+)支持,原本條件太寬鬆,新使用者在中文維基百科站務規定還不甚了解時,就能輕易申請,這情況著實不合理。我也認為必須施加更嚴謹的申請條件,以免浮濫申請權限的情況發生,有些人就是想當一個帽子(維基頭銜)蒐集狂,最近的不當行為頁面剛好有一個例子。--Znppo留言2025年4月27日 (日) 06:57 (UTC)回复
(?)疑問:請問是哪位仁兄?--自由米花🌾🌼 2025年4月28日 (一) 13:30 (UTC)回复
U:Peterxy12,编辑数不足100即申请多个本地和全域权限。Python6345(2025年4月28日 (一) 13:50 (UTC)回复
编辑冲突我猜他想说的应该是这位,不过这位我觉得不是帽子收集狂而是扰乱了…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 13:52 (UTC)回复
(:)回應,我說的就是他XD。--Znppo留言2025年4月28日 (一) 14:00 (UTC)回复
不是扰乱--Peterxy12留言2025年4月29日 (二) 10:27 (UTC)回复
硬性門檻似乎不用那麼高,五百次/兩個月應該夠吧?另外或應說明這是一般建議門檻,若有顯著例外,亦可破格申請。—— Eric Liu 創造は生命(留言留名學生會 2025年4月28日 (一) 18:31 (UTC)回复
(+)支持提高標準--🚊 鐵路Railway 2025年4月29日 (二) 04:29 (UTC)回复
纯粹给个建议方向:个人觉得提高门槛也不一定只看编辑数量,也可以从条目编写、模拟巡查和参与条目(存废)讨论等方面考察能力。当然这样就难以量化了。--Steven Sun留言2025年4月29日 (二) 07:54 (UTC)回复
当前巡查员申请必须有巡查记录,否则会被快速拒绝,且如有用户质疑巡查不当亦需要合理回应。Python6345(2025年4月29日 (二) 10:19 (UTC)回复
如果要提升巡查員的門檻的話,是否應該考慮要求巡查員同時滿足巡查豁免者的門檻?Sanmosa 新朝雅政 2025年4月29日 (二) 12:02 (UTC)回复
我一直很困惑这点。巡查员既然有巡查豁免者的权限,那当然要求不应该低于巡查豁免者,这应该是个逻辑问题吧?(要么就规定巡查员并不能让自己免于巡查,这样也可合乎逻辑。)似乎之前有过多次类似提案但均未通过。 ——自由雨日🌧️❄️ 2025年4月29日 (二) 12:09 (UTC)回复
我在WT:新頁面巡查/存檔3#取消巡查员的巡查豁免权已經提出過「醫者不自醫」的情況,而且也明確指出了「巡查員有巡查別人條目的能力也應該有巡查自己條目的能力」這種說法不對應中文維基百科的現況,但還是存在個別用戶對實際情況視而不見的事情。Sanmosa 新朝雅政 2025年4月29日 (二) 12:39 (UTC) 👍1回复
巡查员身具巡查豁免权、自动免巡印象中算技术问题。您可换角度看,巡查员的豁免与巡查豁免者是相同权限但不同缘由,场地工作人员免于安检/员工通道,极少数嘉宾或委员免于安检,不等于前者需具后者级别。但我仍支持对巡查员被豁免的页面做统计列出并存档以履行复审,或者变相削弱自动免巡(Sakamotosan拒绝接受机器人workaround方案)。--YFdyh000留言2025年4月29日 (二) 20:45 (UTC)回复
正常情況下,如果巡查員確實有有巡查自己條目的能力,那現狀並非一個問題,然而現狀並非正常情況,那也就只能如此管制了。Sanmosa 新朝雅政 2025年4月30日 (三) 14:47 (UTC)回复
顯然應該彈劾你所說案例,而非反過來降低全體巡查員授權標準。—— Eric Liu 創造は生命(留言留名學生會 2025年5月2日 (五) 09:08 (UTC)回复
這不現實,真按你這樣説的話,全部巡查員都得除權。Sanmosa 新朝雅政 2025年5月2日 (五) 13:01 (UTC)回复
既然全部巡查員都得除權,不妨指出几个近期巡查员滥用巡查豁免的案例。Python6345(2025年5月2日 (五) 13:19 (UTC)回复
日期20220626寫的條目來說好了:他在今年4月30日建立的马达加斯加起义條目裏來源與句號之間不知為何出現了空格,而且條目內的兩個來源實際上是同一個來源(Special:Permalink/87050726);他在同日建立的九州风神條目裏來源與句號之間、英文與括號之間也不知為何出現了空格,而且內文的表述也不清不楚,我甚至還不知道九州風神是想要在哪個創業板上市(Special:Permalink/87054660)。Sanmosa 新朝雅政 2025年5月3日 (六) 02:56 (UTC)回复
然後再拿MykolaHK寫的條目舉例:克里米亞韃靼飲食條目是他在昨天建立的,整個條目只有一個來源,“傳統菜餚”章節完全沒有來源,而且還是點列;開爾文橋站條目是他在今年2月16日建立的,大部分正文文段無來源支持,而且整體的翻譯水平實在不太好(比如“且是迄今為止保留此配置的最繁忙的車站”)。Sanmosa 新朝雅政 2025年5月3日 (六) 03:13 (UTC)回复
对于这点我只能认为做翻译的基本上就是忠实翻译,很少人会自己去找来源,当然如果原本的条目有问题那就两边都挂维护模板就好了¯\_(ツ)_/¯翻译腔也是,也得挂上维护模板。--KurGenera(留言) 2025年5月3日 (六) 03:25 (UTC)回复
然而巡查權自帶的巡查豁免權使之實際上基本無法實現。Sanmosa 新朝雅政 2025年5月3日 (六) 03:58 (UTC)回复
(:)回應Sanmosa:謝謝建議。關於克里米亞韃靼飲食,確實來源較少,會先挂維護模板,但這裏我認爲點列是可以接受的,畢竟這裏是介紹各菜式。而開爾文橋那邊雖然有10個來源,但不得不承認正文來源確實較少,這裏也會先挂維護模板,另外想問您認爲「且是迄今為止保留此配置的最繁忙的車站」這句該如何表達?謝謝。--Mykola留言2025年5月3日 (六) 10:29 (UTC)回复
「且是迄今為止保留此配置的車站中最繁忙者」或許較好。Sanmosa 新朝雅政 2025年5月3日 (六) 15:05 (UTC)回复
没有感觉更好。虽然之前也觉得两个“的”不太好,但细看我觉得没问题。问题可能在“保留此配置”的具体意涵(淘汰了吗),繁忙统计范围未指明(线路、城市、全球),以及没有列明来源,{{when}}。--YFdyh000留言2025年5月3日 (六) 15:15 (UTC)回复
@YFdyh000你或許需要結合前文來看,不結合前文來看的話,你自然看不出個所以然來。Sanmosa 新朝雅政 2025年5月4日 (日) 01:22 (UTC)回复
前文也没说月台。--YFdyh000留言2025年5月4日 (日) 03:00 (UTC)回复
我懷疑是沒完全翻譯的鍋。Sanmosa 新朝雅政 2025年5月4日 (日) 13:09 (UTC)回复
@Sanmosa關於克里米亞韃靼飲食開爾文橋站,我已經進行大幅修改並補上來源,相信已達標準。我在日後也會再寫條目推上DYK,通過後再嘗試申請巡查豁免權,以消除疑慮。謝謝提點。—Mykola留言2025年6月8日 (日) 18:07 (UTC)回复
巡查員理當能巡查任何條目(無論是直接改善或是補充標記),不分對象,那自然也包含自己建立的頁面。做不到這點,那就除權,沒問題。—— Eric Liu 創造は生命(留言留名學生會 2025年5月4日 (日) 13:23 (UTC)回复
很多情况是应该发现、注意和提醒,而做不到弹劾。是提升而非降低标准?--YFdyh000留言2025年5月2日 (五) 22:35 (UTC)回复
看了一下Wikipedia_talk:新頁面巡查/存檔3#提案四Wikipedia_talk:新頁面巡查/存檔3#使巡查员可以移除或增加自己的巡查豁免者权限,社群似乎比較接受這個方向的變革,社群可以嘗試朝著這個方向繼續討論下去,會比較容易形成共識。~~Sid~~ 2025年5月3日 (六) 13:40 (UTC)回复
(+)强烈支持,个人认为:
現行條文

巡查員:需編輯至少250次,自首次編輯以來參與維基百科至少30日

提議條文

巡查員:需編輯至少3000次2000次1500次,自首次編輯以來參與維基百科至少120日90日

(原本打算想3000次或者5000次的,感觉不现实😂)--KurGenera(留言) 2025年4月29日 (二) 16:44 (UTC)回复
改了一下,还是1500次吧。1000次感觉还是太少。--KurGenera(留言) 2025年4月29日 (二) 16:51 (UTC)回复
(~)補充:至于巡查豁免权的问题...创建75个有效条目...至少得等鄙人编辑次数上次才有可能吧...因此还是(-)反对需要同时有巡查豁免权程度...--KurGenera(留言) 2025年4月29日 (二) 17:12 (UTC)回复
哥們,這標準太高了。—— Eric Liu 創造は生命(留言留名學生會 2025年4月29日 (二) 20:07 (UTC)回复
加到跟回退員一樣的門檻就好了,同時有巡免的程度對你維來說還是太難了。--SunAfterRain 2025年4月29日 (二) 17:20 (UTC)回复
(!)意見:之前拆权的反对原因为担心巡查员编辑冲刷最近更改,如此可拆巡查员创建操作自动标记为已巡查,但不知是否有技术难题。Python6345(2025年5月2日 (五) 03:22 (UTC)回复
“之前拆权的反对原因为担心巡查员编辑冲刷最近更改”吗?编辑巡查功能上线没多久,也不温不火。--YFdyh000留言2025年5月3日 (六) 03:42 (UTC)回复
阅读之前讨论,我认为这则留言的理据是阻止拆权提案通过的主要原因,可参考Hotaru Natsumi案的支持理由。此外如上述提议因技术难题无法解决,本人倾向拆权但允许自我授权。Python6345(2025年5月3日 (六) 03:56 (UTC)回复
不如設定編輯至少500次,註冊至少90日,創建不少於10個有效且未被提刪的條目,且180日內未被封禁為標準?--FK8438留言2025年5月23日 (五) 00:27 (UTC)回复
為什麼要放寬解封後天數門檻?--Mykola留言2025年5月23日 (五) 00:56 (UTC)回复
我也挺好奇原因的。--~~Sid~~ 2025年6月6日 (五) 13:51 (UTC)回复

小结:社群对于提高巡查员的建议门槛存在共识,但对于“达到与回退员等同标准”并不存在共识。巡查员作为一个权限并不十分“危险”的用户组,使用过高的标准弊大于利。同时,由于下方达成了“分离巡查员的巡查豁免权限”的共识,无需考虑巡查豁免相关的问题。

現行條文

需编辑至少250次,自首次编辑以来参与维基百科至少30日,最近一年内没有受到封禁(不合理封禁除外),且在过去三个月内(新注册者由注册日起计至申请当日)平均每天的编辑次数多于一次。

提議條文

需编辑至少500次,自首次编辑以来参与维基百科至少60日,最近一年内没有受到封禁(不合理封禁除外),且在过去三个月内(新注册者由注册日起计至申请当日)平均每天的编辑次数多于一次。

需要修改的页面包括Wikipedia:權限申請Wikipedia:新頁面巡查。由于上方讨论持续了很久没有新意见了,暂时在这里放置本修改提案一段时间,之后便进行公示。 Stang1315 2025年6月16日 (一) 03:44 (UTC)回复

(+)傾向支持:或可更嚴格。--Mykola留言2025年6月16日 (一) 09:17 (UTC)回复
(+)支持:妥適而穩重的修訂案。—— Eric Liu 創造は生命(留言留名學生會 2025年6月16日 (一) 15:47 (UTC)回复

公示7日,2025年6月27日 (五) 03:58 (UTC)結束 Stang1311 2025年6月20日 (五) 03:58 (UTC)回复

(=)中立:標準稍低。--WiiUf留言2025年6月20日 (五) 11:21 (UTC)回复

重提允許巡查員自我增加與移除自動巡查權/將自動巡查與巡查員權限組分離

[编辑]

重提允許巡查員自我增加與移除自動巡查權/將自動巡查與巡查員權限組分離

[编辑]

已通过:
通过
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

由於我看到上面有這方面的討論需求,所以我單獨拉出來討論提高效率也較易於分別社群共識。

過往討論參見Wikipedia_talk:新頁面巡查/存檔3#提案四Wikipedia_talk:新頁面巡查/存檔3#使巡查員可以移除或增加自己的巡查豁免者權限

另外我對於提案是沒有什麼特別的意見,請不要因為我單獨拉出討論而視為我支持這個提案,謝謝。~~Sid~~ 2025年5月7日 (三) 14:30 (UTC)回复

@ASid如果是這樣的話,倒不如把討論拆得更完整些,兩個提案各自一個小標題。Sanmosa 新朝雅政 2025年5月12日 (一) 07:44 (UTC)回复
OK的,不過現在沒什麼人要參予討論,看起來又要涼了。:(--~~Sid~~ 2025年5月16日 (五) 01:32 (UTC)回复
edit.~~Sid~~ 2025年5月16日 (五) 01:33 (UTC)回复
@SunAfterRainYFdyh000Python6345Kurgenera自由雨日鐵路1August.CShizhaoAqurs1Znppo花开夜Hi here!很抱歉打擾各位了,鑒於討論冷掉,故我把各位ping過來,
先不說提高巡查員標準的事情,為什麼我說不用特地討論標準的問題,因為「將自動巡查與巡查員權限組分離」已經一定程度上降低巡查員的標準,所以我才會說不用太過在意標準的部分。「允許巡查員自我增加與移除自動巡查權」,則是牽扯到自制力的部分,至於如果有人擔心濫用自我授權自動巡查的問題,則以巡查員權限組將報告提到WP:RFDR即可(這部分可以在方針修訂特別註明),再麻煩各位多加參予討論了,謝謝。:)
Sanmosa我就不特別ping了。--~~Sid~~ 2025年5月16日 (五) 01:53 (UTC)回复
静等具体提案。--__Don't bite! 2025年5月16日 (五) 02:04 (UTC)回复
我覺得就算把自動巡查拆掉,巡查員依舊要拉高一些標準,畢竟沒有帽子其實也能巡查條目(只是沒辦法用巡查員的那幾個功能而已),並且要巡查條目也要基本理解怎麼讀條目,我不覺得要求應該比回退員低。--SunAfterRain 2025年5月16日 (五) 11:33 (UTC)回复
(-)傾向反對:提高硬门槛会让一定巡查经验者被迫再次检查被标记为已巡查之条目,虽必要时可IAR但可能引不必要之争议。如允许非巡查员使用隐藏已巡查的条目则对此(=)中立。Python6345(2025年5月16日 (五) 11:58 (UTC)回复
拔掉之後管理員授予巡查員時就不太需要考慮巡查豁免權的問題,儘管巡查員可以自我授權,但社群仍然可以監察,如果該巡查員讓社群覺得他需要被巡查,那他就不該自我授權,如果自我授權就應該提報到WP:RFDR讓社群討論拔掉巡查員權限組的事情。額外一提但管理員與社群在考慮人選時就要特別評估該人過往的行為是否讓人信任他自己的自制力,不過我覺得社群平時就會考慮這點,所以沒什麼好擔心的。--~~Sid~~ 2025年5月17日 (六) 12:32 (UTC)回复
我依然认为由巡查员自行决定是否拥有巡免权是极其无理的,对单独取得巡免权者也非常不公。要拆就完全拆分,两权不再有任何相关。唯有一点我当时想了一阵也认为可以退让,即让巡查员可以巡查自己的条目,这样可以明确巡查动作与职权相符,避免某些因为他可以巡查其他条目所以他也一定可以保证自己条目质量的逻辑死亡。->>Vocal&Guitar->>留言 2025年5月18日 (日) 02:58 (UTC)回复
這也可行。—— Eric Liu 創造は生命(留言留名學生會 2025年5月18日 (日) 06:42 (UTC)回复
有條件支持:需可在Special:最近更改中排除巡查员之编辑。Python6345(2025年5月18日 (日) 07:40 (UTC)回复
这个页里任何人的编辑都会列在其中,你是要排除什么?--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 07:21 (UTC)回复
一般可使用未巡查变更排除巡免和巡查之编辑。如拆巡查之巡免权且不允许自我授权,则本人需有办法在最近更改中排除巡查员之编辑以避免重复检查可能不需要复核之编辑。( π )题外话本人对回退员之编辑无法单独排除亦不满,但技术上无法排除故未提案。Python6345(2025年5月19日 (一) 07:47 (UTC)回复
我理解了,技术问题恕我我无能为力。--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 23:46 (UTC)回复
有條件支持,意见同U:Python6345,希望技术问题早日解决。——南屿小十233对话 | 贡献 | 签名2025年6月2日 (一) 04:57 (UTC)回复
要這麼做當然可以,但我只能說你們看要不要也討論一下順便也把管理員的自動巡查一併拆掉,原因是對於巡查員有自動巡查,本就是基於巡查員理應能處理好自己創建條目的信任,現在這種信任要單獨拉出來討論當然可以,管理員也理應如此,因為不是所有管理員都會寫條目,我過往也不是沒看過管理員寫的東西,需要做一步處理。至於無理的部分我只能說這是對現有巡查員極度的不信任,對單獨取得巡查豁免權的人不公的部分,如果這樣的話我認為社群早該把巡查員權限組的自動巡查拆掉,而不是拖到現在,所以這裡我不是很明白不公在哪,巡查員相對於巡查豁免權本就是比較好申請的,這我不否認,然而在怎麼樣都不該說這是不公,如果不公的話那社群早該拆解巡查員權限組。:(
額外一提,要這樣做的話請自己說服表示這會大幅度增加巡查員負擔的意見。:)
有人說管理員拆掉自動巡查,那自動巡查要誰授予,那當然還是管理員可以自我授權,同樣的管理員濫用自我授權,那這種就應視為濫用權限,該除權,不過我知道社群沒那個時間與精力以這種理由除管理員權就是。:(--~~Sid~~ 2025年5月18日 (日) 13:53 (UTC)回复
有些常年提案在若干年后也会有通过的一天,我不认为社群过往的决定能说明什么问题,相反反映出社群对巡查问题、对条目质量问题一贯的漠视。
经常创建新条目的巡查员自然已经达到巡查豁免者门槛,那么他们当然可以直接申请巡免权,不存在大幅增加巡查员负担的问题。
另外关于管理员,Stang已经提过相同意见,我完全同意。--。->>Vocal&Guitar->>留言 2025年5月18日 (日) 23:30 (UTC)回复
即便如此我仍認為「單獨取得巡查豁免權的人不公」這裡不該說不公,這個說法相當的不好至少我來說。此外你的想法我沒意見,然而基於過往的討論,我看到大家最可以接受的方式,仍然是這個,這次的討論以目前來看也沒什麼人反對這個變革方式,我還是建議你可以考慮接受這個變革,起碼有在改變,而不是僵持不下導致原地踏步。我不是要改變你的想法什麼的,你可以繼續堅持您的想法,但起碼讓情況有所轉變,如果未來社群或您發現很多巡查員濫用自我授權,您再將情況提出來要求移除也不遲不是麼。:)
管理員權限拆解的部分,我認為可能要再等等,因為過往的討論針對這部分沒有很多,應該沒辦法一併處理,社群對此可能會有很多地方需要磨合,我建議先處理巡查員權限組的部分。:)--~~Sid~~ 2025年5月19日 (一) 01:09 (UTC)回复
句句没意见,句句在反对,大可以直接一点反对就行了,我的案也不缺你一票反对。这个案过不过对我一点影响都没有,甚至我也是巡查员我的权限还会变少,我倒是很希望反对我案的巡查员一起来对赌,只要我案通过,大家一起永久辞任巡查员,看看到底是谁舍不得这顶帽子。
上一句还在说管理员也理应如此下一句就变成认为可能要再等等,变脸变这么快不怕自己信用破产吗?--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 07:21 (UTC)回复
?--~~Sid~~ 2025年5月19日 (一) 08:24 (UTC)回复
我會說要再等等是因為這件事情不是我一個人說得算,社群過往也沒有討論,我沒有任何基礎推動。
我會說理應如此,這是基於我的觀察而得出想法。
我建議你試著接受,是因為社群目前並整體上並不怎麼接受你的意見。
我沒意見也確實是真的,我不知道我話講這麼白,原因也說明白,還要被你冠上一句信用破產,你要跟別人對著幹,對著罵我沒意見,請不要坡及我。--~~Sid~~ 2025年5月19日 (一) 08:32 (UTC)回复
另外我也不知道你這是要賭什麼,這有什麼好賭的,不是很明白你的邏輯。--~~Sid~~ 2025年5月19日 (一) 08:36 (UTC)回复
我也再次澄清
Wikipedia:互助客栈/方针#c-ASid-20250519010900-Ohtashinichiro-20250518233000這裡我有說到「基於過往的討論,我看到大家最可以接受的方式,仍然是這個,這次的討論以目前來看也沒什麼人反對這個變革方式,我還是建議你可以考慮接受這個變革,起碼有在改變,而不是僵持不下導致原地踏步。我不是要改變你的想法什麼的,你可以繼續堅持您的想法,但起碼讓情況有所轉變,如果未來社群或您發現很多巡查員濫用自我授權,您再將情況提出來要求移除也不遲不是麼。」
我是要說服你暫時接受,讓變革有所推動而不是在原地踏步,這是基於社群的討論,而不是我的意見,你要堅持照著你的想法變革你可以說,用一副咄咄逼人的樣子在對話,那你請自便。--~~Sid~~ 2025年5月19日 (一) 08:49 (UTC)回复
要这么做当然可以也是你说的,说服你暂时接受也是你说的,从我的角度我只看到你在变来变去,而没有对提案的实质意见。你如果真的没有意见,为什么反复搬出社群(还是两年前的),要建议我说服我接受呢?这一次的讨论里连你在内只有三个人回复了我,你为什么就判定现在的社群不接受我的意见呢?你有没有研究过我上一次为什么故意提一个很奇怪被社群全面反对的方案??为什么你的案就是变革有所推动,那如果你来支持我的案不就是变革大大地推动吗?--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 23:44 (UTC)回复
我已經跟你說明過我對你的意見是真的沒意見,社群即便執行你的方案,我也不會有意見也更加不會反對,這對我也沒什麼影響,也跟你說明過我不是要強行改變你的看法,所以你請自便吧。:)
如果需要幫你另開一個章節來討論你的方案,我很樂意協助。此外我相信你對我的部分回應仍有些許疑惑,這裡也跟您說聲抱歉,我不太想特意解釋。:)--~~Sid~~ 2025年5月21日 (三) 11:48 (UTC)回复
我很难想象移除“被认为是社群中有经验的成员”的管理员之自动巡查权限的必要性。如果连管理员权限都要如此阉割,那站内还能有谁符合具备自动巡查权限的要求?——南屿小十233对话 | 贡献 | 签名2025年6月2日 (一) 04:46 (UTC)回复
大致上支持「默認不巡查但可自行選擇」的這個方向,有具體方針上的新增再看。--Aqurs 2025年5月19日 (一) 03:24 (UTC)回复

將自動巡查與巡查員權限組分離

[编辑]
「將自動巡查與巡查員權限組分離」已經上面是確定的共識,然而措施的部分仍然有人不同意,所以我開了下面的章節討論,請注意這個只是確立「將自動巡查與巡查員權限組分離」的共識。 公示7日,2025年6月1日 (日) 13:34 (UTC)結束~~Sid~~ 2025年5月25日 (日) 13:34 (UTC)回复
請各位查看這則澄清留言,謝謝。--~~Sid~~ 2025年5月27日 (二) 13:59 (UTC)回复
这种提案居然能走到公示,真是神奇。唉。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年5月25日 (日) 15:47 (UTC)回复
那我觉得不如一并将“自动巡查”这个操作彻底拆分出来,包括巡查员和管理员都不应该自动获得这个权限。另外我觉得最大的遗憾就是技术上的问题导致PageTriage没法进行部署,不然整个操作都是水到渠成的:“巡查”这一操作只针对主空间的条目,可以反复对一个条目进行“巡查”(也就是标记可以逆操作),再加上配套的ui和脚本;“自动巡查”这个操作也只针对主空间新建的页面这个行为,也不会给巡查员带来很大的负担。 Stang1334 2025年5月27日 (二) 06:58 (UTC)回复
這部分沒什麼人去討論到,現況無法處理,強硬公示會被說沒有共識為何可以公示,您有空的時候可以推一推社群討論。🫠--~~Sid~~ 2025年5月28日 (三) 05:50 (UTC)回复
可以,我就是顺口一说,公示的内容还是只针对巡查员的。另外再顺嘴一说,一些全域权限(比如全域回退员)附带的自动巡查功能实际上也是应该被去除的,只是做起来比较麻烦。这两个地方可以在未来如果需要的时候作为参考。@ASid Stang1333 2025年5月28日 (三) 05:55 (UTC)回复
我很难想象移除“被认为是社群中有经验的成员”的管理员之自动巡查权限的必要性。如果连管理员权限都要如此阉割,那站内还能有谁符合具备自动巡查权限的要求?——南屿小十233对话 | 贡献 | 签名2025年6月2日 (一) 04:59 (UTC)回复
公示通过WiiUf留言2025年5月31日 (六) 16:35 (UTC)回复
@WiiUfbro是不是忘了5月有31天 Stang1330 2025年6月1日 (日) 04:53 (UTC)回复
啊啊啊,抱歉--WiiUf留言2025年6月1日 (日) 10:00 (UTC)回复
@WiiUf公示期現在是否已完結?Sanmosa 新朝雅政 2025年6月4日 (三) 04:03 (UTC)回复
已經過幾天了。- - 宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️2025年6月4日 (三) 04:08 (UTC)回复
是的呀。-- WiiUf🐉🕯️ 2025年6月4日 (三) 04:34 (UTC)回复

本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

提案“删除巡查员附带的巡查豁免权”已通过,下方段落将讨论具体如何执行,以及相关配套设施事项。 Stang1326 2025年6月4日 (三) 12:02 (UTC)回复

@Stang(調整了關閉範圍並將公示章節降為四級章節)--SunAfterRain 2025年6月4日 (三) 12:07 (UTC)回复
Special:固定链接/87784727#提議提升巡查員的門檻起拆分为独立章节。--Steven Sun留言2025年6月16日 (一) 10:36 (UTC)回复

配套措施

[编辑]

讨论区

[编辑]
這裡是討論拔除後的配套措施,鑒於上面討論的情況,我不想要來干涉這裡的討論了,即便我是沒意見的,所以請各位自便。~~Sid~~ 2025年5月25日 (日) 13:34 (UTC)回复
請注意,本人同意兩權分立的前提是允許巡查員保有巡查自己條目的權力,否則本人不會支持修訂有關政策。—— Eric Liu 創造は生命(留言留名學生會 2025年5月25日 (日) 14:15 (UTC)回复
另外,我需要提出,原因取得巡查權限而合併巡查豁免權限者,屆時均應自動重新授予之。—— Eric Liu 創造は生命(留言留名學生會 2025年5月26日 (一) 08:50 (UTC)回复
我開出了第一炮Wikipedia:權限申請/申請巡查豁免權#User:A2569875。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️2025年5月27日 (二) 03:15 (UTC)回复
为什么巡查员要保有巡查自己条目的权力?本站上除非明显破坏,管理员可以删除自己添加快速删除模板的页面吗? Stang1334 2025年5月27日 (二) 07:00 (UTC)回复
原本是巡查豁免者,後來變成巡查員的巡查員本來就應該要保有巡查自己条目的权力。不然申請成為巡查員成為了處罰???? 處罰禁止繼續巡查豁免者???????? 這樣我申請巡查員我豈不是笨蛋???? 申請了個處罰???? 處罰自己???? 我申請巡查員時你哪隻眼睛看到我申請「巡查豁免者除權」??? 你沒事除我權理由是??? 很遺憾我只能理解為處罰。 @Stang另見我在Wikipedia:權限申請/申請巡查豁免權#User:A2569875的發言。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️2025年5月28日 (三) 06:14 (UTC)回复
如果你曾经是巡查豁免者,在权限相关的配置更新之后就会被重新授予巡查豁免的权限,这个你无需担心。@A2569875 Stang1333 2025年5月28日 (三) 07:34 (UTC)回复
我问的这个问题好像没人讨论啊…如下措施实施后,巡查员是否可以标记自己的条目为已巡查?如果不能,看起来好像没法使用过滤器来自动阻止,只能人工的来发现 Stang1310 2025年6月20日 (五) 10:01 (UTC)回复
个人认为删除权限和标记巡查权限还是不太一样的:删除操作易引发争议,且删除后的内容对普通用户不可见,不易于复查,因此删除操作需要两名用户完成。而巡查操作争议较少,且易于复查,因此由一个用户完成(即巡查自己创建的条目)不会有太大的风险。--Steven Sun留言2025年6月20日 (五) 12:24 (UTC)回复

提案区

[编辑]
Python6345提案之一
[编辑]
  • 技术上移除巡查员之自动巡查权。
  • 允许巡查员自我授权或申请巡查豁免权。
  • 自我授权滥用时应同时除巡查权,申请权限滥用时仅除巡免权。

如拟议二无法实现则本人支持该方案。Python6345(2025年5月28日 (三) 07:09 (UTC)回复

“允许巡查员自我授权”意义何在? Stang1333 2025年5月28日 (三) 07:37 (UTC)回复
该疑虑,本人认为自我授权时可默认巡查员为自身条目摁下巡查按钮,此时除权也应对比滥用巡查权。Python6345(2025年5月28日 (三) 09:45 (UTC)回复
有條件支持,但同时也希望技术问题早日得到解决,避免站务巡察工作积压。——南屿小十233对话 | 贡献 | 签名2025年6月2日 (一) 05:01 (UTC)回复
抱歉,但我看不出這樣分離的意義在哪裡,只能(-)反对--SunAfterRain 2025年6月4日 (三) 12:11 (UTC)回复
Python6345提案之二
[编辑]
  • 技术上禁止巡查员创建操作自动标记为已巡查。
  • 出于尊重,为现有巡查员授巡查豁免权。

本人希望之方案。Python6345(2025年5月28日 (三) 07:09 (UTC)回复

这是不可能的,目前自动巡查不区分这个。如果要在技术上支持这个功能,一个方法是Xiplus的一个分割创建/修改巡查的patch,但是code review方面已经很久没动静了;另一方面是引入PageTriage这个扩展,但是这个目前进度非常缓慢。另外“出于尊重,为现有巡查员授巡查豁免权”的意义何在,如果都授予了还分割什么权限啊。 Stang1333 2025年5月28日 (三) 07:41 (UTC)回复
参阅本人附加提案,可能有部分巡查员曾有巡免或条目已符合巡免标准。Python6345(2025年5月28日 (三) 09:42 (UTC)回复
不是「可能」,是活生生在你面前。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️2025年5月28日 (三) 09:51 (UTC)回复
如果要在技术上支持这个功能,一个方法是Xiplus的一个分割创建/修改巡查的patch,但是code review方面已经很久没动静了;另一方面是引入PageTriage这个扩展,但是这个目前进度非常缓慢本提案为理想提案,如技术上无法实现本人无能为力,请参阅替代提案。Python6345(2025年5月28日 (三) 09:49 (UTC)回复
顯然,原本已持有豁免權限(然後因併入而取消)的巡查員,在權限分割當下仍持有巡查權者,均應返還巡查豁免權。因為權限分割純粹是技術問題,與往後是否彈劾無涉。—— Eric Liu 創造は生命(留言留名學生會 2025年6月5日 (四) 13:11 (UTC)回复
註:此處原有文字,因為本人眼瞎,已由Ohtashinichiro留言)於2025年6月5日 (四) 13:33 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。回复
你確定嗎?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️2025年6月5日 (四) 13:26 (UTC)回复
(!)抗议「不存在返还一说。」我都講三次了,你們是故意當耳邊風的嗎?,如果是故意的,ANM見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️2025年6月5日 (四) 13:29 (UTC)回复
是我眼瞎,我收回言论,诚恳致歉。->>Vocal&Guitar->>留言 2025年6月5日 (四) 13:33 (UTC)回复
上方讨论已指出多名巡查员之条目不符合巡免质量,且涉有曾持巡免权者。故本人认为应集中讨论重审所有曾有巡免权之巡查员是否能于拆权后重获巡免权。Python6345(2025年6月5日 (四) 13:29 (UTC)回复
註:此處原有文字,因為誤會,已由宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️)於2025年6月5日 (四) 14:02 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。回复
誤看成同一人留言。且我已經重新申請權限,「理論上」應該可能大概也許不會影響。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️2025年6月5日 (四) 14:02 (UTC)回复
若有人不合格,請屆時個別提出。請注意,原本拿過巡查豁免者,都是經過社群審核通過。我們這裡應當專注處理技術問題,若認為達不到標準要除權,就應該重走程序,不是藉此機會「一刀切」。除非預設爛人過半,否則此事免談。—— Eric Liu 創造は生命(留言留名學生會 2025年6月6日 (五) 03:49 (UTC)回复
请@Sanmosa前来说明。Python6345(2025年6月6日 (五) 04:00 (UTC)回复
問題在於巡查員就從來沒被特地檢驗過寫條目的能力,Ericliu1912的言論基本上就是在令整件事情變得完全無法檢驗,他的reluctance沒有把授權應有的謹慎當一回事。「巡查員從來沒被特地檢驗過寫條目的能力」是社羣的共業,因此其成本必定要由社羣整體負擔,但看起來Ericliu1912似乎非常不願意這樣做。個人較傾向於下方的Python6345提案二之附加。Sanmosa 新朝雅政 2025年6月6日 (五) 07:24 (UTC)回复
現在的問題是,你所假定「曾持有巡查豁免權而後升格之巡查員一般沒有寫好條目的能力」一事,並沒有確鑿根據,而且不合常理。你上方的說法,更是混淆普通巡查員及合併巡查豁免權的巡查員;後者申請巡查豁免權限之際,本來就已經過「特地檢驗」,不存在你所謂「社群共業」問題。請注意,我從來不支持「为现有(全部)巡查员授巡查豁免权」,而僅是希望把原本誰有的權限還回去。隨意基於假設剝奪他人權限,纔真正缺乏「應有的謹慎」。如果你所說要處理的特別情況,例子舉不出來,就不要訴諸情緒勒索;若例子真能舉出來了,就去辦那些例子。不清楚這有什麼好討論的。甚至我不清楚你我立足點是否相同,搞不好其中誤會可大了,根本不是在談一件事。—— Eric Liu 創造は生命(留言留名學生會 2025年6月10日 (二) 09:58 (UTC)回复
我们这里探讨的不是“自动恢复曾持有巡查豁免权的巡查员相关权限”吗?请问这有任何问题么? Stang1320 2025年6月10日 (二) 11:26 (UTC)回复
我看混了,上面的留言讓我以為你們在說的是所有巡查員在權限分拆後自動授予巡查豁免權。Sanmosa 新朝雅政 2025年6月10日 (二) 15:12 (UTC)回复
上方长期讨论可判断“批量恢复曾持有巡查豁免权的巡查员相关权限”已达成共识, 公示7日,2025年6月27日 (五) 09:54 (UTC)結束。具体名单会在统计之后生成。 Stang1310 2025年6月20日 (五) 09:54 (UTC)回复
Python6345提案二之附加
[编辑]

由于确有多名巡查员所创建条目不合格,或可在授巡查豁免权之前全部公示,如公示期有其他巡查员反对则需讨论。Python6345(2025年5月28日 (三) 07:09 (UTC)于2025年6月10日 (二) 10:30 (UTC)撤回,无人可证大量曾有巡免之巡查员滥用巡免权以至于需集中重审,故支持授予所有曾有巡免权之巡查员巡免权。回复

RainSun8942提案
[编辑]
  • 取消自己的編輯自動標示為已巡查,但仍可以巡查不具備巡查豁免權限之編輯,僅具備巡查豁免權限方可自動標示為已巡查。
  • 由於巡查豁免門檻較高,巡查門檻較低。除可以申請巡查權外,符合巡查豁免申請資格也可申請巡查豁免權限。
以上不知第一項技術上是否可行,另外管理員是否也需要比照辦理。--雨朝Talk#SamekoSaba🐟 2025年6月5日 (四) 05:09 (UTC)回复
1不可行,标记为已巡查是不可逆的操作。2完全可以。管理员是否比照我觉得一步步来比较好,先把巡查员的情况处理好。 Stang1325 2025年6月5日 (四) 08:27 (UTC)回复
您看起來好像搞錯了,我是指將自己的編輯取消自動標記為已巡查,而不是將已巡查逆轉為未巡查的狀態。--雨朝Talk#SamekoSaba🐟 2025年6月5日 (四) 09:22 (UTC)回复
原来如此,我理解错了。你的1所表述的就是上方共识事实上的效果:巡查员自己的编辑不再被自动标记为已巡查,他们仍然可以巡查其他无巡查豁免权的用户的编辑。 Stang1325 2025年6月5日 (四) 09:32 (UTC)回复
是的,僅取消巡查員自己的編輯自動標記為已巡查,此外1有提到自我巡查的部分,是否可以將等候巡查的按鈕隱藏?--雨朝Talk#SamekoSaba🐟 2025年6月5日 (四) 10:21 (UTC)回复
@RainSun8942“等候巡查”的按钮是在哪里的,可以描述一下吗?咱因为不是巡查员看不到。猜测隐藏起来不难,来点css魔法就行了。 Stang1322 2025年6月9日 (一) 01:04 (UTC)回复
降低巡查豁免申请要求
[编辑]

建立75个条目的要求没查到当年相关讨论记录,大概是借用enwiki的标准。而enwiki早已将此标准降为25个条目。个人认为至少要将标准降低到50以下,最好是25-35之间。--Steven Sun留言2025年6月6日 (五) 03:23 (UTC)回复

(!)意見:本人认为硬标准可降至创建10个条目,但需要他人提名或最少一名延确支持后管理员可赋权。Python6345(2025年6月6日 (五) 03:52 (UTC)回复
不确定延确水平。前提定在两名有巡查权限者(净)支持如何?毕竟巡查豁免主要影响巡查员的工作。--YFdyh000留言2025年6月6日 (五) 05:19 (UTC)回复
(+)支持将前提定为需巡查员同意,但(-)反对投票。Python6345(2025年6月6日 (五) 06:04 (UTC)回复
考虑到特定申请可能有人反对,而明确的授权与反对标准较容易审视,即通过反对票来延缓授权进程。我也赞成可以宽松裁量是否授权,暂未考虑投票期限等约束。--YFdyh000留言2025年6月6日 (五) 06:42 (UTC)回复
反对者阐明理由,支持者反驳,如遇长期讨论而管理员无法判断共识之情况可考虑由行政员集体决定。本人不希望RFR和RFA一样成为选举。Python6345(2025年6月6日 (五) 06:51 (UTC)回复
引入DYK/GA/FA的写作数量作为可选条件也可以。比如可将10篇DYK或2篇GA/FA作为参考条件。--Steven Sun留言2025年6月6日 (五) 04:24 (UTC)回复
(+)支持引入,但(-)傾向反對上述写作数量,个人认为10篇DYK过少。--__Don't bite! 2025年6月14日 (六) 11:55 (UTC)回复
条目质量须被巡查员认可提案
[编辑]
現行條文

任何管理員均可將此權限授予熟知維基方針及指引(特別是生者傳記收录标准)的可信賴用戶。建議門檻为创建75個有效條目如您打算為您自己或其他用戶申請此權,請移步至維基百科:權限申請/申請巡查豁免權

提議條文

任何管理員均可將此權限授予熟知維基方針及指引(特別是生者傳記收录标准)的可信賴用戶。建議門檻为创建10個有效條目,且条目质量被巡查员认可。如您打算為您自己或其他用戶申請此權,請移步至維基百科:權限申請/申請巡查豁免權

本人认为巡免权主要需条目平均质量可通过巡查,且10个条目之建议已足够低,故提案未包含DYK/GA/FA之建议标准,如有例外请IAR处理。多日无人留言,如7日内无异议将公示。Python6345(2025年6月10日 (二) 10:47 (UTC)回复

10個條目未免真的太低,但我認同現有門檻確實過高,因此我較為傾向於enwiki的門檻(25個條目),這樣可以確保巡免寫的條目足夠多,又避免為有意申請巡免者造成不必要的負擔。Sanmosa 新朝雅政 2025年6月10日 (二) 15:16 (UTC)回复
保留DYK,又或者做7篇GA如何?--Mykola留言2025年6月14日 (六) 17:49 (UTC)回复
不认可将DYK/GA/FA纳入巡免申请要求,现时条目经少量改善并挂模板后即可通过巡查,无理由要求巡免之条目质量高于可通过巡查之基本标准。Python6345(2025年6月15日 (日) 09:26 (UTC)回复
不需要「經過巡查員認可」,重點是條目品質足夠,這也就是「有效條目」的含義。—— Eric Liu 創造は生命(留言留名學生會 2025年6月10日 (二) 15:34 (UTC)回复
(:)回應:是否條目品質足夠需用户判断,本人倾向由延确判断,但有人质疑延确判断能力且巡免确主要影响巡查员之工作。故在此拟议巡查员判断,阁下如有更好方案还请提出。Python6345(2025年6月14日 (六) 13:41 (UTC)回复
不必更改現況,由社群判斷即可。說實話有什麼權限也不影響能不能讀條目吧?—— Eric Liu 創造は生命(留言留名學生會 2025年6月14日 (六) 17:46 (UTC)回复
理论上不影响,但连DYK都时常可见水票,且阅读一名用户所创之条目判断是否可获巡免耗费精力显高于阅读一篇条目,本人合理担忧出现更多不读条目就(+)支持而多日无人认真读条目提出合理反对意见,导致管理员误授权给质量过差之用户巡免权。本人认为此方案如通过而巡查员不读条目而支持,可以WP:CIR除权;普通用户如可给出合理解释表明认真阅读过条目亦可采纳。Python6345(2025年6月15日 (日) 09:24 (UTC)回复
照理說大部分申請應該會是「提出申請」、「符合基礎門檻」、「無人反對」(有人支持的話會更快)、「管理員授權」;我們應該是鼓勵社群(無論持有權限)參與第二部分過程,因為管理員也非全能。—— Eric Liu 創造は生命(留言留名學生會 2025年6月15日 (日) 12:14 (UTC)回复
让管理员判定即可,目前也不是由管理员判定并授权吗?--Steven Sun留言2025年6月16日 (一) 03:21 (UTC)回复
(-)強烈反对,10个也太少了吧。像LTA:Kurgenera这样的人申请巡免只会让你维更糟糕,个人认为50个适宜。(折中enwiki和中维)--__Don't bite! 2025年6月14日 (六) 11:49 (UTC)回复
(:)回應:此仅为建议标准,而非到达资格后必须授权。Python6345(2025年6月14日 (六) 13:43 (UTC)回复
认真写的条目,10-25个足以判断用户的写作水平。无需50个。况且这只是建议标准,是否授权仍需要管理员及其他用户综合判定写作水平。--Steven Sun留言2025年6月16日 (一) 03:12 (UTC)回复
简单降低标准提案
[编辑]
現行條文

任何管理員均可將此權限授予熟知維基方針及指引(特別是生者傳記收录标准)的可信賴用戶。建議門檻为创建75個有效條目。如您打算為您自己或其他用戶申請此權,請移步至維基百科:權限申請/申請巡查豁免權

提議條文

任何管理員均可將此權限授予熟知維基方針及指引(特別是可供查證生者傳記收录标准)的可信賴用戶。建議門檻为创建25個有效條目。如您打算為您自己或其他用戶申請此權,請移步至維基百科:權限申請/申請巡查豁免權

-- Steven Sun留言2025年6月16日 (一) 03:43 (UTC)回复

考虑到上方多个提案已经详细的讨论过具体降低到什么样的门槛,可以视为讨论已经很充分,因此 公示7日,2025年6月27日 (五) 09:47 (UTC)結束 Stang1310 2025年6月20日 (五) 09:47 (UTC)回复
巡查豁免活跃度要求提案
[编辑]
現行條文
提議條文

此外,当超过3年没有任何编辑活动,报告后如查明属实时,则立即除权。

注意到巡查豁免权没有活跃度要求,并考虑到无编辑用户可能会不了解编辑方针与指引的变动,因此提出活跃度要求。--Steven Sun留言2025年6月16日 (一) 03:43 (UTC)回复

多此一举,已经有六个月未有编辑活动的规定。--雨朝Talk#SamekoSaba🐟 2025年6月16日 (一) 12:23 (UTC)回复
了解,那我 撤回请求。--Steven Sun留言2025年6月16日 (一) 12:51 (UTC)回复

建議增加「姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代」去掉「姓、部、卦、母、國、朝」字之後剩下的東西的「重定向/消歧義」的方針

[编辑]

Wikipedia:頁面存廢討論/記錄/2025/06/12#批量提刪,許多單一字的條目被提刪了,當中很多都是「姓氏部首六十四卦三十六字母/早期中古漢語(切韻音)聲母、國家中國朝代」去掉「姓、部、卦、母、國、朝」字之後剩下的東西,但是,如果有些「姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代」去掉「姓、部、卦、母、國、朝」字之後剩下的東西有重定向或消歧義,有些沒有,這樣顯然不行,所以在此提議增加方針:

任何「姓氏」(劉姓)、「部首」(羽部)、「六十四卦」(節卦)、「三十六字母/早期中古漢語(切韻音)聲母」(透母)、「國家」(德國)、「中國朝代」(隋朝)去掉「姓、部、卦、母、國、朝」字之後剩下的東西(劉、羽、節、透、德、隋)必須有頁面,且該頁面必須符合以下四個條件之一:

  1. 重定向到該(姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代)的條目
  2. 為消歧義頁面,且該消歧義頁面中包含該(姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代)的條目
  3. 為其他條目,且條目頭部有「關於(姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代),請見X(姓、部、卦、母、國、朝)」
  4. 為其他條目,且條目頭部有連到對應的「X(消歧義)」的消歧義頁面,且該消歧義頁面中包含該(姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代)的條目

例如:(以「姓氏、部首、六十四卦、三十六字母」的前16個來舉例,但三十六字母的第5、6、7個(非母、敷母、奉母)目前仍然沒有條目,故只以另外13個來舉例)

類型 符合條件1 符合條件2 符合條件3 符合條件4
姓氏
部首 丿
六十四卦 小畜 同人大有
三十六字母 (提刪中)、

---59.126.168.120留言2025年6月13日 (五) 06:25 (UTC)回复

(=)中立:我認為多數詞語應該可以從消歧义重定向、甚至收錄標準找出理據,不應刪除;不過同意AINH的說法:很多詞語頗有歧義,需要釐清。我在檢查「」的時候,就有類似疑問。--Saimmx留言2025年6月13日 (五) 09:14 (UTC)回复
单字,请去维基词典。--Kethyga留言2025年6月13日 (五) 09:35 (UTC)回复
单字并不能当做提删的理由。——杰里毛斯留言2025年6月13日 (五) 11:01 (UTC)回复
Kethyga的單字提刪理據大概是「不是辭典」方針:在這個方針下,條目只有釋義本身,可能無法成為條目。要反駁的話,可能要進一步闡述為什麼單字不是刪除理由、並以「不是辭典」方針為基礎反駁。--Saimmx留言2025年6月13日 (五) 15:54 (UTC)回复
@Saimmx:我觉得假定他人的观点不是个好习惯。这裏我不将其作为Kethyga的观点而是作为你的观点来来回复。我觉得反而是你需要论述为什么单字就违反了这一方针。是不是词典内容要看这一词指称的含义是词典含义还是百科含义而不是看这一词的字数(尽管客观上有相关性)。“”是词典内容?“沪”是上海的简称是词典内容? ——自由雨日🌧️❄️ 2025年6月13日 (五) 16:17 (UTC)回复
抱歉,亂假定觀點是我的錯。我撤回。--Saimmx留言2025年6月13日 (五) 16:26 (UTC)回复
同上。不成词的语素(通常是一个字)我反对作条目标题,也不赞成建重定向/消歧义,确实是词典内容;但成词且可指称百科含义的语素和单字专名语素完全可以是百科内容。现代汉语只是以双音节词为主而非没有单音节词。 ——自由雨日🌧️❄️ 2025年6月13日 (五) 12:04 (UTC)回复
不知道您說的是(又稱單字)還是單個漢字。無論是哪個,都不是提刪理由。有百科全書性質的內容就應該留下來。譬如我們有維基導遊,但是不能說景點的條目就要全部搬過去。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年6月13日 (五) 17:04 (UTC)回复
注意:這裡的「X國」包括任何國家(包括193個聯合國會員國、2個聯合國觀察員國、10個有爭議的政治實體),而「X」為該國中文國名(包括:台灣、中國大陸、香港、澳門、新加坡、馬來西亞,當中的任何一個地方使用的中文)的第一個漢字,即使中文很少對這個國家這樣用都一樣,例如對於「巴西、巴林、巴拿馬、巴哈馬、巴拉圭、巴貝多、巴基斯坦、巴勒斯坦國、巴布亞紐幾內亞」這些國家,X=巴,而對於「密克羅尼西亞聯邦」這個國家,X=密,對於「斯里蘭卡、斯洛伐克、斯洛維尼亞」這些國家,X=斯,對於「賽普勒斯」這個國家,X=賽,對於「阿爾巴尼亞、阿爾及利亞、阿富汗、阿根廷、阿拉伯聯合大公國、阿曼、阿拉伯葉門共和國」這些國家,X=阿,依此類推。--59.126.168.120留言2025年6月13日 (五) 11:03 (UTC)回复
另外我漏掉了,包括中國的省份(包括:省、自治區、直轄市、特別行政區)的單字簡稱(例如「冀」為河北省、「滬」為上海市)也一樣,雖然對於這些單字簡稱都很早就有重定向或消歧義了。--59.126.168.120留言2025年6月13日 (五) 11:06 (UTC)回复
另請@59.126.168.120針對「不是辭典」方針闡述:請問這個改動,是否與「不是辭典」方針衝突?是的話,是否有其他方針支持改動?--Saimmx留言2025年6月13日 (五) 15:59 (UTC)回复
重點是,總不能有些(姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代)的去掉「姓、部、卦、母、國、朝」字之後剩下的東西可以重定向/消歧義,有些不行吧?這樣是雙標。--59.126.168.120留言2025年6月14日 (六) 01:29 (UTC)回复
我認爲這符合「標題所代表的個人、群體、概念、地方、事件、物體等。」只有針對字本身的說明才符合WP:NOTDICT,對字所常代表事物進行重定嚮不宜以「不是辭典」爲由拒絕。——𠭞留言2025年6月18日 (三) 08:37 (UTC)回复
我的目的是要讓人們搜尋「姓氏、部首、六十四卦、三十六字母/早期中古漢語(切韻音)聲母、國家、中國朝代」去掉「姓、部、卦、母、國、朝」字之後剩下的東西(例如「」時)的時候都可以快速找到對應的頁面(劉姓羽部節卦透母德國隋朝),所以這些東西都必須要有重定向或者消歧義。--59.126.168.120留言2025年6月18日 (三) 05:24 (UTC)回复
已在WT:重定向WT:消歧义发送讨论通告,另请Ericliu1912注意方针(WP:讨论发起位置),勿再违规添加存档。 ——自由雨日🌧️❄️ 2025年6月18日 (三) 05:39 (UTC)回复
(=)中立。我認同這一呼籲,但覺得不值得爲此設立方針。我認爲大部分有必要重定/消歧的頁面適用於「別名重新導向至更符合維基百科方針的正式名稱」。——𠭞留言2025年6月18日 (三) 08:37 (UTC)回复

為修訂存廢覆核方針放寬臨時恢復制度事

[编辑]

提議修訂天體收錄標準

[编辑]