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

互助客棧： 消息  方针  技术  求助  条目探讨  其他 |  知识问答

發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

公告欄

• [公告] 在本地启用安全投票及electionadmin权限、調整COVID-19條目共識的規定、規範日本選舉條目命名及禁止有關藝人演出的獨立列表條目羅列非固定參與的節目已經通過。
• [公告] 修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应、选举监察员运作细节及开放自由提名管理员等权限申请、仲裁委员会成立后的管理人员解任机制、抄襲論述併入不要包含原始資料的副本指引、規範資訊框內母公司子品牌的列出方式（重公示）、修订用户名方针与用户页指引、賦予過濾器助理建立或修改防濫用過濾器的權限及修订政治人物关注度指引正在公示，如有意見請儘快提出。
• [討論] 互助客栈方针区正在討論不限期不是永久-解封指引與第二次機會、是否將格式手冊移動到MOS命名空間下、在非原創方針新增例子以禁止綜合常識及可靠來源、擴充ITNR獲選類別及根据WP:用戶頁对WP:用戶框进行修订，請踴躍參與討論。
• [討論] 互助客栈技术区正在討論修订过滤器警告信息，請踴躍參與討論。
• [討論] 互助客栈条目探讨区正在討論有關日本內閣條目的命名問題，請踴躍參與討論。
• [討論] 互助客栈其他区正在討論实装Automoderator工具、是否应关闭中文维基百科以抗议基金会举措、管理人員任免制度檢討等事、本地部署安全投票及相关权限、禁制復核及提议将编辑提示内容同步到首页每日提示版块展示，請踴躍參與討論。
• [討論] 互助客棧試行案討論區正在討論討論遞進機制試行案-檢討意見分享，請踴躍參與討論。
• [廣告] 第四屆臺灣－斯洛伐克編輯松正在進行中，直到12月31日結束，歡迎踴躍貢獻！

• [協作] 现有135个页面需维基化，402个条目需清理，41个移动请求正在讨论。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	关于Wikipedia:避免地域中心#地理，建议增加关于“来”字的论述	40	12	Sanmosa	2024-12-19 18:46
2	修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应	87	8	自由雨日	2024-12-20 08:58
3	將WP:格式手冊所有方針與論述移動到MOS命名空間，並將MOS命名空間更名為「格式手冊」	1	1	Sanmosa	2024-12-20 08:58
4	应根据WP:用戶頁对WP:用戶框进行修订	1	1	Sanmosa	2024-12-20 09:17
5	赋予过滤器助理修改滥用过滤器权限	45	10	Sanmosa	2024-12-17 16:56
6	提議維基百科:抄襲併入維基百科:不要包含原始資料的副本	57	8	沈澄心	2024-12-20 18:03
7	請求社群關注仲裁委員會在管理員的離任討論中相關的權限問題	48	9	0xDeadbeef	2024-12-20 13:23
8	重新讨论NT:MUSIC	1	1	Sanmosa	2024-12-17 16:42
9	維基百科:命名常规 (人名)中的例子姜太公已经移动	3	3	魔琴	2024-12-13 05:23
10	建議Wikipedia:愛好者內容擴增「交通迷內容」方針之請求與討論	20	4	Sanmosa	2024-12-19 19:06
11	被不限期封禁用户不应默认复审移除IP封禁豁免权限	1	1	Sanmosa	2024-12-18 07:27
12	欢迎就Wikipedia:格式手冊/無障礙/2025草稿提供意见	3	2	ItMarki	2024-12-16 12:58
13	提議DYK/GA/FA引入cooldown time(或譯冷靜時間)	60	11	Sanmosa	2024-12-20 15:38
14	提議WP:POINT引入反對言論規範。	1	1	Sanmosa	2024-12-20 08:48
15	控制複雜ANM案例	11	7	August0422	2024-12-20 18:04
16	建議明確签名的「255字节」是以何种編碼計算	3	2	内存溢出的猫	2024-12-20 17:10

發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面 或完成討論之議題
手動設定
當列表出現異常時， 請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注：（重新整理）

維基百科格式與命名

Talk:加油！中村同學！！ § 建議更名：“加油！中村同學!!”→“加油！中村同學！！”

“加油！中村同學!!” → “加油！中村同學！！”：! or ！--HeihaHeihaHa-麻瓜了……（留言） 2024年11月21日 (四) 06:30 (UTC)

Talk:南华大学 (湖南) § 建議更名：“南华大学 (湖南省)”→“南华大学 (湖南)”

“南华大学 (湖南省)” → “南华大学 (湖南)”：原本的条目名是“南华大学 (湖南)”，不知道为什么要被移动到“南华大学 (湖南省)”。“湖南”已足够消歧义，且更符合习惯，类似中国地质大学（北京）（这里的括号不是维基百科的消歧义，但能体现常用的命名习惯）。--小林子冲（留言） 2024年11月23日 (六) 22:00 (UTC)

Talk:亨利·比索 § 有關為非漢字文化圈人事物擬定香港譯名的問題

該條目的中文部份由本人創建，一直利用香港音譯將Bishop寫成「比索」，早陣才留意到原來兩年前由淺藍雪將我的標題改為「亨利·畢曉普」，本人今天打算重新增幅，亦因為見已有Note TA而將標題改回為本人最初的用語時，卻被一名稱為向史公哲曰的騷擾，他以廣東話叫法為「原創研究」不斷回退我的修改，甚至不容許我用任何方式將「畢曉普」轉換為「比索」，甚至強行將我一直撰寫開的「比索」換為「畢曉普」，意圖不容許我日後再進行增減時再使用「比索」一詞。並且將香港慣常處理英文讀音的方法定義為「原創研究」和「無心中生有」。現在更剛在本人的討論頁上留下所謂「嚴重警告」的恐嚇。

從Google中我同意「畢曉普」、「畢夏普」的使用可能比「比索」為多，但向史公哲曰執着中文維基內只有使用「畢曉普」、「畢夏普」所以不可以有「比索」的寫法再硬塞以「原創研究」來打壓，完全是架空中文維基的包容性和容許多樣化，對此我需要提出社群的建議。

或是當我被向史公哲曰的橫蠻干預而無法再為條目貢獻時，我寧可以創建者的身份申請廢掉條目。--Foamposite（留言） 2024年12月1日 (日) 08:27 (UTC)

Talk:协调世界时 § 建议删除"现在时间"框

该框内显示的时间并不是当前的协调世界时,而只是上次按"刷新"获得的时间.该时间并没有实际意义.增加一个链接到显示当前协调世界时的网站即可.--Uwuw（留言） 2024年12月5日 (四) 18:55 (UTC)

Wikipedia talk:條目命名一致性決議 § 提议：规范部分铁路条目站名的译法

现状

自2012年起，中维有关JR货物各货物大站条目“○○貨物ターミナル駅”出现了“某某货物总站”的译法。诸如2012年出现的条目札幌货物总站。此后接连出现了东京货物总站、大阪货物总站等车站条目皆从其译法。

问题

一个大问题：“貨物Terminal駅”翻译成“货物总站”的根据在哪？

查Google发现，在2012年前,网络来源中十分缺少有关车站译为货物总站的说法，反倒是2012年札幌货物总站等条目出现之后，类似的翻译多了起来。甚至在2019年，中国铁科院有关人士发表论文时，也引用了“总站”的说法（doi:10.16669/j.cnki.issn.1004-2024.2019.12.12）。因此我怀疑最初维基“货物总站”译法可能为原创研究，并一定程度上造成了长达十余年的文献循环论证。

查证

查铁道科学名词审定委员会《铁道科技名词——汉英法德俄日六种语言》（简体中文）时，所谓“ターミナル駅”翻译为“区段站”。但是欠缺“貨物ターミナル駅”的翻译。

查铁道综合技术研究所《铁道技术用语辞典》（日语）时，ターミナル駅，翻译为“枢纽站”，而“貨物ターミナル駅”翻译为“货运枢纽站”。

以上两例或可证明至少在中国大陆的铁路术语中，所谓“总站”的翻译是非常有问题的。

提议

因为不知道非中国大陆的地区术语是否也有对应翻译，需要请教社群中其他地区的有识者（如@鐵路1@雪雨73），并早日确定翻译方案以匡正对应诸多条目的名称。-- 西行寺海苔子 ハナノモトニテ 2024年12月15日 (日) 12:08 (UTC)

維基百科方針與指引

Wikipedia talk:互助客栈 § 有關互助客棧方針版的長度壓力問題

此前，互助客棧方針版的長度一度逾60萬位元組，在我搬運了若干已結束或stale了的討論後才降到40多萬，然而這個長度還是比起其他互助客棧的版塊來得長（互助客棧其他版的長度現在是20多萬位元組，條目探討版是10多萬，消息、技術與求助版不超過10萬），而且在頁面載入與編輯上也產生了一些問題（我在電腦嘗試載入或編輯頁面的話，頁面完全載入所需的時間顯著地延長了）。有鑒於此前曾有討論提議以WP:徵求意見機制取代互助客棧方針版的機能，我認為現在是合適的時機來提出這件事情。Sanmosa _新朝雅政 2024年10月23日 (三) 00:30 (UTC)

Wikipedia talk:可靠来源 § （硕士论文）怎样的影响可以算作“显著学术影响”

• “硕士学位论文通常未经类似评估，因此不如博士学位论文可靠，除非其具有显著学术影响。”是否需要用信息页说明“显著学术影响”？
• 对于一般的（无“显著学术影响”）硕士论文而言，相关行文似乎也有模糊之处，只点出硕士论文“不如博士论文可靠”，而未明言其“不是可靠来源”。是否需要点出“除非具有显著学术影响，否则硕士论文不是可靠来源”（英维是明确点出的：“Masters dissertations and theses are considered reliable only if they can be shown to have had significant scholarly influence.”）？--自由雨日🌧️（留言｜贡献） 2024年10月23日 (三) 16:21 (UTC)

Wikipedia talk:消歧义 § 2020年10月修订案与格式讨论

修订案主要涉及#章节安排问题（最简单的做法只需将一个三级标题改为二级标题），以及#修订WP:消歧义命名的问题。格式讨论涉及主从消歧义页面编写方式（若有必要则亦应修改指引）。——自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 04:39 (UTC)

Wikipedia talk:管理員的離任 § 仲裁委員會成立後的管理人員解任機制（續）

經共識訂立的仲裁機制及其他過往討論中均就仲裁委員會在處理管理人員解任案獲得社群廣泛同意，在維基百科討論:仲裁委员会#管理人員解任中就達成了「仲裁委員會有權調查管理人員行為是否失當後交社群再行決議」，但就仲裁委員會如何行使有關職權仍有待商榷。我想將這個議題分拆成多個部分去探討，期望獲得最大程度的共識。本討論分為以下部分：

1. 彈劾機制；
2. 糾舉機制；
3. 直接除權；及
4. 依請求介入社群程序。

(※)注意：此四機制並非僅能採納其中一個，這四個機制的設計是完全可以共容的。

--路西法人 2024年10月27日 (日) 16:39 (UTC)

Wikipedia talk:封禁方针 § 完善WP:封禁「不限期不是永久」總方針

所謂「不限期」不應理解為「永久」，但WP:封禁並沒有指引給管理員對解封的指引，以確保符合這個目的。對此，建議修改WP:封鎖方針，引入擔保制及對巡查員或回退員進行擴權，以進行有條件解封。

想法：

• 管理員需就不限期封鎖用戶的封鎖理由寫上解封條件。
• 不限期封鎖用戶可在完成解封條件後找廷伸確認用戶請求擔保
• 由廷伸確認用戶向管理員確定不限期封鎖用戶已完成解封條件，並聲明會負責監督該名用戶的編輯。
• 廷伸確認用戶監管不力的話，會被剝奪擔保資格。
• 巡查員或回退員對該名用戶的編輯進行二次確認。
• 直至管理員認為那名編輯者真誠悔改，然後解除監管。
• 只要擔保者決定不對該名用戶進行擔保或 巡查員或回退員 認為編輯有問題，隨即啟動即時封鎖程序，解封條件會較上一次更嚴格。

好處：減低管理員的工作壓力，從而達到不限期不是永久的目的。--唔好阻住我愛國（留言） 2024年11月9日 (六) 04:02 (UTC)

Wikipedia talk:非原创研究 § 關於非原創研究問題

1.假設美國某媒體報導：「2024年2月30日，川普發表了一場講話，關於他上任後會徵收關稅。」

那麼，我可不可以基於上述資料，斷定美國將會在川普上任後會徵收關稅？

2.假設英國某媒體中文版報導：「2025年2月31日，白悟空將2026年2月31日於Google Play上架」

那麼，我可不可以基於上述資料，斷定白悟空不能在中國下載？

相關討論：Wikipedia talk:格式手冊/電視#對於剛訂立的格式手冊/電視，細節上的疑問--唔好阻住我愛國（留言） 2024年11月19日 (二) 11:21 (UTC)

Wikipedia talk:格式手册/两岸四地用语 § 提議容許中華民國（中華臺北）體育代表隊使用「中華隊」簡稱

中華民國（中華臺北）體育代表隊使用「中華隊」簡稱，乃其來有自。又無論「中華民國（代表）隊」或「中華臺北（代表）隊」，均可簡稱為「中華隊」，行文實較簡易，且得維持一致格式。故比照港澳代表隊之例，建議放寬格式手冊規定，容許首次提及中華民國或中華臺北代表隊完整名稱後，於條目正文（不包含表格及模板等）使用「中華隊」簡稱；與此同時，仍繼續禁止使用「中華」稱呼，避免過度歧義。望社群斟酌。若有其他方案，亦可一併提出。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月26日 (二) 18:32 (UTC)

Talk:亨利·比索 § 有關為非漢字文化圈人事物擬定香港譯名的問題

該條目的中文部份由本人創建，一直利用香港音譯將Bishop寫成「比索」，早陣才留意到原來兩年前由淺藍雪將我的標題改為「亨利·畢曉普」，本人今天打算重新增幅，亦因為見已有Note TA而將標題改回為本人最初的用語時，卻被一名稱為向史公哲曰的騷擾，他以廣東話叫法為「原創研究」不斷回退我的修改，甚至不容許我用任何方式將「畢曉普」轉換為「比索」，甚至強行將我一直撰寫開的「比索」換為「畢曉普」，意圖不容許我日後再進行增減時再使用「比索」一詞。並且將香港慣常處理英文讀音的方法定義為「原創研究」和「無心中生有」。現在更剛在本人的討論頁上留下所謂「嚴重警告」的恐嚇。

從Google中我同意「畢曉普」、「畢夏普」的使用可能比「比索」為多，但向史公哲曰執着中文維基內只有使用「畢曉普」、「畢夏普」所以不可以有「比索」的寫法再硬塞以「原創研究」來打壓，完全是架空中文維基的包容性和容許多樣化，對此我需要提出社群的建議。

或是當我被向史公哲曰的橫蠻干預而無法再為條目貢獻時，我寧可以創建者的身份申請廢掉條目。--Foamposite（留言） 2024年12月1日 (日) 08:27 (UTC)

Wikipedia talk:维基百科不是什么 § 出版書籍、雜誌是否為WP:NOT

如題所述，請教以下情況甚麼時候屬WP:NOT及判定依據?

• A)條目收錄自行出版之書籍或論文(有一手來源、但沒有二手、三手來源)；
• B)條目收錄自行出版之書籍或論文(有二手、三手來源)；
• C)條目收錄非自行出版之雜誌，雜誌內容包括照片、採訪(有一手來源、沒有二手、三手來源)；
• D)條目收錄非自行出版之雜誌，雜誌內容包括照片、採訪(有二手、三手來源)；
• E)條目收錄非自行出版之雜誌，雜誌內容包括照片，但沒有採訪(有一手來源、沒有二手、三手來源)；
• F)條目收錄非自行出版之雜誌，雜誌內容包括照片，但沒有採訪(有二手、三手來源)；--Abcet10（留言） 2024年12月4日 (三) 14:31 (UTC)

Wikipedia talk:用戶框 § 应根据WP:用戶頁对WP:用戶框进行修订

从范围上来看，用户框是用户页的子集。用户框的内容也应受到WP:UPNOT的限制。想起这一点是因为近日又有新用户（Carl66066）连续建立多个在我看来并不合适的用户框。以该用户此前的用户页为例：

• 视觉效果十分糟糕：颜色搭配不当，背景颜色和文字颜色接近，文本框宽度参差不一；
• 反复宣告自己的观点：使用大量文本详细描述自己的观点，而这些观点基本上与维基媒体运动及社群协作毫无关联；
• 名称不明确：模板名称与文本内容不相符，或存在歧义。

由于类似的编辑者以往也存在，我认为有必要按照WP:UP修订WP:UBX，把Template:Subcat guideline-en从WP:UBX移掉，对目前的用户框进行整理，将文本内容过于注重表达个人意见的改为中性的陈述或简单的宣告，无可救药的模板批量送存废。——暁月凛奈 (留言) 2024年12月4日 (三) 15:19 (UTC)

(＋)支持。另外除了根据中维的《WP:用户页》修订之外，也可以根据目前英维的en:WP:Userboxes修订？因为似乎中维的版本有些落后了…… ——自由雨日🌧️❄️ 2024年12月4日 (三) 15:27 (UTC)

Wikipedia talk:命名空间 § 將WP:格式手冊所有方針與論述移動到MOS命名空間，並將MOS命名空間更名為「格式手冊」

因為此案涉及到方針指引的移動，故不放在技術區，放在方針區

前言

見前次討論，已有初步共識，不過當時有意見認為需近一步討論，也因 此案涉及到方針指引的移動故需要在方針區確認共識或進一步討論。

方針/指引的部分即：

• 將所有WP:格式手冊的子頁面(►)移动到MOS:空間下。

技術細節：

• 將MOS更名為「格式手冊」，即：

• 編輯以下頁面：

在這些介面設定頁面中 MediaWiki:Nstab-mos MediaWiki:Nstab-mos/zh MediaWiki:Nstab-mos/zh-hant MediaWiki:Nstab-mos/zh-tw MediaWiki:Nstab-mos/zh-hk MediaWiki:Nstab-mos/zh-mo MediaWiki:Nstab-mos/zh-hans MediaWiki:Nstab-mos/zh-cn MediaWiki:Nstab-mos/zh-sg MediaWiki:Nstab-mos/zh-my MediaWiki:Conversion-ns126

中填入格式手册或格式手冊

• 提出工單將「格式手册」和「格式手冊」設定為「MOS」的別名（比照當時維基專題命名空間的設置）
• 命名空間偵測模板更新「格式手冊」命名空間名稱

正文

見前次討論，因為MOS語言維基百科的創立，因此本站設立的MOS捷徑得以因此技術原因phab:T363538，被升格為命名空間。當時的討論主流共識認為，既然都有名字空間了，不如把對應頁面都(►)移动進去。

我現在的想法是，既然基金會都升格MOS為正式命名空間了，我們不使用實在浪費。且屆時上述更名技術操作全部完成後，移動到下面的頁面如維基百科:格式手冊/避免自我提及將會直接顯示為「格式手冊:避免自我提及」同當時「維基百科:XX專題」變為「專題:XX」的好處。

提及上次「關於本命名空間」之討論參與者@S8321414、SunAfterRain、魔琴：歡迎再次發表意見。

• (～)補充 現行「指引上」MOS的地位現在是偽命名空間，然而目前基金會已經將之升格為「真」命名空間，因此「技術上」MOS的地位現在是「真」命名空間。這次希望的修訂就是能充分利用這個「真」命名空間，同時修訂相關方針指引以滿足phab:T363538的現況。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月5日 (四) 04:06 (UTC)

Wikipedia talk:關注度 (音樂) § 重新讨论NT:MUSIC

各位编辑，在下长期以来在浏览编辑维基百科的过程中，发现存在大量的近似爱好者内容，这些作品大多以单曲、演唱会和部分音乐综艺节目为主，通常无法证明其关注度，内文更是不重要的内容堆砌。但是，这些条目又往往能绕过当前NT:MUSIC的相关论述，使编者很难在存废问题或其他条目编辑问题上达成共识。依在下所见，当前的NT:MUSIC至少存在以下问题：

• 在关于来源的问题上，现今条文是他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及，但是根据中国大陆当前现状，由于充斥大量的内容农场和宣传内容，使许多看似可靠来源实则存在潜在的不中立现象，如自己按门铃自己听中的中国网来源（《歌手·当打之年》今晚终极奇袭 周深首秀未发布新曲）之类，在下看不到任何属于可靠来源的证据。
• 在关于音乐作品的内容中，维基百科:商业排行与认证是部分维基编者编辑部分单曲条目的重要依靠，但是中国大陆的音乐榜单要么是平台的自嗨、要么是粉丝的刷榜，毫无公信力可言。如被部分编辑推崇的腾讯音乐由你榜，就曾被举报过开通年会员可大大提高用户打榜（主要包括播放、收藏、下载、分析、点赞歌曲等）权重（1），并且该榜单仅限腾讯拥有版权的音乐，此类排行榜获得什么周榜月榜第几名、有多少可信度自有公论，其他类似网易、酷狗等等推出的野鸡榜单更是不用再浪费时间。
• 另外，在相当多内容的条目中存在大量毫无意义的内容，几乎要把维基百科变成Fandom。如“天外来物”世界巡回演唱会中什么“衢州新闻媒体中心在抖音官方账号上发布了视频，表达了对薛之谦的感谢”、自己按门铃自己听中类似“周深在演唱的時候，身穿一件珍珠裝飾的牛仔夾克，搭配黑色T恤和牛仔褲亮相”的表述，在下看不出放在条目内的必要。
• 现存的NT:MUSIC中没有关于演唱会关注度的表述。

综上所述，现存的NT:MUSIC及其他相关页面均为论述或指引，并且部分表述相当模糊，大量的条目游走在关注度的边缘，因此在下建议社群对上述内容进行重新讨论并争取达成共识并升格为方针。由于刚刚提起讨论，在下暂不提出新的方案内容，待社群讨论后再进行总结。--SheltonMartin留言|签名 2024年12月11日 (三) 01:22 (UTC)

Wikipedia talk:申请解除权限 § 被不限期封禁用户不应默认复审移除IP封禁豁免权限

Wikipedia:申请解除权限在议的多项提议和既往“判例”表明，永封用户经由“已封禁或除权用户复审”快速剥夺IPBE权限。然，本站用户对IPBE权限的使用多是因为GFW封锁下被迫使用代理编辑，为正常编辑所必须之权限，在用户尚未被移除编辑其讨论页权限前移除其IPBE权限在实践上剥夺了被封禁用户编辑其讨论页进行初步申诉的能力，显然是越俎代庖。此外，依据Wikipedia:IP封禁豁免#移除權限一节，被封禁用户虽可能已不被社群信任，但亦不太可能滥用其权限（IPBE），被完全封禁的用户的权限也会因为不活动而自动移除，并无主动快速移除其IPBE权限的必要性。综上所述，提议：

現行條文	提議條文 出于保留受GFW影响的用户在被封禁后使用其讨论页进行申诉的能力，对于拥有IPBE权限的无限期封禁用户，在无证据证明该用户可能滥用其IPBE权限的情况下，不应在其被不限期禁止编辑其讨论页前主动移除其IPBE权限。

此提议需要熟悉反破坏工作（如傀儡调查）的社群成员讨论，另ping之前在布告板参与讨论的@自由雨日、Ericliu1912、Allervous、Manchiu、阿南之人。--HeihaHeihaHa-戒慎恐惧……（留言） 2024年12月13日 (五) 13:40 (UTC)

