Wikipedia:互助客栈/方针

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

发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。

公告栏

• [公告] 在本地启用安全投票及electionadmin权限、调整COVID-19条目共识的规定、规范日本选举条目命名及禁止有关艺人演出的独立列表条目罗列非固定参与的节目已经通过。
• [公告] 修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应、选举监察员运作细节及开放自由提名管理员等权限申请、仲裁委员会成立后的管理人员解任机制、抄袭论述并入不要包含原始资料的副本指引、规范资讯框内母公司子品牌的列出方式（重公示）、修订用户名方针与用户页指引、赋予过滤器助理建立或修改防滥用过滤器的权限及修订政治人物关注度指引正在公示，如有意见请尽快提出。
• [讨论] 互助客栈方针区正在讨论不限期不是永久-解封指引与第二次机会、是否将格式手册移动到MOS命名空间下、在非原创方针新增例子以禁止综合常识及可靠来源、扩充ITNR获选类别及根据WP:用户页对WP:用户框进行修订，请踊跃参与讨论。
• [讨论] 互助客栈技术区正在讨论修订过滤器警告信息，请踊跃参与讨论。
• [讨论] 互助客栈条目探讨区正在讨论有关日本内阁条目的命名问题，请踊跃参与讨论。
• [讨论] 互助客栈其他区正在讨论实装Automoderator工具、是否应关闭中文维基百科以抗议基金会举措、管理人员任免制度检讨等事、本地部署安全投票及相关权限、禁制复核及提议将编辑提示内容同步到首页每日提示版块展示，请踊跃参与讨论。
• [讨论] 互助客栈试行案讨论区正在讨论讨论递进机制试行案-检讨意见分享，请踊跃参与讨论。
• [广告] 第四届台湾－斯洛伐克编辑松正在进行中，直到12月31日结束，欢迎踊跃贡献！

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

#	💭 话题	💬	👥	🙋 最新发言	🕒 (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)

过滤器助理组的设立

通过：

提案无人反对。规则条文将先行修改。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)

我通告User:ASid/回退员通告及通知名单User:ASid/回退员通告/SList，你们看一下可以的话就发送吧。--~~Sid~~ 2023年10月3日 (二) 01:50 (UTC)

看起来没什么问题。--冥王欧西里斯（留言） 2023年10月5日 (四) 07:37 (UTC)

修订WP:BANEX

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)

WP:BANEX 电子邮件版

现行条文 在以下情况下用户的编辑不受禁制影响： 回退非常显而易见的严重破坏（如页面被替换为不当内容）或违反生者传记方针的内容； 作必要且符合社群规范的争议解决，即提出对禁制本身的合理疑虑。此包括： 要求阐明禁制范围；及 提出禁制申诉。 被禁制用户进行其认为符合以上禁制例外情况的编辑行为，必须即时透过讨论页或编辑摘要等方式说明如何符合上述情况；如对某操作有否违反禁制有疑虑时，应要求澄清而非迳自为之。

提议条文 在以下情况下用户的编辑不受禁制影响： 回退非常显而易见的严重破坏（如页面被替换为不当内容）或违反生者传记方针的内容； 作必要且符合社群规范的争议解决，提出对禁制本身的合理疑虑等，即： 要求阐明禁制范围；及 提出禁制申诉；及 使用电子邮件向管理员陈述情况。 被禁制用户进行其认为符合以上禁制例外情况的编辑行为，必须即时透过讨论页或编辑摘要等方式说明如何符合上述情况；如对某操作有否违反禁制有疑虑时，应要求澄清而非迳自为之。

方针应该明确说明，例如互动禁制的对方如果到你的讨论页疯狂辱骂骚扰，你要怎么办？是否只能等着别人发现去提报。这次主要参考了竹生和Wong128hk的意见。---桐生ここ★[讨论] 2023年10月2日 (一) 03:29 (UTC)

但就现行条文而言，向管理员邮件列表寄送告状信已经是不违反禁制的渠道（虽然可能有不少人在遇到问题时可能不会想到有这样一条渠道），我的意见是在“应要求澄清而非迳自为之”后面加入相关指引性文字，比如“若需要检举互动禁制的另一方违反禁制，您可以向管理员邮件列表寄送电子邮件或到管理员的对话页作出举报，但注意进行后者时仍需遵守禁制”之类的。--🎋竹生🎍 2023年10月2日 (一) 13:34 (UTC)

@Newbamboo：

如果不做更改，“作必要且符合社群规范的争议解决”似乎没有必要保留，因为永远只能是“提出对禁制本身的合理疑虑”。

而且，“若需要检举互动禁制的另一方违反禁制”感觉有一种鼓励性质，而“到管理员的对话页作出举报”又涉及允许讨论页举报是否允许另一方在讨论下自辩。--桐生ここ★[讨论] 2023年10月6日 (五) 15:17 (UTC)

---

