跳转到内容

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

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

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


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


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 有關申請權限與申請解除權限的方針條文與申請區的放置問題 78 7 Sanmosa 2025-07-14 20:52
2 重提允許巡查員自我增加與移除自動巡查權/將自動巡查與巡查員權限組分離 148 22 Mirfaek 2025-07-13 11:04
3 讨论页行为的边界:是善意提醒还是骚扰攻击性的贴标签行为? 1 1 1F616EMO 2025-07-11 13:47
4 提議於優良條目、典範條目、特色列表以及特色圖片等典優評選的「投票程序」增加一條文 1 1 自由雨日 2025-07-12 16:50
5 提議允許用戶可按頁面大小存檔其他用戶的討論頁 33 12 Steven Sun 2025-07-15 21:16
6 提议明确页面存废讨论批量提删的执行细节 1 1 Hamish 2025-07-14 21:29
7 中国大陆简体问题 1 1 Linxingjun 2025-07-16 10:20
8 有關《林夕》條目中的目錄顯示異常情況 1 1 1F616EMO 2025-07-16 14:04
9 仲裁委員會的捷徑(快捷方式)問題 9 5 Ericliu1912 2025-07-19 15:46
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

正在廣泛徵求意見的議題

議題清單

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

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:繁简处理 § 繁體模式以「臺灣台語」爲正,不受WP:臺台限制

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

Talk:GB 13000 § 建議更名:“GB 13000”→“GB/T 13000”
GB 13000” → “GB/T 13000”:该标准已自强制性标准更改为推荐性标准。Nebulas-Star留言) 2025年6月24日 (二) 08:42 (UTC)
Talk:塔納通·宗龍倫吉 § Chuengrungrueangkit的翻譯

現有素里亚·庄龙伦吉塔納通·宗龍倫吉兩叔侄的條目,兩個條目中對Chuengrungrueangkit此一姓氏的翻譯有所不同,因此我希望在此處尋求一個統一翻譯的方式。Sanmosa DC23 2025年7月6日 (日) 01:37 (UTC)

Wikipedia talk:命名常规/音乐 § 提議取消對消歧義後綴「(EP)」的禁用

本命名常規在建立之初,就引入了「(迷你專輯)」為規範消歧義後綴。在2021年9月對「MediaWiki:Titleblacklist」的編輯請求中,為配合命名常規的需要,「(EP)」被禁止作為消歧義後綴。

2024年1月在互助客棧的討論得出將「迷你專輯」改為消歧義、內容分拆為「EP」與「迷你密紋唱片」的結論後,中文維基百科內各處就停止了將「EP」翻譯為「迷你專輯」,以與「mini album」(迷你密紋唱片)做區別。根據當前的共識,是否應該修訂本命名常規?此處拋磚引玉提出2個方案:

方案一,考慮取消對「(EP)」的禁用,可以根據實際需要選用「(EP)」或「(迷你專輯)」。

方案二,考慮將當前非韓語、華語的EP由「(迷你專輯)」統一修改為「(EP)」;未來仍允許編者自主選用「(迷你專輯)」表示迷你密紋唱片。通過機器人可以實現。

副知命名常規的主要編寫者與所有相關討論的參與者@MilkypineSanmosaSoftyuPseudo Classes魔琴FactrecordorDavid XuangAbcet10Dabao qian。--SuperGrey (留言) 2025年7月10日 (四) 18:15 (UTC)

Wikipedia talk:格式手册/标点符号 § 提案:修訂「書1」對於软件名的规定
此討論正在公示7天,直至2025年7月23日 (三) 15:38 (UTC)結束;如有意見請儘快提出。
現行條文
  • 书1:可标示书名、书名篇名并举、报纸名、杂志名、图表名、文件名、全中文或中文在名称中占主导地位的软件名,电影、电视、诗歌、音乐、雕塑等各类用文字、声音、图像等表现的作品名用双书名号
提議條文
  • 书1:可标示书名、书名篇名并举、报纸名、杂志名、图表名、文件名,以及电影、电视、诗歌、音乐、雕塑、电子遊戏等各类用文字、声音、图像等表现的作品
    GB/T 15834—2011规定「全中文或中文在名称中占主导地位的软件名」使用书名号标示,但实际罕见。

 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月16日 (三) 15:35 (UTC)

Wikipedia talk:格式手册/日期和数字 § 〈概數的兩個鄰數之間的書寫〉跟进《格式手册·标点符号》修订

《格式手册/标点符号》§顿号修订,此处应该跟进,变动如左:

現行條文

相鄰的兩個數字並列連用表示概數時,必須使用漢字,連用的兩個數字之間不得用頓號“、”隔開:

  • 正确:三五天、一千七八百元、一二十個
  • 错误:3、5天、 一千七、八百元、 1、20個
提議條文

相邻或相近的两中文数字连用表示概数时,必須使用漢字,其间一般無須用顿号隔開。唯會產生歧義时,可加上頓號以清楚說明意思。

  • 正确:三五天。一千七八百元。一二十個。九、十人。
  • 错误:3、5天。一千七、八百元。1、20個。九十人。

 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月17日 (四) 06:19 (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:中立的观点 § 对“Wikipedia:中立的观点”最近修改的异议

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

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

--Ma3r铁塔) 2025年6月8日 (日) 01:26 (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:删除 § 在存廢討論中禁止/建議避免使用圖示標記立場

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

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

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

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

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

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

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

Wikipedia talk:討論頁指引 § 建議統一討論頁及布告板的主題標題層級爲二級標題

既然先前討論串已有明確的修改共識,以下討論該如何修改。除了下面提到的改動以外,還需對外觀進行略微改動(如,去掉「提名區」2級標題),以及存檔bot需要修改配置,這個因為很簡單故不贅述。--SuperGrey (留言) 2025年6月24日 (二) 03:40 (UTC)

Wikipedia talk:傀儡 § 就臨時賬戶修改登出編輯的相關條文


由於本站已經部署臨時賬戶,但「在登出狀態下編輯」一節尚未更新,現提議修訂如下:

現行條文
在退出状态下编辑

在某些情况下,拥有账号的编辑者有可能会以未登录状态编辑维基百科,原因例如登录状态意外过期,以新设备访问维基百科,经其他网站编辑维基百科,遗忘账号密码等。未登录的编辑者不得主动欺骗其他编辑者,例如直接声明没有帳號或将会话用于本方针前述列出的濫用多重帳號的行為。为了保护隐私,在退出状态下编辑的编辑者永远不需要将其用户名与编辑时的IP地址相关联。

如使用多重IP地址进行编辑,以迷惑他人或违反上述原则,亦可视作是使用多重帐号的行为。注册用户在未登录情况下進行編輯,其IP地址亦會被視為另一个账户。故如果您因无心之失登出並作出編輯,您可联系管理员或拥有监督权限的用户以避免被誤會。

如果您担心IP编辑者实际上是一个拥有账户的用户,并且在退出时以不适当的方式进行编辑,您可以将此方针通知IP编辑者({{subst:uw-login}}可用于此目的)。如果继续发生这种行为,您可通过傀儡調查页面发起调查。
提議條文
在退出状态下编辑

在某些情况下,拥有账号的编辑者有可能会以未登录状态编辑维基百科,原因例如登录状态意外过期,以新设备访问维基百科,经其他网站编辑维基百科,遗忘账号密码等。未登录的编辑者不得主动欺骗其他编辑者,例如直接声明没有帳號或将会话用于本方针前述列出的濫用多重帳號的行為由於臨時賬戶的IP地址可被臨時賬戶IP查看者存取,为了保护隐私,在退出状态下编辑的编辑者永远不需要将其用户名与其臨時賬戶相关联。

如使用多個臨時賬戶进行编辑,以迷惑他人或违反上述原则,亦可视作是使用多重帐号的行为。注册用户在未登录情况下進行編輯,其臨時賬戶亦會被視為另一个账户;若用戶清除了瀏覽器Cookie、手動登出了臨時賬戶或切換了裝置,在再次進行編輯時,亦會建立另一個臨時賬戶。故如果您因无心之失登出並作出編輯,您可联系管理员或拥有监督权限的用户以避免被誤會。

如果您担心使用臨時賬戶的編者实际上是一个拥有註冊账户的用户,并且在退出时以不适当的方式进行编辑,您可以将此方针通知該臨時賬戶編者({{subst:uw-login}}可用于此目的)。如果继续发生这种行为,您可通过傀儡調查页面发起调查。

邀請@TigerzengStangA2569875。--1F616EMO喵留言回覆請ping) 2025年7月1日 (二) 03:53 (UTC)