Wikipedia talk:关注度 (人物) § 修订政治人物关注度指引

此討論正在公示7天，直至2024年12月27日 (五) 02:11 (UTC)結束；如有意見請儘快提出。

現擬修訂WP:关注度 (人物)如下：

現行條文 政治實體及一級行政區的領導階層（例如總統、總理和首相等等）、法律上或事实上最上級及一級行政區行政機構的成員（例如，內閣成員、中共中央政治局常委）、立法機關的議長、議員或代表。

提議條文 現任、曾任及／或候任國際級、國家／地區級及／或（採用聯邦制或類似政治體制的國家的）一級行政區級權力機關的重要實權公職及／或立法機關成員。 参考資料

Sanmosa _{Samāʾun la-ʿamruka ʾaw ka-s-samā} 2024年12月13日 (五) 15:59 (UTC)

Wikipedia talk:不要為闡釋觀點而擾亂維基百科 § 提議WP:POINT引入反對言論規範。

現行條文	提議條文 如果你在一場討論中欲發表反對言論，但是您發現自己並沒有時間持續關注該討論內容。 理當不要發言，以免您因為對提案不理不睬的態度而妨礙其他人形成共識。 而不要只撇下反對意見卻沒有跟進其他編輯者就着您的反對意見進行深入討論。

現行條文	提議條文 如果你在一場討論中欲發表反對言論。 理當在討論階段表達反對意見。 而不要在公示/投票結束當天提出反對意見。

--唔好阻住我愛國（留言） 2024年12月18日 (三) 14:53 (UTC)

維基百科提議

Wikipedia:互助客栈/其他 § 在本地啟用安全投票及electionadmin权限

原标题：SecurePoll elections with the electionadmin right

（我很抱歉用英语写作。请随意翻译此消息。）

Hello! My name is Joe Sutherland and I'm on the Trust and Safety team at the Wikimedia Foundation. In the past, your community has shown interest in holding elections with SecurePoll — perhaps you already have through votewiki. We are now looking into making this available to local communities to run elections themselves. This will require the "electionadmin" right to be enabled on your project, which is a right that allows access to sensitive information.

As such, it is likely that you will need to run a Request for Comment (or similar process) to ascertain consensus for the implementation of this feature. To help guide such a discussion, we've put together a Meta-Wiki page with more information about what enabling the right will mean for your community.

If your community does discuss and decides to move forward with this, T&S would like to support you — please let us know via email ( ca@wikimedia.org ) if and when consensus is reached. Thank you!--JSutherland (WMF)（留言） 2024年10月17日 (四) 20:07 (UTC)

Wikipedia:互助客栈/其他 § WMF考虑向印度法院披露编辑身份信息，本站是否应该关站抗议

原标题为：WMF考虑向印度法院披露编辑身份信息，英维正在讨论关站抗议

参见：亚洲国际新闻诉维基媒体基金会案、Wikipedia:頁面存廢討論/記錄/2024/11/14 § 亚洲国际新闻诉维基媒体基金会案、en:Wikipedia:Community response to Asian News International vs. Wikimedia Foundation、en:Wikipedia:2024 open letter to the Wikimedia Foundation和en:Wikipedia talk:2024 open letter to the Wikimedia Foundation § Update from 14 November hearing

2024年11月14日17:29 (UTC)，也就是几个小时以前，英文维基百科用户发起民意调查，讨论是否就基金会考虑向印度法院披露编辑身份信息而闭站抗议。如果英维闭站抗议，本站是否跟随？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月14日 (四) 20:09 (UTC)

Wikipedia:互助客栈/其他 § 重启Automoderator部署讨论

於Phabricator查看
編號T367306的工單

十余月前，该讨论向社群引介了自动化反破坏Automoderator工具，然其因热度不足而无疾而终。因此，我谨引用原留言：

大家好，我的名字是Sam Walton，是管理员工具（Moderator Tools）团队的产品经理。我们正在开发一个名为Automoderator的项目，该项目让社群能够根据社群自定义的规则自动回退破坏性编辑。我们正在寻求对我们项目的意见，并有一些问题需要巡查员和管理员的参与，以帮助我们更好地理解。除了项目主页面上的概述和问题之外，我们还有两个子页面提供更具体的资讯：

如果您想研究Automoderator的准确率，并查看它在不同编辑上的表现，我们设置了一个测试流程。您可以帮助我们找到新的模式，并在Automoderator部署之前将其纳入考虑范围（译注：例如怎样改善误判问题、使用什么程度的准确率（cution levels）比较好）。 评估计划是用来确定Automoderator是否实现目标且不会产生负面影响的计划初稿。如果您对我们收集的数据或制定的指标有任何想法，那么您可以在这里分享！

如果您对Automoderator有任何疑问，或者您的社群是否想要使用这个工具，请告诉我！
— User:Samwalton9_(WMF)

还请社群评估该工具部署之可能性及价值为荷。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月18日 (三) 19:45 (UTC)

Wikipedia:互助客栈/其他 § 编辑提示已建设完毕，现提议将内容同步到首页“每日提示”版块展示

经过Tisscherry君最近一段时间的不懈努力，Wikipedia:提示的所有每日提示内容已经建设完成（终于完成了一个天坑orz）。有鉴于此，如Wikipedia:每日提示维护小组#任务所述，现提议将“提示”内容同步到首页“每日提示”版块更新，特此征求社群意见。--Jeffchu2014（留言） 2024年12月19日 (四) 10:43 (UTC)

再修封鎖及禁制方針

@路西法人：抱歉，讓您久等了；感謝您整理及草擬方針的努力，使條文變得沒有那麼雜亂。 -- 月都 ※ 2023年5月17日 (三) 16:29 (UTC)

(＋)贊成：Special:Diff/76271880，如果給予新的理由或提議，應該可以重提過去的討論。 -- 月都 ※ 2023年5月17日 (三) 16:29 (UTC)

(～)補充：傀儡是有可能互相模仿，CU外不能100%肯定與主帳號的關係，其後的中維破壞者多數已被鴨子封掉，社群是否掌握事情的全貌。 -- 月都 ※ 2023年6月3日 (六) 16:32 (UTC)

再修封鎖方針

局部通過。其餘部分顯然無共識採納。--路西法人 2023年10月2日 (一) 00:54 (UTC)

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

---

已更改提案；如有意見，歡迎在框內提出。 -- 月都 ※ 2023年6月28日 (三) 23:40 (UTC)

---

現行條文 管理員應當在執行封鎖前瞭解情況，並必須解釋並佐證其執行的封鎖。封鎖應具有威慑作用，以防止維基百科受破壞及擾亂，阻止當前持續的破壞行為，並避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。 封鎖僅可用於組織維基百科收到破壞或擾亂，而絕非「懲罰」用戶之用；封鎖不可用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖。一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

提議條文 管理員應當在執行封鎖前瞭解情況，並必須解釋並佐證其執行的封鎖。封鎖是預防性措施，避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。 封鎖僅可用於阻止維基百科受到破壞或擾亂，而絕非「懲罰」用戶之用；封鎖不可用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖。一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

• 某種程度上，路西法人是說對了，最終還是為了阻止再犯，意義是確實存在：阻嚇或嚇阻是指使人害怕而停止某種行為，威懾是指使用封鎖來讓人恐懼屈服。
• Deter，尤其是指出阻止的方法，既可解為做某事將有壞結果的威脅；也可解為使某人難以做某些事情，對於破壞者設置自動封鎖，技術上阻止24小時內繼續編輯，事實上禁制時段視為不允許繼續編輯。

Google Translate：

• 阻嚇 ⇒ deter
• 嚇阻 ⇒ deter
• 威懾 ⇒ deterrence
• deter ⇒ 阻止／嚇住／威懾
• deterrence ⇒ 威懾／妨礙物

• 從2021年2月2日起，通用行為準則（UCoC）屬於維基媒體方針：任何維基媒體項目的當地方針不得規避／削弱／忽視此方針。

參見UCoC章節3.2

當某人實際上或被認為具有權力／特殊權限／影響力的時候，對別人採取不尊重／殘酷／暴力行為，就會構成濫用職權。在維基媒體的情境，它可能以辱罵或心理虐待的形式出現、以及可能與騷擾的部分重疊。

• 公務、官方和工作人員濫用職權：獲委任的公務人員、維基媒體基金會或分支的官方和工作人員，利用權威／知識／資源，以恐嚇或威脅別人。
• 濫用資歷和權勢：利用自己的職位或名譽來恐嚇他人。我們希望在運動中具有豐富經驗和權勢的人表現得格外謹慎，因為他們的敵對言論可能會帶來意想不到的強烈反應。具有社群權威的人，擁有被視為可靠的特殊權限，不應濫用此權限來攻擊反對者。
• 心理操縱：惡意地使某人懷疑自己的知覺／感受／理解，以贏得辯論或強迫某人按照自己的方式行事。

• LTA：原因不在於罪大惡極，如何製造寒蟬效應，而是數個月來發生同類的事情，短期內較大可能繼續破壞；不管一個人，還是一群人，只要通過鴨子測試，明顯的模仿或分身均可被封鎖。
• 危險性：防止他們威脅用户的安全。
• 嚇阻理論，我認為詞彙常用於刑罰，透過嚴懲他們來殺雞儆猴；設置較長的封鎖時間，因為較短的封鎖時間，不足以防止同類行為。
• 維基百科的警告訊息，起初是用於促進溝通協作，鼓勵有成效或和睦相處的行為；指明用戶可能會被封鎖，目標不在於把貢獻者嚇跑，讓他們有心理準備，預告是副作用較小的方案。

-- 月都 ※ 2023年5月17日 (三) 23:24 (UTC)

(－)強烈反对以上觀點：

1. UCoC明顯不阻止依照方針指引作出防止破壞的嚇阻性封鎖，顯然不屬於「辱罵」、「心理虐待」、「騷擾」、「濫用職權」、「濫用資歷和權勢」、「心理操縱」任何一點，您引用了卻完全沒有說明如何違反了。請停止過度詮釋UCoC。
2. 「我認為詞彙常用於刑罰」不代表詞彙就只能用於刑罰。
3. 封鎖方針指明封鎖應具有嚇阻性質跟警告訊息用什麼語調完全無關。

請你說話不要一塊一塊，「設定較長的封鎖時間，因為較短的封鎖時間，不足以防止同類行為」連句子都稱不上，我讀你的留言讀得很辛苦。--路西法人 2023年5月18日 (四) 02:25 (UTC)

• 我想說的是阻嚇或威懾，不認為是一個較好的詞彙，上方留言是我的重新翻譯版本，意義上相對接近於英文版本。
• 我認為阻止一詞可以應對所有情況，LTA怎麼嚇他們也不肯離開，根本就不感到害怕。
• 76937184/76937767，回應關於警告訊息的部分。

-- 月都 ※ 2023年6月3日 (六) 16:32 (UTC)

(！)意見：請問何謂「預防性措施」呢？--Kriz Ju（留言） 2023年5月19日 (五) 21:00 (UTC)

預防性是指防止可能發生的事情。 -- 月都（補簽）2023年5月28日 (日) 00:12 (UTC)

(－)反对：可能發生的事情是指什麼？機率和可能性如何評估呢？什麼條件可以被認為會發生何事？難以定義和評估。以此看來，個人反對。封禁不是用來消滅所有疑慮和可能性的，要這樣說，把所有人都封禁自然也不會有破壞。下次請記得簽名。--Kriz Ju（留言） 2023年5月30日 (二) 16:35 (UTC)

當時趕着寫，所以漏簽了；我認為您說的蠻有道理，預測總會有不準確。 -- 月都 ※ 2023年6月3日 (六) 16:32 (UTC)

現行條文 防止擾亂 主页面：維基百科:擾亂性編輯 管理員可因用戶作出不適合維基百科文明協作氛圍或影響其他參與者協作共建百科全書的擾亂行為而實施封鎖，其中包括但不限於以下屬嚴重擾亂的行為： 蓄意破坏； 游戏维基规则； 為闡述觀點而作出擾亂維基百科的行為； 骚扰或其他不文明行为； 打编辑战，尤其違反回退不过三原则者； 發佈广告宣传及垃圾內容； 蓄意觸發過濾器； 違反方針與指引，尤其濫用多個帳號；及 試圖透過維基百科程序外的行動脅迫其他用戶，不論有關行動在站內或站外進行。 在一般情況下，用戶在首次被封鎖前會收到數次警告，但執行封鎖時仍應當在被封鎖用戶的對話頁提供適當說明或理據以減少爭議；再犯者在被重新封鎖前可能不需再次警告。 純粹擾亂 以下帳號均具有明顯擾亂維基百科的可能性，可在無警告的情況下被封鎖（一般為不限期封鎖）： 顯然不是在建設百科全書的用戶； 根據貢獻紀錄而判定為僅用作宣傳特定事物（包括人物、公司、產品、服務和組織）的用戶帳號（詳細請參閱維基百科:利益衝突和維基百科:廣告）； 不適當的用戶名； 登入密碼被公布或在一個團體中分享的共用帳號； 未經審核批准或豁免審核運行，或疑似故障的機器人。

提議條文 防止擾亂 主页面：維基百科:擾亂性編輯 管理員可因用戶作出不適合維基百科文明協作氛圍或影響其他參與者協作共建百科全書的擾亂行為而實施封鎖，其中包括但不限於以下屬嚴重擾亂的行為： 蓄意破坏； 游戏维基规则； 為闡述觀點而作出擾亂維基百科的行為； 骚扰或其他不文明行为； 打编辑战，尤其違反回退不过三原则者； 發佈广告宣传及垃圾內容； 蓄意觸發過濾器； 違反方針與指引，尤其濫用多個帳號； 顯然不是在建設百科全書；及 試圖透過維基百科程序外的行動脅迫其他用戶，不論有關行動在站內或站外進行。 在一般情況下，用戶在首次被封鎖前會收到數次警告，但執行封鎖時仍應當在被封鎖用戶的對話頁提供適當說明或理據以減少爭議；再犯者在被重新封鎖前可能不需再次警告。 純粹擾亂 以下帳號均具有明顯擾亂維基百科的可能性，可在無警告的情況下被不限期封鎖： 只用於破壞的賬號； 根據貢獻紀錄而判定為僅用作宣傳特定事物（包括人物、公司、產品、服務和組織）的用戶帳號（詳細請參閱維基百科:利益衝突和維基百科:廣告）； 不適當的用戶名； 登入密碼被公布或在一個團體中分享的共用帳號； 未經審核批准或豁免審核運行，或疑似故障的機器人。

顯然不是在建設百科全書，涵蓋範圍較廣，英維沒有補充，只說是它是常使用的原因，所以提議修改位置；純破壞用户，常見程度較高。 -- 月都 ※ 2023年5月17日 (三) 23:33 (UTC)

如果是移動條文而不是整個NOTHERE刪除就可以。另外可在無警告的情況下被予以不限期封鎖。--路西法人 2023年5月18日 (四) 02:27 (UTC)

現行條文已被修改；如有意見，歡迎在框內提出。 -- 月都 ※ 2023年7月17日 (一) 23:23 (UTC)

---

原提議條文 管理員應當在執行封鎖前瞭解情況，並必須解釋並佐證其執行的封鎖。封鎖是預防性措施，避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。 封鎖僅可用於阻止維基百科受到破壞或擾亂，而絕非「懲罰」用戶之用；封鎖不可用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖。一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

新提議條文 管理員應當在執行封鎖前瞭解情況，並必須解釋並佐證其執行的封鎖。封鎖僅可用於阻止維基百科受到破壞或擾亂，避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。 封鎖不可用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖。一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

以上。 -- 月都 ※ 2023年6月3日 (六) 16:32 (UTC)

( ! ) 將於七天後公示：如有意見，歡迎在下方提出。 -- 月都 ※ 2023年6月18日 (日) 23:39 (UTC)

您移除「嚇阻」我就繼續(－)反对，封鎖必須同時有強烈的嚇阻及教育意識，缺乏任何一個作用均不可；阻止當前及未來擾亂行為正是嚇阻。且閣下此部分修訂方式極具誤導性，「原提議條文」部分可讓人以為是現今方針條文，以致他人沒看清就不知道什麼條文被移除了。--路西法人 2023年6月19日 (一) 02:00 (UTC)

首先謝謝您提出意見，我明白您維護維基百科的善意；然而很抱歉地告訴您一個壞消息：當前仍然沒有採納您的提議，具體原因請見下方。 -- 月都 ※ 2023年6月28日 (三) 23:40 (UTC)

現行條文 管理員應當在執行封鎖前瞭解情況，並必須解釋並佐證其執行的封鎖。封鎖應具有威慑作用，以防止維基百科受破壞及擾亂，阻止當前持續的破壞行為，並避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。 封鎖僅可用於組織維基百科收到破壞或擾亂，而絕非「懲罰」用戶之用；封鎖不可用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖。一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

提議條文 管理員應當在執行封鎖前瞭解情況，並必須解釋並佐證其執行的封鎖。封鎖只可用於阻止維基百科受到破壞或擾亂，避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。 封鎖不可用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖。一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

➕️ 嚇阻的贊成理由：對於累次被封鎖的維基人來說，設置較長封鎖時間的原因是較短封鎖時間不足以阻止同類行為。
➖️ 嚇阻的反對理由：對於首次被封鎖的維基人來說，設置較長封鎖時間可能製造恐慌，被封鎖者的情緒變得不穩定，因而做出激進行為。

---

➕️ 嚇阻的贊成理由：對於曾經建設維基百科的參與者，他們會擔心封鎖帶來的後果，那就是被禁止編輯維基百科，有助於打消他們擾亂維基百科的念頭。

➖️ 嚇阻的反對理由：對於持續破壞維基百科的參與者，他們會無視封鎖帶來的後果，任何禁制是家常便飯，自動封鎖過期後繼續搗蛋，相信其他方法不能阻止破壞行為，威嚇可能讓他們變得雀躍。

---

➕️ 嚇阻的贊成理由：使用封鎖來讓人知道不可以擾亂維基百科，因此被視為有效的做法。

➖️ 嚇阻的反對理由：教育用户可以使用提醒的方法，禮貌地指出您認為不妥當的地方。

---

👤 月都的綜合意見：我認為阻止一詞能夠全方位應對所有情況，任何做法都是圍繞着阻止的中心；此提案以討論的理據作為主要考量，選擇較為穩妥的方針條文。 -- 月都 ※ 2023年6月28日 (三) 23:40 (UTC)

仍然(－)反对，一日移除「deter嚇阻」一意而只剩「stop/block阻止」就仍然是與英維不一致（封鎖的目的必定是一致）且剝奪了一定意思。還是那句，任何移除「嚇阻」一詞而沒有適當同義詞取代的提案就會無限期反對。--路西法人 2023年7月1日 (六) 07:26 (UTC)

LuciferianThomas所言有理。我甚至覺得這部分完全沒必要修改，我建議提案人不要繼續浪費時間在這部分上。Sanmosa _{Акум орь ничодатэ, кроеште-ць алтэ соарте} 2023年7月4日 (二) 16:29 (UTC)

我會說是熱誠，大家都心繫維基百科；至於不要繼續浪費時間，向您說不好意思，因為我辜負您的期望沒有做到。 -- 月都 ※ 2023年7月15日 (六) 00:01 (UTC)

1. 回應Special:Diff/76259549，嚇阻理論的英文版本是Deterrence_(penology)，Penology的中文版本是刑罰學；這裏的方針以中文為準，deter／stop／block的翻譯只供參考。

回應Special:Diff/77282709，即便不代表詞彙只能用於刑罰，嚇阻一詞帶有讓人害怕的意思，最終目標是阻止某人做出擾亂維基百科的行為；威懾一詞只有讓人恐懼屈服的意思。

1. 修訂位於名為「原則」的章節，這裏的原則是指所有封鎖的基本準則，如果繼續保留嚇阻／威懾的相關同義詞，那就是說基本上封鎖必須有讓人害怕／恐懼／屈服的效果，但有可能使得被封鎖者感到惶悚不安，再加上被封鎖本身帶來不愉快情緒，因而造成混亂失控不是奇怪現象。
2. 雖然您和我都希望維基百科不會變差，但是經過綜合考量後，我認為需要剝奪在條文裏嚇阻或威懾的意思。

-- 月都 ※ 2023年7月15日 (六) 00:01 (UTC)

扭曲原意不可取。Sanmosa _{In vain} 2023年7月15日 (六) 00:11 (UTC)

您說的有道理。 -- 月都 ※ 2023年7月17日 (一) 23:23 (UTC)

您繼續吧，我繼續維持我的反對意見。反正又不是只有我反對您。--路西法人 2023年7月15日 (六) 01:41 (UTC)

就算您反對，還是希望您同意。 -- 月都 ※ 2023年7月17日 (一) 23:23 (UTC)

現行條文 防止擾亂 主页面：維基百科:擾亂性編輯 管理員可因用戶作出不適合維基百科文明協作氛圍或影響其他參與者協作共建百科全書的擾亂行為而實施封鎖，其中包括但不限於以下屬嚴重擾亂的行為： 蓄意破坏； 游戏维基规则； 為闡述觀點而作出擾亂維基百科的行為； 骚扰或其他不文明行为； 打编辑战，尤其違反回退不过三原则者； 發佈广告宣传及垃圾內容； 蓄意觸發過濾器； 違反方針與指引，尤其濫用多個帳號；及 試圖透過維基百科程序外的行動脅迫其他用戶，不論有關行動在站內或站外進行。 在一般情況下，用戶在首次被封鎖前會收到數次警告，但執行封鎖時仍應當在被封鎖用戶的對話頁提供適當說明或理據以減少爭議；再犯者在被重新封鎖前可能不需再次警告。 純粹擾亂 以下帳號均具有明顯擾亂維基百科的可能性，可在無警告的情況下被封鎖（一般為不限期封鎖）： 顯然不是在建設百科全書的用戶； 根據貢獻紀錄而判定為僅用作宣傳特定事物（包括人物、公司、產品、服務和組織）的用戶帳號（詳細請參閱維基百科:利益衝突和維基百科:廣告）； 不適當的用戶名； 登入密碼被公布或在一個團體中分享的共用帳號； 未經審核批准或豁免審核運行，或疑似故障的機器人。

提議條文 防止擾亂 主页面：維基百科:擾亂性編輯 管理員可因用戶作出不適合維基百科文明協作氛圍或影響其他參與者協作共建百科全書的擾亂行為而實施封鎖，其中包括但不限於以下屬嚴重擾亂的行為： 蓄意破坏； 游戏维基规则； 為闡述觀點而作出擾亂維基百科的行為； 骚扰或其他不文明行为； 打编辑战，尤其違反回退不过三原则者； 發佈广告宣传及垃圾內容； 蓄意觸發過濾器； 違反方針與指引，尤其濫用多個帳號； 顯然不是在建設百科全書；及 試圖透過維基百科程序外的行動脅迫其他用戶，不論有關行動在站內或站外進行。 在一般情況下，用戶在首次被封鎖前會收到數次警告，但執行封鎖時仍應當在被封鎖用戶的對話頁提供適當說明或理據以減少爭議；再犯者在被重新封鎖前可能不需再次警告。 純粹擾亂 以下帳號均具有明顯擾亂維基百科的可能性，可在無警告的情況下予以不限期封鎖： 只用於破壞的賬號； 根據貢獻紀錄而判定為僅用作宣傳特定事物（包括人物、公司、產品、服務和組織）的用戶帳號（詳細請參閱維基百科:利益衝突和維基百科:廣告）； 不適當的用戶名； 登入密碼被公布或在一個團體中分享的共用帳號； 未經審核批准或豁免審核運行，或疑似故障的機器人。