现行条文 在以下情况下用户的编辑不受禁制影响： 回退非常显而易见的严重破坏（如页面被替换为不当内容）或违反生者传记方针的内容； 作必要且符合社群规范的争议解决，即提出对禁制本身的合理疑虑。此包括： 要求阐明禁制范围；及 提出禁制申诉。 被禁制用户进行其认为符合以上禁制例外情况的编辑行为，必须即时透过讨论页或编辑摘要等方式说明如何符合上述情况；如对某操作有否违反禁制有疑虑时，应要求澄清而非迳自为之。

提议条文 在以下情况下用户的编辑不受禁制影响： 回退非常显而易见的严重破坏（如页面被替换为不当内容）或违反生者传记方针的内容； 提出对禁制本身的合理疑虑。此包括： 要求阐明禁制范围；及 提出禁制申诉。 被禁制用户进行其认为符合以上禁制例外情况的编辑行为，必须即时透过讨论页或编辑摘要等方式说明如何符合上述情况；如对某操作有否违反禁制有疑虑时，应要求澄清而非迳自为之。作必要且符合社群规范的争议解决，即使用电子邮件向管理员陈述情况请求处理亦不违反禁制。

按照竹生意见重新修改。--桐生ここ★[讨论] 2023年10月6日 (五) 15:32 (UTC)

公示 7 日：自 2023年10月13日 (五) 15:32 (UTC) 开始公示，于 2023年10月20日 (五) 15:32 (UTC) 结束公示。（提醒：此公示有可能需要更新公告栏，请协助更新。公示期间如有反对意见则此公示无效。）--桐生ここ★[讨论] 2023年10月6日 (五) 15:45 (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)

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

相关讨论见此（尖刀蛏的同行评审讨论），简单地说就是我在各类格式手册（包括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)

宜用比号而非冒号？推荐使用比号，不得用冒号，难道还有什么不推荐但也没被否定的符号…？--洛普利宁 2023年10月2日 (一) 08:51 (UTC)

比如%，成（三成，七成），分数和$^{1}/_{2}$之类的。--落花有意12138 2023年10月3日 (二) 02:13 (UTC)

但是我的感觉是，分数表示“比运算的结果”，而不是比本身……可能您的意思是“不应用冒号替代比号”。--洛普利宁 2023年10月3日 (二) 13:16 (UTC)

比号算是冒号的一种吧？似乎不在正式标点符号名单中。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年10月2日 (一) 09:05 (UTC)

[2]，部分语言下混用，但至少中文应当区分。--YFdyh000（留言） 2023年10月2日 (一) 09:35 (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)

同荷花意见。--桐生ここ★[讨论] 2023年10月2日 (一) 05:04 (UTC)

罢，我收回我的反对意见。不过我们得想办法处理不合理附言的问题，例如这个 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月2日 (一) 16:26 (UTC)

基金会人员或监管员、选举管理员是否可以看到对应关系？如果确有必要是否可请基金会移除对应票？--桐生ここ★[讨论] 2023年10月2日 (一) 17:07 (UTC)

原先我是打算移除必须写明理由的，因为RFA也没有强制要求。不过看到您所举例，我觉得或许可以用另外一种方法，不使用安全投票的投票选项，安全投票里只有留言框。

投票方式是在留言框内写：

• 支持：原因理由巴拉巴拉。
• 反对：原因理由巴拉巴拉。
• 啦啦啦啦。（不写支持反对的废票）

--桐生ここ★[讨论] 2023年10月2日 (一) 17:17 (UTC)

• 我修改的是条件跟提出，这里修改的是过程，其实刚好没有overlap，两个修订可以同步进行。顺带一提我支持用安全投票-某人✉ 2023年9月30日 (六) 13:36 (UTC)

---

现行条文 答辩：在解任提出后，被解任人有5天的答辩期，对于解任申请中指出的问题进行答辩。被解任人（或他许可的其他用户）可以整理答辩内容，并置于解任理由之下，这些内容不被折叠。如果解任人在5天内没有答辩，被视为无答辩意见，不过仍可在投票期间发表意见。 投票：答辩期过后，进入投票程序。投票期为14天，符合人事任免投票资格者（不包括被解任人）可以投支持票（同意解任）或反对票（反对解任），也可以在讨论区发表意见，无论支持票还是反对票，投票人需给出理由。联署人自动计为支持解任，但仍可以在投票期间改变意向。用户可以在投票期内改变立场，结果以投票期结束后为准。重复投票和傀儡投票将被视为无效票。 结果：有效表决的最低总有效票数为25票。如总有效票数低于25票，则不论结果如何，均视为解任案不通过。若总有效票数达至少25票，且支持解任票数多于一半者，则投票通过。惟怀疑投票结果被作弊或其它不恰当行为严重影响，可由行政员讨论决定该次投票是否有效。 收回权限：投票结果为解任时，则由行政员除权或将社群的共识提报给元维基，申请收回该管理人员的权限。