Wikipedia talk:介面管理員 § 修订界面管理员有关2FA的内容
此討論正在公示7天,直至2025年7月24日 (四) 00:26 (UTC)結束;如有意見請儘快提出。

众所周知,界面管理员用户组的创建就是降低安全风险,而双因素认证就是一个可以有效提高账号安全,从而避免账号被破解导致出现事故的工具。元维基已明确对当地的界面管理员用户组强制开启双因素认证,英文维基百科也参考了元维基的这一要求。本站长期缺乏这方面的要求,是时候在方针中明确强调这一点了。

同时,近日行政员拥有了查看一名用户是否启用了双因素认证的功能,因此合理提议,行政员在授予用户界面管理员权限时,应使用Special:VerifyOATHForUser确认对方已经启用了这一功能,否则不予授权。

提议修订如下:

現行條文

用戶可經申請成為介面管理員,並長期持有權限。界面管理员须经票选产生,票选为期十四日,得至少25票支持为之有效,而支持者占其中总得票数至少75%才可通过。投票通過後,則由行政員授權。管理員如為2018年7月5日前上任,經三日投票,簡單多數支持,則可以取得介面管理員權限。如果三日內未有任何用戶投票,則應延長至七日。期後如仍無用戶投票,則由行政員決定是否任命。用戶如需申請短期權限,則可至行政員布告板申請。用戶可參與討論及表態是否贊同申請,並附以理據支持。最終由行政員按討論內容決定是否批准申請。

提議條文

用戶可經申請成為介面管理員,並長期持有權限。界面管理员须经票选产生,票选为期十四日,得至少25票支持为之有效,而支持者占其中总得票数至少75%才可通过。投票通過後,則由行政員授權。行政员在授权前,应使用Special:VerifyOATHForUser检查用户是否启用了双因素认证。如果用户无法启用这一功能,行政员应告知用户前往元维基申请启用双因素认证。在未启用双因素认证时,行政员不得授权。管理員如為2018年7月5日前上任,經三日投票,簡單多數支持,則可以取得介面管理員權限。如果三日內未有任何用戶投票,則應延長至七日。期後如仍無用戶投票,則由行政員決定是否任命。用戶如需申請短期權限,則可至行政員布告板申請。用戶可參與討論及表態是否贊同申請,並附以理據支持。最終由行政員按討論內容決定是否批准申請。

希望可以参与讨论,谢谢。 Stang1298 2025年7月2日 (三) 15:10 (UTC)

Wikipedia talk:禁制 § 被禁止編輯計劃命名空間的編者可否回應佈告版上的指控

如果被禁制(禁止WP頁面),然後被提報至 維基百科:管理員佈告板/其他不當行為維基百科:當前的破壞 等頁面,他回應的話 是否構成違反編輯禁制。
最近的例子 Wikipedia:管理员布告板/其他不当行为#HMOXDSS1_2。--—Jackyming留言貢獻・這位編輯者是一位奶味藍🤩) 2025年7月4日 (五) 16:52 (UTC)

Wikipedia talk:保護 § 事實修訂用戶頁的預見性半保護

當前的半保護方針規定了允许用户出于预见性原因要求半保护自己的用户页面,然此寫法顯然會讓人誤會為只要申請基本上就可以通過。查@Bluedeck(這裡是故意ping的)原始加入條文的澄清聲明指出:

故我認為應該將這句寫清楚。

現行條文
半保護政策用于保護受到嚴重破壞的頁面和讨论页面的存档,例如编辑戰等會對頁面構成嚴重影響,這個政策不是用來保護具有爭議的頁面的,因為這會限制了部份使用者編輯頁面的自由。但是,允许用户出于预见性原因要求半保护自己的用户页面。管理員在執行這政策時應持與執行全保護政策時同一樣的要求,不論是由他們自行決定還是由其他頁面要求的,如请求管理员帮助、请求保护页面或其他相類的頁面。
提議條文
半保護用於防止非自動確認用戶對頁面造成嚴重破壞,如编辑戰等可能嚴重影響頁面內容的行為,適用對象包括一般內容頁面與討論頁面的存檔。

半保護不應用於保護具有爭議的頁面,惟用戶頁若用戶有合理的理由提出請求則不在此限。

管理員處理半保護請求時應與全保護的處理要求相同。

(我重寫了整句話,因為不重寫整句話要改實在很怪 囧rz……)--SunAfterRain 2025年7月5日 (六) 16:44 (UTC) 👍1

左右两边没有实际差别,并且右边更清晰,我觉得很好。不过题外话:现在我觉得如果用户想要半保护某个用户子页其实没什么不可以,而且我觉得半保护和全保护的标准要相同这一点我也不太同意。。。。Bluedeck 2025年7月5日 (六) 22:19 (UTC)
@Bluedeck我猜原本的意思是要同樣的處理態度(例如不能說全保護要刪五個字才叫破壞,但半保護只要刪三個字就可以當成破壞)看待?問問原始加入者@Shizhao。--SunAfterRain 2025年7月6日 (日) 04:09 (UTC)
Wikipedia talk:收錄標準/交通 § 建議巴士總站的收錄標準

目前香港有大量巴士總站獲得收錄,但我檢查後發現不少巴士總站只是單純的路邊巴士總站,實際上與普通路邊巴士站無分別,收錄價值甚低。建議更新收錄標準指引,除非有大量傳媒報導的路邊巴士站(這樣會直接符合GNG),否則應拒絕收錄路邊巴士總站。設有車坑的,則可被視為相對重要,值得收錄,而巴士轉車站可被視為設有1條車坑的巴士總站(而且設立時通常會有大量傳媒報導)。這樣,坑狀巴士總站、鋸齒型巴士總站、分層式巴士總站以及巴士轉車站都符合標準,避免了大量刪除巴士總站的可能性。另外,對於香港以外的巴士總站,亦可考慮採用類似方式處理,比如澳門的巴士總站、台灣的公路轉運站、中國大陸的公路汽車站和長途客運站,乃至其他國家的類似巴士總站等等也大差不差。User:SanmosaUser:Foamposite,你們說呢?--owennson聊天室獎座櫃) 2025年7月8日 (二) 19:14 (UTC)