參考路西法人的建議。 -- 月都 ※ 2023年5月28日 (日) 00:12 (UTC)

( ! ) 將於七天後公示：如有意見，歡迎在下方提出。 -- 月都 ※ 2023年6月18日 (日) 23:39 (UTC)

 公示7天：修改防止擾亂章節的提議條文。 -- 月都 ※ 2023年7月28日 (五) 16:20 (UTC)

 通過。 -- 月都 ※ 2023年8月7日 (一) 11:23 (UTC)

現行條文 管理員應當在執行封鎖前瞭解情況，並必須解釋並佐證其執行的封鎖。封鎖應具有威慑作用，以防止維基百科受破壞及擾亂，阻止當前持續的破壞行為，並避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。 封鎖僅可用於阻止維基百科收到破壞或擾亂，而絕非「懲罰」用戶之用；封鎖不可用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖。一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

提議條文 管理員應當在執行封鎖前瞭解情況，並必須解釋並佐證其執行的封鎖。封鎖只可用於阻止維基百科受到破壞或擾亂，避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。 封鎖不可用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖。一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

封鎖應具有【阻嚇／嚇阻／威懾】作用，意思是讓用户害怕後果而不做出破壞，相關詞彙傾向於懲罰的重心。為甚麼封鎖不應該有懲罰的用途？在阻止用户損害維基百科的同時，思考對用户未來建設維基百科的影響。 -- 月都 ※ 2023年7月17日 (一) 23:23 (UTC)

仍然(－)反对。你把上面討論摺疊了不代表我和Sanmosa的意見就沒了。你搬十萬次還是一樣的結果。--路西法人 2023年7月18日 (二) 17:19 (UTC)

---

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

再修禁制方針

現行條文 全站範圍禁制 全站範圍禁制褫奪在中文維基百科的一切編輯權利，被禁制人士不論使用任何帳號或IP位址均禁止在任何情況下編輯中文維基百科的任何部分，依照 § 禁制申訴規範在其用戶討論頁提出的申訴為唯一例外。全站範圍禁制可用於以下情況： 屢次繞過封鎖：全站範圍禁制在用戶主帳號被不限期封鎖，且用戶查核最少三次確認濫用多重帳號的情況自動生效。 全域鎖定：全站範圍禁制在用戶帳號於中文維基百科被不限期封鎖，且因跨維基破壞或濫用多重帳號而被全域鎖定的情況自動生效；因帳號被盜而被全域鎖定者不在此限。

提議條文 全站範圍禁制 全站範圍禁制褫奪在中文維基百科的一切編輯權利，被禁制人士不論使用任何帳號或IP位址均禁止在任何情況下編輯中文維基百科的任何部分，依照 § 禁制申訴規範在其用戶討論頁提出的申訴為唯一例外。全站範圍禁制可用於以下情況： 全域鎖定：全站範圍禁制在用戶帳號於中文維基百科被不限期封鎖，且因跨維基破壞或濫用多重帳號而被全域鎖定的情況自動生效；因帳號被盜而被全域鎖定者不在此限。

當前不允許繞過封鎖，實際上相當於禁制；若想解除可提出封鎖申訴，所以不建議提出禁制申訴。 -- 月都 ※ 2023年5月17日 (三) 23:24 (UTC)

离个题，我建议各位提案的时候在标题概括一下自己想做什么，不然存档到讨论页一排都是「建议修订xx方针」「再修xx方针」「建议修订xx方针 2」什么的 囧rz…… ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年5月18日 (四) 01:15 (UTC)

我認為您的建議是值得考慮，如果太多或重寫就會讓標題冗長；此外，本來想原話題，編輯衝突只能想新話題。 -- 月都 ※ 2023年5月28日 (日) 00:12 (UTC)

封鎖和禁制都是不允許繞過的，但封鎖是針對帳號，禁制是針對個人，所以實際上有更廣的執行度。提出的理由跟上次提案通過前已被回應的理由相同，討論過於近期，基本上是為無效論點。反而是這兩種列明狀況應走完整的社群共識解封而非單靠管理員解除，能列出來的兩個情況都可嚴重了，僅僅一個管理員的判定未必足夠。--路西法人 2023年5月18日 (四) 02:32 (UTC)

修订WP:BANEX

現行條文 在以下情況下用戶的編輯不受禁制影響： 回退非常顯而易見的嚴重破壞（如頁面被替換為不當內容）或違反生者傳記方針的內容； 作必要且符合社群規範的爭議解決，即提出對禁制本身的合理疑慮。此包括： 要求闡明禁制範圍；及 提出禁制申訴。 被禁制用戶進行其認為符合以上禁制例外情況的編輯行為，必須即時透過討論頁或編輯摘要等方式說明如何符合上述情況；如對某操作有否違反禁制有疑慮時，應要求澄清而非逕自為之。

提議條文 在以下情況下用戶的編輯不受禁制影響： 回退非常顯而易見的嚴重破壞（如頁面被替換為不當內容）或違反生者傳記方針的內容； 作必要且符合社群規範的爭議解決，例如提出對禁制本身的合理疑慮。此包括： 要求管理员对其他用户违反互动禁制的行为采取行动（但通常不能超过一次，且应仅提及违规事实）；及 要求闡明禁制範圍；及 提出禁制申訴。 被禁制用戶進行其認為符合以上禁制例外情況的編輯行為，应该即時透過討論頁或編輯摘要等方式說明如何符合上述情況；如對某操作有否違反禁制有疑慮時，應要求澄清，而非逕自為之。

註釋

看了WP:VPO的相关讨论，我认为有必要修改禁制方针，使方针更合理。桐生ここ★[讨论] 2023年8月16日 (三) 16:02 (UTC)

现行方针甚至比如互动禁制的对方如果到你的讨论页骚扰，你不能提报对方，否则就是违反禁制。新修订的方针则允许你对对方违反禁制提报一次。--桐生ここ★[讨论] 2023年8月16日 (三) 16:13 (UTC)

建议同时引入en:WP:CTBE以对应单向互动禁制时骚扰被禁制用户的情况。--Mys_721tx（留言） 2023年8月19日 (六) 17:59 (UTC)

(＋)支持。--桐生ここ★[讨论] 2023年8月24日 (四) 09:37 (UTC)

是否可以公示了？桐生ここ★[讨论] 2023年8月27日 (日) 16:08 (UTC)

Ping之前在WMLO案参与讨论的用户：@Mys 721tx、Dewadipper、Cangjie6、Mafalda4144、Longway22、Hoben7599、Sanmosa、Newbamboo、BlackShadowG、LuciferianThomas，如有打扰还请见谅。--桐生ここ★[讨论] 2023年9月5日 (二) 03:47 (UTC)

我没有意见。——Aggie Dewadipper 2023年9月5日 (二) 06:55 (UTC)

謝謝，沒有意見。但比較在意這樣WMLO君可以提前解封嗎？--Mafalda4144（留言） 2023年9月5日 (二) 08:41 (UTC)

(＋)支持，而且認為應解除User:WMLO的無理封禁，以及憑着個人對規則的極度（節刪）、反常識的離譜解讀而對User:WMLO實行無理封禁的User:Mys 721tx必須公開承認自己的錯誤並鄭重向User:WMLO道歉，否則User:Mys 721tx應當遭受彈核或濫權審判。Cangjie6（留言） 2023年9月6日 (三) 19:38 (UTC)

Mys 721tx的操作在方针上是没有问题的，有问题的是方针。--桐生ここ★[讨论] 2023年9月7日 (四) 01:18 (UTC)

已節刪非常顯然的人身攻擊，亦請閣下停止對管理員假定惡意。管理員已清晰提供理由的封鎖即非「無理」，請撤回肆意指控。一般而言是法無禁止即可行，但禁制方針本質就是相反，禁制方針未有明確容許的行為就是被禁止的（使用佈告板提高對方在本站原先並未明確容許），苗君以此判定封鎖不可能視為遊戲規則、肆意解讀方針甚至濫權，反而是按章辦事的表現；後續討論中認為可以加這個豁免是後來的社群詮釋，此亦不能改變苗君執行封鎖之時確實未有這條豁免的事實，不可能以此認為苗君濫權。--路西法人 2023年9月7日 (四) 01:23 (UTC)

依據討論頁指引，此处被折叠的发言已被認定為不合適評論並標記。原因：訴諸人身、訴諸動機、人身攻擊。--路西法人 2023年9月12日 (二) 01:51 (UTC)

第一，我在過去的討論和申述中，已論證了即是是依據目前中文維基的條文寫法，User:Mys 721tx的解讀仍然是極度違反常識與常理的、極度離譜的、極度反智的。如果依照大家對真正破壞行為及對正常詞彙的正常理解，依照正常的常識與常理，不可能出現User:Mys 721tx的解讀。User:Mys 721tx的解讀只會在不理性的、無視事情實況的、盲目地信仰喧嘩兩成敗的、無視用戶遭遇問題時以正常機制請求或要求管理員處理這基本權利的、製造出寒蟬效應的前提下，才會出現的。這種解讀若獲得執行（本事件中就是User:Mys 721tx親自執行了這種極度反常的解讀，作出無理封禁，嚴重侵害了User:WMLO應有的權利）以及獲得其他編輯的盲目認同甚至說項，只會令維基走向人治，對維基百害而無一利（除了對本身就是維基人治化的擁護者來說）。這些論述，我都有客觀的事實支持，立論過程符合邏輯，絕對不是User:LuciferianThomas現在所誣衊我、冤枉我、老屈我並藉此大興莫須有文字獄恣意胡亂刪除我有理據發言中所使用的無理藉口——所謂的人身攻擊。

第二，關於User:LuciferianThomas現在誣衊我、冤枉我、老屈我的所謂「人身攻擊」，正好我在之前的討論中就引用過維基本身的條目來說明：——關於訴諸人身：不是所有針對發言者個人的言論都屬訴諸人身謬誤。哲學家李天命认为：「其實只要沒有將品格批判當做駁論的理據，那批判就沒有犯人身攻擊的謬誤。否則的話，父母責罵子女，法庭判辭批評罪犯的操行，便全都犯上人身攻擊的謬誤了。」如果當前論題確實與對方有關，那麼並不是訴諸人身。——訴諸人身條目。而我的發言中也只是指出事實，以及提出有事實作論據且符合邏輯的立論來作出公開論證。User:LuciferianThomas曲解所謂「人身攻擊」的定義，藉此來恣意胡亂刪除我有理據發言，如果這裏仍然有絲毫理性可言，如果中文維基不是要其他用戶寒蟬化，User:LuciferianThomas應理有責任就其誣衊我、冤枉我、老屈我而向我公開道歉，並還原對我所施行的文字獄之原文。

第三，在理性討論中，User:LuciferianThomas有權不認同我的論述，有權以符合客觀事實與邏輯的立論來公開反駁我，卻不可以剝奪我依事實立論的發言權以及我免於恐懼的自由。一旦User:LuciferianThomas或其他管理員/有權者過了這條界線，剝奪我依事實立論的發言權以及我免於恐懼的自由，這就馬上不再是理性討論，而只是鬥泥漿摔交、鬥人治、鬥極權、鬥「誰大誰惡誰正確」的一場反智反理性的、曝現人性黑暗面的卑污「遊戲」。現在User:LuciferianThomas的行徑，以曲解詞義的冤罪來誣衊、冤枉、老屈我，以文字獄刪除我有客觀事實與邏輯支持的立論發言，甚至還進一步到我的用戶頁警告、恫嚇會封禁我，正好完完全全是這樣的行爲。如果User:LuciferianThomas只是沒想清楚一時衝動才這樣做，如果User:LuciferianThomas還要維護自己有理性的、不是反智、崇尚人治與極權的外表，理應把這一切悉數撤回並向我鄭重公開道歉，否則User:LuciferianThomas只是再一次親自示範了何謂「所有動物一律平等，但有些動物比其他動物更平等。」

說完，回去當回寒蟬。若要在我身上向全球網民示範中文維基是如何「所有動物一律平等，但有些動物比其他動物更平等」的話，我夫復何言。--Cangjie6（留言） 2023年9月10日 (日) 03:15 (UTC)

補充一句：在User_talk:維基百科最忠誠的反對者#封禁申訴中足以見到，即使根據未修定的原條文，不認同User:Mys 721tx的解讀與執行的，認為User:Mys 721tx的解讀是無理、執行是濫權的維基人，不只我一個，甚至不只兩三個，是有一定數量的。個別編輯/管理員/有權者以個人說法去為User:Mys 721tx荒謬的言與行怎麼文飾、怎麼護短都好，一切自然地看在地球村的睽睽眾目中。--Cangjie6（留言） 2023年9月10日 (日) 09:24 (UTC)

不反對。對第一條的修訂的意見：請善用腳註。--路西法人 2023年9月5日 (二) 04:06 (UTC)

已修改。--桐生ここ★[讨论] 2023年9月5日 (二) 04:18 (UTC)

作为原提议人表示(＋)支持。--BlackShadowG Slava Ukraini! 2023年9月10日 (日) 13:22 (UTC)

公示 7 日：自 2023年9月16日 (六) 16:02 (UTC) 开始公示，于 2023年9月23日 (六) 16:02 (UTC) 结束公示。（提醒：此公示有可能需要更新公告栏，请协助更新。公示期间如有反对意见则此公示无效。） --桐生ここ★[讨论] 2023年9月12日 (二) 11:04 (UTC)

仍然有兩個(？)疑問：

• 如果賦予其中一方「要求」的權利，是否應該同時給予另一方「自辯」的權利？以及這樣是否抵觸互動禁制的本意？
• 目前存在不通過提報頁面就能完成提報的方法，即向管理員郵件列表發送檢舉郵件，這樣是否能夠達致相同的效果？如果能，則是否應該用其替代草案中的「要求」一句？

--🎋竹生🎍 2023年9月12日 (二) 16:06 (UTC)

• 这份草案来自BlackShadowG翻译enwiki，故而我没有多做修改，实际上也有Mys 721tx所说的问题：单向互动禁制时骚扰被禁制用户，被禁制用户无法以条文的「要求管理员对其他用户违反互动禁制的行为采取行动」请求管理员采取行动，但后来我认为「作必要且符合社群規範的爭議解決，例如提出對禁制本身的合理疑慮。」这里改为“例如”允许了单向互动禁制时骚扰被禁制用户，被禁制用户请求管理员采取行动。因此的「作必要且符合社群規範的爭議解決」自然也包括自辩的权利。
• “但通常不能超过一次”限制了提报只能一次，也给了管理员根据实际情况放宽条件的权利，因此个人认为不超过一次没有抵制互动禁制本意。这里是否应该明确任何「作必要且符合社群規範的爭議解決」通常不能超过一次，提请社群讨论。
• 不是所有人都使用邮件。

--桐生ここ★[讨论] 2023年9月12日 (二) 17:10 (UTC)

可见修改案仍有模糊之处，建议在厘清"通常不能超过一次"和"应仅提及违规事实"的范围后再修改方针。-Mys_721tx（留言） 2023年9月12日 (二) 17:13 (UTC)

承蒙諸君參與討論，作爲當事人業已解封。看到此討論，容本人發表一些針對當事管理員處理行爲的意見。規則只是原則，既然只是原則，那麽就要在必要時刻依照常識行事。從此案的討論來看（无论是讨论页还是客栈），均體現出一點：即但凡具備點常規認知的管理員，就不應執行此種法條的錯誤闡釋。管理员也只能符合一般人的認知行事，進而協調社群：其中例子可見“用戶討論頁選擇性移除言論構成曲解討論”的規則，就是由管理員Xiplus做出符合社群認知的解釋后，而后所形成的良性定例修改。否則此規則若按修訂前的字面解釋，別人是有權選擇性移除的。

反觀，User:Mys 721tx是以個人的违背常理的不當解讀在傷害普通用戶權益后，把這個問題丟給社群處理；相當於其肯定法條的錯誤闡釋的同時，又在浪費社群的時間告訴他何爲“常識“。此类讼棍或扰乱性封禁本就不应被提倡，更不应免其责任。此案所引起的方針修改，我不會否認修改嘗試本身的作用，但我得說，如果“公理”必须要靠輕辱用戶的过程才能得以實現，那麽我沒有自信向周圍的人推廣這個站點。另對比目前版本方針的“封禁應當有威懾作用”的條文，也不免讓人覺得為社群感到恥辱，請問是在威懾什麽？用這種個人扭曲的反常識事物對普通用戶所作的“威懾”，我只會稱之爲暴政。请路西法人停止為暴政辯護。謝謝。——WMLO※議程表 2023年9月16日 (六) 11:02 (UTC)

WP:BANEX新草案

在以下情況下用戶的編輯不受禁制影響：

1. 回退非常顯而易見的嚴重破壞（如頁面被替換為不當內容）或違反生者傳記方針的內容；
2. 作必要且符合社群規範的爭議解決，但每件事不能超过一次；例如：
   • 请求管理员对其他用户违反互动禁制的行为采取行动；及
   • 请求管理员对其他用户违反方针指引而直接对自己造成影响的行为采取行动。
3. 提出對禁制本身的合理疑慮，此包括：
   • 要求闡明禁制範圍；及
   • 提出禁制申訴。

被禁制用戶進行其認為符合以上禁制例外情況的編輯行為，应该即時透過討論頁或編輯摘要等方式說明如何符合上述情況；如對某操作有否違反禁制有疑慮時，應要求澄清，而非逕自為之。

註釋

根据上面的意见做了调整。桐生ここ★[讨论] 2023年9月12日 (二) 18:13 (UTC)

可考虑设立标准报告模板以确保报告仅提及某一页面中有违反互动禁制之事实而完全避免提及另一用户。-Mys_721tx（留言） 2023年9月12日 (二) 18:19 (UTC)

同意。--桐生ここ★[讨论] 2023年9月12日 (二) 18:23 (UTC)

这样的模板如何：

==<nowiki/>= 請求檢視疑違反互動禁制的編輯 ===
* [[Special:Diff/00000000]]
* {{pagelinks|1=User talk:Example}}
* 违反互动禁制。
* 发现人：XXXXX

增加了一条“提及对方时应尽量以差异链接取代对方的用户名”。桐生ここ★[讨论] 2023年9月12日 (二) 18:39 (UTC)

这里征求意见：

是用

作必要且符合社群規範的爭議解決，但每件事不能超过一次；例如：

允许所有争议解决，每件事只限一次。

还是

作必要且符合社群規範的爭議解決，但每件事不能超过一次；即为：

只允许提出对方违反禁制，和自己受到对方行为的直接影响的争议解决。--桐生ここ★[讨论] 2023年9月12日 (二) 18:51 (UTC)

建議整個AN3/ANM改按事件作標題，「某某頁面編輯爭議」「User:某某行為不當」，此案所轄情況就「請求檢視疑違反互動禁制的編輯」。然後像英維那樣開分段給涉事用戶做「一次陳述」（不論是什麼情況的提報，途人有問題就再分段提出，由此可維持討論秩序，互動禁制的用戶則可避免直接回應對方，只作出自己視角的陳述。--路西法人 2023年9月14日 (四) 08:01 (UTC)

赞同，这个要另立规范AN3/ANM提报流程。--桐生ここ★[讨论] 2023年9月14日 (四) 13:14 (UTC)

(！)意見參照現有個案問題，應當重視監查條款之實際運用是否得當，認為修正條款，需按照社區爭議應對之流程、梳理本地重大爭議或非常典型之個案作為修正案一部分，輔助社區和代權人理解適用條款時需要留意之問題，並依據案情爭議程度確立擴大討論、覆核和程序檢討等機制，避免相關內容引用存在之主觀化和非公正、缺乏制衡等問題。——約克客（留言） 2023年9月13日 (三) 04:08 (UTC)

@BlackShadowG、Newbamboo：想咨询原提案人及有表达疑问用户的意见，新提案是否可行，是否应修改。桐生ここ★[讨论] 2023年9月14日 (四) 06:12 (UTC)

「但每件事不能超過一次」是否意味著雙方仍然能在同一個提報串下多次互相回應？這點需要解釋清楚。--🎋竹生🎍 2023年9月14日 (四) 15:12 (UTC)

可以增加一个词明确一下：

• 每件事不能超過一次讨论（可以发几次）
• 每件事不能超過一次陈述（只能发一次）

--桐生ここ★[讨论] 2023年9月14日 (四) 15:21 (UTC)

我希望社群能确认选择哪种版本：

作必要且符合社群規範的爭議解決，但每件事不能超过一次讨论，即为：

只能提出对方违反禁制，和自己受到对方行为的直接影响的争议解决的讨论，但可以多次回应。

或：

作必要且符合社群規範的爭議解決，但每件事不能超过一次陈述，例如：

可以提出任何争议解决，但只能作出一次陈述，不能多次回应。--桐生ここ★[讨论] 2023年9月14日 (四) 15:29 (UTC)

一點意見：

1. 作必要且符合社群規範的爭議解決，但每件事不能超过一次陳述，且應僅提及爭議本身，即為：
   • 请求管理员对其他用户违反互动禁制的行为采取行动；及
   • 请求管理员对其他用户违反方针指引而直接对自己造成影响的行为采取行动。
   • 在遭到以上二點所述之指控時為自己作出辯解，且應僅闡明自己的行為如何不違反編輯禁制。

註釋

--🎋竹生🎍 2023年9月14日 (四) 16:01 (UTC)

參考Newbamboo意見修改：

在以下情況下用戶的編輯不受禁制影響：

1. 回退非常顯而易見的嚴重破壞（如頁面被替換為不當內容）或違反生者傳記方針的內容；
2. 作必要且符合社群規範的爭議解決，但每件事不能超过一次陳述，且應僅提及爭議本身，即為：
   • 请求管理员对其他用户违反互动禁制的行为采取行动；及
   • 请求管理员对其他用户违反方针及指引而直接对自己造成影响的行为采取行动；及
   • 在遭到以上二點所述之指控時為自己作出辯解，且應僅闡明自己的行為如何不違反方針及指引。
3. 提出對禁制本身的合理疑慮，此包括：
   • 要求闡明禁制範圍；及
   • 提出禁制申訴。

被禁制用戶進行其認為符合以上禁制例外情況的編輯行為，应该即時透過討論頁或編輯摘要等方式說明如何符合上述情況；如對某操作有否違反禁制有疑慮時，應要求澄清，而非逕自為之。

註釋

公示 7 日：自 2023年9月21日 (四) 16:37 (UTC) 开始公示，于 2023年9月28日 (四) 16:37 (UTC) 结束公示。（提醒：此公示有可能需要更新公告栏，请协助更新。公示期间如有反对意见则此公示无效。） --桐生ここ★[讨论] 2023年9月14日 (四) 16:37 (UTC)

@桐生ここ：我對於目前版本不太放心。“即”字論為限定解釋，應該考慮設置不兜底條款，即以常理為基礎而非規則性的硬式。比如我在互助客棧的討論中，爲了檢討Mys 721tx的濫權言行，不可避免地提及那互動禁制用戶的名字（好了，我現在作爲互動禁制一方又在“間接提及”用戶了。根據上方“即字論”的嚴苛定義，您們是否又覺得需要被提報到管理員佈告板了？届時再增加一堆規定？再次通過輕辱用戶的過程實現公理？然後再謂之管理員“按章辦事的體現”“錯的是方針，不是管理員”之類？）施行過於嚴格的定義反而不是一件好事。所以對目前版本表示(－)強烈反对。如有必要，至少應將兩個版本（即現行的版本和@User:BlackShadowG君提供的英維譯本）一并列出得到社群傾向性共識后施行方爲佳。——WMLO※議程表 2023年9月18日 (一) 06:27 (UTC)