提议条文 准备：在联署通过后，开始进行安全投票的准备程序。同时，被解任人有5天的答辩期，对于解任申请中指出的问题进行答辩。被解任人（或他许可的其他用户）可以整理答辩内容，并置于解任理由之下，这些内容不被折叠。如果被解任人在5天内没有答辩，被视为无答辩意见，不过仍可以继续发表意见。 投票：安全投票开启后，应至少持续二周。符合人事任免投票资格者（不包括被解任人）可以投支持票（同意解任）或反对票（反对解任），投票人需在附言框给出理由。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。重复投票和傀儡投票将被视为无效票。 监票：若本地有两名或以上监督员在安全投票开始前表示愿意监票，则由愿意执行监票工作的监督员与其他监管员共同协助监票。若本地能够执行监票工作的监督员不足两人，则由监管员独自负责监票。 计票和评估：在投票时间结束后，由监票者计算出得票比率。有效表决的最低总有效票数为25票。如总有效票数低于25票，则不论结果如何，均视为解任案不通过。若总有效票数达至少25票，且支持解任票数多于一半者，则投票通过。惟怀疑投票结果被作弊或其它不恰当行为严重影响，可由行政员讨论决定该次投票是否有效。 解除权限：投票结果为解任时，则由行政员除权或将社群的共识提报给元维基，申请解除该管理人员的权限。

使用比较条文，另外也做了修改。--桐生ここ★[讨论] 2023年10月2日 (一) 18:27 (UTC)

是否同意按此修订方针？

RFDA方针修订涉及重大，Ping之前参与讨论的人@AINH、魔琴、Hehua、YFdyh000、Mafalda4144、Ericliu1912、Sanmosa、Yichen Ding、Z7504、Cwek、S8321414、1233、Dewadipper、ATannedBurger、Psycho CSL、AT、Gluo88，打扰见谅。--桐生ここ★[讨论] 2023年10月6日 (五) 17:49 (UTC)

大致( ✓ )同意，不过投票人给出的理由会和RFA一样在开票之后不记名展示吗？——Aggie Dewadipper ※ Beat Griz! 2023年10月6日 (五) 20:37 (UTC)

(＋)支持。若要回应楼上的疑问，个人觉得可以全部不记名展示，然后若是有发现投票理据具有争议者可不计该票（换句话说，展示出的投票附言数应与所有票数加起来一样）。个人觉得在保留隐私但又需要确认理据是否合理的情况下将附言不记名展示确实是最好的办法。至于之前提到的SecurePoll筹备繁琐有悖RFDA防止管理继续OOO（自填，我想假定善意）的论点，我认为社群不妨也趁这段准备期间再多想想这位管理是否值得解任。若是担心该被解任管理员会在投票期间继续引发争议，可自联署达到门槛后暂时除权直到有投票结果为止，然后再根据投票结果决定是否维持权限。--$\int$（☎）dt 2023年10月6日 (五) 22:03 (UTC)

(＋)倾向赞成，但要怎么确认哪个附言对应的是哪种票？请监票人处理？--冥王欧西里斯（留言） 2023年10月6日 (五) 22:55 (UTC)

如果监票人、基金会可以处理就维持原样，如果不能处理，可以考虑安全投票里不设投票选项，只有附言框，投票方式是：

你同意解任管理员XXX吗？

• 支持请在附言框写“支持：原因理由”。
• 反对请在附言框写“反对：原因理由”。
• 不按照上述格式为废票、弃权。
• 附言框：[ 支持：XXXX。 ]

另外上面提到的SecurePoll筹备繁琐，如果当事人确实继续滥用权限也可以由另外一位管理员先封禁再继续投票。--桐生ここ★[讨论] 2023年10月7日 (六) 02:26 (UTC)

大致赞成。--在下荷花，请多指教（欢迎签到） 2023年10月7日 (六) 00:36 (UTC)

( ✓ )同意--PC 2023年10月7日 (六) 02:14 (UTC)

感觉差别不大，大致支持。“需在”是“须在”吗，是否真的有意义，比如“支持”是有效理由吗，“+++”呢，“可信/不可信”呢。很担心监票或行政员指摘理由和废除特定投票，包括如“理由不成立”。--YFdyh000（留言） 2023年10月7日 (六) 07:32 (UTC)

我认为监票员或行政员除非在已经过社群讨论的情况下不应指摘和废除投票，应在投票结束并贴出全部附言后再去讨论是否个别投票有无“意义”。--$\int$（☎）dt 2023年10月7日 (六) 08:32 (UTC)

当然我亦不反对可提前讨论一些一望而知为无意义的投票以便监票员或行政员快速辨认何为不适当的投票理据，但这个问题和本讨论欲解决的问题并无直接关联。且假如社群对监票员/行政员没有足够信任，那还是避免掺入黑箱操作比较好。--$\int$（☎）dt 2023年10月7日 (六) 08:40 (UTC)

最后的“收回权限”提到：“投票结果为解任时，则由行政员除权或将社群的共识提报给元维基，申请收回该管理人员的权限。”实际上行政员只能授权，无法移除介面管理员以外的管理人员权限。因此，行政员除权的说法只适用于介管。--AT 2023年10月7日 (六) 09:31 (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)