Wikipedia talk:命名常规/音乐 § 提議取消對消歧義後綴「(EP)」的禁用

本命名常規在建立之初,就引入了「(迷你專輯)」為規範消歧義後綴。在2021年9月對「MediaWiki:Titleblacklist」的編輯請求中,為配合命名常規的需要,「(EP)」被禁止作為消歧義後綴。

2024年1月在互助客棧的討論得出將「迷你專輯」改為消歧義、內容分拆為「EP」與「迷你密紋唱片」的結論後,中文維基百科內各處就停止了將「EP」翻譯為「迷你專輯」,以與「mini album」(迷你密紋唱片)做區別。根據當前的共識,是否應該修訂本命名常規?此處拋磚引玉提出2個方案:

方案一,考慮取消對「(EP)」的禁用,可以根據實際需要選用「(EP)」或「(迷你專輯)」。

方案二,考慮將當前非韓語、華語的EP由「(迷你專輯)」統一修改為「(EP)」;未來仍允許編者自主選用「(迷你專輯)」表示迷你密紋唱片。通過機器人可以實現。

副知命名常規的主要編寫者與所有相關討論的參與者@MilkypineSanmosaSoftyuPseudo Classes魔琴FactrecordorDavid XuangAbcet10Dabao qian。--SuperGrey (留言) 2025年7月10日 (四) 18:15 (UTC)

Wikipedia talk:討論頁指引 § 讨论页行为的边界:是善意提醒还是骚扰攻击性的贴标签行为?

核心问题:维基百科是否允许用户以“澄清误导”或“陈述事实”为由,在讨论页上对其他用户的发言逐条张贴其过往的、与发言内容本身无关的负面信息(如称“该用户曾被封禁“、“使用傀儡”等等)?

本次讨论的具体背景案例

我的子账户因使用程序不当而受到管理员Tigerzeng封禁6个月的处罚。随后之前与我就具体条目内容存在异议的用户Lvhis便以“傀儡发言”为由删除了本人(子账户)的讨论页发言,又以“偏离主题”为由删除了另一用户要求其留意他人意见、不要擅动条目的留言(special:diff/87892033)。后由其他用户根据管理员意见帮忙恢复。

但在管理员Tigerzeng多次告知Lvhis “已经不足以造成误导”、“已经没有理由去做更多的行动”,并明确建议若仍有分歧“应将问题暴露给更大范围的社群讨论”,以及有第三方用户明确反对Lvhis擅自去添加标注的情况下,用户Lvhis仍坚称“当时造成的误导还没消失”,并据此擅自采取行动,继续反复在本人的逐条留言上方添加其自定义的大字报式标签(“xxx系xxx违规建立的傀儡账号...已被封禁6个月”),又再次以Liu116提及本人两账号同属一人的发言属于“偏离条目主题”为由,删除了对其讨论页行为的批评意见。本人后续再次将该行为提报至ANM,但管理员仍未对其所有行为作出明确的裁定和判罚,导致争议僵持至今。

补充说明: 为帮助社群更全面了解情况,有必要指出,即便在遭到二位管理员的委婉反对后,用户Lvhis的行为模式仍在持续,坚持发表歪曲事实的言论

1.曲解管理员操作:声称管理员的干预是为了保护其添加的tmbox。而事实是,管理员的干预是在Liu116提请页面保护后,为了阻止其第三次删除他人留言而引发编辑战所采取的标准化行动。

2.坚持置若罔闻:依然在为自己删改他人留言的行为辩解,认为自己行为无错,并攻击第三方用户动机。

这种被管理员(虽然委婉)反对后依然持续进行歪曲事实、攻击他人的行为,进一步凸显了探讨并明确相关规范和行为准则的紧迫性和必要性。

行为分析:

1.在讨论页利用自定义的模板,给他人的发言逐段插入负面标签的做法,是一种没有任何方针支持和允许的变相人身攻击,且违反WP:TPG(破坏了上下文语境和阅读完整性,构成变相删改他人留言)。账户关系信息已在用户主页等处有方针指定的渠道公示,个人不应越权擅自发明私刑规则。无视管理员早已多次强调的“误导已消除”的裁定而再欲强行在讨论页上进行重复的、非标准的自定义“示众”,破坏和干扰他人意见/不同观点的正常呈现,唯一的目的就是羞辱和骚扰对手,其实质为一种为打击报复和贬低攻击异见者的私刑,而非善意的、中立的澄清。如果社群对上例中Lvhis式的独断行为缺乏明确的反对,任由其游戏或自创规则,将会开启一个非常危险的先例和潘多拉魔盒。

傀儡方针中已有关于标注的规定,但仅限于在用户页上进行标准化的公示。如果案例中这种无任何方针支持的、在讨论页四处“贴标签”的滥用行为(即便陈述了部分事实)被允许,那么谁都可以借对方的“黑历史”(如曾被封禁、曾创建不合格条目等)给他人留言逐条张贴大字报来进行变相的攻击(本质上是因人废言和人身攻击的一种形式),这将彻底毒化讨论页的协作环境,将其变为互贴标签的战场,与文明等方针完全背道而驰。

一个用户的程序性过失和身份无关乎其讨论发言的论证质量(除非因制造虚假多数意见而构成实际误导),更不应成为另一个用户对其进行无休止的、超出方针允许范围的骚扰攻击和私刑的理由。用户的身份、封禁记录等信息,应由其用户页的官方模板进行统一、中立的公示,不应由其他用户在各处进行个人的、非标准的“示众”。

2.程序上无视共识流程。在本案中Lvhis在管理员已明确建议“应将问题暴露给更大范围的社群讨论”且有第三方反对后,仍强行执行其单方面操作。这是对共识精神的根本破坏。任何有争议的操作,在进入社群讨论程序后都应暂停执行,何况存在明显反对。


建议:

提议社群明确(或对WP:TPGWP:NPA进行补充,写入类似的规定):--SK.留言) 2025年7月11日 (五) 00:40 (UTC)
Wikipedia talk:游戏维基规则 § 對《遊戲維基規則》序言的若干小修訂

本次擬議修訂如下:

  1. 廢除「惡意使用」,代以「故意以錯誤的方式使用」
    • 在中維的實踐中,GAME這一概念中的「惡意」含義已經被淡化;在實踐中,GAME多是作爲一個行爲被提述,而無暗示該行爲的動機。如搜尋ANM的存檔,不難看到提述GAME的留言多用類似「構成WP:GAME」、「犯了WP:game」、「是WP:GAME的一種」的字眼。
    • 另參見英文維基百科關於移除「惡意」一詞的討論
  2. 廢除「不應該視作是善意的失誤」,代以「像善意的失誤一樣被處理」
    • 這一句自頁面建立起已經存在,而英維的對應版本使用的是「should not be treated the same as a good faith mistake」,而非「should not be treated as a good faith mistake」,爲中維誤譯。
  3. 廢除「管理員的警告」,代以「他人的警告」

綜上,提議修訂序言如下:

現行條文
游戏维基规则Gaming the system)是指恶意使用维基百科方针和指引,阻碍维基百科目标实现的行为。游戏维基规则可能表现为滥用程序、扰乱性编辑或其他违反社群共识精神的行为。一般而言,编辑者游戏维基规则是为了阐释观点、持续打编辑战或强化某一特定的非中立观点
如果有编辑者发现规则中存在漏洞,使得他们可以侵犯社群标准或不当使用管理工具,那这种行为就不应该视作是善意的失误。但是,封禁是预防性措施而非惩罚性措施。一般而言,管理员的警告是阻止游戏维基规则的最佳方式,因为清晰的警告往往能协助纠正善意的失误和恶意的游戏行为。如果编辑者无视警告,重复其行为,或者他们发现新的方法来达成相同的扰乱目的,那么他们更有可能是在恶意游戏维基规则。
提議條文
游戏维基规则Gaming the system)是指故意以錯誤的方式使用维基百科方针和指引,阻碍维基百科目标实现的行为。游戏维基规则可能表现为滥用程序、扰乱性编辑或其他违反社群共识精神的行为。一般而言,编辑者游戏维基规则是为了阐释观点、持续打编辑战或强化某一特定的非中立观点
如果有编辑者发现规则中存在漏洞,使得他们可以侵犯社群标准或不当使用管理工具,那这种行为就不应该善意的失误一樣被處理。但是,封禁是预防性措施而非惩罚性措施。一般而言,他人的警告是阻止游戏维基规则的最佳方式,因为清晰的警告往往能协助纠正善意的失误和恶意的游戏行为。如果编辑者无视警告,重复其行为,或者他们发现新的方法来达成相同的扰乱目的,那么他们更有可能是在恶意游戏维基规则。

以上,提請社羣討論。--1F616EMO喵留言回覆請ping) 2025年7月12日 (六) 01:03 (UTC) 👍1

(+)支持--某人 2025年7月12日 (六) 02:20 (UTC)
Wikipedia talk:快速删除 § G15的具體含義
@Sanmosa上面問題沒回我,所以User_talk:Xiplus/沙盒11User_talk:Xiplus/EditnoticeUser_talk:Xiplus/存檔(這是個模板,不是討論頁存檔,不符豁免條件)都符合G15?--Xiplus#Talk 2025年7月12日 (六) 03:28 (UTC)
Wikipedia talk:快速删除 § 跨命名空間重新導向

我想在這裏尋求大家對於以下情境的恰當性的看法:

  1. 位於非討論頁空間但指向討論頁空間的重新導向(如Template指向Talk);
  2. 位於討論頁空間但指向非討論頁空間的重新導向(如Talk指向Template);與
  3. 位於Draft talk空間但指向其他討論頁空間的重新導向(如Draft talk指向Talk),

以上。Sanmosa DC23 2025年7月13日 (日) 01:25 (UTC)

Wikipedia talk:内容评选 § 提議修改優良條目、典範條目、特色列表以及特色圖片等典優評選的「投票程序」

根據上一條討論串的反饋,我提議將典優評選改為「半投票半共識制」。「半投票半共識制」不同於以往的「共識制」提案。我在此處回應了常年提案的疑點。

此處拋磚引玉,提供2個可操作的具體方案。--SuperGrey (留言) 2025年7月13日 (日) 23:36 (UTC)

Wikipedia talk:删除 § 提议明确页面存废讨论批量提删的执行细节

因时有批量提删出现可能致页面可读性降低,或提删、通知、后续删除等操作致最近更改被冲刷等情况,谨此提议如下:

  1. 单次批量提删提出超过60个页面时({{DRItem}}上限),提删者应使用诸如「Wikipedia:頁面存廢討論/記錄/2025/07/14/批量提删」或其他单一页面列出被提报的页面后链接至主AFD页
  2. 单次批量提删提出超过5个页面创建者为同一人时,提删者可以在主AFD页使用{{ping}}等间接方式通知此创建者

以上。--Hamish T 2025年7月14日 (一) 11:02 (UTC)

Wikipedia talk:内容评选 § 關於使用類似RFC的機制邀請更多編者參與評選

有見社群對於使用類似RFC的機制邀請社群或某專題成員參與評選的討論熱烈,為免影響上方討論,避免過度離題,現邀請@SanmosaSuperGreyTisscherryRoyal SailorCdip150在此集中討論相關事宜。--1F616EMO喵留言回覆請ping) 2025年7月17日 (四) 05:57 (UTC)

Wikipedia talk:格式手册/日期和数字 § 〈概數的兩個鄰數之間的書寫〉跟进《格式手册·标点符号》修订

《格式手册/标点符号》§顿号修订,此处应该跟进,变动如左:

現行條文

相鄰的兩個數字並列連用表示概數時,必須使用漢字,連用的兩個數字之間不得用頓號“、”隔開:

  • 正确:三五天、一千七八百元、一二十個
  • 错误:3、5天、 一千七、八百元、 1、20個
提議條文

相邻或相近的两中文数字连用表示概数时,必須使用漢字,其间一般無須用顿号隔開。唯會產生歧義时,可加上頓號以清楚說明意思。

  • 正确:三五天。一千七八百元。一二十個。九、十人。
  • 错误:3、5天。一千七、八百元。1、20個。九十人。

 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月17日 (四) 06:19 (UTC)

Wikipedia talk:内容评选 § 臨時要求DYKC評選提及先前參與投票的用戶

由於目前DYKC尚未啓用二級標題,無法通過訂閱話題得知一條目的評選動態,從而容易忽略其他用戶的正當合理意見,因此提議修改DYKC投票須知如下:

現行條文
  • 投票者須於投票發起時已為自動確認用戶。不可投票予自己主編之條目。
  • 投票者请使用**号,而不要使用*号或#号,以保持版面清晰美观。
  • 投票者可用{{支持}}、{{反对}}(或{{support}}、{{oppose}})进行投票,動用到自定義參數修改預設顯示文字的模板不計票。可用其他模板作为引子来表述观点。例:
    • (+)滋磁(无效)
    • (+)强烈支持(无效)
  • 若在投票结果确认後投票或發表意見,请同時清空DYKEntry模板的result参数,以免影響自動更新。
  • 关于投票的有效性,請參考上方「獲選標準」中,「关于投票的有效性,采取下列规定」的文字。
提議條文
  • 投票者須於投票發起時已為自動確認用戶。不可投票予自己主編之條目。
  • 投票者请使用**号,而不要使用*号或#号,以保持版面清晰美观。
  • 投票者可用{{支持}}、{{反对}}(或{{support}}、{{oppose}})进行投票,動用到自定義參數修改預設顯示文字的模板不計票。可用其他模板作为引子来表述观点。例:
    • (+)滋磁(无效)
    • (+)强烈支持(无效)
  • 投票時,若提出了新的意見(即非單純支持而不提出自己的見解),必須提及先前曾參與投票的用戶。若該意見與其他非投票留言密切相關,亦建議提及相關用戶。若用戶在投票時應提及某些用戶而沒有提及之,其他用戶可代爲提及,該票仍屬有效。
  • 若在投票结果确认後投票或發表意見,请同時清空DYKEntry模板的result参数,以免影響自動更新。
  • 关于投票的有效性,請參考上方「獲選標準」中,「关于投票的有效性,采取下列规定」的文字。