请参考历史讨论，有「即为」和「例如」两种版本，当时仅Newbamboo有表达意见，认为应限定为「即为」，没有其他人表达意见，因此就采取该方案公示。

请社群重新讨论并确定：

作必要且符合社群規範的爭議解決，但每件事不能超过一次陳述，且應僅提及爭議本身，即為：

还是

作必要且符合社群規範的爭議解決，但每件事不能超过一次陳述，且應僅提及爭議本身，例如：

--桐生ここ★[讨论] 2023年9月18日 (一) 09:22 (UTC)

( π )题外话：WP:IBAN的「直接或間接於本站內提及或評論另一方」的「提及」是否只代表提到该用户名。--桐生ここ★[讨论] 2023年9月18日 (一) 09:34 (UTC)

同样认为经过多次修改的版本反而不如最初翻译自英维的版本：

1. “但通常不能超过一次”变成了“每件事不能超过一次陈述”，还加上了不能增删修改陈述内容的规定，我认为这只是画蛇添足。首先中维本身在站务上就不如英维活跃，如果第一次陈述未得到社群相应，再进行陈述显然是合理的。此外，举报人在有必要的情况下也可以继续提供事件的细节，或者为其叙述增加更详细的内容，这也没有理由被禁止。直接限制只能陈述一次的做法，无异于鼓励在官僚体系下照本宣科地执行规条，这个条文明显忽略了常识的重要性。
2. “且应仅提及违规事实”变成了“且应仅提及争议本身”，这里反而把应该清晰化的语言模糊化了。“仅提及违规事实”代表着举报人只应该说明对方做出了什么违反编辑禁制的行为（例如：“A回退了我的编辑”、“A在某页面指责我的行为”），但变成“仅提及争议本身”就可以进行很广泛的解释了，可以把整起争议甚至禁制本身是怎么回事都添油加醋地解释一遍（例如：“A做过什么什么样的行为，与我的立场有什么什么样的不同，因为什么什么不当行为被禁制。现在他回退了我的编辑，这不仅违反了什么什么方针，我还相信这是受到什么什么立场的驱使，他屡教不改，我建议管理员施以不限期封禁”没错，这也半句不离争议，都是有关“争议本身”的发言），我相信这不是社群希望看到的。
3. 还有上方WMLO君指出的，把“例如”变成“即为”，我实在看不懂这样做的必要性在哪里，难道社群没有常识来辨别什么是“必要且符合社群规范的争议解决”，必须要方针来框定哪些内容属于这些情况？上方WMLO引用了Wikipedia:規則只是原則这篇论述，我觉得很应景，摘取其中一句话：“在任何情況下，方針指引都不是用於精確定義原則。閱讀這些方針指引頁時，應該使用常識來理解，必要時忽略這些規則。”，显然这样的条文已经是把常识的重要性给忽略了。
4. 请求管理员对其他用户违反方针及指引而直接对自己造成影响的行为采取行动；及、在遭到以上二点所述之指控时为自己作出辩解，且应仅阐明自己的行为如何不违反方针及指引。，先不提“其他用户违反互动禁制的行为”/“其他用户违反方针及指引而直接对自己造成影响的行为”有多少差别，还专门给出一条可以自辩的规定……嗯，我更加认为这个条文在默认社群没有常识来判断何为“必要且符合社群规范的争议解决”了，还需要明确框定这种情况。

综上，我必须明确(－)反对这个版本的条文，并强烈请求回滚至最初的英译条文。目前的版本做出过于严格和死板的规定，简直是在鼓励照本宣科地执行规条，完全忽略在解决问题时常识的重要性。再次引用这句话：“在任何情況下，方針指引都不是用於精確定義原則。閱讀這些方針指引頁時，應該使用常識來理解，必要時忽略這些規則。”--BlackShadowG Slava Ukraini! 2023年9月18日 (一) 13:50 (UTC)

Ping之前参与讨论的用户：@Mys 721tx、Dewadipper、Cangjie6、Mafalda4144、Newbamboo、LuciferianThomas，如有打扰请见谅。--桐生ここ★[讨论] 2023年9月18日 (一) 18:16 (UTC)

補Ping @Longway22。--桐生ここ★[讨论] 2023年9月18日 (一) 18:35 (UTC)

謝謝black閣下之總結陳詞，認為確實需要檢討很多方面之問題，社區在該案應當考慮以上因素和見解。--約克客（留言） 2023年9月19日 (二) 02:05 (UTC)

一、使用「即為」是為了防止規則過於模糊而遭到隨意解釋，若真有不得已的情況，那上面提到的IAR已經足以彌補，故(－)反对將即為改成例如。

二、若每件事可以進行多次陳述，無異於讓雙方可以繼續進行無意義互動，完全違背互動禁制的本意，故(－)強烈反对允許進行多次陳述和增修。--🎋竹生🎍 2023年9月19日 (二) 04:42 (UTC)

感謝BlackShadowG君及Longway22閣下的補充意見，而本人的意見已經在上方陳述過，不在此贅述。(＋)支持BlackShadowG提供的英維譯本。至於那个嚴苛限定的條文，説的未免狠一點，這只會醖釀出一群法匠阻礙社群公理之實現。——WMLO※議程表 2023年9月19日 (二) 05:08 (UTC)

「作必要且符合社群规范的争议解决」一條下似乎為解決互動禁制的問題而設立，但對於其他類型的禁制是否適用？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月20日 (三) 02:49 (UTC)

另，提報對方可以强制規定用固定連結（在功能區有），或者d:zh:U:。但需不需要第三人通知對方？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月23日 (六) 07:45 (UTC)

我们先确认一点，就是现行方针的确需要修正，确保可以向管理员提报不违反禁制。具体方针细节的争议，双方是否可以提供一个折中方案？桐生ここ★[讨论] 2023年9月20日 (三) 04:32 (UTC)

事實可能需要修正之關鍵不是條文框架，而應當是約束代權人或其他關聯代權行為之中，所顯而易見違背基本操守、違背公義等等之活動或表徵，

而且同時應考慮提報機制本身是否具備充足因素保證爭議不被利益關聯第三方訴諸妨害，如利用機制漏洞及社區實際局限等，而反复、重複提報所有與單一方相左者：或僅有單純與單一方就個案存有不統一意見者，或未有支持單一方訴諸不友好對待與其衝突方者，或與單一方有所衝突方者間達成共識者等等。

另外，如該議案提交中典型之施行禁制爭議個案可見，本身背景亦屬本地實際長期未能有效處理諸多個案問題之爭議一環，重點本身如社區資源可見，是禁制之賦予，即為彌補社區自治力等無法有效應對爭議或系統問題，所採用之折中手段。而有關禁制關聯衍生之問題，如個案可見，即為受禁制表面限制下，基於施行折中方案前同一類本地未能解決問題因素，而重新提交之情況，

如此應檢視相關既定已形成所謂折中方案本身，是否仍可維持有效避免擴大維基本地局限問題。

如果僅就個案情況而言，必須關注之因素是折中替代處理實際採編活動爭議之，單純禁制發生採編活動爭議是否具備有效性、建設性，和其他效益影響等疊加，必要是適用重新檢討禁制施行程序（替代直接梳理採編爭議或其他方案），而非仍著眼於完善表面文章治理。--約克客（留言） 2023年9月21日 (四) 03:59 (UTC)

基本上反對這項修訂。修補漏洞然後製造另一個漏洞。

無可否認，確實現行方針未有向受互動禁制用戶提供足夠指引，指出當對方違反互動禁制時，應該如何回應，例如電郵管理員郵件列表。

但如果因此就容許受互動禁制用戶於提報時，於站內提及及評論對方，那當其中一方違反互動禁制時，互動禁制就會即時形同虛設，隨時令爭議再起。

當要發出互動禁制，即是雙方爭議已經去到極度白熱化，絕對不應該允許在站內有任何一絲互動之可能。

以上。--J.Wong 2023年9月23日 (六) 10:20 (UTC)

我仍不改變「不反對」修訂之立場，但望社群複檢當時社群引入IBAN時的討論，考慮當初不將提報對方違反禁制列入可接受行為範圍內的原因是否仍然適用。另，在讀完當初引入IBAN的討論後，更確定WMLO等人聲稱互相提報符合方針一說沒有社群共識依據，本就未曾列入方針且有共識不採納，單純就是為了個別人士利益而扭曲方針，行為不可取。不否認社群在這段時間內達成新的初步共識，但此前絕無方針依據，請諸位堅稱管理員操作「違反常識」的用戶考量當初發言是否同時「違反有原因而通過的共識」。--路西法人 2023年9月23日 (六) 14:34 (UTC)

由于目前已有依据此初步共识的“判例”，故争议点在于选择：

1. BlackShadowG版（英文维基原版）
2. Newbamboo版（限制提报陈述一次）
3. Wong128hk版（维持现行方针并说明允许EMAIL）

--桐生ここ★[讨论] 2023年9月23日 (六) 14:51 (UTC)

Wong128hk版的方案和我上一次討論時提出的差不多，應該明確指引一條不會違反編輯禁制的渠道，但我絕對無法接受允許進行多次提報、陳述或增修的方案，原因和Wong128hk閣下在引入互動禁制方針時和現在的見解相同。另外就之前引起爭議的事件而言，雙方編輯禁制的原因就是因為在管理員布告版進行的無意義互動，那麽繼續試圖在管理員布告版解決新的爭議無異於緣木求魚，故我認為之前引起爭議的事件不足以作為考慮本修訂案的依據。--🎋竹生🎍 2023年9月24日 (日) 06:28 (UTC)

想再補充一點，請諸位好好想想為什麼要有「互動禁制」，就是社群或管理員相信用戶與受禁制者或受禁者與受禁者之間，已經無可能單靠正常交流討論去排解紛爭。既然已經無法透過討論去排解紛爭，還提供討論空間或要求透過妥協、討論去訂定如何理解及執行方針，無異於緣木求魚，為執行添加大量障礙。所以條文必須極之清晰，是不可逾越的紅線，不應該存在任何討論空間。要照本宣科就照本宣科。--J.Wong 2023年9月24日 (日) 07:47 (UTC)

禁制方針本就應該是「法無容許即禁止」，不容得「我覺得這句應該這樣解讀」的說法，這次爭議中顯然很多人都無視了這條基本原則。當初修訂禁制方針本就該將「禁制的意義」一段維持與英維相同的「禁制就是禁制」（ban means ban）。--路西法人 2023年10月2日 (一) 03:08 (UTC)

引入en:WP:CTBE

節錄Wikipedia:互助客栈/方针#修订WP:BANEX建議引入CTBE的相關留言。--路西法人 2023年10月2日 (一) 03:16 (UTC)

建议同时引入en:WP:CTBE以对应单向互动禁制时骚扰被禁制用户的情况。--Mys_721tx（留言） 2023年8月19日 (六) 17:59 (UTC)

(＋)支持。--桐生ここ★[讨论] 2023年8月24日 (四) 09:37 (UTC)

见上方，提请讨论。桐生ここ★[讨论] 2023年8月27日 (日) 16:08 (UTC)

原則上支持，但您維需先排除用戶使用原就中性的詞批評他人就被指控人身攻擊的思想。建議先把什麼才構成人身攻擊釐清再說。--路西法人 2023年8月27日 (日) 16:55 (UTC)

佔位防存檔。--路西法人 2023年10月2日 (一) 00:58 (UTC)

似乎沒什麼問題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年10月2日 (一) 02:10 (UTC)

過濾器助理組的設立

通過：

提案無人反對。規則條文將先行修改。Sanmosa _{віки-віків} 2023年8月17日 (四) 00:40 (UTC)

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

---

就其他議題，我的意見是：

二、此前本站社群的共識應當是在設立具有相關權限之專門職務以後撤銷回退員過濾器查閱權，而非直接予以撤銷；我認為截至目前為止，相關共識沒有改變。未繼續推動設立專門職務的討論是社群的怠惰（或不可抗力），不太算是尋求繞過共識直接撤銷權限的理由。請先考慮繼續推動設立具有相關權限之專門職務以實踐社群最初共識，若這次討論尚無進展，再考慮直接撤銷權限，亦並非難事。

三、今年一月互助客棧曾有相關討論，社群共識大抵支持賦予巡查豁免者不帶重新導向移動權限。我不反對。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年7月6日 (四) 15:30 (UTC)

我認為私隱問題大於一切，不能因為“反破壞需求”而無視私隱問題，而當時的社群共識顯然包含了“出於私隱考量，回退員的隱藏過濾器源碼閱讀權應予剝奪”這點。社群無能力設置具隱藏過濾器源碼閱讀權的用戶權限組不是無視隱藏過濾器源碼閱讀權帶來的私隱問題的理由，而我對私隱問題的重視也是我在OA2021前有一定程度上的遠見地早早提出管理人員上任選舉須應用安全投票的原因。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月6日 (四) 22:55 (UTC)

另外回退员移除查看私有过滤器设置的后续是考虑设一个新组来承载相应权限，但新组考虑没有？既然提案者这么上心，或者可以先考虑推进新组的建立先？（当然也可以说，社群某些编辑有点乌合之众，这样半吊子的决定都能想得出来，比鸭乸还不靠谱）——Sakamotosan路过围观 | 避免做作，免敬 2023年7月7日 (五) 01:16 (UTC)

我上心的只有私隱問題，「反破壞需求」甚麼的我不關心。我當時一知道隱藏過濾器源碼閱讀權有私隱問題後，就立即自主請辭回退員了。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月7日 (五) 01:34 (UTC)

此前本站社群的共識應當是在設立具有相關權限之專門職務以後撤銷回退員過濾器查閱權，而非直接予以撤銷；我認為截至目前為止，相關共識沒有改變。未繼續推動設立專門職務的討論是社群的怠惰（或不可抗力），不太算是尋求繞過共識直接撤銷權限的理由。同Ericliu1912，與原有撤銷過濾器查閱權限的共識衝突。--路西法人 2023年7月7日 (五) 01:51 (UTC)

見我此前在2023年7月6日 (四) 22:55 (UTC)的留言。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月7日 (五) 05:46 (UTC)

回退员拔掉查看私有过滤器的必要后续是建新组承载，如果新组搞不定，那要么无视掉这个蹩脚的共识，要么尽快推进新组的创建，而不是直接拔了算了。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月7日 (五) 01:57 (UTC)

我認為私隱問題為大，「反破壞需求」在私隱問題面前只是虛無飄渺的東西。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月7日 (五) 05:49 (UTC)

贊同提議2、3，1那個拔不拔倒是無所謂，不過就如上面提到的，提議2大概還要搭配新建的Wikipedia:過濾器助理群組，但目前尚未通過。--冥王歐西里斯（留言） 2023年7月7日 (五) 03:02 (UTC)

我记得之前回退员没夺权的原因之一是没有设立承接该权限的用户组，可能会严重影响反破坏，建议讨论时考虑到这点。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年7月7日 (五) 15:26 (UTC)

如果社群對於所謂「隱私」問題足夠重視，相關議題就不會一路拖延，以至於提案人還要出此下策，尋求直接撤銷相關權限。我想這次也是一個提醒，社群是時候徹底解決此前討論之遺緒。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年7月7日 (五) 15:29 (UTC)

我倒是想知道這“可能會嚴重影響反破壞”到底有多“嚴重”，我覺得這説法完全是在誇大其詞，難不成中文維基百科在2012年到2017年間反破壞的工作真的受毀滅性的影響嗎？我覺得不是。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月7日 (五) 16:30 (UTC)

大家都來齊了，實在太好。所以User:Temp3600/過濾器助理到底還有沒有爭議需要處理?還是已經可以直接公示?--Temp3600（留言） 2023年7月9日 (日) 18:42 (UTC)]

我回看了一下之前的討論，我實在是看不出任何就當時的提案的合理反對意見。我覺得要是你真想公示的話，連著我的提案2打包一起也可以。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 01:09 (UTC)

我覺得是可以直接公示了，至於要不要跟上面回退員的權限組合修正案一起公示倒是無所謂。--冥王歐西里斯（留言） 2023年7月10日 (一) 03:20 (UTC)

此案通過即分拆回退和過濾器閱覽權直接生效（依過往共識），上方提案二連公示都用不著（事實性修訂）。--路西法人 2023年7月10日 (一) 03:23 (UTC)

@LuciferianThomas：但WP:回退功能的條文需要修改，所以實際上仍然需要公示，頂多就是讓WP:回退功能的條文修改跟User:Temp3600/過濾器助理打包公示而已。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 03:25 (UTC)

簡單啊。等技術上過濾器助理設立、回退員正式移除過濾器檢視權（已有共識）時，「回退員沒有過濾器檢閱權」才正式生效，此時「原有但不再有過濾器檢閱權」的修改即符合共識方針下的事實性修訂，跟中維2018年被剝奪用戶查核權後用戶查核方針事實性修訂（Special:Diff/48893035）類似。--路西法人 2023年7月10日 (一) 03:41 (UTC)

中文維基百科2018年被剝奪用戶查核權的事情是WMF進行的，而WMF的決定是不受社群限制的，這跟需要社群共識才能設立過濾器助理組的情況不同。而且，User:Temp3600/過濾器助理之前的公示也沒有通過，讓WP:回退功能的條文修改跟User:Temp3600/過濾器助理打包公示其實是符合你説的做法的。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 03:53 (UTC)

反正多公示一案也不成什麼問題（ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年7月10日 (一) 09:20 (UTC)

@LuciferianThomas。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 09:25 (UTC)

純粹覺得沒必要。你們喜歡就行，反正又不是錯。--路西法人 2023年7月10日 (一) 09:41 (UTC)

考慮到我的提案2跟其他提案沒有顯著關聯，我覺得提案2其實可以分開討論。看回上方的討論，基本上反對提案2的人都只是反對單獨施行提案2，而並不反對（甚至支持）提案2與過濾器助理相關方針同時施行。既然這裏有人提到過濾器助理相關方針的事，而且反響也沒我想像中那麽差，我感覺可以將提案2與過濾器助理相關方針的提案綜合一下，因此現有以下提案：

1. 以User:Temp3600/過濾器助理的內容替換WP:過濾器助理的現有內容，並在替換後將WP:過濾器助理設為執行方針；以及
2. 修改WP:回退功能如下，以反映提案通過後回退員的私有過濾日誌閲讀權被剝奪的事實：

現行條文 权限总览 对比起一般用户，回退员可以： 快速回退最后一位用户对某一页面的编辑； 查看标记为非公开的滥用过滤器的过滤日志； 查看被标记为非公开的滥用过滤器（2022年12月，社群决定移除回退员的此权限，惟未实际执行）； 移动页面时不在原页面创建重定向； 查看未受监视的页面列表。 （……） 額外功能 自2012年6月19日起，回退員可以查閱私有防濫用過濾器的過濾日誌，可以在Special:AbuseLog搜索私有過濾器的觸發記錄（一般用戶只能顯示「觸發防濫用過濾器」，回退員可以顯示過濾器編號），亦可以檢查或閱讀有關過濾日誌的詳細資料。以上各項功能於2011年12月之前曾開放予所有自動確認用戶，但為了保障安全，已被全域禁用了。但自2017年9月6日起重新開放給回退員，使其能夠瀏覽隱密過濾器的過濾設定。

提議條文 权限总览 对比起一般用户，回退员可以： 快速回退最后一位用户对某一页面的编辑； 查看标记为非公开的滥用过滤器的过滤日志； 移动页面时不在原页面创建重定向； 查看未受监视的页面列表。 （……） 額外功能 自2012年6月19日起，回退員可以查閱私有防濫用過濾器的過濾日誌。 在Special:AbuseLog搜索私有過濾器的觸發記錄（一般用戶只能顯示「觸發防濫用過濾器」，回退員可以顯示過濾器編號）的功能於2011年12月之前曾開放予所有自動確認用戶，但為了保障安全，已被全域禁用了。回退員自2017年9月6日起曾一度重獲以上權限，但出於私隱問題，以上權限已於（權限剝奪技術上生效當日）重新被剝奪，相關權限現由管理員與過濾器助理持有。

以上，兩者應視為一整體。為方便稱呼，此綜合提案可稱為“提案2A”。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 11:00 (UTC)

@Ericliu1912、Cwek、LuciferianThomas、@S8321414、Yining Chen、魔琴、Temp3600（所有曾參與提案2及／或此處過濾器助理相關方針的討論的人）。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 11:05 (UTC)

(？)疑問：为何此权限对编辑数的要求比回退员还要少二分之一？--Yichen Ding（留言|主账户） 2023年7月10日 (一) 14:30 (UTC)

@Temp3600：確實有些詭異。要不要調高一下？調高到1000或2000都是不錯的選擇。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 14:32 (UTC)

原意是讓"在其他維基項目上的管理員"可以方便獲權而設的。我現在重讀，覺得改為全域1000/2000編輯次數會較合適。--Temp3600（留言） 2023年7月10日 (一) 14:45 (UTC)

@Temp3600：暫時冒昧代改為“需在全域編輯1000次或以上”。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 14:50 (UTC)

看起來沒什麼問題。--冥王歐西里斯（留言） 2023年7月10日 (一) 23:51 (UTC)

所以回退員以後到底還能不能查閱私有防濫用過濾器日誌及搜尋搜索私有過濾器的觸發記錄？這好像跟下面「檢查或閱讀私有過濾日誌的詳細資料」同義？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年7月10日 (一) 12:13 (UTC)

• 這一點值得討論。我建議回復2017年9月6日前之安排。--Temp3600（留言） 2023年7月10日 (一) 14:07 (UTC)

  附議Temp3600。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 14:31 (UTC)

合理，已調整。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 14:52 (UTC)

• 話說這樣是不是仍應保持"額外功能"之稱?還是可以看日誌。--Temp3600（留言） 2023年7月10日 (一) 17:09 (UTC)

  已再調整。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 23:08 (UTC)

@Temp3600：请问“高度可信”是多高？不了解防滥用过滤器有多么隐私，可以说明一下吗？“良好账户保安操守”和“了解正则表达式”有无现存验证方法？还是只需要被提名人承诺就可以？--落花有意12138 2023年7月15日 (六) 09:21 (UTC)

為了順利交接，建議在過濾器助理方針通過後，即日接受申請，並以MMS提示現任回退員此項制度變更。現任回退員仍必須符合過濾器助理的申請條件才可獲得此新身分。回退員的相關權限則正式於方針通過一個月後移除。--Temp3600（留言） 2023年7月10日 (一) 14:12 (UTC)

附議。Sanmosa _{心不在焉，視而不見，聽而不聞，食而不知其味} 2023年7月10日 (一) 14:31 (UTC)

可以。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年7月11日 (二) 02:33 (UTC)

看起來沒什麼問題。--冥王歐西里斯（留言） 2023年7月11日 (二) 02:56 (UTC)

支持這個提案，不過我有個問題我時常會查看過濾器日誌是否有被誤封用戶，我是否可以以此為理由申請過濾器助理呢?還望解答謝謝。--~~Sid~~ 2023年7月14日 (五) 12:47 (UTC)