所以回到主题，到底要不要大发慈悲的说一下太阳倒数这四个字到底怎么个犯忌？什么机缘下封的？要怎么样才不会重蹈覆辙？到底要封到什么时候？不想给理由能不能至少写个我高兴？不想给期限可不可以至少说是无限期？连讨论页都保护起来可不可以别还摆个您可以和其他人讨论此页嘲弄人？

至少至少至少，太阳倒数在那堆正则表达式的哪一行？有没有注解？有没有人可以修？有没有人想去修？有没有？有—没—有？

再叫我猜，我就要猜是因为最红最红的红太阳才封掉太阳倒数。而且若对维基百科没有爱，早就在这一大堆啰唆之前先好好散布自家的猜想了。所以不要再留些隐语叫人猜了。猜测久了会变猜疑，猜疑久了就变猜忌。到最后各位就会看到有人一上来就莫名其妙的大发脾气，然后各位就很正义的把人给封了。各位一定都遇过这种事。再这样搞下去的话，以后一定还有，莫谓言之不预。2603:8000:500:FB00:691B:A1A:9F86:CE39（留言） 2023年10月5日 (四) 05:39 (UTC)

WP:VPT#神秘的半保护页面，标题黑名单就是这样，没日志。--桐生ここ★[讨论] 2023年10月5日 (四) 06:31 (UTC)

• “太阳倒数这四个字到底怎么个犯忌？”因为标题含有“数”或者“数”。
• “什么机缘下封的？”因为WP:X43。
• “不想给理由能不能至少写个我高兴？”这种规则都是因为破坏者太多了才设立的，就好像清洁工看见垃圾太多了会高兴吗？
• “要怎么样才不会重蹈覆辙？到底要封到什么时候？”我问一下当时添加规则的管理员。
  • @Xiplus：.*[數数]于2022年加入，既然这位匿名用户回报有误报，是否可以改用过滤器监视呢？这样至少可以留记录。

--砜中嘌呤的白磷_{萃取 打谱} 2023年10月6日 (五) 15:34 (UTC)

这部电影还有其他中文译名，可不可以就用改名的方式避掉“数”呢？至于这种滥杀无辜的一字式封法有多么正义，没这边的事就不用费神解说了。反过来说，如果还要这样封下去，这边就会继续想出自以为是的理由及看来可笑的解方来与已经烦不胜烦的管理员互惹对方生气。2603:8000:500:FB00:F883:820D:283A:460（留言） 2023年10月7日 (六) 05:21 (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)

我认同Gluo88在上面提出的“沟通无效的判断人是提案人”。下一步联署可作进一步验证。

我的理解是无效就是没有解决问题，即提案人和被提案人没有共识。--落花有意12138 2023年10月2日 (一) 08:10 (UTC)

那么任何一个提案人即可死活不同意沟通有效，从而必然构成此条件以继续弹劾。由提案人判断是否沟通有效有显然的利益冲突。--路西法人 2023年10月2日 (一) 08:17 (UTC)

下一步联署可以做进一步验证，也就是可以加上一句“联署人应该检查程序是否合规”。另一方面，即使确定了“沟通无效”的定义，提案人依然可以因为利益冲突无视这一定义。--落花有意12138 2023年10月2日 (一) 08:26 (UTC)

所以根本从头到尾都不应该由提案人去确认此一条件，而是应与当前进行的RFA一样，沟通过，联署完，先由行政员确认再开始后续解任流程。--路西法人 2023年10月2日 (一) 09:26 (UTC)

联署失败或雪球关闭足以应对，以前不是没有过。达成联署的重大争议，不是解任流程限制或行政员决断所能所应解决的，除非出现傀儡等额外问题而暂停。如果出现继续沟通可行，应允许联署人撤回。--YFdyh000（留言） 2023年10月2日 (一) 08:30 (UTC)