此提議措施爲DYKC改用二級標題前確保相關人士能收到通知的臨時方案,故不適用於GA、FA等評選,並應在DYKC使用二級標題後自動廢除。以上,知會@TisscherryNewbamboo,另邀請社羣討論。--1F616EMO喵留言回覆請ping) 2025年7月19日 (六) 00:54 (UTC)

維基百科提議

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

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

Wikipedia talk:管理人員申請意向調查 § 就管理人員申請意向調查徵集意見

英維的管理人員申請意向調查(英語:Optional RfA candidate poll)可以讓編者知道申請成爲管理人員的當選機會,接受社羣在這方面的意見,並使編者瞭解到自己在這方面的弱點。爲讓擬申請成爲管理人員的中維編者亦能受惠,我從英維翻譯了該頁面(WP:管理人員申請意向調查),並進行了以下修改:

由於啓用意向調查無需將之訂立爲方針指引,因此無需公示等正式程序,我計劃在徵求足夠廣泛的意見並初步修改不足之處後,便會付諸實踐,並繼續檢查機制是否存在問題。以上,提請社羣討論。--1F616EMO喵留言回覆請ping) 2025年6月27日 (五) 08:23 (UTC)

WikiProject talk:中国行政区划 § {{PRC admin}}及其子模板清理讨论
#模板標題改用民政部行政代碼
假定上方公示通過且已刪除(或標記停用)村級模板頁面,因統計代碼已不再公開,提議將現有模板全部改用行政代碼為標題,並保留原標題的重新導向。因模板影響深遠,提案者暫未細緻檢查各處用例,還請社群可以給予寶貴意見。

因本讨论串预期会暂时保持开放,将章节名修改为便于索引的纯文字模式,将正进行的公示方案调整为三级标题。谨此。--Hamish T 2025年7月12日 (六) 07:42 (UTC)

Wikipedia talk:内容评选 § 提議修改優良條目、典範條目、特色列表以及特色圖片等典優評選的「投票程序」

根據上一條討論串的反饋,我提議將典優評選改為「半投票半共識制」。「半投票半共識制」不同於以往的「共識制」提案。我在此處回應了常年提案的疑點。

此處拋磚引玉,提供2個可操作的具體方案。--SuperGrey (留言) 2025年7月13日 (日) 23:36 (UTC)

Wikipedia talk:内容评选 § 關於使用類似RFC的機制邀請更多編者參與評選

有見社群對於使用類似RFC的機制邀請社群或某專題成員參與評選的討論熱烈,為免影響上方討論,避免過度離題,現邀請@SanmosaSuperGreyTisscherryRoyal SailorCdip150在此集中討論相關事宜。--1F616EMO喵留言回覆請ping) 2025年7月17日 (四) 05:57 (UTC)

Wikipedia talk:内容评选 § 臨時要求DYKC評選提及先前參與投票的用戶

由於目前DYKC尚未啓用二級標題,無法通過訂閱話題得知一條目的評選動態,從而容易忽略其他用戶的正當合理意見,因此提議修改DYKC投票須知如下:

現行條文
  • 投票者須於投票發起時已為自動確認用戶。不可投票予自己主編之條目。
  • 投票者请使用**号,而不要使用*号或#号,以保持版面清晰美观。
  • 投票者可用{{支持}}、{{反对}}(或{{support}}、{{oppose}})进行投票,動用到自定義參數修改預設顯示文字的模板不計票。可用其他模板作为引子来表述观点。例:
    • (+)滋磁(无效)
    • (+)强烈支持(无效)
  • 若在投票结果确认後投票或發表意見,请同時清空DYKEntry模板的result参数,以免影響自動更新。
  • 关于投票的有效性,請參考上方「獲選標準」中,「关于投票的有效性,采取下列规定」的文字。
提議條文
  • 投票者須於投票發起時已為自動確認用戶。不可投票予自己主編之條目。
  • 投票者请使用**号,而不要使用*号或#号,以保持版面清晰美观。
  • 投票者可用{{支持}}、{{反对}}(或{{support}}、{{oppose}})进行投票,動用到自定義參數修改預設顯示文字的模板不計票。可用其他模板作为引子来表述观点。例:
    • (+)滋磁(无效)
    • (+)强烈支持(无效)
  • 投票時,若提出了新的意見(即非單純支持而不提出自己的見解),必須提及先前曾參與投票的用戶。若該意見與其他非投票留言密切相關,亦建議提及相關用戶。若用戶在投票時應提及某些用戶而沒有提及之,其他用戶可代爲提及,該票仍屬有效。
  • 若在投票结果确认後投票或發表意見,请同時清空DYKEntry模板的result参数,以免影響自動更新。
  • 关于投票的有效性,請參考上方「獲選標準」中,「关于投票的有效性,采取下列规定」的文字。

此提議措施爲DYKC改用二級標題前確保相關人士能收到通知的臨時方案,故不適用於GA、FA等評選,並應在DYKC使用二級標題後自動廢除。以上,知會@TisscherryNewbamboo,另邀請社羣討論。--1F616EMO喵留言回覆請ping) 2025年7月19日 (六) 00:54 (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)回复
@Xiplus不反對。最近較忙,我會在這幾日內整理總體方案。Sanmosa 宮掖事祕莫能辨也 2025年6月23日 (一) 04:55 (UTC)回复
經整合的具體提案如下:
  1. WP:權限申請廢除方針地位,移除“簡介”與“要求”的全部內容,並更名為“WP:申請權限”,所有子頁面同。
  2. WP:申请解除权限引述現WP:解除權限方針的部分代之以現WP:權限申請“解任”的內容(下條所述的部分例外),並將其中指向WP:申请解除权限的內部連結替換為“本頁”。
  3. WP:權限申請“解任”中「如機器人帳戶同時持有AWB使用權及機器人權限,不受此限並應該依據機器人方針活躍度要求,AWB使用權與機器人權限同步移除。」一句移至WP:解除權限
  4. 修改下列頁面中有關權限申請位置的規定的文字描述:
以上。Sanmosa 宮掖事祕莫能辨也 2025年6月27日 (五) 00:07 (UTC)回复
@Sanmosa:巡查豁免訂為方針要不要在Wikipedia:互助客栈/方针#重提允許巡查員自我增加與移除自動巡查權/將自動巡查與巡查員權限組分離提出?--Xiplus#Talk 2025年6月30日 (一) 13:32 (UTC)回复
@Xiplus可。Sanmosa 宮掖事祕莫能辨也 2025年7月1日 (二) 03:23 (UTC)回复
@Xiplus考慮到下方討論串的狀況,WP:巡查豁免權立為方針的事情似乎不太好拆到那邊處理。Sanmosa 宮掖事祕莫能辨也 2025年7月4日 (五) 09:19 (UTC)回复
提議條文

Wikipedia:AutoWikiBrowser#註冊與申請權限訂為章節方針:

欲於中文維基百科上使用此軟體,須於申請頁面申請自動維基瀏覽器使用權限。