如果你是指查閱該項濫用日誌的詳細資料，這不算是常規目的，所以在申請理據中沒有列為常規原因。然而，你可嘗試以"其他經社群確認為有必要閱覽不公開過濾器的用戶"為理由申請。--Temp3600（留言） 2023年7月14日 (五) 13:35 (UTC)

好的謝謝解答。--~~Sid~~ 2023年7月14日 (五) 13:40 (UTC)

有一執行上的問題：參考時間不應採方針通過時間而是實際配置時間，不然方針通過一個月phab還沒過就啥也不是。--路西法人 2023年7月25日 (二) 16:41 (UTC)

@LuciferianThomas：所以我寫的是“權限剝奪技術上生效當日”。我的建議是在權限剝奪技術上生效前維持該括注，在權限剝奪技術上生效後將括注替換為生效日期。Sanmosa _{In vain} 2023年7月26日 (三) 09:48 (UTC)

是回覆Temp3600的留言，沒注意提案是否有差異。--路西法人 2023年7月26日 (三) 12:11 (UTC)

活躍度

• 我聽說有人覺得三個月的活躍度太緊了。大家覺得六個月如何?別的提議也行。--Temp3600（留言） 2023年7月13日 (四) 20:31 (UTC)

個人認為過濾器助理取得社群信任這點其實比活躍重要。因此，不如將活躍度設為6個月，但是過濾器助理的上任需要經過社群討論至少一週、取得一致共識並獲得5人以上有人事任免權者支持方可當選。同時，考慮到門檻比較高，同時界面管理員又是受到社群信賴者且也較精通技術方面的問題，可以讓不是管理員的界面管理員同時擔任當然過濾器助理。--クオン·千の海を越えて·愛おしき欠片 2023年7月13日 (四) 23:52 (UTC)

先設立了權限再説吧。Sanmosa _{In vain} 2023年7月14日 (五) 01:08 (UTC)

不是不可以，但我還是有點擔心私隱問題。另外，我們也沒太多人關注權限申請頁面，要找到5個有人事任免權的人其實有相當的難度。Sanmosa _{In vain} 2023年7月14日 (五) 01:08 (UTC)

如果當選依然是由管理員決定，那我覺得授權門檻也沒有本質上的提高，更像是簡單把回退員權限拆分掉了，和設立這個權限的初衷是減少隱私泄漏多少有些出入。更何況，現在中文維基百科很少有人持有的小權限已經太多，進一步增加這種權限本身也會使管理進一步複雜化。--クオン·千の海を越えて·愛おしき欠片 2023年7月14日 (五) 12:26 (UTC)

你都能說“現在中文維基百科很少有人持有的小權限已經太多”了，再結合“要找到5個有人事任免權的人其實有相當的難度”這點，難道你不覺得你的提議也會引致“很少有人持有的小權限”繼續出現，繼而“使管理進一步複雜化”？此外，“使管理進一步複雜化”並不是不重視私隱的理由，為了私隱問題而“複雜化”原本相對“簡單”的程序並不是自找麻煩，而是必要的覺悟。Sanmosa _{In vain} 2023年7月14日 (五) 13:43 (UTC)

@Temp3600。Sanmosa _{In vain} 2023年7月14日 (五) 16:01 (UTC)

鼓勵及時除權的安排

為了鼓勵過濾器助理在休假(指暫時不參與過濾器有關工作)時及時除權，建議為無爭議自行除權的過濾器助理復權提供方便。具體條文:

• 於"持權要求"下開設三級標題"自行凍結權限"，條文為"如過濾器助理預計自己在未來暫時無法參與過濾器事務，應及時自行除權或申請暫時解除權限。如日後希望復職，可在再次申請時注明，管理員可無須討論批准該申請。
• --Temp3600（留言） 2023年7月14日 (五) 14:00 (UTC)

(？)疑問：这样有何意义？--Yining Chen（留言|贡献） 2023年7月14日 (五) 14:26 (UTC)

我也想問這個問題。而且，要是真的要這樣做的話，這安排僅限於過濾器助理似乎也不太好。Sanmosa _{In vain} 2023年7月14日 (五) 14:30 (UTC)

@Temp3600：你要不要囘來關注一下這邊的提案？Sanmosa _{In vain} 2023年7月16日 (日) 11:51 (UTC)

@Temp3600？如果沒回應的話，那我就默認維持“三個月的活躍度”安排與不增加“鼓勵及時除權的安排”的條文了。Sanmosa _{In vain} 2023年7月26日 (三) 09:50 (UTC)

最後確認

@Temp3600？Sanmosa _{In vain} 2023年8月7日 (一) 00:28 (UTC)

現公示提案2A 7日，具體修改參見上方所示。此次公示的提案將維持「三個月的活躍度」安排，且並不增加「鼓勵及時除權的安排」的條文。Sanmosa _{In vain} 2023年8月10日 (四) 00:09 (UTC)

@Sanmosa目前的草案是6個月活躍度--銀河市長—☎️— 2023年8月10日 (四) 06:28 (UTC)

@銀河市長：已修正描述。Sanmosa _{In vain} 2023年8月10日 (四) 07:08 (UTC)

---

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

通過後處理

於Phabricator查看
編號T344398的工單

@Stang、Ericliu1912：可以報P站賦權了。Sanmosa _{віки-віків} 2023年8月17日 (四) 00:45 (UTC)

@Sanmosa：希望咱理解的没什么问题；同时您们可以做一下本地化，现在twn上这个组叫滥用过滤器助手 / 濫用過濾器協助人員，如果需要可以本地覆盖一下。 Stang^★ 2023年8月17日 (四) 04:02 (UTC)

@Stang：中文名應統一改為「過濾器助理」。Sanmosa _{віки-віків} 2023年8月17日 (四) 04:05 (UTC)

我倒是覺得應該叫做「濫用過濾器助理」，可以簡稱「過濾器助理」。另外，「濫用過濾器」就是濫用行為的過濾器，我認為「防濫用過濾器」是冗贅翻譯，也應該一起調整。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年8月17日 (四) 07:27 (UTC)

提交了一些编辑请求，等待处理 Stang^★ 2023年8月17日 (四) 08:31 (UTC)

这个组已经创建完成了，接下来是本站的一些paperwork了。 Stang^★ 2023年8月17日 (四) 08:31 (UTC)

@Stang：請問回退員的abusefilter-view-private與abusefilter-log-private權限是否已經移除？Sanmosa _{віки-віків} 2023年8月17日 (四) 13:29 (UTC)

没有啊，上面的讨论不是為了順利交接……回退員的相關權限則正式於方針通過一個月後移除么 Stang^★ 2023年8月17日 (四) 13:32 (UTC)

@Stang：啊，這點我忘了。到時社群記得要移除那些權限就是了。Sanmosa _{віки-віків} 2023年8月17日 (四) 13:47 (UTC)

怎么没人写给回退员发的信息的初稿啊， Stang^★ 2023年8月20日 (日) 15:11 (UTC)

移除權限流程與共識不同

@Stang、Sanmosa：公告和修改的條文僅移除回退員abusefilter-view-private之權限，但請求移除的則是abusefilter-log-private和abusefilter-view-private。--銀河市長—☎️— 2023年8月31日 (四) 12:54 (UTC)

當時刪漏了，現在補刪就可以。Sanmosa _{віки-віків} 2023年8月31日 (四) 12:56 (UTC)

什麼意思？是要多移除還是少移除？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年8月31日 (四) 16:21 (UTC)

說的是WP:回退功能的條文的事情，請求移除的權限仍應是abusefilter-log-private和abusefilter-view-private。Sanmosa _{віки-віків} 2023年9月1日 (五) 14:47 (UTC)

如果不在實際公示內容中，就不應該移除。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月2日 (六) 10:42 (UTC)

公示時僅有abusefilter-view-private應需重新公示？--銀河市長—☎️— 2023年9月2日 (六) 05:38 (UTC)

@Sanmosa、Stang：先留個程序性反對繼續執行移除權限，期望的權限移除未符過往公示，而公示要求的回退員通告也還沒發，pre-requisite還沒達到就反對執行「方針通過一個月後移除權限」。請重新公示。--路西法人 2023年9月3日 (日) 01:04 (UTC)

同意，以「補刪就可以」一句就帶過去也未免太隨便了。--Borschts ^™ 2023年9月27日 (三) 04:11 (UTC)

(▲)同上--銀河市長—☎️— 2023年9月3日 (日) 12:52 (UTC)

(－)反对使用“偷梁换柱”的方法一次除掉两项权限。首先，此前的多次讨论均只论证了移除abusefilter-view-private的必要性，然而此前有过明确支持保留abusefilter-log-private权限的意见。个人不认为这种事可以用“漏删”这样的理由简单略过。--Yining Chen（留言|贡献） 2023年9月10日 (日) 12:24 (UTC)

同Yining Chen，(－)反对偷梁换柱。--桐生ここ★[讨论] 2023年9月12日 (二) 03:23 (UTC)

@Sanmosa、Temp3600、Stang：請重新公示--銀河市長—☎️— 2023年9月11日 (一) 07:51 (UTC)

回退員通告沒人寫，先找個人來寫吧，我沒時間。另外，我個人高度不認可Yining Chen上方的說辭，安保問題不能以他這種態度來看待，如果單移除abusefilter-log-private而不移除abusefilter-view-private的話，這裏做的事也相當於沒有意義了。Sanmosa _{віки-віків} 2023年9月11日 (一) 09:58 (UTC)

其實是移除abusefilter-view-private。公開abusefilter-view-private確實比abusefilter-log-private更有風險，因為有了日誌並不能完全判別規則。因此我認為以保安問題的角度看待，abusefilter-log-private的急迫性較低，故abusefilter-view-private應照原定時程移除，至於移除abusefilter-log-private應盡速重新公示，改為公示後一周移除。@Sanmosa您是否同意此做法？--銀河市長—☎️— 2023年9月11日 (一) 11:05 (UTC)

(？)疑問：为何此前并未讨论移除abusefilter-log-private权限，此处却能“直接公示”？提案人Sanmosa此前将两者混为一谈，现在却以“这里做的事也相当于没有意义”为理由一次移除两项权限，是否有游戏维基的嫌疑？--Yiningx_Puppet（留言|主账户） 2023年9月12日 (二) 09:01 (UTC)

先前公示沒有移除abusefilter-log-private的相關內容。如果Sanmosa認為已有共識，公示先前沒寫進公示而後來移除者是最基本的；如果公示通過，就假定沒有異議，反之若有異議就必須進行討論--銀河市長—☎️— 2023年9月12日 (二) 10:52 (UTC)

您可能误解了本人的意思。本人非常赞同您的观点，即移除的项目都要公示；然而Sanmosa希望移除的项目在此前并未经讨论。因此本人的意思是，对于是否要移除abusefilter-log-private权限这一点或许还需进一步讨论。--Yiningx_Puppet（留言|主账户） 2023年9月12日 (二) 15:43 (UTC)

我認為還是要請提案人解釋一下為什麼移除該權限為必要之舉。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月13日 (三) 08:58 (UTC)

我認為應該解釋的我已經解釋得非常清楚了，我應該也沒有必要重複。此外，我從未反對任何重新公示相關提案的提議，我僅僅是不滿意特定用戶的用語與態度（“高度不認可Yining Chen上方的說辭”）而已，我對於部分用戶超譯我的説法的舉動實在無法理解。此外，還是回到回退員通告沒人寫的問題，先找個人來寫回退員通告吧，不然這提案再重新公示也不是沒有用嗎？Sanmosa _{віки-віків} 2023年9月16日 (六) 12:12 (UTC)

因為無論是社群早前第一階段共識，以及近來的相關討論，從頭到尾都是針對過濾器閱讀權，而並不針對過濾器日誌閱讀權。我不認為在除去過濾器閱讀權的情況下，單純閱讀日誌以助於反破壞能有什麼安全疑慮。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月16日 (六) 15:50 (UTC)

没人说您“反对任何重新公示相关提案的提议”，现在问题是该提案或许需要“打回”重新讨论。希望您能正视社群对此提案在程序上的疑问，并对此做出适当解释。--Yining Chen（留言|贡献） 2023年9月17日 (日) 06:33 (UTC)

我也不反對這樣處理，我也不排除我有看錯一些東西的可能。Sanmosa _{віки-віків} 2023年9月17日 (日) 09:47 (UTC)

(！)意見：非公開日誌閱讀權從2012年到2017年非公開閱讀權開放的這5年間是否有因此對反破壞造成影響？在不確定那5年間是否有影響的情況下，我覺得可以在非公開閱讀權撤銷後進行觀察，如果真有因為非公開日誌閱讀權造成反破壞工作受到影響，再來考慮除權也不遲。Lily135（留言） 2023年9月17日 (日) 12:21 (UTC)

@Sanmosa：討論通過已經一個多月，移除權限的通告都還沒有人寫沒發，不發只能無限期拖延執行。閣下作為提案人應儘後續跟進之責，完成共識所要求之移除權限流程。而abusefilter-log-private未曾正式討論且後續亦有不少用戶反對移除，應作無共識結，不包含在移除的權限之內。--路西法人 2023年10月1日 (日) 02:04 (UTC)

@Stang：Phabricator任務不應該是stalled，社群對於移除前一部分權限已經有共識。至於後一部分權限是否應當移除的問題，建議另外在底下提案討論。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年10月1日 (日) 06:03 (UTC)

共識要求發通告都還沒做，是程序上stall而不是技術上stall。--路西法人 2023年10月1日 (日) 06:38 (UTC)

提议设立Growth导师指引

现有导师有不活跃、不回答新用户提问、自己建立的条目也有问题无法指导新用户等问题，提议设立Growth导师指引，规范取得导师身份和移除导师身份的条件。

方案一：采取目前的导师申请条件，但增加不活跃、被封禁、长期不回应新手提问移除导师身份的流程。

方案二：参考巡查、回退等取得权限的方式，及移除权限的方式，由管理员审核。

方案三：参考AFC审核员取得身份和移除身份的方式及条件，设立由导师及管理员组成的“Growth导师委员会”，管理员为固定委员，“Growth导师委员会”进行审核取得导师身份，若不活跃、被封禁、长期不回应新手提问等将由“Growth导师委员会”移除导师身份。--桐生ここ★[讨论] 2023年9月9日 (六) 16:55 (UTC)

(＋)支持：延伸确认用户可以自行成为导师，但也可以被罢免（方案一和方案二结合），这样可以确保新手得到良好的帮助而不至占用过多的资源。—顺颂时祺 ZhaoFJx^{（论•编）} 2023年9月9日 (六) 17:35 (UTC)

還要特地搞委員會有點太超過了，不過確實需要一點規則，包含如果被管理員移除除特殊理由外，未有申訴禁止一段期限內自己加回去--RainBeforeSun（留言） 2023年9月10日 (日) 07:23 (UTC)

参考上面的意见，已经建立了草案：WP:Growth导师，提请讨论。桐生ここ★[讨论] 2023年9月12日 (二) 06:20 (UTC)

英文維基百科看起來大部分是寫在en:Wikipedia:Growth Team features/Mentor list裡面，或許可以也可以把裡面的內容看是要搬到對應的頁面，還是要搬到這個草案的頁面（但看起來是放到對應的頁面比較適合），還有，可能也可以把en:Template:User Growth Team features mentor、en:Template:User mentor topicon跟en:Template:User mentor拿到本站來用。--冥王歐西里斯（留言） 2023年9月12日 (二) 09:00 (UTC)

不需要是指引，論述就夠了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月12日 (二) 13:10 (UTC)

@Ericliu1912：關於管理員介入後的處理還是需要是指引吧--SunAfterRain 2023年9月13日 (三) 11:43 (UTC)

基本上我認為沒有必要。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月15日 (五) 01:40 (UTC)

剛才花費了一些時間測試出只要封鎖目標對MediaWiki:GrowthMentors.json的編輯權限就能達成禁止自行登記成導師的效果，看您們覺得有沒有需要動用到這部分@桐生ここ、ZhaoFJx、S8321414、Ericliu1912（感謝Stang的協助）--SunAfterRain 2023年9月13日 (三) 13:01 (UTC)

可以用以约束部分滥用以扰乱规则的维基人，不过其他情形（诸如不活跃，指导不力等）就不必了--顺颂时祺 ZhaoFJx^{（论•编）} 2023年9月13日 (三) 22:26 (UTC)

所以要是这样的话，一年内不能申请权限了对吧？--MilkyDefer 2023年9月15日 (五) 05:20 (UTC)

基本上我覺得還是據個案判斷，如果確實有改善就可以考慮提前同意重返。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月15日 (五) 11:31 (UTC)

如果是直接採用封鎖的方式的話直接走封禁申訴就可以了...？--SunAfterRain 2023年9月17日 (日) 11:09 (UTC)

我觉得管理员除权时决定是否限制自行登记、限制多长时间，限制期内可以向管理员申请重返。--桐生ここ★[讨论] 2023年9月16日 (六) 03:10 (UTC)

• 可以考慮設立該指引啊，就是很難活躍起來就是了。厲害的用戶都嘛靠自己寫條目就好了，根本也用不到什麼「Growth導師指引」，不是嗎？這個和協作計劃的本質基本一樣，就是所謂的「換湯不換藥」而已。難活躍起來的討論、政策，再討論一點意思也沒有，浪費時間而已。--Z7504非常建議必要時多關注評選（留言） 2023年9月25日 (一) 15:36 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

提议修改快速删除方针中的F7章节

最近发现有一些图像因为涉及非自由版权的问题，在维基共享资源上被提删，然而有人根据合理使用的方针上传了图像的本地版本，但是很快被机器人识别并按照F7提请快速删除。之前就有类似于迪拜哈里法塔图像的案例。对于上述产生的情况，是否需要调整F7快速删除的适用范围？

以下我举个例子：

A是一位摄影师，他拍摄了法国著名的一座现代主义的建筑。

B是一位维基共享资源的资深用户，他根据法国没有全景自由的事实，并获悉这座建筑于2016年才竣工，于是对该图像提交了存废讨论。

C是中文维基百科的一位用户，他创建了这个建筑的条目。

D发现原先的图像被提交存废讨论后，根据非自由图像的依据，上传了本地版本的图像。

E很快根据F7立即提交对本地图像的快速删除。

对于上次这种情况下，F7删除的合理性有待商榷。如果当一个图像在维基共享资源被提交存废讨论，然后又在本地根据非自由文件的上传程序上传的文献，我认为最好的方式还是转文件存废讨论。--СлаваУкраїні! 2023年9月9日 (六) 09:14 (UTC)

個人想法：

已棄用提案

現行條文 與維基共享資源檔案重複的檔案

提議條文 與維基共享資源檔案重複的自由版權檔案（重複名稱的非自由檔案應當被提交存廢討論或者移動到合適的名稱）

--Hoben7599—論 | 支持立場新聞 2023年9月9日 (六) 09:49 (UTC)

(＋)支持--銀河市長—☎️— 2023年9月9日 (六) 10:46 (UTC)

“应当提交存废讨论”即可。自由著作权文件也可以移动到合适的名称来解决F7问题吧？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月9日 (六) 13:45 (UTC)

既然這樣就改為：與維基共享資源檔案重複的自由版權檔案（重複名稱的非自由檔案應當被提交存廢討論）--Hoben7599—論 | 支持立場新聞 2023年9月9日 (六) 13:53 (UTC)

被字不需要。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月10日 (日) 13:02 (UTC)

快速刪除模板已經明確提醒，「請檢查文件於共享資源有妥善授權。」因此在相關共享資源檔案有存廢討論的情況下，人類編者本就不應當掛快速刪除模板，就算是機器人理論上也應該要能夠自動辨識（只是目前好像還沒有這種設定）。同時，也不應該使用移動操作來處理這種問題。如果有需要，請使用Keep local模板。社群可以明確遭提交存廢討論的共享資源檔案，其本地複本不適用F7原則。但我認為上面那種修改是沒有必要的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月9日 (六) 15:26 (UTC)

即使模板写了，方针也应明确。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月10日 (日) 13:01 (UTC)

没有移动的需求，即使文件名不同文件的hash也相同，然后此情况确实可以写入方针明确做法。--在下荷花，请多指教（欢迎签到） 2023年9月13日 (三) 02:25 (UTC)

擬議條文沒有考慮到CC0（無版權）的情形，不過為F7新增額外的條文好像也不錯（但請不要放到條款標題裏），要不我也擬一版吧。Sanmosa _{віки-віків} 2023年9月16日 (六) 11:56 (UTC)

現行條文 F7. 與維基共享資源檔案重複的檔案。 使用模板{{d|新文件名}}或直接用{{d}}或{{NowCommons}}。

提議條文 F7. 與維基共享資源檔案重複的檔案。 此項條款僅適用於維基共享資源檔案與本地複本具體內容完全相同之情況； 惟若本地檔案係依據非自由內容使用準則中「最小限度使用」原則而限制大小，則此項條款仍應適用。 此項條款不適用於單純只有檔案名稱相同，或維基共享資源檔案著作權尚有爭議（例如遭提交刪除請求）之情況。 使用模板{{d|新文件名}}或直接用{{d}}或{{NowCommons}}。

暫時想到可以這樣寫。雖然算是對現時默認的不成文處理方式的一種總結，但予以明確總比不明不白來得好。Sanmosa _{віки-віків} 2023年9月16日 (六) 12:07 (UTC)

@Fumikas Sagisavas、Hoben7599、銀河市長、魔琴、Ericliu1912、Hehua。Sanmosa _{віки-віків} 2023年9月17日 (日) 09:51 (UTC)

基本上同意。--Hoben7599—論 | 支持立場新聞 2023年9月17日 (日) 09:55 (UTC)

@Sanmosa：所謂「具體內容完全相同」是否包含圖片品質（解析度等）等細節差別？因為本站合理使用檔案必然會有壓縮，那就與共享資源檔案不「完全相同」了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月17日 (日) 11:13 (UTC)

@Ericliu1912：啊，確實該排除這些因素，但想不到較好的表達方式，或許寫成「因本地檔案屬合理使用而進行的壓縮所導致的差異視同不存在」？Sanmosa _{віки-віків} 2023年9月17日 (日) 15:58 (UTC)

我有点没看懂第二条是在规定什么？--在下荷花，请多指教（欢迎签到） 2023年9月18日 (一) 00:21 (UTC)

其實跟前一條是在講同一件事情，建議直接刪除。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月18日 (一) 01:52 (UTC)

修改於2023年9月18日 (一) 08:46 (UTC)。Sanmosa _{віки-віків} 2023年9月18日 (一) 08:46 (UTC)

我再調整了一下行文，您看看怎麼樣。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月18日 (一) 08:59 (UTC)

大體沒意見。Sanmosa _{віки-віків} 2023年9月18日 (一) 09:27 (UTC)

7日（實際上是近9日）內無新意見，現公示提案7日。Sanmosa _{віки-віків} 2023年9月27日 (三) 05:06 (UTC)

提议重构“避免地域中心”方针的“地理”节，并将内容细化分离到格式手册；另呼吁建设细化格式手册

日前在相关讨论中，方针“避免地域中心”“用语方面”之“地理“一节，已经暴露出比较明显的问题，包括：

• 作为方针却包含过多操作细节，致使方针作为凝聚社群高级别共识的文本难以灵活适应实际情况；
• 内文逻辑混乱，前文说“撰写地理条目时”内文却在讲“一般提及时”，导致整段文意不清；
• 缺少普遍性的可操作规范，一面地理条目的定义句格式不清（这间接导致了前面相关讨论的产生），另一面内文一般性提及时却没有标准，粗到国还是细到县全凭感觉，固然不同情况需要灵活处理，但是大致提供一个范例以供参考还是非常有益的。