“显然不当强行联署解任”显然需要讨论共识。如果讨论不充分，我不反对行政员暂停投票流程并推进继续讨论，但不赞成以没有共识的理由（观点）终止流程。目前看，流程终结后未有明显“沟通程序”出现。--YFdyh000（留言） 2023年10月2日 (一) 08:46 (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小时之后才能提出，在这段时间里当事人之间应该尽量沟通。只有在沟通无效的情况下才可以发起取消管理员权限的投票。内容必须详细，指出管理滥权的原因，并根据编辑记录及用户贡献提出相关证据，如内容不符或原因不合理，可视作申请无效。为了防止一案多审，除非有新证据出现，否则不得就同一事件重复提起解任。

提议条文 条件：必须在事件发生之后已发起沟通至少48小时，在这段时间里当事人之间应该尽量沟通，只有在沟通无效的情况下才可以提出解任投票。为了防止一案多审，除非有新证据出现，否则不得就同一事件重复提出解任。 提出：由一名自动确认用户提出解任管理员申请并说明理由，内容必须详细指出管理滥权的原因，并根据编辑记录及用户贡献提出相关证据。提出解任管理员申请后，必须随即在该管理员的用户对话页留言通知（可使用{{NoteforRFDA}}）。

注解

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

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

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

修改了高亮，并删除未变化的部分（应该未变化罢） ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月2日 (一) 16:39 (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，按历史案件的惯例来判断。
3. 只是按原方针和历史案例可以更明确地解读,没有新变化。上面建议隐含： 无论事件发生之后，或NoteforRFDA发生之后， 都不能立刻申请，都需沟通至少48小时。 --Gluo88（留言） 2023年10月2日 (一) 03:04 (UTC)

以上Gluo88之留言曾于2023年10月2日 (一) 04:15 (UTC)修改，因修改后造成讨论扭曲而以绿色背景色注明为留言后新增。--路西法人 2023年10月2日 (一) 07:03 (UTC)

请停止发表本末倒置的看法。阁下现在的提案正正就是容许用户在事件发生后立刻发NoteforRFDA即提起除权，而不是先沟通后除权。--路西法人 2023年10月2日 (一) 03:19 (UTC)

本人（LuciferianThomas）回复前此处原有留言，因用户在回复后删除并重新留言造成明显扭曲讨论，故恢复回复当下存在之留言以证。--路西法人 2023年10月2日 (一) 07:03 (UTC)

(！)意见阁下的“请停止发表本末倒置的看法。”让我很不舒服。

• 每个人的看法都是主观的，在下认为：阁下对在下这种评价“请停止发表本末倒置的看法”，不应该。
• 把在下的看法加上“本末倒置的看法”评价, 用"请停止"这样的命令式的? 在下都不知道怎样形容才好?
• 如果相互都是用这种方法指责对方， 如何能进行理性的文明的讨论？
• 不知我是否能继续讨论。在下敬请社群发表看法.

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

管理员解任投票是一个最终手段，在发起投票前应先经过充分的讨论、再三确认，以避免造成不必要的误会是WP:解任方针的条文，是客观的基本原则，不存在“主观的看法”的空间。持续推动先提解任后解释的就是将方针的基础给掀开，妥妥的本末倒置。--路西法人 2023年10月2日 (一) 03:36 (UTC)

(！)意见阁下的“请停止发表本末倒置的看法。”让我很不舒服。

• 每个人的看法都是主观的，在下认为：阁下对在下这种评价“请停止发表本末倒置的看法”，不应该。
• 把在下的看法加上“本末倒置的看法”评价, 用"请停止"这样的命令式的? 在下都不知道怎样形容才好?
• 如果相互都是用这种方法指责对方， 如何能进行理性的文明的讨论？
• 在下敬请社群发表看法， 关注文明讨论的问题。关注把和自己相反的意见加上“本末倒置”的标签， 阻止对方发表与其相反的意见。
• 不知我是否能继续讨论。

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

批评阁下“本末倒置”就成了不文明，显然的滑坡谬误。每逢被批评就给批评者冠上不文明的高帽，跟WMLO滥用“文明”指控有何分别？阁下一再执意推行违反方针原则的意见，甚至为了营造我没事找事、“不文明”的形象两次在我回复之后更改自己留言，请停止扰乱讨论正常秩序。--路西法人 2023年10月2日 (一) 07:17 (UTC)

已再一次修改条文，使其贴近原方针。桐生ここ★[讨论] 2023年10月2日 (一) 08:36 (UTC)

旧版已被放弃。--桐生ここ★[讨论] 2023年10月3日 (二) 17:14 (UTC)

折中方案 新版

现行条文 提出：由一名自动确认用户提出解任管理员申请，并说明理由。提出解任管理员申请后，必须随即在该管理员的用户对话页留言通知（可使用{{NoteforRFDA}}）。 条件：申请必须在事件发生48小时之后才能提出，在这段时间里当事人之间应该尽量沟通。只有在沟通无效的情况下才可以发起取消管理员权限的投票。内容必须详细，指出管理滥权的原因，并根据编辑记录及用户贡献提出相关证据，如内容不符或原因不合理，可视作申请无效。为了防止一案多审，除非有新证据出现，否则不得就同一事件重复提起解任。

提议条文 条件：申请前必须已发起沟通至少48小时，在这段时间里当事人之间应该尽量沟通，只有在沟通无效的情况下才可以提出解任投票。为了防止一案多审，除非有新证据出现，否则不得就同一事件重复提出解任。 提出：由一名自动确认用户提出解任管理员申请并说明理由，内容必须详细指出管理滥权的原因，并根据编辑记录及用户贡献提出相关证据。提出解任管理员申请后，必须随即在该管理员的用户对话页留言通知（可使用{{NoteforRFDA}}）。

注解

@AINH：不知道您是否认可这个版本。--桐生ここ★[讨论] 2023年10月2日 (一) 09:00 (UTC)

修改了高亮，删除了未更动的部分。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月2日 (一) 16:56 (UTC)

已再修改，试图贴近AINH的提案。--桐生ここ★[讨论] 2023年10月3日 (二) 16:37 (UTC)

我还是认为应该将所有硬条件都删除。即使保留“只有沟通无效”为折中也不是不能，但还是回到一开始的两大问题：

1. 由谁判定？
2. 怎样判定？何谓“沟通无效”？

这两个问题没有清晰定义还真的很难说“是否认可”--某人✉ 2023年10月3日 (二) 16:06 (UTC)

鉴于有人把和自己相反的意见加上“本末倒置”的标签，用"请停止"这样的命令式， 阻止对方发表与其相反的意见。和鉴于其随后的做法，为了保持文明讨论的气氛， 在下退出讨论。--Gluo88（留言） 2023年10月2日 (一) 11:13 (UTC)

各方意见总结

某人：

• 取消沟通无效以及内容不符/合理的硬条件。
• 行政员与社群判断罪状是否成立存在矛盾怎么办。

Mafalda4144：

• 不绑定48小时。
• 不允许翻旧帐。
• 破坏者们尽到通知义务后发起连署，管理员们光是处理这些就饱了。
• 可以先提报到不当的行为。

路西法人：

• 避免提了解任才讨论，保留事件发生后48小时才开始解任程序。
• 反对移除沟通无效的条文，但应增加社群普遍认同违规事实情节严重。

落花有意：

• 沟通无效就是没有解决问题，即提案人和被提案人没有共识。
• 联署人应该检查程序是否合规。

YFdyh000：

• 联署失败或雪球关闭足以应对。
• 达成联署的重大争议，不是解任流程限制或行政员决断所能所应解决的，除非出现傀儡等。
• 应允许联署人撤回。

J.Wong：

• 确保有足够沟通，确保争议并非沟通可以解决。
• 确保所列罪状成立，经过审核，才进入下一阶段。
• 投票由始至终都应该只是扮演最后确认的部分，大家不是陪审团。
• 联署连最基本审核及分析都没有，看不到有效筛走不合理提案。

Gluo88：

• 历史案例中沟通无效/确保所列罪状成立的判断是提案人个人。
• 联署筛选掉部分不合理提案，其他不合理提案依靠投票阶段筛选。

意见可能会遗漏、删减、理解错误的情况，见谅。桐生ここ★[讨论] 2023年10月3日 (二) 17:57 (UTC)

才看到。咱先说咱的观点：绝对禁止联署期被提名解任的管理员游说取消联署。私以为这和拉票行为没有区别。--忒有钱 凪のあすから 10th Anniversary（留言） 2023年10月3日 (二) 18:19 (UTC)

冷静期不是我修订的核心，纯粹在Mys后续争议有此讨论我顺带划入去一并修改。我对此本身没有什么意见--某人✉ 2023年10月3日 (二) 18:23 (UTC)

括号内为附注
某人：

• 取消沟通无效以及内容不符/合理的硬条件。（沟通无效由提案人判断；内容不合理由联署人判断）
• 行政员与社群判断罪状是否成立存在矛盾怎么办。（已是社群判断）

Mafalda4144：

• 不绑定48小时。（没有绑定）
• 不允许翻旧帐。（解任条件已限制）
• 破坏者们尽到通知义务后发起连署，管理员们光是处理这些就饱了。（即使现在也可以满足要求就发起联署，即使不满足他也可发到客栈，无视他们）
• 可以先提报到不当的行为。（提报到客栈）

路西法人：

• 避免提了解任才讨论，保留事件发生后48小时才开始解任程序。（申请前必须已发起沟通至少48小时）
• 反对移除沟通无效的条文，但应增加社群普遍认同违规事实情节严重。（没有移除；紧急除权可处理）

落花有意：

• 沟通无效就是没有解决问题，即提案人和被提案人没有共识。（已写在总结内容）
• 联署人应该检查程序是否合规。（要求联署人需审核）

YFdyh000：

• 联署失败或雪球关闭足以应对。（已写在总结内容）
• 达成联署的重大争议，不是解任流程限制或行政员决断所能所应解决的，除非出现傀儡等。（社群解决；傀儡由行政员解决）
• 应允许联署人撤回。（已写在总结内容）

J.Wong：

• 确保有足够沟通，确保争议并非沟通可以解决。（已写在总结内容）
• 确保所列罪状成立，经过审核，才进入下一阶段。（联署人审核，并要求提供分析确保联署人已审核）
• 投票由始至终都应该只是扮演最后确认的部分，大家不是陪审团。（已写在总结内容）
• 联署连最基本审核及分析都没有，看不到有效筛走不合理提案。（要求联署人审核并提供分析确保联署人已审核）

Gluo88：

• 历史案例中沟通无效/确保所列罪状成立的判断是提案人个人。（已写在总结内容）
• 联署筛选掉部分不合理提案，其他不合理提案依靠投票阶段筛选。（已写在总结内容）

综合上方意见，互相融合、抵消之后的结果：

• 申请前必须已尝试沟通至少48小时，确保有足够沟通。
• 沟通无效就是没有解决问题，即提案人和被提案人没有共识，争议并非沟通可以解决，提案人认为所列罪状成立及沟通无效后提报到互助客栈。
• 社群普遍认同违规就会参与联署，联署人应该审核所列罪状后提供联署理由及分析，投票做最后确认；联署人也可自行决定撤回联署，联署及投票会筛选掉不合理提案。出现傀儡这类复杂情况由行政员暂停。--桐生ここ★[讨论] 2023年10月3日 (二) 19:06 (UTC)

根据上方结果的修订案：

现行条文 提出：由一名自动确认用户提出解任管理员申请，并说明理由。提出解任管理员申请后，必须随即在该管理员的用户对话页留言通知（可使用{{NoteforRFDA}}）。 条件：申请必须在事件发生48小时之后才能提出，在这段时间里当事人之间应该尽量沟通。只有在沟通无效的情况下才可以发起取消管理员权限的投票。内容必须详细，指出管理滥权的原因，并根据编辑记录及用户贡献提出相关证据，如内容不符或原因不合理，可视作申请无效。为了防止一案多审，除非有新证据出现，否则不得就同一事件重复提起解任。 联署：7日内，必须收集至少7名有投票资格的用户联署，用户可以在互助客栈提出解任的意向，并征求联署人。满7人联署后解任案方为成功提出。一旦收集到7名联署人，则立即进入下一阶段。7日后仍未有足够联署者，被提解任人无须答辩，解任案自动失效。

提议条文 条件：申请前必须已尝试沟通至少48小时，在这段时间里当事人之间应该尽量沟通解决，只有在沟通无效的情况下才可以提出解任投票。为了防止一案多审，除非有新证据出现，否则不得就同一事件重复提出解任。 提出：由一名自动确认用户在互助客栈提出解任管理员申请并说明理由，内容必须详细指出管理滥权的原因，并根据编辑记录及用户贡献提出相关证据。提出解任管理员申请后，必须随即在该管理员的用户对话页留言通知（可使用{{NoteforRFDA}}）。 联署：7日内，必须收集至少7名有投票资格的用户联署，联署人应检查解任申请的理由及证据，确认符合解任条件，并提供联署理由，满7人联署后解任案方为成功提出。一旦收集到7名有投票资格的联署人，则可以进入下一阶段，亦可由行政员讨论决定适当延长联署期，推迟进入下一阶段，以期社群进行更多的沟通。联署期间，联署人也可自行决定撤回联署。7日后仍未有足够联署者，被提解任人无须答辩，解任案自动失效。惟怀疑联署结果被作弊或其它不恰当行为严重影响，可由行政员讨论决定重新进行一次联署。

注解

--桐生ここ★[讨论] 2023年10月3日 (二) 20:01 (UTC)

内容已修改。--桐生ここ★[讨论] 2023年10月4日 (三) 01:47 (UTC)

再一次修改，增加行政员可要求重新进行一次联署。--桐生ここ★[讨论] 2023年10月4日 (三) 03:04 (UTC)

内容已修改，依据LuciferianThomas意见。--桐生ここ★[讨论] 2023年10月4日 (三) 13:19 (UTC)

再加一句补底，路西法君会否仍认可此版本？-某人✉ 2023年10月4日 (三) 14:25 (UTC)

按照魔琴所说修改。--桐生ここ★[讨论] 2023年10月5日 (四) 04:45 (UTC)

---

(＋)支持-某人✉ 2023年10月4日 (三) 02:17 (UTC)

这里的“当事人之间没有共识”又如何认定？Sanmosa _{віки-віків} 2023年10月4日 (三) 08:13 (UTC)

再次重申，“争议”不应是发起解任管理员的原因，“经社群确认滥用编辑或管理权限”才应是主因。--路西法人 2023年10月4日 (三) 11:06 (UTC)

虽然有点无限回圈感，但也是想知道，当事人之间看来没有共识时该怎么办？没有共识就进行联署是可以的？没有缓起诉观察期吗？--Mafalda4144（留言） 2023年10月4日 (三) 11:30 (UTC)

怎么就不可以了？巡退都没有甚么“缓起诉观察期”，怎么管理员的门槛比巡退还宽松了？--某人✉ 2023年10月4日 (三) 12:19 (UTC)

所以是无论有没有聊出个结果，只要发起人觉得时间到了还是没共识，就是进行下去，对吗？即使被提报者觉得我有在进行讨论了，也还是要看发起人的感觉，我的理解没错吧？--Mafalda4144（留言） 2023年10月4日 (三) 13:02 (UTC)

我认为“确实符合解任条件”更加清楚一点，也能回应上文的要求。“不合理[地...]以封禁相威胁”和“严重违反社群共识及礼仪”两项似乎不算“滥用编辑或管理权限”……但如果改成这样这句似乎说了等于没说……🤔 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月4日 (三) 19:18 (UTC)

副知@AINH、LuciferianThomas ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月4日 (三) 19:19 (UTC)

封锁本是管理权限，不合理的封锁威胁（即，并非基于方针指引而以封锁胁迫其他用户）则属于“有明显意图滥用管理权限”。严重违反社群共识及礼仪分开说，前者违反社群共识的部分属于滥用编辑权限；违反礼仪则除了失控的辱骂和人身攻击，否则因人人道德标准不同，几乎不可能会有社群共识表明违反礼仪，多数只能构成“争议”，而非常明显（如前述情况）则可归类滥用编辑（专案或讨论页）权限。单纯的“争议”不必然构成“滥用编辑权限”，但“滥用编辑权限”则必然造成“争议”，解任针对的必须是滥用权限而非争议。--路西法人 2023年10月5日 (四) 07:29 (UTC)

这样更改后，除了稍稍让解任流程更清楚一点之外，又有什么实质性改变？--Yining Chen（留言|贡献） 2023年10月6日 (五) 09:32 (UTC)

让方针更清楚，也符合当初的设立的精神，双方都不反对，就是最好的改变。--桐生ここ★[讨论] 2023年10月6日 (五) 13:22 (UTC)

但注解一，还是没有说明，有在沟通但没共识之下，还是要进行下去吗（也没人壳以回答啊～），我先前说的缓刑或观察接近这个意思，若有在沟通了，是否能暂缓，观察其后续行为呢？还是大家就认为就是进行下去，反正投票即正义？--Mafalda4144（留言） 2023年10月7日 (六) 02:27 (UTC)

原本的方针也没有写观察期，而且谁来宣布停止联署进入观察期，仲裁委员会吗？--桐生ここ★[讨论] 2023年10月7日 (六) 02:33 (UTC)

巡退都没有甚么“缓起诉观察期”，怎么管理员的门槛比巡退还宽松了？有沟通就是免死金牌？那么虫虫飞是不是也不能弹劾了？--某人✉ 2023年10月7日 (六) 02:58 (UTC)

“是否能暂缓，观察其后续行为呢”，解任投票完成但失败就是暂缓，等于存在意愿解任，但无明确共识（过半支持），且间隔至少6个月是相当长的观察期了。--YFdyh000（留言） 2023年10月7日 (六) 07:24 (UTC)

(＋)赞成--YFdyh000（留言） 2023年10月7日 (六) 07:26 (UTC)

我知道理念已经是这样，但可否明文写进去“沟通无效由提案人判断”-某人✉ 2023年10月7日 (六) 07:45 (UTC)

这不对吧，明显会增加扰乱，谁都可以主观认为无效或必然无效并提案。至少要有局部共识。如果要书面化，比如要求（建议）确认可能获得至少2人联署——根据观察近期讨论，比如有人提议或赞成；否则可能被雪球关闭——比如明显扰乱，明显仍在有效沟通（需有进展），或者3日后无联署趋势（仅为想法，未必明确约定）。--YFdyh000（留言） 2023年10月7日 (六) 08:07 (UTC)

Non free系列模板的|image has rationale参数

我们会看到非自由使用图片的模板里有这样一句话

致管理员与巡查员：如果本图像拥有一个合适的合理使用依据，请在本授权模板增加|image has rationale=yes参数。

这个参数带出了两个庞大的维护分类，但实际上，巡查文件时，几乎没有人给文件加上这个参数，也很少有人在图片上点击巡查按钮。这里想提问，这个参数到底有没有用，如果有用能否通过一些工具或者机器人等手段让它应用起来，如果没有用要不要取消这一参数？以上。--在下荷花，请多指教（欢迎签到） 2023年10月4日 (三) 15:40 (UTC)

是否可对Wikipedia:存废复核请求的管理员结论格式进行一定规范？

目前存废复核虽已规定管理员应给予“维持原决”、“发还/转介”、“推翻”、“要求介入”等结论，但是目前存废复核却并不如WP:AIV（当前的破坏）、WP:RFR（权限申请）等页面一般有一个约定俗成的结论格式规范。个人认为，如果能非强制性、给予一种建议性质的格式规范可以使存废复核的结论更加直观。个人设想的结论格式如左：

接受：推翻。支持申请人主张。

 驳回：维持原决，即维持原本的删除/保留决定。

 转交存废讨论：发还/转介，发回重新进行存废讨论。

搁置至讨论完成：要求介入（目前较少使用）。

不相关/ 不适用：非存废复核受理范围、提请页面未被删除等等情形。

希望大家提出意见。--クオン·千の海を越えて·愛おしき欠片 2023年10月6日 (五) 13:58 (UTC)

( ✓ )同意，建议做出类似{{RSNG}}、{{Blocked}}的专用回复模板，方便管理员标记，并考虑增加“还原并(►)移动到草稿”、“允许重建”等情况。--桐生ここ★[讨论] 2023年10月6日 (五) 14:36 (UTC)