申請者須達到基本資格:主命名空間非自動編輯250次以上或主命名空間編輯500次以上,自首次編輯以來參與維基百科30日以上,且最近一年內沒有受到封禁(不合理封禁除外)。申請者須了解自動維基瀏覽器的用途和使用方法,在申請時闡明申請原因、使用計畫及任務預定之編輯頻率,管理員若在審核過程中有疑問,可邀請機器人審核小組成員發表意見。若您預計可能進行大量自動編輯,建議充分了解機器人方針,並申請機器人權限;管理員有權在申請者申請機器人權限前拒絕其自動維基瀏覽器使用權限申請。另外,對於已獲機器人審核小組批准運作的機器人,可直接予以授權。

若您的申請事項僅為短期且量少的工作,建議先至機器人作業請求頁面進行請求,或求助已有自動維基瀏覽器使用權限者協助完成。

Wikipedia:機械人方針#對特定工作項目的額外限制新增章節: 添加評級模板 批量在條目討論頁中添加評級模板須申請以下權限擇一:

  1. 機器人權限。
  2. 机器用户巡查豁免權
@Sanmosa看看有無問題。--Xiplus#Talk 2025年6月27日 (五) 12:47 (UTC)回复
@Xiplus可。Sanmosa 宮掖事祕莫能辨也 2025年6月27日 (五) 12:58 (UTC)回复
若您預計可能進行大量自動編輯,建議充分了解機械人方針,並申請機械人權限 -> 「申請者如預計可能進行大量自動編輯,應循機械人方針規定同時申請機械人權限」,原語句似乎沒有明確是「管理員要建議申請者充分了解...」還是「申請者被建議充分了解...」,存在一定歧義。--Hamish T 2025年7月2日 (三) 00:25 (UTC)回复
不反對此調整。Sanmosa 宮掖事祕莫能辨也 2025年7月2日 (三) 23:57 (UTC)回复
@Sanmosa 七天内没有异议,请问现在能公示了吗?Пусть от победык победе ведёт! 2025年7月11日 (五) 09:13 (UTC)回复
更新:經整合的具體提案如下:
  1. WP:權限申請廢除方針地位,移除“簡介”與“要求”的全部內容,並更名為“WP:申請權限”,所有子頁面同。
  2. WP:申请解除权限引述現WP:解除權限方針的部分代之以現WP:權限申請“解任”的內容(下條所述的部分例外),並將其中指向WP:申请解除权限的內部連結替換為“本頁”。
  3. WP:權限申請“解任”中「如機器人帳戶同時持有AWB使用權及機器人權限,不受此限並應該依據機器人方針活躍度要求,AWB使用權與機器人權限同步移除。」一句移至WP:解除權限
  4. WP:機械人方針#對特定工作項目的額外限制新增章節[1]
  5. 修改下列頁面中有關權限申請位置的規定的文字描述:
以上。上述一系列提案自現在起即時公示7日。Sanmosa DC23 2025年7月14日 (一) 12:52 (UTC)回复

参考資料

  1. ^ 新增內容如下:
  2. ^ 修改後的內容如下:

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

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

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

過往討論參見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提案之二
补丁已部署,提交了一批批量恢复权限请求。相关页面的描述将同步进行更新。 Stang1300 2025年6月30日 (一) 07:57 (UTC)回复
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

  • 技术上禁止巡查员创建操作自动标记为已巡查。
  • 出于尊重,为现有巡查员授巡查豁免权。

本人希望之方案。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)回复

名单,共26名用户需恢复权限。 Stang1307 2025年6月24日 (二) 03:16 (UTC)回复
移除权限是否需要提前MMS通知相关权限持有者?上文关于“允许巡查员保有巡查自己条目的权力”的讨论尚未有共识。移除权限后是否允许“巡查员保有巡查自己条目的权力”?--Steven Sun留言2025年6月24日 (二) 13:11 (UTC)回复
@Steven Sun会;这样做的话我感觉不合适的地方在于,这样不就相当于什么也没变嘛,设想一个巡查员创建了条目之后点个按钮,和之前的情况也没什么区别啊。 Stang1305 2025年6月25日 (三) 06:39 (UTC)回复

这一公示已通过。等待补丁的部署,管理员可以对上述的用户的权限进行恢复。相关方针将被修改,MMS通知将在补丁执行后发送。 Stang1303 2025年6月27日 (五) 10:00 (UTC)回复