所以提议：

1. 分拆WP:BIAS的“地理”一节，在原处留下精神和刚要，具体的内容分拆到格式指引并添加链接，在格式指引建立“地理”章节或页面。

2. 草拟在原方针中保留：

• 说明地理方面容易产生地域中心的重要原因是一般的中文读者不一定熟悉知名度相对低的地点，且没有足够信息时较低行政级别的地名很容易大量重名却难以检索；
• 扩充原有的“凤山”案例，说明两方面的情况；
• 指明详见格式指引。

3. 草拟创建格式指引/地理，包含两部分：“地理条目的定义句规范、模板与实例”和“内文一般提及地点时的指引与实例参考”，其具体内容大致草拟如下：

• （行政区划）地理条目的定义句模板为：（某地）是（国家/地区名）（从一级行政区逐层细化直至本级区划的上一级）的（行政级别）[，位于（地理位置，最好是一级行政区内的位置说明，有自然地理天然划分的按天然划分说明）]。（方括号内为有必要或能明显提供有效信息时补充的内容。）
• 内文提及时的规范比较复杂，大致要在第一次提及某地时至少指出包含当地并中文环境下众所周知的上级地名（国家地区/众所周知的省、知名城市或特殊地点等），前文提及且不会混淆时可按逐层细化的方法去较低的地名或直接省略。这部分还请诸位群策群力。

关于上面的提议，还有几条简短的说明：

• 不提及原有的“本地本国/外地外国”差异、不使用“本港”的案例、不强调“外国/外国人”的原因是统一的：这不是地理部分的内容，而且在现有的方针“这里是‘中文维基百科’”一节已经论述得十分透彻了，甚至“本港”的案例也已举过。
• 选择“凤山”的案例，一是这是原有的案例，继续采用能体现方针逐渐更进演化的传统，某种程度上也是维护维基百科的连续性；二是在前述相关讨论中User:heartingvia指出“凤山”这个地名的重名率很高，这使得这个案例可以同时完美应对需要解说的两个方面。
• 地理条目模板句的构成，主要是考虑到地理条目常见的地理-行政二元性，定义句应当尽量将两者都明确表述，又行政区划通常明确，所以作为定义句更清晰。详细案例依然见前述讨论中本人的意见，特别是其中所提及的新加坡、上海、南京三个城市和基隆、澎湖、台北、金门四个市县的案例。

能力不足，大体只能详细到这个程度，考虑到和原讨论的主题已经分离，在这里重新提出议案。另外还有一点个人意见：社群应当加强细化格式手册等“基础工程”。现在许多编辑常常或动辄希望修改方针，结果当然是屡动议屡失败；或只一条条分散写论述，结果很难发现、检索，成果也不容易积累。个人觉得，应当加强格式手册和指引层面的建设，一方面将方针解放出来，在方针中留下刚要，维持其稳定的同时使具体细节的变动更加灵活，另一方面，手册的编纂和普及能很大程度提高所有人的效率。比如现今互助客栈其他版关于“斜坡计划”的讨论中就有人提到，对新手来说，从五大支柱到两岸四地用语再到格式手册的介绍乃至最基本的“接触度”，都是大大不足的。像我本人已经自认为非常爱“钻钻看看”了，还是感到检索格式、指引、技术文档，都很困难。很多积极的潜在贡献者，就被这样刷掉了。我想，维基百科发起了很多针对不同主题的贡献活动，也许也可以考虑以同样的精神发起一些致力于完善维基百科和她的社群、系统规范自身的贡献活动。先把属自己的文档写好，能更好地书写这个世界。

以上，共社群参阅。祝安。

Xsgzjmxs（留言） 2023年9月10日 (日) 20:51 (UTC)--Xsgzjmxs（留言） 2023年9月10日 (日) 20:51 (UTC)

大致认同。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月18日 (一) 05:57 (UTC)

沒具體文本的話，這事實在難辦。Sanmosa _{віки-віків} 2023年9月18日 (一) 08:54 (UTC)

是否考慮整合為慣常之wikipedia論述類版面，可能可方便社區持續檢視或討論等之。--約克客（留言） 2023年9月19日 (二) 02:07 (UTC)

看来目前主要的意见都是赞同意向但缺少成文。我近日杂事缠身，隔了半个月才回来回复一下，也没有起草方针、格式手册的经验，短期内恐难写成完善文稿。有讨论者提出写成论述页面的意见，但我也完全没有写作论述页面的经验。我想社群中如果有人恰巧时间充裕，可以动笔起草，如果有相关成果请给我留条消息；如果都不凑巧，我估计也迟早会回来写出文稿，但这就时日无期了。希望看到且有意的维基人积极推动。Xsgzjmxs（留言） 2023年9月26日 (二) 21:46 (UTC)

关于日俄争议领土的命名

本节讨论内容范围包括整个千岛群岛和库页岛，目前这些领土由俄罗斯联邦萨哈林州实际控制。WP:命名常规/中文译名具争议条目命名在萨哈林州地名应用时，几条规则自相矛盾了。

地图上对岛屿的名字都是使用日式译名（除了阿特拉索夫岛）；然而对于城镇，却清一色都是俄式译名，比如南萨哈林斯克、科尔萨科夫、大洋城等。

而目前如果按照WP:命名常规/中文译名具争议条目命名的2. 汉文名优先于非汉文（如英文）译名，这些城镇似乎全应该换成日式译名。这不仅不符合现状、不符合地图，也不符合5. 主权具争议土地，以实际管辖之国家之称谓优先。

总之，在萨哈林州，命名规则自相矛盾了。

之前在克里利翁半岛/能登吕半岛的争执中，被人移走了。而几年前千岛群岛也是俄式日式译名来回搬。

兹鉴于争议，提请为WP:命名常规打补丁，特别增加WP:命名常规/中文译名具争议条目命名/萨哈林州一节。按照《俄罗斯地图册》第95页实际给的译名来。--超级核潜艇（留言） 2023年9月13日 (三) 09:56 (UTC)

這份「中文譯名具爭議條目命名」本身這個邏輯就不是很站得住腳。定立的時間太早了，那時候的社群未必有這個能力去制定這個規則，所以就寫出來這樣的玩意。我這裏建議是重新定立規則，而不是另外寫補丁。--Ghren🐦🕖 2023年9月13日 (三) 11:17 (UTC)

路過看了一下。其實命名規則本身並沒有自相矛盾。

要注意到，1~5的規則前有寫，「條目名稱將依照以下順序尋找適當的中文名稱當作條目名」。也就是說，2（漢文名優先於非漢文（如英文）譯名。例：獨島或竹島均優於利揚庫爾岩）優先於5（主權具爭議土地，以實際管轄之國家之稱謂優先。例：獨島由大韓民國實際管轄，因此選用此名）。規則2的優先度高於規則5，按相關規則，只有在符合2的前提之下（比如獨島和竹島都符合2、而利揚庫爾岩被排除）才能用5來判斷（因此命名為獨島而非竹島）。

在千島群島與庫頁島（樺太）的地名部分（不全是日俄爭議領土。日方目前僅主張北方四島為其領土），照1~5的順序的話，除了庫頁島會因為規則1的關係優先於樺太/薩哈林，其餘部分按相關規範應以日文漢字名較俄文譯名為優先。

以上判斷乃依相關規則作出解釋，如社群認為相關共識不恰當，亦可在有共識的前提下進行相關規則之修訂。唯需充分論證舊有共識何以過時或者不當、新案又如何能改善維基百科。不過個人是認為除非必要、或者利遠大於弊，否則不太需要勞師動眾就是了...-Peacearth（留言） 2023年9月13日 (三) 23:17 (UTC)

但是如果按照2优先于5而选择日式译名，这又与实际常用名不符了——在大陆的实际使用情况如下，您在台灣“科爾薩科夫”“大泊”哪個譯名更常用？如果能搜到紙質的較新的台灣出版的《俄羅斯地圖冊》是最好（不知道您們是不是還叫他們“蘇俄”？）；所以我认为应该加补丁。

萨哈林州地名在大陆译名的实际使用情况：

岛名：萨哈林岛（库页岛）（双语并记）；丘列尼岛、阿特拉索夫岛、莫涅龙岛（俄式）；千岛群岛其他岛屿为日式；

城镇名、海湾名：全为俄式；但南千岛群岛上未标注任何市镇名，只有日式岛名。

海峡名：只列出宗谷海峡（拉彼鲁兹海峡）、得抚海峡、克鲁森施滕海峡、第四千岛海峡、鞑靼海峡。

火山名：全为俄式，共收录科洛科尔火山（得抚岛）、戈里亚夏火山（新知岛南部）、萨雷切夫火山（松轮岛）、谢韦尔金火山（春牟古丹岛）、富斯火山（幌筵岛）和阿莱德火山（阿特拉索夫岛）--超级核潜艇（留言） 2023年9月14日 (四) 01:38 (UTC)

這套規則充其量只是能運行而已，仔細一想就會有很多問題。比如說因為規則1，WikiProject_talk:鐵道#关于全面移除日本铁路相关条目的和制汉语词语的讨论中一些日語名詞在條目標題中那就得轉成中文，因此或者要偏向一些不常用的名稱；

規則3，對於歐美地區的地名當地華人使用的名稱，就會優於常用的名稱，比如「滿地可」會優於「蒙特利爾」；

「漢文」名優於「非漢文」譯名這條規則，首先要問啥是「漢文」，「漢文」一般就是指中文而已。然後「漢文」優於「非漢文」名稱這個規則是否真的可以呢？從「庫頁島」島上的地名來說，一個五十年前，和日本人才用的地名，只怕不及俄羅斯本身的地名常用。--Ghren🐦🕗 2023年9月14日 (四) 12:50 (UTC)

对，我也觉得当时的举例实际上不当，原文的第二条用的是日韩争议的独岛/竹岛/扬利库尔岩做例子，因为争议双方都是汉字文化圈；而日俄争议岛屿，如果第二条优先于第五条，那明显日式译名永远优先于俄式译名；然而实际上的情况就如上边说的，地图上有俄有日。要不然就只能打补丁。--超级核潜艇（留言） 2023年9月14日 (四) 13:15 (UTC)

这份WP:命名常规/中文译名具争议条目命名也留意过，按照上面的讨论，这份细则应该被写入过WP:命名常规总则中，但是命名常规已经被大幅修改过，当然也仍包括提及了其他分则，但并没有在包括这个细则，甚至之后的导航中也就将其当做草案来看待，那这份“中文译名具争议条目命名”是否仍具有方针或指引性，或者是否有新共识认为它不再有效，如果仍有效，是否给予适当的“名分”，再讨论是否规则可用，至少Peacearth给出的解读，规则可以用；如果无效，那就没有为这个东西而讨论的需要了，按总则来判断即可。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月14日 (四) 01:08 (UTC)

就不能簡單一點，實際哪個常用便用哪個嗎？--AT 2023年9月14日 (四) 11:15 (UTC)

我就是按照实际的《俄罗斯地图册》上标注的修改的能登吕半岛to克里利翁半岛，但被移动回去了。--超级核潜艇（留言） 2023年9月14日 (四) 12:22 (UTC)

應以現在的俄羅斯俄語名稱為準，若語源與過去的日本日語名稱一致（比如都源自阿伊努語）則可沿用既有漢字，否則應直接音譯俄羅斯俄語名稱；除非其他名稱壓倒地常用。--紺野夢人 2023年9月14日 (四) 13:54 (UTC)

我就弱弱地問一句：Wikipedia:命名常规/中文译名具争议条目命名好像沒有現行方針指引的地位？Sanmosa _{віки-віків} 2023年9月16日 (六) 12:18 (UTC)

@Sanmosa：討論最後似乎是無疾而終（雖然支持者看似佔多數），提案內容也並沒有正式寫入命名常規。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月18日 (一) 08:49 (UTC)

既是如此，不屬現行方針指引的Wikipedia:命名常规/中文译名具争议条目命名相較屬現行方針指引的主命名常規而言在這裏並不具備太大的參考價值。Sanmosa _{віки-віків} 2023年9月18日 (一) 08:52 (UTC)

我現在只支持在二戰後中文出版地圖上使用過日語名的地名使用日語，其他的地名則傾向於使用俄語。--🎋竹生🎍 2023年9月24日 (日) 06:46 (UTC)

参考資料

关于数值比值中的冒号问题

相关讨论见此（尖刀蛏的同行评审讨论），简单地说就是我在各类格式手册（包括MOS:PUNCT、MOS:MATH、MOS:DATENUM）中均没有找到在数值比中应使用全形冒号（形如2：1）或是半形冒号（形如2:1）的相关规定（也有可能是我没找到合适的归类）。如果社群未做规定，可以把比值冒号这个命名规则添加进格式手册。----FradonStar|^{和而不同是君子} 2023年9月14日 (四) 08:15 (UTC)

我能想到有三种方法：

• 2:1（半角冒号）
• 2 : 1（半角冒号两旁有一个空格）
• 2：1（全角冒号）

参考一下，LaTeX是这么写比值的：$2:1$。--ItMarki^探討人生 2023年9月14日 (四) 09:17 (UTC)

中国大陆常见字体，冒号等符号会设计在一格的左侧，所以全角冒号的2：1看起来像这样「2:  1」。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月14日 (四) 10:58 (UTC)

另外用全角冒号会使比能在冒号后换行，如2：
1 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月14日 (四) 11:02 (UTC)

如果用半形加空格也会有换行的问题吧，比如“2 :
1”。----FradonStar|^{和而不同是君子} 2023年9月14日 (四) 11:34 (UTC)

還有一種寫法是用「比號」U+2236 ∶ RATIO，效果是 2∶1，對比半形冒號是 2:1。語義上可能用該符號較佳，但不清楚是否常用或是否有中文標準，有文章[1]認為「最新的《现代汉语词典》（第7版）在“比例”一词的举例中，明确地使用了两点居中的比号。因此，上述例子中用的两点靠下的冒号，均应改为两点居中的比号。」（LaTeX印象中沒有區分比號和冒號，但在LaTeX中，二元運算符與關係符的空格大小有差異，如

$2\mathbin {:} 1$（將冒號作為二元運算符，接受前後兩個數為輸入，輸出其比值）與

$2:1$（冒號預設是關係符）。——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2023年9月14日 (四) 11:50 (UTC)

其實可以用Template:Ratio來顯示：{{ratio|4|3}}→4∶3；{{ratio|16|9}}→16∶9。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年9月14日 (四) 12:01 (UTC)

(＋)支持。——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2023年9月14日 (四) 12:06 (UTC)

(＋)支持(？)疑問：产生这个问题最开始是因为有编辑对某物种长宽高的比“5.5：1.9：1”当中的冒号有质疑，但英维模板的doc当中说明了这种模板不适合三个数值及以上的比例，有没有办法在{{ratio}}的基础上做出{{ratio|5.5|1.9|1}}可显示的效果呢？--FradonStar|^{和而不同是君子} 2023年9月14日 (四) 13:01 (UTC)

{{ratio|5.5:1.9:1}}→5.5∶1.9∶1 --街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年9月14日 (四) 13:35 (UTC)

了解了，感谢。那我认为这个话题应该可以结束了。----FradonStar|^{和而不同是君子} 2023年9月14日 (四) 15:32 (UTC)

---

建议在WP:格式手册/标点符号#冒号新增一条：

冒5：表示数学上的“比”时应使用「比號」U+2236 ∶ RATIO，如2∶1。也可以使用模板{{ratio|3:2}}、{{ratio|3|2}}或LaTeX（应该怎么写？）。

 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月22日 (五) 08:59 (UTC)

(＋)支持。----FradonStar|^{和而不同是君子} 2023年9月23日 (六) 01:38 (UTC)

可是在實踐上並不常用，最常用的還是普通冒號「:」。「比號」用起來也挺麻煩。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月23日 (六) 06:31 (UTC)

(＋)贊成。或者“宜使用”来避免“麻烦”，但至少应优先用，不过英文等上下文中是否要使用，应该考虑一下。是否类似除号用/还是÷，也是输入问题。--YFdyh000（留言） 2023年9月23日 (六) 06:50 (UTC)

使用「比號」有什麼實際好處嗎？實際上根本沒人會用。 Ghren🐦🕓 2023年9月23日 (六) 08:31 (UTC)

语义不同，外观不同。“1:1:1”丑；“1：1：1”畸形、歧义；“1 : 1 : 1”门槛低但输入和复制也不轻松，等宽和非等宽字体下有差异。1∶1∶1。--YFdyh000（留言） 2023年9月23日 (六) 08:51 (UTC)

那兩個點距離太寬了，搭配數字起來比用冒號還要難看啊。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月23日 (六) 12:54 (UTC)

指U+2236太宽吗，我这里看与“1 : 1”是一样的，但两个点偏下而非居中，不确定是否就该如此。等宽下的“1 : 1”反而很宽很丑。--YFdyh000（留言） 2023年9月23日 (六) 13:07 (UTC)

建议新开一个章节，“比号”，因为比号并不属于冒号。可在冒号节加入连接提示。

提議條文 比1：表示数学的比时宜使用「比號」U+2236 ∶ RATIO，不应用冒号。 2∶1 {{ratio|2:1}} 2∶1 或 {{ratio|2|1}} 2∶1 <math>2:1</math> $2:1$ 或 <math>2\mathbin{:}1</math> $2\mathbin {:} 1$

基于魔琴2023年9月22日 (五) 08:59 (UTC)版。——落花有意12138 2023年9月30日 (六) 16:22 (UTC)

存廢覆核請求

雖然是中維陳年問題，但Wikipedia:存廢覆核請求能否招募專責管理負責，個案積壓半年以上確實不太理想。—日月星辰｜留言簿 2023年9月19日 (二) 05:43 (UTC)

WP:存廢助理，不過看起來大概是很難通過。--冥王歐西里斯（留言） 2023年9月19日 (二) 07:35 (UTC)

比較熱衷於處理相關站務的@KirkLU、Wong128hk君近期都稍微不活躍一些。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月19日 (二) 11:14 (UTC)

优化流程比专责更好，明确阶段性和时间表，如邀请讨论和公示。Wikipedia:互助客栈/其他#设立「评议会」及「管理员处理决定公示机制」。--YFdyh000（留言） 2023年9月19日 (二) 20:50 (UTC)

存廢覆核一个大问题就是名字的问题。“存廢覆核”就意味着“存废讨论”定案后不管是删除还是保留有异议，然后放到“存廢覆核”做最终的讨论，这必然导致效率不会高。其实原先的“删除请求”和“恢复删除请求”就明晰的多，我就是提出删除，“删除请求”定案后如果是被删了且有异议，那就去“恢复删除请求”要求恢复；而对“删除请求”定案后保留的页面有异议，则可以过一段时间（或根据其他要求）再提“删除请求”。这样一套流程其实更简单明了--百無一用是書生 (☎) 2023年9月20日 (三) 02:36 (UTC)

感觉问题不在这里。您说的流程听上去是有人请求恢复、管理员认为合理，就可直接恢复，这样虽快但也不太好。--YFdyh000（留言） 2023年9月20日 (三) 02:42 (UTC)

我哪里说过“管理员认为合理，就可直接恢复”。我说的其实就是以前的流程而已，或者说就是enwiki现在的afd流程--百無一用是書生 (☎) 2023年9月21日 (四) 02:20 (UTC)

我不记得“恢复删除请求”是怎样的了，也许按字面理解出现偏差。复核请求和恢复请求，不都是认为新的讨论共识足以推翻旧有讨论吗，未理解为何复核变成最终结论、效率低下。效率高我会理解为“要求恢复”的请求被批准无需追溯旧有共识。--YFdyh000（留言） 2023年9月21日 (四) 22:08 (UTC)

因为“恢复删除请求”复核的只是删除问题，“存废复核”则复核的是删除和保留两类问题，效率自然不一样--百無一用是書生 (☎) 2023年9月22日 (五) 06:13 (UTC)

所以「發還存廢討論」這種結果不會在英文維基百科出現？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月22日 (五) 08:08 (UTC)

标题已修改为：Wikipedia:互助客栈/其他#‎设立「邀请讨论」及「管理员处理决定公示」机制。--桐生ここ★[讨论] 2023年9月20日 (三) 06:47 (UTC)

问：RFDA该不该上安全投票

距上次相关讨论已经过了一年半，现在又有RFDA了，请问如果真到了投票那一步该怎么办呢？--在下荷花，请多指教（欢迎签到） 2023年9月20日 (三) 03:05 (UTC)

既然RFA采取安全投票，因此RFDA也应该采取安全投票。

(＆)建議修订WP:RFDA方针，采取安全投票。--桐生ここ★[讨论] 2023年9月20日 (三) 03:36 (UTC)

同樣認為該修訂WP:RFDA採用安全投票。--冥王歐西里斯（留言） 2023年9月20日 (三) 07:08 (UTC)

已提出修订案：#提议WP:管理員解任投票采取安全投票。--桐生ここ★[讨论] 2023年9月20日 (三) 07:10 (UTC)

 吐槽：「提议修改快速删除方针中的F7章节」下面的章节在移动端显示上都有问题。--桐生ここ★[讨论] 2023年9月20日 (三) 07:12 (UTC)

@桐生ここ：已協助調整排版。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月20日 (三) 07:55 (UTC)

@Ericliu1912：您用移动端看一下，「提议修改快速删除方针中的F7章节」以下的一级章节全部都变成了「提议修改快速删除方针中的F7章节」的子章节。我猜测是哪里有HTML标签没有闭合产生的问题。--桐生ここ★[讨论] 2023年9月20日 (三) 08:34 (UTC)

依據現行規則，解任申請尚未採用安全投票。就算修訂規則，這次解任申請可能也趕不上。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月20日 (三) 05:04 (UTC)

真可憐，這個獨裁社群以前居然沒人想過這個問題，也不一起實施，這當然(＋)支持啊。不然就是維基百科的「雙軌並行制」？選一個管理員都已經實施安全投票，現在居然跟別人說解任一個管理員可以不用再實施安全投票，不是在講笑話嗎？是說，不用再邀請討論了，反正對本來就不想選或者選不上管理員的用戶來說，這種討論是完全沒意義的。--Z7504非常建議必要時多關注評選（留言） 2023年9月20日 (三) 08:02 (UTC)

提议WP:管理員解任投票采取安全投票

见#问：RFDA该不该上安全投票，提议WP:RFDA采取安全投票，修订方针如下：

解任程序

• 條件：申请必须在事件发生48小时之后才能提出，在这段时间裡当事人之间应该尽量沟通。只有在沟通无效的情况下才可以发起取消管理员权限的投票。內容必须詳細，指出管理濫權的原因，並根據編輯記錄及用戶貢獻提出相關證據，如內容不符或原因不合理，可視作申請無效。為了防止一案多審，除非有新證據出現，否則不得就同一事件重覆提起解任。
• 提出：由一名自動確認用戶提出解任管理員申請，並說明理由。提出解任管理員申請後，必須隨即在該管理員的用戶對話頁留言通知（可使用{{NoteforRFDA}}）。
• 聯署：7日內，必須收集至少7名有投票资格的用户联署，用户可以在互助客栈提出解任的意向，并徵求联署人。滿7人聯署後解任案方為成功提出。一旦收集到7名联署人，则立即进入下一阶段。7日後仍未有足夠聯署者，无须进行安全投票的准备程序，被提解任人也無須答辯，解任案自動失效。
• 准备：在联署通过后，开始进行安全投票的准备程序。同时，被解任人有5天的答辩期，对于解任申请中指出的问题进行答辩。被解任人（或他许可的其他用户）可以整理答辩内容，并置于解任理由之下，这些内容不被折叠。如果解任人在5天内没有答辩，被视为无答辩意见，不過仍可在投票期間發表意見。
• 投票：安全投票开启后，应至少持续二周。符合人事任免投票資格者（不包括被解任人）可以投支持票（同意解任）或反对票（反对解任），也可以在讨论页发表意见。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。重复投票和傀儡投票将被视为无效票。
  • 监票：若本地有两名或以上监督员在安全投票开始前表示愿意监票，则由愿意执行监票工作的监督员与其他监管员共同协助监票。若本地能够执行监票工作的监督员不足两人，则由监管员独自负责监票。
• 計票和评估：在投票時間結束后，由监票者計算出得票比率。有效表決的最低總有效票數為25票。如總有效票數低於25票，則不論結果如何，均視為解任案不通過。若總有效票數達至少25票，且支持解任票數多於一半者，則投票通過。惟懷疑投票結果被作弊或其它不恰當行為嚴重影響，可由行政員討論決定該次投票是否有效。
  • 解除权限：投票结果为解任时，則由行政员除權或将社群的共识提报给元维基，申请解除该管理人员的权限。

--桐生ここ★[讨论] 2023年9月20日 (三) 06:11 (UTC)

• (－)反对：畢竟我在站外被某些人得了個“雙標”的駡名，這次就不妨坐實了。我反對的主要理由在於投票時，其他用戶的意見、爭論即為對管理員爭議，或對社群有危害與否指出的必要一環。倘若使用安全投票（即打亂投票附屬意見後，在結果時公佈），這將大幅度減弱社群慎重考慮此人是否勝任的要件。且解任和選舉相比，本就相對罕見而更需要廣汎的看待。——WMLO※議程表 2023年9月20日 (三) 07:18 (UTC)

  此案与RFA不同，此案仅投票的部分采用安全投票，而表达意见仍在讨论页上进行，不使用安全投票附属意见。--桐生ここ★[讨论] 2023年9月20日 (三) 07:23 (UTC)

  既是如此，豈非是一邊投票，一邊闡述自己的投票意見？那這安全投票和沒設又有什麽區別呢？——WMLO※議程表 站立在金阶用目来观睁 2023年9月20日 (三) 07:46 (UTC)

  您這道理就不對了，投票者並不一定需要公開表達意見，但還是可以投票；安全投票是保障投票者的意志自由，而不是箝制投票者公開發表意見的權利。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月20日 (三) 07:53 (UTC)

  您這道理就不對了。倘若將表達意見和投票一并規範，您的“保障投票者的意志自由說”就成立。然而桐生君似乎也認知到，在解任投票上不直接地指出當事人的意見，顯將最小化地檢討涉事用戶。且論，如果您這理論能夠實現，那麽，我仍然能夠通過意見觀察，得知哪位投票者大概投了什麽票，仍然能威脅到他的意志自由。權衡考慮過後，我仍然維持雙重標準，對此提議表示(－)反对，應對RFA實行安全投票，而RFAD不實行安全投票。到底難兩全，不是麽。——WMLO※議程表 2023年9月20日 (三) 08:01 (UTC)

  我同意Eric Liu的说法。--桐生ここ★[讨论] 2023年9月20日 (三) 08:30 (UTC)

  您這道理反過來也說得通啊（ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月20日 (三) 08:58 (UTC)

  @維基百科最忠誠的反對者：仔細閱讀之後我仍然無法理解您的說法。而就當前的情況所說，我觀察到已經有對於表達支持或反對的用戶發出疑似的嘲諷或試圖施加壓力或情緒勒索的多個可能案例，不論在站內還是群內。因此我認為允許投票人保密的投票是絕對有必要的，但考慮到您的想法，投票期間表達意見則公開在討論頁上發表。--桐生ここ★[讨论] 2023年9月20日 (三) 13:56 (UTC)

  @桐生ここ：我親愛的桐生君，也就是您得想想，爲何您下意識主張RFAD是部分安全投票，而RFA確是整體的安全投票。原因在於，盡可能地指出管理員失當本身，要略微高於自由意志受到威脅的重要性。而我則更直白點，在這個基礎之下，我寧願不用安全投票。不知道這麽説，您有沒有理解。二、我認爲只有站外，沒有站内（或者從站外來到站内的）。關於這個問題，您可以查閲一下本人著作，我自認寫的任何論述都可燒掉，唯獨此書不能燒——《女巫道德》。本來是寫著泄憤的，但是越看越真實。——WMLO※議程表 2023年9月20日 (三) 14:10 (UTC)

已將此章節併入下方（上方）討論。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月20日 (三) 07:51 (UTC)

基于本站历年来RFDA的乱象，我认为还是公开投票的好。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月20日 (三) 10:01 (UTC)

本站历年的RFA也颇见乱象，但也用了安全投票。安全投票能明显保护投票人，我觉得可以试试看。--在下荷花，请多指教（欢迎签到） 2023年9月20日 (三) 10:17 (UTC)

有一說一，此處的實際困難在於當初本站同意管理員申請採用安全投票的同時，也訂下了只能每年幾次定期提名的規則。但解任投票顯然不可能以定期出現，因此若社群依舊同意非定期管理員申請可能帶來的困難大過好處，則這種困難同樣也適用於管理員解任投票；反之亦然，若社群已經不同意有困難，則限制管理員申請只能定期提出的規則就變得毫無意義。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月20日 (三) 12:36 (UTC)

RFA採取定期投票是有益的，因為安全投票有技術困難無法隨便就舉行，同時定期投票有助於迫使社群找出適合成為管理員的人，從而大量提名管理員候選人以增加管理員。

RFDA不能採取定期投票，因為解任連署是不可能像提名管理員候選人一樣能在固定時間提出的，使用常識就能明白，而且RFDA數量非常稀少，偶爾提出一次應該不會對元維基和其他安全投票的工作人員造成壓力。

而現實世界的選舉也是如此，選舉通常是固定時間登記候選人，固定時間舉行投票，而罷免是隨時可以提出，連署後即舉行投票。--桐生ここ★[讨论] 2023年9月20日 (三) 13:35 (UTC)

上面這句「解任連署是不可能像提名管理員候選人一樣能在固定時間提出」確實是如此，但個人認為仍然應該使用安全投票，如同上面已經講過的，不然此討論串大概只是又一個「演演戲而不正式實施」的討論串。現實世界無論是選一個候選人還是罷免一個特定候選人，通常都嘛用不記名的。那到底為什麼不能一樣用安全投票？可想而知。技術上反正都已經知道能做得到安全投票了話，就不要再騙人說做不到了吧？以後甚至維基獎勵的投票也考慮此方式，應該也剛好而已。--Z7504非常建議必要時多關注評選（留言） 2023年9月20日 (三) 14:14 (UTC)

维基奖励也要改安全投票是要累死谁吗？--在下荷花，请多指教（欢迎签到） 2023年9月21日 (四) 00:15 (UTC)

維基獎勵在技術上不可能使用安全投票，否則整個vote wiki將無法舉行任何其他的選舉。--1233 （T / C） 2023年9月21日 (四) 01:35 (UTC)

真可憐，公然說謊的獨裁社群，這樣講的話那互助客棧技術區可以廢除了，因為根本沒技術可言。所以提出什麼技術問題，根本也沒人能解決。不想幹管理員或是不想寫維基百科的話，早點退休不好嗎？如果技術上真的能做到，不只維基獎勵，甚至連平常所看到的DYK、FA/FL/FP/GA投票應該都能做到才對，有沒有真的懂的人願意幹維基百科這行的問題而已。如果沒人願意幹，當然只能繼續用傳統模式啊，不是廢話嗎？--Z7504非常建議必要時多關注評選（留言） 2023年9月21日 (四) 08:30 (UTC)

不支持过多滥用安全投票系统，毕竟这套东西不是我们直接配置的，甚至现在管理员选举也是基于这个因素按批量推送申请的。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月21日 (四) 03:17 (UTC)

解任投票应该需要迅速解决，显然依赖安全投票反而增加操作不便，我认为解任投票还是按传统模式处理。即使之前讨论也像是偏一半一半意见的考虑。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月21日 (四) 03:19 (UTC)

「傳統模式→拉票→獨裁社群一點進步都沒有」，以上。總之這類討論非常沒有意思，因為這個獨裁社群非常的墨跡，做事一點都不乾脆，甚至公然說謊。--Z7504非常建議必要時多關注評選（留言） 2023年9月21日 (四) 08:34 (UTC)

我不肯定我有沒有記錯，但我的印象是OA2021前也存在特定用戶就RFDA投票事宜向其他用戶施壓的情況（例如威脅該等用戶不要投票），這樣看來RFDA是有實行安全投票的具體需要的。我認為上方WMLO的說法有一定程度上的偏頗，畢竟一個在本地頁面闡述自己的意見的人也不一定會在安全投票頁面中投票的，我完全可以選擇只在本地頁面指出管理員失當（或沒有失當）而不投票，因此意見觀察並不經常有效。Sanmosa _{віки-віків} 2023年9月21日 (四) 08:47 (UTC)

另外一個今年剛好碰到的技術問題，就是同時有管理員申請，若確定有人申請，那就可能撞期。照理講應該是解任投票先處理，但管理員申請本來都特地定期排程了，結果還要挪開，會顯得有點怪。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月21日 (四) 13:38 (UTC)

（註：所以個人認為單論這次解任投票技術上或實際上都不適合採用安全投票）—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月21日 (四) 14:25 (UTC)

技术人员目前正在让中维能够在本地发起安全投票，所以个人认为未来在技术上其实并不存在太大问题。--Yiningx_Puppet（留言|主账户） 2023年9月21日 (四) 15:36 (UTC)

社群向來喜歡談未來展望，不過未來經常是難以預測的。我認為對於這類重大問題，如果要宣稱消滅相關技術障礙，都應該至少等到任務確實部署以後再說，因為方針與指引修改通常是立即生效。（當然若社群同意置緩衝期那又是另一回事了）—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年9月21日 (四) 17:23 (UTC)

對目前解任程序的修改沒有意見。另外想請問，比如這次的狀況，連署票的其中一人被封禁了，這樣是否不影響解任程序的進行呢？--Mafalda4144（留言） 2023年9月23日 (六) 13:38 (UTC)

感觉不应溯及既往，除非傀儡行为。不过，被封禁用户可能无法参与正式的安全投票，那么如果是非安全的计票，应扣除联署票？如果安全投票后封禁，该扣除吗。--YFdyh000（留言） 2023年9月23日 (六) 14:02 (UTC)

联署本来就不应该自动计入票数，联署人应另外安全投票。现在的WP:RFA也没有说联署自动计入票数，所以我提出的修订案也没有自动计入。以后的RFDA联署只是支持提起投票，而不一定是支持解任，被封禁导致没有完成安全投票就是没有投票。如果安全投票之后被封禁，不应该扣除，何况你也不知道他投的什么票。--桐生ここ★[讨论] 2023年9月23日 (六) 14:34 (UTC)

既不扣除也不计入，取消“由联署带出的支持”一段，直接看最终投票结果。--在下荷花，请多指教（欢迎签到） 2023年9月23日 (六) 14:54 (UTC)

没人来讨论一下具体的RFDA方针条文嘛…--桐生ここ★[讨论] 2023年9月26日 (二) 16:25 (UTC)

那我再重申一下反对意见。RfA是觉得谁适合当管理员，可能有印象、个人评价等因素众口难调。但RfDA有具体的解任事由，更有针对性；而且，看的是证据和论证，每一票都需要理由，每个理由也会被记在投票页上，受到社群监督。User:Lt2818君说过：“公开投票下，[...]谁重人情而眛事实，清清楚楚。”我不知道不受监督的不信任票有什么危害。所以我反对在RfDA用SecurePoll。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月26日 (二) 17:17 (UTC)

为什么安全投票“不受监督”呢？--在下荷花，请多指教（欢迎签到） 2023年9月27日 (三) 00:20 (UTC)

在RFDA中使用安全投票也有其必要性，一定程度上说RFDA比RFA更可能受到威胁（如果有）。不过可以要求RFDA安全投票必须填写投票理由--在下荷花，请多指教（欢迎签到） 2023年9月27日 (三) 00:24 (UTC)

“我不知道不受监督的不信任票有什么危害”未看懂。附一句理由就清清楚楚吗。--YFdyh000（留言） 2023年9月27日 (三) 21:14 (UTC)

@魔琴--在下荷花，请多指教（欢迎签到） 2023年9月30日 (六) 02:09 (UTC)

大概是认为人们在投下违背良心的一票前会想想社群甚至全世界的眼睛吧，如果安全投票的话那谁有没有偷偷摸摸昧良心不论事实投票那真的就只有天知道了。啊，毕竟之前WMCUG的集体投票行动也是通过公开投票看出来的嘛。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月30日 (六) 11:55 (UTC)

那么不受监督的信任票有什么危害？为什么RFA使用安全投票没有危害，而RFDA就有危害？--桐生ここ★[讨论] 2023年9月30日 (六) 13:23 (UTC)

那就把RFA改回去，之前应对wmc的措施就是改安全投票，既然认为安全投票倒会导致上述问题为什么要用呢？--在下荷花，请多指教（欢迎签到） 2023年10月1日 (日) 07:22 (UTC)

• 我修改的是條件跟提出，這裏修改的是過程，其實剛好沒有overlap，兩個修訂可以同步進行。順帶一提我支持用安全投票-某人✉ 2023年9月30日 (六) 13:36 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，下方#修改管理員解任程序完成后，再进行安全投票方针修订。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

保護及半保護模版是否該說明保護原因與期限？

編輯一個條目，在編輯模式下說這是半保護。好，那就去找找半保護的原因，不要再犯……呃……找不到……

好，不要管原因，耐心等到保護期間結束吧，保護到何時呢？……呃……沒有……

啊，模版上說到討論頁留言。……嗯，雖然不知道什麼時候才會有人去看，但還是試試好了……呃……討論頁也半保護，還很嘲諷的留同一個模版連到討論頁，遞迴很好玩嗎你們……

所以大家明白為什麼有人一發言就罵人了嗎？因為被玩弄了啊。

還有，不要再建議去註冊了。註冊完還是遇到一樣問題，只是半保護換成保護而已。況且要有歸屬感才能引人註冊。設置連環的牆給人一撞再撞再來說註冊完就可以穿牆對於增加註冊意願來說一點幫助都沒有好嗎？該做的是在保護或半保護模版上放上確切的理由與時限，不是要人猜，用遞迴方式嘲諷人好嗎？你理由寫個我爽，時限寫個無限期，都還沒現在這麼令人生氣。

還有，過濾器也有類似要人猜的問題，更過份的是有時還限制猜的次數。不過這是另個議題了。一般編輯都鼓勵編者寫摘要了，有權保護條目過濾詞句的人比一般編者更省事更無責是吧？嗄？

2603:8000:500:FB00:E9B1:8E88:12C3:26A1（留言） 2023年9月25日 (一) 04:01 (UTC)--2603:8000:500:FB00:E9B1:8E88:12C3:26A1（留言） 2023年9月25日 (一) 04:01 (UTC)

一般看历史记录、日志中保护分项（对于没移动过的话一般容易找到）可以找到。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月25日 (一) 06:17 (UTC)

如果可以的话，能否说一下是哪个条目或者页面连同讨论页一并保护？——Sakamotosan路过围观 | 避免做作，免敬 2023年9月25日 (一) 06:23 (UTC)

大概有十几篇条目是这样的待遇。 --MilkyDefer 2023年9月25日 (一) 08:08 (UTC)

@Cwek：仔细看了一下，我觉得这位IP指的非常有可能是条目原神相关争议和讨论页Talk:原神相关争议。参见WP:RFPP。

考虑到我跟那位搞破坏的IP长达一个小时的27RR拉锯战，我坚决反对现在解除这个条目的保护。--MilkyDefer 2023年9月26日 (二) 09:38 (UTC)

就案例的话，没必要解除保护。如果就是否显示更详细保护信息的话，可以看看，不过有点偏技术向了。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月27日 (三) 01:37 (UTC)

保護模板能否提供直接連至保護日誌的連結？-- Matt Zhuang表示有事按「此」留言 2023年9月25日 (一) 09:16 (UTC)

可以考虑，引用logid（如果对应到保护日志记录），不过需要工具（例如TW）适配和人员指导注意；另外也要考虑像标题黑名单的“保护”（刚刚技术版展示了这个情况 囧rz……）需要添加说明。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月25日 (一) 09:41 (UTC)

也可以考慮寫小作文讓mw直接顯示被保護的理由--SunAfterRain 2023年9月26日 (二) 10:05 (UTC)

保护日志写得很明白了吧。不过您是怎么从讨论页连到讨论页的？讨论页的“无法编辑”提示没有连到讨论页的链接。“您可以申请解除保护、登录或创建账号”最后那个创建账号可以删了，创建了也没用。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月26日 (二) 17:52 (UTC)

那麼請問太陽倒數在保護日誌的什麼地方？當撞上半保護模板時要怎麼連過去？如果已經不熟悉這部分了，登出一下，用IP用戶的身份按一下編輯不就明白了嗎？而上面亂猜還猜錯的，瞭解到被迫去猜的感覺了嗎？嗄？2603:8000:500:FB00:4185:1AB2:EF32:8391（留言） 2023年9月28日 (四) 06:22 (UTC)

MediaWiki:Titleblacklist-semiprotected的“该保护使用标题黑名单实施。”不太容易加说明。“您可以和其他人讨论此页。”应该适时禁用，或者正则允许编辑讨论页。“.*[數数]”等影响条目会不会太多。--YFdyh000（留言） 2023年9月28日 (四) 07:13 (UTC)

“您可以和其他人讨论此页。”一句应该在标题黑名单正则能cover到talk page的时候禁用（比如换一个提示叫Titleblacklist-semiprotectied-talkpagedisabled）2023年9月30日 (六) 13:13 (UTC)-- ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月30日 (六) 13:13 (UTC)

原来还是标题黑名单的问题……但提示信息已经提到会涉及标题黑名单的“保护”。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月28日 (四) 07:49 (UTC)

很多人不懂正则表达式。并且没有后续流程指引。--YFdyh000（留言） 2023年9月28日 (四) 16:14 (UTC)

修改管理員解任程序

現行條文 解任程序 提出：由一名自動確認用戶提出解任管理員申請，並說明理由。提出解任管理員申請後，必須隨即在該管理員的用戶對話頁留言通知（可使用{{NoteforRFDA}}）。 條件：申请必须在事件发生48小时之后才能提出，在这段时间裡当事人之间应该尽量沟通。只有在沟通无效的情况下才可以发起取消管理员权限的投票。內容必须詳細，指出管理濫權的原因，並根據編輯記錄及用戶貢獻提出相關證據，如內容不符或原因不合理，可視作申請無效。為了防止一案多審，除非有新證據出現，否則不得就同一事件重覆提起解任。 聯署：7日內，必須收集至少7名有投票资格的用户联署，用户可以在互助客栈提出解任的意向，并徵求联署人。滿7人聯署後解任案方為成功提出。一旦收集到7名联署人，则立即进入下一阶段。7日後仍未有足夠聯署者，被提解任人無須答辯，解任案自動失效。 (...) 收回权限：投票结果为解任时，則由行政员除權或将社群的共识提报给元维基，申请收回该管理人员的权限。

提議條文 解任程序 提出：由一名自動確認用戶於客棧對相關管理員提出不信任動議，並說明理由。內容必须詳細，指出管理濫權的原因，並根據編輯記錄及用戶貢獻提出相關證據。提出不信任動議後，必須隨即在該管理員的用戶對話頁留言通知（可使用{{NoteforRFDA}}）。 條件：解任申请必须在不信任動議提出至少48小时之后才能立案，在这段时间裡当事人之间应该尽量沟通，當事管理員亦可在這段期間在此期間嘗試說服提案者及社群放棄解任。若果當事雙方在此階段內達成共識，解任申請自動失效。若雙方未能達成共識，提案者可進入下一階段徵求聯署。為了防止一案多審，除非有新證據出現，否則不得就同一事件重覆提起解任。 聯署：7日內，必須收集至少7名有投票资格的用户联署，用户可以在互助客栈提出解任的意向，并徵求联署人。滿7人聯署後解任案方為成功提出。在此期間被解任人仍然有權遊說聯署用戶放棄聯署。一旦收集到7名联署人，则立即进入下一阶段。7日後仍未有足夠聯署者，被提解任人無須答辯，解任案自動失效。 (...) 收回权限：投票结果为解任时，則由行政员除權或将社群的共识提报给元维基，申请收回该管理人员的权限。

提案背景可見Mys解任案的後續爭議。簡單說說改了什麼，基本上就兩大方向：

1. 明確界定「48小時」冷靜期是由提出不信任動議起計，而非事件發生後起計 (這亦是近年所有解任案的計算方式)
2. 取消「溝通無效」以及「內容不符/合理」的硬條件
   • 相關管理員即使有溝通並不代表其自動免於被彈劾。先例有如先前蟲蟲飛解任案中，即使相關管理員很積極溝通，並不能代表其可免於濫用傀儡的相關責任。
   • 若果解任案理由不合理，相關解任在聯署階段就會被擋下來，先例有如KOKUYO解任案。
   • 最後也是最重要的一點：「合理與否」以及「溝通有效與否」應該由社群整體決定，而非由一個利維坦決定。聯署本身就是共識流程，尤其解任機制作為社群制衡管理員權力的程序，更不應該由行政員矯正此共識產生流程，否則長久下去將很容易變成官官相衛。

-某人✉ 2023年9月30日 (六) 12:34 (UTC)

(＋)贊成 在下认同上述解读和理据。

1. 在下认为新提议内容分与原来方针没有矛盾。新提案内容只是按：1.原来方针内涵， 2.近年的案例（虫虫飞解任案，KOKUYO解任案）对原来方针解读，做更清晰的解读, 避免社群解读分歧。
2. 在下进一步观点详细表述在社群就此的初步讨论中： Wikipedia_talk:管理員解任投票/Mys_721tx#提案人不愿意接受沟通内容，认为要求不被满足还是提起罢免，这样该给谁判断？ 和 Wikipedia_talk:管理員解任投票/Mys_721tx#探讨_管理员离任方针“溝通無效”，“事件48小时”的计时起点,与难被看到的非直接回复_的解读分歧。
3. 关于原方针“积极沟通”的解读: 提案人没发有关解职正式沟通通知或者通知48小时的时间内，提名解职。这可以认定提案人没有“积极沟通”。这种情况下，提案人的提案申请过程就违反了方针。如果被提名解职的管理员的对有关解职正式沟通通知没有回应或者没有按大家习惯性公认（common sense）的直接回应。这可以认定仅仅只是被提名解职的管理员没有“积极沟通”。被提名解职的管理员没有“积极沟通”, 不应该终止联署和后续投票过程。
4. 关于按原方针和案例，“沟通无效”的认定人是提案人个人。 如果被提名解职的管理员即便“积极沟通”， 但回应不足说服和影响提案人（参照近年进入联署阶段的类似案例： 蟲蟲飛（提案人认定沟通无效， 7联署，联署通过， 15支持），Jimmy_Xu（提案人认定沟通无效， 0联署，联署流产）, KOKUYO（提案人认定沟通无效，2联署，联署流产）），仅仅提案人就判定“沟通无效”并正式申请解职。 但被提名解职的管理员可以在联署阶段继续沟通（特别应该“积极沟通”），影响可能的联署人，甚至使得已签名联署人放弃联署,“往粗略共识的方向协调”， 使得社群不支持解职，使得联署流产(近年案例：Jimmy_Xu, KOKUYO)
5. 关于新修订内容中提到，取消“沟通无效”以及“内容不符/合理”的硬条件，实际只是按原方针和历史案例可以更明确地解读出：申请阶段的 沟通无效/确保所列“罪状”成立 的判断是提案人个人不是其它多人或者行政员。 按原方针和历史案例（如上提到的虫虫飞等案例中判断，是提案人个人），明确了案原方针确保所列“罪状”成立于否谁来判断？的答案。 --Gluo88（留言） 2023年10月1日 (日) 12:47 (UTC)--Gluo88（留言） 2023年9月30日 (六) 15:02 (UTC)