等通知發送再行授予權限吧(當然同步是最理想,不過有些困難?)。—— Eric Liu 創造は生命(留言留名學生會 2025年6月27日 (五) 10:15 (UTC)回复

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

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

既已移除權限,WP:巡豁資訊頁需要相應更新。--Zheng Zhou留言2025年6月30日 (一) 06:11 (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)回复
简单降低标准提案
通过,将对相关页面进行描述修改。 Stang1300 2025年6月30日 (一) 09:15 (UTC)回复
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

現行條文

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

提議條文

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

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

考虑到上方多个提案已经详细的讨论过具体降低到什么样的门槛,可以视为讨论已经很充分,因此 公示7日,2025年6月27日 (五) 09:47 (UTC)結束 Stang1310 2025年6月20日 (五) 09:47 (UTC)回复
(-)反对,75→25过于宽松,未见有如此大幅下修的必要性。中文维基百科几乎无人在做二次巡查,对于巡免权限仍应慎重。->>Vocal&Guitar->>留言 2025年6月24日 (二) 11:28 (UTC)回复
雖然我不反對這個下調,但我感覺現在不是提這事的時機,這事應該另開討論串處理。(補可供查證方針連結的事情倒是可以繼續,因此公示或許暫時不必撤下。)Sanmosa 宮掖事祕莫能辨也 2025年6月24日 (二) 16:47 (UTC)回复
@Steven SunStangOhtashinichiroSanmosa是否可考慮先改為50篇條目?75篇確實偏多。—— Eric Liu 創造は生命(留言留名學生會 2025年6月27日 (五) 02:56 (UTC)回复
不反對。Sanmosa 宮掖事祕莫能辨也 2025年6月27日 (五) 05:08 (UTC)回复
不反对。--Steven Sun留言2025年6月27日 (五) 06:19 (UTC)回复
另外对现有条目的重写是否也可以计入“创建有效条目”?毕竟这个权限主要是考察条目写作能力,而“重写”与“创建”在能力考察上似乎没有太大区别。--Steven Sun留言2025年6月27日 (五) 06:31 (UTC)回复
很有道理,我觉得是可以这么看的,重写的判定标准可以从DYKC那里抄过来。 Stang1303 2025年6月27日 (五) 06:55 (UTC)回复
可以算,不如說之前不算有點厲害。要不改為「創建或全面重寫」?—— Eric Liu 創造は生命(留言留名學生會 2025年6月27日 (五) 09:13 (UTC)回复
可。这样修改了公示的内容是否要重新计算公示期啊。 Stang1303 2025年6月27日 (五) 06:55 (UTC)回复
@Stang現在公示規定很複雜了,我其實看不太懂。如果要追求穩妥,那就再公示七日,要不然可以改成公示三日之類的,吧。總之,先確定條文改動為好。—— Eric Liu 創造は生命(留言留名學生會 2025年6月27日 (五) 09:13 (UTC)回复
@Ericliu1912那就延长3天的公示期吧, 延迟公示3日,2025年6月30日 (一) 09:47 (UTC)結束。对公示的内容进行了修改。刘酱同志如果有精力可以另开提案修改方针公示规定。 Stang1303 2025年6月27日 (五) 09:41 (UTC)回复
2025年6月30日是星期一。--夏冰 2025年6月30日 (一) 06:20 (UTC)回复
然后?@Summerize Stang1300 2025年6月30日 (一) 07:07 (UTC)回复
不好意思,我只是注意到「延遲公示3日」的日期和星期不符想說提醒一下,我不該留言的,抱歉打擾了。--夏冰 2025年6月30日 (一) 07:24 (UTC)回复
@Summerize啊,不好意思我都没注意到这一个地方 :),感谢你的留言,已经进行了修正。 Stang1300 2025年6月30日 (一) 07:37 (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)回复

綜合條目數量與DYK數量提案

現行條文

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

提議條文

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

以上綜合條目質量及數量。 —WiiUf留言2025年6月26日 (四) 04:45 (UTC)回复

(-)反对,DYK可做附加,但此权无任何绑定DYK的理由。--。->>Vocal&Guitar->>留言 2025年6月26日 (四) 11:30 (UTC)回复
同Ohtashinichiro,社羣中總有不願參與DYK的用戶,維基百科不可強迫用戶參與。Sanmosa 宮掖事祕莫能辨也 2025年6月27日 (五) 00:10 (UTC)回复
不同意直接納入申請制度,理由同上。當然,社群還是要鼓勵參與新條目推薦候選。—— Eric Liu 創造は生命(留言留名學生會 2025年6月27日 (五) 02:58 (UTC)回复
50個有效條目 或 25個有效條目且至少擁有10個新條目推薦(1個典範/優良條目視為3個新條目推薦),符合其一即可,如何?--Factrecordor留言2025年6月29日 (日) 13:06 (UTC)回复
支持門檻多樣化,我當時也是用差不多條件取得巡免的(以IAR的方式以約5X條有效頁面附帶數篇GA與DYK的情況取得)。--WiTo🐤💬 2025年7月1日 (二) 07:34 (UTC)回复
我認為可以作為「同等能力」證明之一。-- 宇帆-娜娜奇🐰桑朵菈🌿草茶☕(留言☎️·簽到☘️ 2025年6月30日 (一) 06:15 (UTC)回复

修訂後提案

現行條文

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

提議條文

任何管理員均可將此權限授予熟知維基方針及指引(特別是可供查證生者傳記收录标准)的可信賴用戶。建議門檻为:

  • 創建或重寫[註 1]50個有效條目,或;
  • 创建或重寫25個有效條目至少擁有10個新條目推薦(1個典範/優良條目視為3個新條目推薦)

如您打算為您自己或其他用戶申請此權,請移步至維基百科:權限申請/申請巡查豁免權

  1. ^ 重写的标准可参考Wikipedia:新条目推荐/候选内的说明

綜合上方部分用戶的意見,修改提案。—WiiUf留言港區國安法5週年 2025年7月3日 (四) 08:35 (UTC)回复

其他想法

既然主要是要確認條目寫出來有沒有問題,那不妨加入「近期三個月內不得出現建立的條目(不含重定向)被提交CSD和AFD的紀錄,或近期所有AFC均通過審核」之類的條件如何?-- 宇帆-娜娜奇🐰桑朵菈🌿草茶☕(留言☎️·簽到☘️ 2025年7月1日 (二) 00:10 (UTC)回复

這完全有被大規模擾亂操作的空間,不贊同。Sanmosa 宮掖事祕莫能辨也 2025年7月1日 (二) 05:26 (UTC)回复
(-)反对拿AFD/CSD作为评判标准,你维某些蠢货会进行报复性提删这事不是一天两天了,完全是给扰乱者提供操作空间。——Mirfaek 2025年7月13日 (日) 03:04 (UTC)回复

讨论页行为的边界:是善意提醒还是骚扰攻击性的贴标签行为?

提議於優良條目、典範條目、特色列表以及特色圖片等典優評選的「投票程序」增加一條文

提議允許用戶可按頁面大小存檔其他用戶的討論頁

鑒於某些用戶(特別是近年沒有再編輯的退休用戶)的討論頁過長,這裏提議讓其他用戶(又或只開放予巡查員或管理員)依照說明:如何將討論頁存檔,以頁面大至某個元組之數量執行存檔他人過長的用戶頁。個人認爲十萬元組或以下存一次檔可為標準。抄送@魔琴(感謝意見)。——Mykola留言 · 簽名 · 烏克蘭專題 2025年7月12日 (六) 13:13 (UTC)回复

附议。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月12日 (六) 13:50 (UTC)回复
感觉执行方式及标准容易起争议。长页面可能涉及的讨论数难说,用户喜好也难说。是部分存档还是整页存档。--YFdyh000留言2025年7月12日 (六) 17:11 (UTC)回复
或許可以統一在達到一定大小就可以先代他們把額外元組除歡迎辭存檔,將此設定為軟性措施,先建議,如用戶無回應則可以先為執行,如最後他們萬一覺得不妥就復原或再依他們喜好調整。又或許只將此計畫推行於已幾年沒有編輯大概已退休的用戶討論頁(畢竟afd等通知按一般處理手法程序發送予使用者為佳?)——Mykola留言 · 簽名 · 烏克蘭專題 2025年7月13日 (日) 01:47 (UTC)回复
按时间如何?之前遇到过十多年的讨论全堆在讨论页的用户,由于加载过慢直接放弃交流了。——暁月凛奈 (留言) 2025年7月12日 (六) 22:18 (UTC)回复
這個也可考慮,但我覺得每個使用者在訂閱消息或其建立的頁面被提刪的數量之類可以差很多,可能有一年要存檔一兩百多個或只有十幾個話題的情況出現。(個人認為設定數字門檻較為標準化?--Mykola留言 · 簽名 · 烏克蘭專題 2025年7月13日 (日) 02:15 (UTC)回复
(!)意見導入機器人自動存檔,明確運作規則,確實佈達運作規則,公告後試辦,試辦後無異常或其他意見,可全面推行。
  • 不需要人工處理
  • 需要確認運作規則
--Rastinition留言2025年7月13日 (日) 02:11 (UTC)回复
用户可能有不同的存档子页面命名惯例,机器人不一定明白。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月13日 (日) 06:23 (UTC)回复
我认为用户页和用户讨论页对于相应用户而言是具有一定程度的自主权,除非用户允许或者一些维护情况下(例如DYK更新等),尽量会排斥其他用户的操作。因此,没这个必要性。——Sakamotosan路过围观 | 避免做作,免敬 2025年7月13日 (日) 06:28 (UTC)回复
这本身就是「维护情况」。太长的用户讨论页会导致其他用户载入缓慢,阻碍溝通;到達MediaWiki允许的页面大小上限後甚至无法溝通。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月13日 (日) 08:12 (UTC)回复
我不认为如此,因为讨论页归档只是一种良好的惯例但不必须,也就是这不是强制需要的。如果对应用户不想做存档,你奈他不何,如果需要弄的话,他早就弄了。——Sakamotosan路过围观 | 避免做作,免敬 2025年7月13日 (日) 10:03 (UTC)回复
? ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月13日 (日) 10:05 (UTC)回复
他想不想是他自己的事,他不存档影响到我给他發消息了,这事就和我有关了。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月13日 (日) 10:08 (UTC) 👍1回复
同意。由其他用戶進行存檔應訂立規定,只在不存檔會造成嚴重阻礙時才進行存檔,並儘量尊重原用戶的存檔習慣(如有)。--1F616EMO喵留言回覆請ping2025年7月13日 (日) 10:09 (UTC)回复
如果真要設立,只同意人手存檔,且被存檔頁面應達到公認顯著影響其他用戶進行溝通的標準。--Hamish T 2025年7月13日 (日) 10:53 (UTC)回复
一般不應代為存檔,除非達到MediaWiki技術上限(如從前本人遇過討論頁滿至拒絕大量消息遞送者),或已相當阻礙頁面載入(此應以最嚴格情況判定);存檔應優先考慮存入既有存檔頁面(若有且符合存檔範圍),若非要新建存檔頁面,亦應儘量配合既有命名格式;不得以機器人自動存檔;不得直接移動討論頁作為存檔,避免割裂編輯歷史;不得在存檔過程中更動原始討論內容;存檔時應以編輯摘要註明,並在討論頁留下通知,最好存檔以前就先予以充分提醒;若當事人回歸,應完全尊重其後續處置。以上是一些基本原則建議。當然,這本是一種侵門踏戶,所以我覺得最好還是排除所有技術原因以外的主觀認定情況。—— Eric Liu 創造は生命(留言留名學生會 2025年7月13日 (日) 20:53 (UTC)回复
大致同意。除非技术上影响讨论插入(这样才代为移动为讨论页存档,为了能插入新的讨论提醒),讨论页是否存档不应该成为强制介入其他用户讨论页的前提。——Sakamotosan路过围观 | 避免做作,免敬 2025年7月14日 (一) 05:48 (UTC)回复
认同,未经过用户许可的情况下,仅允许在无法加入新内容/严重影响页面加载的情况下才可以存档用户讨论页。 Stang1286 2025年7月14日 (一) 09:21 (UTC)回复
「不得直接移动讨论页作为存档」,如果頁面已經大到閣下列出的這種程度,用移動討論的方式設置存檔應該也是受到一定阻礙的。(如果能頂着大頁面載入把他的討論剪切粘貼到新的頁面,會不會可以認爲其實這個頁面還是能用的?)而移動頁面只需要載入一個特殊頁面,操作會方便一些。不過,建立存檔頁面時研究現有命名格式也是需要載入頁面看看的。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月15日 (二) 02:00 (UTC)回复
查了一下本站用户讨论页长度前百,不认为有设立此规定的必要性。但不反对就是了,大致意见同上方三位用户。--Hamish T 2025年7月14日 (一) 11:23 (UTC)回复
真的嗎?有十個以上使用者討論頁面元組破百萬,這加載起來多少有困難。--Mykola留言 · 簽名 · 烏克蘭專題 2025年7月14日 (一) 14:52 (UTC)回复
破百萬的那幾位用戶,我隨機看了7個歷史,一版的「MediaWiki message delivery」,這樣的討論頁我確實認為沒有清理的必要。--Hamish T 2025年7月14日 (一) 15:03 (UTC)回复
您可以再看看上面的數據庫頁面,破百萬的用戶沒有一個是近一個月有貢獻的(補充:Jasonzhuocn君剛好卡點),似乎需要溝通的可能性也沒那麼大。--Hamish T 2025年7月14日 (一) 15:36 (UTC)回复
同意目前不用為此設立特別規定,至多是作為社群討論留下紀錄,供後人參考。—— Eric Liu 創造は生命(留言留名學生會 2025年7月14日 (一) 17:45 (UTC)回复
倒是想到,社群可以先給這些同志發提醒呀(亦可標註此處討論),反正有益無害。—— Eric Liu 創造は生命(留言留名學生會 2025年7月14日 (一) 21:11 (UTC)回复
之前遇到過達到MediaWiki單頁大小限制的用戶討論頁。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月15日 (二) 01:46 (UTC)回复
既然涉及的人不多,还是先跟这些用户沟通为好,并事先提醒若页面大小达到技术限制可能会被其他用户存档。--Steven Sun留言2025年7月15日 (二) 13:16 (UTC)回复

提议明确页面存废讨论批量提删的执行细节

中国大陆简体问题

有關《林夕》條目中的目錄顯示異常情況

仲裁委員會的捷徑(快捷方式)問題

目前仲裁委員會有「WP:A/M&T」這個捷徑,但是WP:A是《宣告》,這樣做好嗎?是否應該改用WP:AC的子頁面?這又讓我想到,仲裁委員會是否需要單獨的命名空間或者僞命名空間? ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2025年7月16日 (三) 14:07 (UTC)回复

我有以下三個建議:
  1. 使用英維做法:英維使用的捷徑格式頗爲隨意,但都不使用子頁面,如WP:ARBPIA5指向巴勒斯坦—以色列相關條目(五),以及WP:YASUKE指向關於彌助的爭議。按此邏輯,捷徑可定爲「WP:ARBM&T」。
  2. 使用WP:ARB的子頁面:雖然目前ARB指向仲委會,但其語義其實更加接近「Arbitration」而非「Arbitartion Commitee」,應該比WP:仲裁WP:ARBIWP:ARBINFO更好。按此邏輯,捷徑可定爲「WP:ARB/M&T」。
  3. 使用單獨僞命名空間「ARB:」,即「ARB:M&T」。
我比較支持第二個做法,因爲中維沒有如第一點那麼隨意的風氣,又仲裁案的數量應不至於需要單獨的僞命名空間。不過我比較好奇中文捷徑應該怎麼取——如果红渡厨和Lemonaka,WiiUf在ANM的争议獲正式立案,應該定爲「WP:ARB/红渡厨」、「WP:ARB/HONGDUCHU」、「WP:ARB/HDC」、「WP:ARB/HLW」,還是什麼奇怪的東西?--1F616EMO喵留言回覆請ping2025年7月16日 (三) 17:06 (UTC)回复
是否只有中文維基百科使用WP:A指代WP:宣告Sanmosa DC23 2025年7月17日 (四) 06:20 (UTC)回复
英維不存在「宣告」,WP:A則指向Wikipedia:Attribution。--1F616EMO喵留言回覆請ping2025年7月17日 (四) 06:33 (UTC)回复
我的想法是WP:A在本地可以改為指向WP:仲裁委员会,那WP:A/M&T就不再是一個問題了,畢竟WP:宣告並非常用頁面。Sanmosa DC23 2025年7月17日 (四) 08:12 (UTC)回复
WP:A的鏈入頗多,又不同於WP:擾亂這類語義上容易誤會而必須更改的例子,未必適合更改。--1F616EMO喵留言回覆請ping2025年7月17日 (四) 08:51 (UTC)回复
連入不至於多吧,剛才看過,就只有106個,有共識的話,用bot處理掉即可(人手處理也可以,就是有些麻煩)。Sanmosa DC23 2025年7月17日 (四) 11:46 (UTC)回复
英維有WP:ANN指向Wikipedia:Milestones--User:What7what8🏠 2025年7月18日 (五) 21:05 (UTC)回复
其實我不希望為所有案件設定捷徑,案名縮成那樣反而看不懂了。真要設定,則應用「WP:ARB」子頁面。另同意不應更改「WP:A」捷徑去向。—— Eric Liu 創造は生命(留言留名學生會 2025年7月19日 (六) 07:46 (UTC)回复