(！)意見，為什麼只能綁定48小時？如果剛好兩位都很多話想說也非常積極討論但是毫無共識，時間到就無論結果舊繼續下一步連署的意思嗎？連署可以7日，答辯只設定48小時的原意是？

(－)反对「提出」一段的新增內容，看來就是允許翻舊帳了。--Mafalda4144（留言） 2023年9月30日 (六) 15:47 (UTC)

48小時是原本就有的內容，而且我已經新強調「至少」，雙方很多話想說很積極討論可以繼續討論呀，條文從來都沒有強制48小時後就一定要開始連署。提出一段的新增內容都是原本就有的內容，只不過是從「條件」移至「提出」。而且要求彈劾需要提出證據也有錯？--某人✉ 2023年9月30日 (六) 16:03 (UTC)

“翻旧账”，WP:RfDA已经列出了合理的解任理由，翻不翻旧账和“程序”一节的规定无关。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月30日 (六) 16:48 (UTC) +1 gluo88为此+1了。--Gluo88（留言） 2023年9月30日 (六) 17:01 (UTC)

但就WMLO案例來看，就是各自解讀，無論有沒有結果時間到了就下一步，另外，既然這次事件會被當成關鍵參考重點，若是認為自己受到不公平對待的VIP們，到客棧發起解任討論了，同時也比照參考此次，盡到通知義務後發起連署，試問，無論過或不過，管理員們光是處理這些就飽了，無理提報又不能冷處理不回應等等被說沒溝通，平常還有生活其他事要忙，終於上線了得要先趕緊「溝通」，這樣沒人敢擔管理員了，有種動不動就要被抓出來討論是否濫權，更不用說修訂內容模糊地看來就是可以翻舊帳啊。--Mafalda4144（留言） 2023年9月30日 (六) 20:07 (UTC)

@Mafalda4144：新修订内容只是解任程序没有涉及翻旧账，有关内容在WP:解任條件：發生於提出解任申請前的1年內，而且並未在早前的解任案中用作證據。--桐生ここ★[讨论] 2023年10月1日 (日) 00:56 (UTC)

基本上(＋)支持，但对修订能否通过抱有怀疑。--YFdyh000（留言） 2023年9月30日 (六) 19:41 (UTC)

支持需要釐清但(－)反对當前建議條文。當前建議條文看來是「方便成功解任」而不是「方便爭議解決」，完全背離原先意義。

1. 原先解任程序（包括動議、連署）等寫事件發生後48小時才開始是就是為了避免「提了解任才討論」這一無助爭議解決的流程順序，新條文變相一來就開始解任，喊打喊殺，更變項要脅管理員（不論解任是否合理），以您維環境不可能促成有效討論，應保留「事件發生後48小時才開始解任程序」（包括動議、連署）的要求而不是「解任動議48小時後才開始連署」。
2. 反對移除「溝通無效」的條文，但應擴寬為「溝通無效或社群普遍認同違規事實情節嚴重」以涵蓋社群對於特定管理員行為嚴重違反方針指引一事主流無異議的情況，如明顯濫用管理員專有權限（如保護、封鎖等），或構成一般用戶很可能會因而被封鎖的違規情況（如濫用多重帳號）。

--路西法人 2023年9月30日 (六) 23:49 (UTC)

@AINH：

参考路西法人和您的意见提出折中的修订方向：

1. 條件：申请人必须在事件发生72小时之内尝试沟通，在这段时间裡当事人之间应该尽量沟通解决，只有在此沟通无效的情况下才可以发起解任投票。
2. 用NoteTag明确定义“沟通无效”是什么。
3. （删除）

--桐生ここ★[讨论] 2023年10月1日 (日) 01:41 (UTC)

反對一切試圖剝奪行政員終止討論的權力。WP:行政員：行政員須具備在出現複雜情況的時候決定投票共識及結論，並能有效地對這些決定做出全面解釋的能力。若剝奪行政員終止權則整個RfDA形成「無王管」，不論程序不當、拉票、解任理由顯然不當強行聯署解任（暴民式解任）等諸多原因顯然應該終止流程都無法處理，最終還是得上元維基吵，根本是本末倒置。--路西法人 2023年10月1日 (日) 01:50 (UTC)

OK，那么删除第三条。--桐生ここ★[讨论] 2023年10月1日 (日) 01:52 (UTC)

@LuciferianThomas：您是否可以同意上面两条？--桐生ここ★[讨论] 2023年10月1日 (日) 02:20 (UTC)

同意，但需先判斷什麼是「溝通無效」。--路西法人 2023年10月1日 (日) 03:06 (UTC)

感謝你的調解但冷靜期反而不是我修訂的核心。你把冷靜期加長到一星期甚至半個月我都不反對，但任何形式的硬條件都必須去掉。如我所說：難道蟲蟲飛因為很積極溝通，所以彈劾案就不成立了嗎？--某人✉ 2023年10月1日 (日) 03:17 (UTC)

現行條文 條件：申请必须在事件发生48小时之后才能提出，在这段时间裡当事人之间应该尽量沟通。只有在沟通无效的情况下才可以发起取消管理员权限的投票。

提議條文 條件：申请人必须在事件发生72小时之内尝试沟通，在这段时间裡当事人之间应该尽量沟通解决，只有在此沟通无效的情况下才可以发起解任投票。

@AINH：您可能理解错了，申请不是必须在事件发生48小时之后才能提出，需要緊接事情發生的48小時去提出，而是改成必须在事件发生72小时之内有尝试沟通，而且沟通无效之后提出，不要求紧接着事件发生去提出。--桐生ここ★[讨论] 2023年10月1日 (日) 03:24 (UTC)

好的，但如我所說：時間定義真的不是我最著重的地方--某人✉ 2023年10月1日 (日) 03:36 (UTC)

如您所举例，积极沟通但是没有达成共识或者双方没有互相理解谅解，属于有效沟通吗？所以我们要明确定义这个有效沟通是什么。--桐生ここ★[讨论] 2023年10月1日 (日) 03:39 (UTC)

基本上，任何程序都只是為了確保有足夠溝通，確保該管理員與社群之間之爭議並非溝通可以解決。

另外，前置程序，無論是多少人聯署，是應該確保所列「罪狀」成立，經過審核，才進入下一階段。

投票由始至終都應該只是扮演最後確認的部分，而非「我覺得罪成」，「我覺得無罪」，大家不是陪審團。

做到以上三點，才對得起「解任投票是最後手段」這句話。如果你們能做到上述三點，還敢有人跳出來說無效，我也不會再留在這個社群。

以上。--J.Wong 2023年10月1日 (日) 01:50 (UTC)

btw. 離題一下，所以mys的溝通如何？是大家都覺得說了幾句已經解決？還是怎樣？不會是實質問題沒解決，先來討論程序一番吧？--J.Wong 2023年10月1日 (日) 01:59 (UTC)

苗君已在RFDA討論區釋出討論善意，有部分用戶已參與相關討論。--路西法人 2023年10月1日 (日) 02:07 (UTC)

参照近年进入联署阶段的类似案例： 蟲蟲飛溝通如何？

关于按原方针和案例，在申请阶段，“沟通无效”的认定人是提案人个人。 如果被提名解职的管理员即便“积极沟通”， 但回应不足说服和影响提案人（参照近年进入联署阶段的类似案例： 蟲蟲飛（提案人认定沟通无效， 7联署，联署通过， 15支持），Jimmy_Xu（提案人认定沟通无效， 0联署，联署流产）, KOKUYO（提案人认定沟通无效，2联署，联署流产）），仅仅提案人就判定“沟通无效”并正式申请解职。--Gluo88（留言） 2023年10月1日 (日) 02:10 (UTC)

关于“mys的沟通如何”，在联署阶段，要看其理据对联署人和潜在联署人的说服力，由社群这些人初步判断是有问题的可能性。--Gluo88（留言） 2023年10月1日 (日) 02:23 (UTC)

我針對的真的不是mys，我亦無意對mys展開第二次彈劾。退一步說即使這次修訂通過我都不會嘗試推翻這次的結果，畢竟不溯及既往。我針對的，and no offence，是行政員有權依自主判斷而強行中斷任何彈劾過程的過大權力--某人✉ 2023年10月1日 (日) 03:23 (UTC)

问题是关于确保所列“罪状”成立于否谁来判断？

在下理解是通过三个阶段才能最终由社群判断。 提案人只是原告，本社群大多数的解任案例都是失败的，管理员绝大多都无罪。如果要求，前置程序确保所列“罪状”成立（=预先猜出通过三个阶段才能最终由社群判断的结果）， 以往90%案件都无法进入联署阶段。--Gluo88（留言） 2023年10月1日 (日) 02:08 (UTC)

「審核」，又是回到那個問題：由「誰」審核？行政員嗎？如果行政員覺得「罪狀」不成立但社群覺得成立這矛盾又如何調解？--某人✉ 2023年10月1日 (日) 03:29 (UTC)

個人想法是，修正方針可以是，將模糊不清的部份修訂得更為明確，而不是將之解釋範圍形成更大的洞。

早先另一位被緊急除權的管理員，有先被提報到不當的行為，而且該名管理員是同樣事件的累犯，對吧？若要檢討管理員過去的錯誤，就事論事和對事不對人的基礎下，個人認為是「同樣的錯誤一犯再犯，沒有解決問題反而造成社群更大困擾」來檢視管理員是否適任問題，這樣才不會被鑽空翻舊帳，也不構成無限上綱，

所以在所謂的48小時溝通期之前，管理員們也是帳號使用者，可以走完相應流程後，也就是討論頁提醒和提報至不當的行為，前兩項以及來到客棧都沒回應，就真的構成拒絕溝通，看來真的不適任了，更不用說一直犯同樣的錯誤。

如果狀況嚴重到得直接略過流程，相信社群的判斷也會很明快的。

還是說管理員不能先被提醒，被提醒就是直上客棧走任免流程？個人想法是，管理員只是獲得管理權限的使用者，當然他們本該更謹慎面對方針和指引，偶有誤判，若都能修正都好說，但不能因為這些人有頭銜權限，就要把他們的行為放大來看。--Mafalda4144（留言） 2023年10月1日 (日) 07:16 (UTC)

(！)意見 新修订内容（取消“沟通无效”以及“内容不符/合理”的硬条件）实际只是将原方针模糊不清的部分按历史案例修订得更为明确。

• 如： 按原方针和历史案例可以更明确地解读出：申请阶段的 沟通无效/确保所列“罪状”成立 的判断是提案人个人,如按原方针和历史案例（如上提到的虫虫飞等案例中判断，是提案人个人），明确了案原方针确保所列“罪状”成立于否谁来判断？的答案。
• 新修订内容会减少管理员行使裁量时引起在社群引起大的争议可能性。 这种社群大的争议， 耗费多个管理员行政员和社群大量的时间和精力。 --Gluo88（留言） 2023年10月1日 (日) 13:03 (UTC)

折中版本

現行條文 提出：由一名自動確認用戶提出解任管理員申請，並說明理由。提出解任管理員申請後，必須隨即在該管理員的用戶對話頁留言通知（可使用{{NoteforRFDA}}）。 條件：申请必须在事件发生48小时之后才能提出，在这段时间裡当事人之间应该尽量沟通。只有在沟通无效的情况下才可以发起取消管理员权限的投票。內容必须詳細，指出管理濫權的原因，並根據編輯記錄及用戶貢獻提出相關證據，如內容不符或原因不合理，可視作申請無效。為了防止一案多審，除非有新證據出現，否則不得就同一事件重覆提起解任。 聯署：7日內，必須收集至少7名有投票资格的用户联署，用户可以在互助客栈提出解任的意向，并徵求联署人。滿7人聯署後解任案方為成功提出。一旦收集到7名联署人，则立即进入下一阶段。7日後仍未有足夠聯署者，被提解任人無須答辯，解任案自動失效。 答辩：在解任提出后，被解任人有5天的答辩期，对于解任申请中指出的问题进行答辩。被解任人（或他许可的其他用户）可以整理答辩内容，并置于解任理由之下，这些内容不被折叠。如果解任人在5天内没有答辩，被视为无答辩意见，不過仍可在投票期間發表意見。 投票：答辩期过后，进入投票程序。投票期为14天，符合人事任免投票資格者（不包括被解任人）可以投支持票（同意解任）或反对票（反对解任），也可以在讨论区发表意见，无论支持票还是反对票，投票人需给出理由。联署人自动计为支持解任，但仍可以在投票期间改变意向。用户可以在投票期内改变立场，结果以投票期结束后为準。重复投票和傀儡投票将被视为无效票。 結果：有效表決的最低總有效票數為25票。如總有效票數低於25票，則不論結果如何，均視為解任案不通過。若總有效票數達至少25票，且支持解任票數多於一半者，則投票通過。惟懷疑投票結果被作弊或其它不恰當行為嚴重影響，可由行政員討論決定該次投票是否有效。 收回权限：投票结果为解任时，則由行政员除權或将社群的共识提报给元维基，申请收回该管理人员的权限。

提議條文 條件：申请人必须在事件发生之后尝试沟通至少48小时，在这段时间裡应该尽量沟通解决，只有在沟通无效的情况下才可以提出解任投票。為了防止一案多審，除非有新證據出現，否則不得就同一事件重覆提出解任。 提出：由一名自動確認用戶提出解任管理員申請並說明理由，內容必须詳細指出管理濫權的原因，並根據編輯記錄及用戶貢獻提出相關證據。提出解任管理員申請後，必須隨即在該管理員的用戶對話頁留言通知（可使用{{NoteforRFDA}}）。 聯署：7日內，必須收集至少7名有投票资格的用户联署，用户可以在互助客栈提出解任的意向，并徵求联署人。滿7人聯署後解任案方為成功提出。一旦收集到7名联署人，则立即进入下一阶段。7日後仍未有足夠聯署者，被提解任人無須答辯，解任案自動失效。 答辩：在解任提出后，被解任人有5天的答辩期，对于解任申请中指出的问题进行答辩。被解任人（或他许可的其他用户）可以整理答辩内容，并置于解任理由之下，这些内容不被折叠。如果解任人在5天内没有答辩，被视为无答辩意见，不過仍可在投票期間發表意見。 投票：答辩期过后，进入投票程序。投票期为14天，符合人事任免投票資格者（不包括被解任人）可以投支持票（同意解任）或反对票（反对解任），也可以在讨论区发表意见，无论支持票还是反对票，投票人需给出理由。联署人自动计为支持解任，但仍可以在投票期间改变意向。用户可以在投票期内改变立场，结果以投票期结束后为準。重复投票和傀儡投票将被视为无效票。 結果：有效表決的最低總有效票數為25票。如總有效票數低於25票，則不論結果如何，均視為解任案不通過。若總有效票數達至少25票，且支持解任票數多於一半者，則投票通過。惟懷疑投票結果被作弊或其它不恰當行為嚴重影響，可由行政員討論決定該次投票是否有效。 收回权限：投票结果为解任时，則由行政员除權或将社群的共识提报给元维基，申请收回该管理人员的权限。

注解

参考双方意见的折中版本。--桐生ここ★[讨论] 2023年10月1日 (日) 13:49 (UTC)

能否加回顏色HL顯示此提案增修了哪些條文？--J.Wong 2023年10月1日 (日) 22:44 (UTC)

由于条件和提出的上下顺序做了修改，所以有点不知道要如何标记………--桐生ここ★[讨论] 2023年10月2日 (一) 02:27 (UTC)

(！)意見 关于“事件”按原方针和历史案例和Wikipedia:管理員的離任#解任条件可能应该如下解读。

• 条件：申请人必须在该管理员的用户对话页留言通知（可使用NoteforRFDA）发生72小时之内尝试沟通 （注： Wikipedia:管理員的離任#解任条件 上方所列的一个或多个行为(事件)需要是： ...发生于提出解任申请前的1年内，而且并未在早前的解任案中用作证据。），在这段时间里申请人和该管理员应该尽量积极沟通，相互积极回应对方质疑。 只有在此沟通无效[注 1]的情况下才可以提起解任投票。为了防止一案多审，除非有新证据出现，否则不得就同一事件重复提起解任。
• 注 1：按原方针和历史案例： 申请阶段的“沟通无效”否由提案人个人判断。--Gluo88（留言） 2023年10月1日 (日) 14:21 (UTC)

  Gluo所言本末倒置。先提出除權再討論完全無助任何爭議解決流程，更是與「解任投票是最後手段」的基本原則相違背。--路西法人 2023年10月1日 (日) 14:27 (UTC)

• 按原方针和历史案例， 在下理解是爭議解決通过三个阶段才能最终由社群判断。 提案人只是原告，原告的申请是个人行为。 按原方针和历史案例，申请阶段的“沟通无效”判断， 是方针赋予社群个人的权力。
• 本社群大多数的解任案例都是失败的，管理员绝大多都无罪。如果要求，前置程序确保所列“罪状”成立（=预先猜出通过三个阶段才能最终由社群判断的结果）， 以往90%案件都无法进入联署阶段。联署阶段判断才进入社群行为。--Gluo88（留言） 2023年10月1日 (日) 14:38 (UTC)

  @Gluo88：我有一个问题，您认为这个折中方案，是否比现行方针稍微更好一点？--桐生ここ★[讨论] 2023年10月1日 (日) 14:43 (UTC)

  在下认为您试图作出比原方针更清晰的表述形式. 在下仅仅希望按原方针和历史案例，作出比原方针更清晰的表述形式。不希望与原方针和历史案例有冲突。感谢您的努力。--Gluo88（留言） 2023年10月1日 (日) 14:50 (UTC)

  对于放松时间长度等，没有异议。--Gluo88（留言） 2023年10月1日 (日) 14:56 (UTC)

  那個註一，各位都不認為可以先提報到不當的行為嗎？如果有問題要溝通，在這個時候應該就可以有共識了。--Mafalda4144（留言） 2023年10月1日 (日) 15:36 (UTC)

  • 按照原有的方针和历史案例,情况似乎如此: 提案人只是原告,原告的申请是个人行为。在申请阶段,关于“沟通无效”的判断,是方针赋予社群中的个人的权力。否则,绝大多数历史案件都无法进入联署阶段(90%)。
  • 关于您之前提到的“朝着粗略共识方向协调”,按照原有方针和历史案例,那是在联署阶段进行的。联署阶段可以有效筛选掉不合理的提案。
  • 申请阶段的沟通是原告和被告之间的行为。联署阶段的沟通， “朝着粗略共识方向协调”，是被告与社群之间的行为。 --Gluo88（留言） 2023年10月1日 (日) 16:17 (UTC)

  您能否先以正常文法整理您的語言，除了還是本末倒置以外還有一樣是看不懂。--路西法人 2023年10月1日 (日) 16:01 (UTC)

  多谢指正，已经改了。关于回答的内容，在下感觉自己只是按照原有的方针和历史案例解读而已。 --Gluo88（留言） 2023年10月1日 (日) 16:18 (UTC)

  也一併回應某人，Gluo88君，其實問題真的不是由誰審核，而是有沒有審核，該不會告訴在下，哪個所謂不信任動議以及聯署是已經盡了社群審核、把關之責吧？上面多番強調，聯署有效篩走不合理提案，但抱歉，連最基本審核及分析都沒有。恕在下直言，感覺就像在起哄。完全看不到「聯署有效篩走不合理提案」。另外，麻煩不要再跟我提蟲蟲飛，如果他那也叫溝通，在下也無話可說。

  至於我問Mys後續，也不是要各位提二次彈劾。而是既然諸位都已經去到覺得此人留不得，覺得問題非溝通可以解決，為什麼沒有任何後續行動。在下實在很不解。所以連分析跟指出問題都不幹，大家是期望問題憑空消失？--J.Wong 2023年10月1日 (日) 23:09 (UTC)

  在下想請各位想想什麼是解任程序。解任投票真的不是判斷管理員有沒有違規之理想場所。解任投票的問題是「支持解任與否？」不是「管理員有違規與否？」請想想分別在哪。--J.Wong 2023年10月1日 (日) 23:23 (UTC)

  • 多谢您的回应和解释。“其实问题真的不是由谁审核,而是有没有审核”,我认同您的理解是正确的。按照原有的方针和历史案例,情况似乎是:提案人只是原告,原告的申请是提案人个人判断（=沒有審核）。初步社群审核在连署阶段进行。
  • 关于完全看不到“联署有效筛选不合理提案”,按照原有的方针和历史案例,联署只是筛选掉部分不合理提案,其他不合理提案依靠投票阶段筛选。
  • 同意“解任投票不是判断管理员违规的理想场所”。同意 解任投票的問題是「支持解任與否？」
  • 在下的主要关注是解任程序本身与原有方针和历史案例的一致性,而不是个案本身。其他人主要也是由于“沟通无效”的解释和判断权的分歧，而主要质疑终止投票的措施。
  • 在下个人感觉,如果社群目前无法就如何明确解释原方针达成共识,可以暂搁置问题,仍旧运用原方针及参照历史案例处理。即使在解释上有分歧,给大家更多时间思考,以后遇到争议再讨论。
  • 不知社群中有谁对英维的解任申请的条件熟悉？ 是提案人个人判断（=沒有審核）？还是社群判断？还是管理员判断？也许社群可以思考和调研一下，看看其方法和理据。
  • 只是个人浅见而已。 非常感谢您的关注。

  --Gluo88（留言） 2023年10月2日 (一) 00:08 (UTC)

已根据意见重新修改提案。--桐生ここ★[讨论] 2023年10月2日 (一) 02:25 (UTC)

(！)意見 在下目前想到两点：

1. 如果"申请人必须在事件发生之后尝试沟通至少48小时，在这段时间里应该尽量沟通解决。" , 但是 NoteforRFDA发生之后（ 注：NoteforRFDA发生之后当然也是事件发生之后）， 尝试沟通不到48小时， 历史按案例，会认为不满足申请条件。应该清晰化为：

   "申请人必须在NoteforRFDA发生之后尝试沟通至少48小时，在这段时间里应该尽量沟通解决。“

2. 注 1：按原方针和历史案例： 申请阶段的“沟通无效”否提案人个人判断。" 或者去掉注 1，按历史案件的惯例来判断。 --Gluo88（留言） 2023年10月2日 (一) 03:04 (UTC)

請停止發表本末倒置的看法。閣下現在的提案正正就是容許用戶在事件發生後立刻發NoteforRFDA即提起除權，而不是先溝通後除權。--路西法人 2023年10月2日 (一) 03:19 (UTC)