维基百科:互助客栈/其他

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

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

公告栏

• [公告] 快速删除方针R7款的调整及第一届仲裁委员会选举方案已经通过。
• [公告] 微调放宽中文名注明位置、提议引入CollapsibleToggle作为默认启用可选择关闭的小工具、设立编者著作权调查、新闻动态/重复发生的项目中的领导人更替、引进CampaignEvents扩展、公布管理人员任免案有资格投票者人数及名单及为非原创研究方针翻译章节部分新增补充说明正在公示，如有意见请尽快提出。
• [公告] 讨论页话题索引现正重投测试。如有意见、建议或报错，请至互助客栈的讨论串提出。
• [讨论] 互助客栈条目探讨区正在讨论末任中华民国大陆时期一级行政区行政首长列表是否应即时撤销FL资格的问题，请踊跃参与讨论。
• [讨论] 互助客栈其他区正在讨论管理人员任免制度检讨等事及第一届仲裁委员会选举方案细节，请踊跃参与讨论。
• [讨论] 快速删除方针讨论页正在讨论快速删除方针O4款的调整，请踊跃参与讨论。
• [讨论] Unblock-zh.org正在试运行。同时互助客栈继续对于其各项细节征求意见。
• [通知] 深色模式现已供所有行动版及桌面版网站（Vector 2022和Minerva皮肤）的用户使用。如有任何问题，欢迎在讨论页或通过页面右侧的回报功能提出。
• [协作] 第二十二次动员令于7月6日至9月8日间举行，欢迎踊跃参与！

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

#	💭 话题	💬	👥	🙋 最新发言	🕒 (UTC+8)
1	评级系统缺失问题	1	1	Jimmy-bot	2024-08-27 00:29
2	Unblock-zh.org	84	16	Bluedeck	2024-08-20 16:16
3	请求社群判断已经数据过期的用户是否为傀儡	6	3	MCC214	2024-08-25 12:27
4	仲裁委员会的选举	40	8	人间百态	2024-08-27 12:58
5	中华台北、中国台北、中国北京、中华北京都是高风险主题	1	1	Jimmy-bot	2024-08-27 00:29
6	引进CampaignEvents扩展	5	4	人间百态	2024-08-26 21:20
7	再议设立编者著作权调查	9	5	人间百态	2024-08-24 14:29
8	为管理人员任免制度检讨等事	42	15	Ericliu1912	2024-08-26 23:36
9	关于新建LTA页面	16	6	Nostalgiacn	2024-08-25 13:27
10	管理操作复核请求：被提报用户明显存在不文明行为时拒绝做出相应处理	21	8	UjuiUjuMandan	2024-08-26 16:45
11	请求CCI Lki5168	13	6	Lemonaka	2024-08-28 02:00
12	管理操作复核请求：不对显然违反双向交互禁制的行为进行处理	8	3	自由雨日	2024-08-28 04:27

发言更新图例
最近一小时内
最近一日内
一周内
一个月内
逾一个月
特殊状态
已移动至其他页面 或完成讨论之议题
手动设置
当列表出现异常时， 请先检查设置是否有误

正在广泛征求意见的议题

以下讨论需要社群广泛关注：（重新整理）

维基专题与协作

目前此主题无正在讨论的议题

Unblock-zh.org

Unblock-zh.org网站的样子

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）7月7日update：软件进入试运行阶段，此时产生的工单等数据将永久保留。Bluedeck 2024年7月8日 (一) 19:21 (UTC)

附带一个教学视频 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外用户申请账号的方式是Wikipedia:账号请求发送邮件，其实也没有太不方便。但是这个途径我觉得还是更直观一点，比邮件列表好用一点，尤其是管理员处理的时候。我的想法是网站可以和邮件列表并存，或者以后达成互联。欢迎提出意见。Bluedeck 2024年4月29日 (一) 04:05 (UTC)

PS. 已经收到tigerzeng的意见，允许用户自定义提供的IP地址字段，以解决部分代理的问题。Bluedeck 2024年4月29日 (一) 04:22 (UTC)

超 英 赶 美 —— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月29日 (一) 08:09 (UTC)

我最期待的画面出现了。--AT 2024年4月29日 (一) 09:14 (UTC)

好吧，终于把这个弄出来了——是蓝桌弄的？那就不出奇了。 赞——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)

非常好UX。至于是否方便了用户，我好奇能否在合理的范围内收集一些统计数据作对比，这样最有说服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)

另外这个工具让我想到了我很久之前做的维基媒体服务器连通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)

非常好软件。

不必要的功能建议：1.通过遍历封禁日志的摘要有无对应模板，显示是否是ip封禁。2.通过接口调用在界面一键创建账户（和授予ipbe？）

另外问一下数据托管在哪里？将来投入使用的话需要作为存档使用，所以数据需要备份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)

一键创建账户/授予PIBE的话，有两种途径。第一，管理员通过oAuth授权unblock-zh.org，通过管理员账号操作，然后从本地日志看来，操作者是管理员。第二种途径是，成立一个机器人账号，比如名叫 unblock-helper-abot，并且赋予机器人管理权限，然后通过机器人操作，并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话，我倾向于使用第二种方式，因为我希望尽量不要向第三方授权我自己的账号，但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)

使用OAuth可以只需要简单的身份识别获得权限，用于确认是不是登录系统的对应是wiki的哪个用户。然后代理操纵的机器人可以标记操作人员的wiki用户名（通过前面获得的信息）。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)

如果不改变单管理员授权模式，我倾向于第一种，这样和原先的工作模式保持一致，便于查询。

mw:OAuth/For_Developers称应用做的操作会有标签。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)

在这里没有看到可以使用oauth给用户添加组别的选项，那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)

的确只能这样。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)

咱好像记着这种权限似乎不需要特别勾上某个选项就默认拥有，您要不尝试一下？ Stang^★ 2024年5月8日 (三) 01:14 (UTC)

真的假的，在授权的时候不声明却可以操作改变用户组这么重要的操作？如果是真的那也是个bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)

用API能查IP有没本地封或者全域封，好像不是必要。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)

赞 赞 赞 牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)

@Bluedeck：话说可给管理员布告板抄送一份通知链接至此？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月1日 (六) 08:43 (UTC)

@Bluedeck：想好奇请问是否有考虑过部属在wikitech:Help:Cloud VPS？如果有，为什么不选择部属在该处？--SunAfterRain 2024年6月4日 (二) 09:30 (UTC)

管理员通告版：不知道效果会怎么样啊。等上线后在ASN通告一下，然后TG呀IRC呀广播一下应该就行。CloudVPS：他的介绍说自己是标准的VPS，但是又有迹象表明他不是完全标准的环境，导致我不想把时间花在部署，测试，更换环境，以及踩坑上面。对我来说，写软件是趣味十足的事情，而调试环境则是让我胃肠不适的事情。目前我没有换环境的需求，因为开销太小。如果有我再考虑cloudvps。cloudvps的另一个问题是只有在virginia有DC，但这不是一个大问题。Bluedeck 2024年6月8日 (六) 04:00 (UTC)

以我个人看法，部属在CloudVPS的隐私疑虑绝对会比一个外部网站好很多，当然你维社群愿意接受那我也没什么意见就是了。虽然不清楚是笔误还是什么的，如果开销太小的话我自己是会考虑换过去啦。--SunAfterRain 2024年6月10日 (一) 17:54 (UTC)

可以理解你所说的。我可以把cloudVPS当作一个长期目标，最终迁移到那上面去。Bluedeck 2024年6月14日 (五) 05:29 (UTC)

试运行

在过去的几周里，我增加了最后的一些的功能，分别是1）按日期搜索排列工单；2）邮件回复模板；3）管理员删除工单、删除消息界面；4）用户改名功能。我想知道大家觉得还缺少哪些网站本身的功能（邮件服务器、机器人授予IPBE除外）。如果感觉差不多了，那么可以进行试运行。试运行期间，再对可能发现的新的功能需求进行补充。试运行的提议正在进行公告。如果通过，将会将网站首页文字改为试运行，并暂时移除一些只具有展示效果的链接，然后在用户无法注册的提示页面加入网站的链接，这些操作大概最多需要一天就能完成。在试运行决议通过前，如果对网站有任何问题，欢迎在此讨论。Bluedeck 2024年5月13日 (一) 23:30 (UTC)

功能方面，个人认为管理员不应该有删除工单的能力，这个应该由维护者来做，比如遇到spam/扰乱性工单就打上相应的标签，若干天后自动删除；可不可以出个statistics大概写一下某月某人处理了多少工单之类的；反spam方面怎么样，你觉得需要加个recaptcha吗；模板建议是放到Github或者类似公开的地方，需要改的人发pr；可以考虑加一个link/merge功能么，比如一个用户就一个问题发了多个ticket，这个时候可以把它们关联起来；感觉可以把login改的小一点，或者让非管理人员意识到不需要登录就可以发ticket。

另外就是建议放到toolforge或者cloud VPS上。顺便问个问题，你觉得这个系统需要承担unblock-zh最原始的封禁申诉职能吗 Stang^★ 2024年5月14日 (二) 01:47 (UTC)

• 谢谢提议！简短回应：

• 删除工单就是为了应对扰乱才设计的功能。删除之后可以恢复或检视。（UI需要另外添加）工单的永久保留或删除问题在下面讨论。
• 反spam：UTRS目前是阻止同一个IP地址多次发送工单。但是我的方案不记录IP地址，无法阻止。我可以考虑一下记录ip地址的hash，并由此进行rate limit。我个人完全不喜欢captcha，除非不得已，我可能会考虑上captcha。在此之前我会尽量用其他手段处理spam问题。我有一些asymmetric proof of work的方法能防止自动化的spam。如果有人无聊到要手工spam，那么唯有记录IP并进行区段查封这一个办法。（但是这样一来，不就把本身的目的给击败了？？）
• 邮件模板：我不会放在github，毕竟不是每个管理员都会开PR，我简单的开一个用户页面存储目前的模板，谁想添加，给我留个言即可。邮件模板都是非常简单的纯文字模板。当然，如果你喜欢用gh，那么在前端的repo里有一个文件，你也可以直接PR这个文件。
• link/merge：race condition太多，最多做成stack overflow/github issues那样，“标记为#109的duplicate。关闭”这种解决方案。
• login改小：我肯定会让新用户看到不login就能发工单，这是一个重要的因素。
• statistics：这个我一定会做，因为这会让处理工单变得很有趣，我的设想是做一个leaderboard，能够激发人们对于处理工单的无限潜能，哈哈哈哈。
• Hosting：toolforge不能满足我的要求，CloudVPS不熟悉。将来打算支持图片上传，需要一个能挂载S3的环境，另外多区域host允许你把服务器托管在东京/首尔/LA。目前，服务器托管在Vultr的新泽西区上面。
• 这个网站做成网站的形式，是为了新用户方便的注册+IPBE（也就是unblock-zh-ipbe的功能）。处理被长期封禁的用户在邮件列表中50-100封邮件那么长的申诉，并不是网站初衷。如果有人就是要在网站上申诉，管理员也选择在网站上处理，那我不会站出来阻止，但是如果网站上出现了对维基百科历史有一定意义的讨论内容，我觉得有应当抄送一份到邮件列表。

Bluedeck 2024年5月14日 (二) 04:12 (UTC)

update: 已经增加了查看和恢复已删除工单的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)

另外还有两个别的需要讨论的问题：

1. 工单是否永久保存？永久保存是目前的默认，而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法，想征求一下大家的意见。
2. 开源：从一开始我就设想开源。这个项目有4个repo，其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中，然后才能开源。请期待。
3. 共同参与：如果您想共同参与开发，或者参与对服务器的运维，欢迎在这里提出来。Bluedeck 2024年5月14日 (二) 04:49 (UTC)

感谢贡献，整体非常完善。如有需要可以协助维护。--Borschts^{™ 欢迎外带一碗罗宋汤} 2024年5月14日 (二) 13:32 (UTC)

存档应保留，只是可以限制普通用户存取。另外，也应考虑先行在站内撰写说明页面，或补充现有方针与指引不足，以便利用。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月14日 (二) 15:05 (UTC)

注意到两点可以改善：

• 无法创建账号者不应提供“我不想提供邮箱”的选项，创建账号时需填写对方电邮地址才能安全发送临时密码。如果不想提供邮箱则难以协助创建账号。
• 需要添加提示文字，若不提供IP地址则申请有可能不获受理（始终审批IPBE时需要验证用户是否使用proxy）。

--路西法人 2024年5月15日 (三) 07:52 (UTC)

我脑海中预想的不提供邮件的处理方式：网站生成一个强的随机密码并记录在工单中，用户通过随机密码登录。优点：用户不需要邮箱地址。缺点：不提供邮箱的用户等于需要不断的刷新页面查看处理进度，是一个糟糕的体验。对于管理员，需要复制粘贴网站生成的密码来创建账户，也是多了一个步骤。上面我只是说明了操作的可行性，至于这个功能是否保留，可以继续讨论决定。对于第二点，IPBEG如果有这个要求，那我完全可以添加这个提示文字（甚至可以在维基百科设置一个页面，比如Template:Unblock-zh/strings/new-ticket-notice，然后网站可以反映这个页面的任意文字。）Bluedeck 2024年5月19日 (日) 06:22 (UTC)

我的想法是只要有任何第三方人员可以接触到任何密码的方案都是不安全的，尤其在发送邮件时在此类第三方网站留存临时密码亦是相当危险的；即使我信任你会尽力保障网络安全，但显然不安全的操作应尽可能完全避免。邮件、代理IP地址等都尚算不太危险的信息，密码真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)

我想了一下觉得你说得很有道理。如果有的用户收到临时密码后不加更改，那么等于这个用户的密码永远的挂在一个所有管理员都能看到的地方，是不妥的。我已经把界面改成如果请求账号，必须提供邮箱，否则无法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)

一些minor的建议：about一页，Puzzle Globe似可译为“拼图球”，Wikibooks译名应为“维基教科书”非“维基图书”。不提供邮件的提示，“一串30几位的工单”应作“三十几位”。login界面没有明显的返回按钮，侧栏也消失了。lookup界面可以考虑加注工单号和邮箱择一提供即可。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月21日 (二) 03:01 (UTC)

另外我在想让其选择点选提交IP的选项是否也应该把UA也提供给审核用户检阅（方便反破坏比对）。--路西法人 2024年5月23日 (四) 07:54 (UTC)

统一回复。1）login界面有意如此设计。2）必须同时输入工单号和邮件，否则任意人士可以通过广泛查询邮件探知私密工单。3）UA信息只有CU才能访问，所以显然不能提供。另外就算用户主动提供了，那么IPBE处理者拿什么进行比对呢？毕竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)

2) 啊那就是提前提示创建工单时未提供电子邮箱的须放空？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月27日 (一) 06:29 (UTC)

没有提供电邮的工单号会比较长，所以我可以改一下软件，让这种工单号不论是否输入电邮都能够正常查询。这样可以不破坏界面简洁易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)

好的 赞 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月29日 (三) 07:32 (UTC)

---

将开始试运行。公示已经进行了一个多月，收集到了很多改进意见，并实施了很多更新。今天起，我将正式修改MediaWiki软件界面，在网站上标注试运行字样，并在公告栏和ASN中对社区和管理员们进行公告。Bluedeck 2024年7月7日 (日) 16:26 (UTC)

@Bluedeck：请问IPBEG们可以如何存取工单？--路西法人 2024年7月10日 (三) 03:25 (UTC)

@LuciferianThomas：我正在编写为IPBE权限持有者提供权限的功能。完成后，IPBE将获得和管理员基本一致的功能。目前编写的功能是对于下方讨论中方案一的实现。编写完成后，我将会在用户讨论页面通知IPBEG权限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)

@Bluedeck：能更新进度吗？--路西法人 2024年7月22日 (一) 02:49 (UTC)

现在IPBE已经能取得权限使用了，但是目前用户界面和IPBE权限能做的事情不吻合，比如IPBE无权删除工单，但是会显示删除按钮，我正在改这些小问题。Bluedeck 2024年7月29日 (一) 07:08 (UTC)

@Bluedeck：预计试行多久？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年7月20日 (六) 17:44 (UTC)

不知道，但是目前肯定不是一个完善的状态。比如我就发现了好多好多想要改进的地方，写在Roadmap中。Bluedeck 2024年7月29日 (一) 07:08 (UTC)

IPBEG的权限基本设置完成，测试可用，在此通知IPBEG组成员@user:AINH，@user:ASid，@user:Borschts，@user:LuciferianThomas，@user:SCP-2000，@user:だ＊ぜ。Bluedeck 2024年8月1日 (四) 01:43 (UTC)

感谢。希望未来能添加罐头回复（请求提供更多信息如封禁讯息、已授权〔时长〕）等。--路西法人 2024年8月1日 (四) 02:21 (UTC)

是的，我自己在处理中，也发现了罐头回复的重要性。我将会加入这个功能。Bluedeck 2024年8月2日 (五) 20:35 (UTC)

繁体支援

这个网站估计主要的受众是大陆梯子人士。但是，由于很多管理员是繁体用户，那么我就增加了一系列的繁体支援，但是都是Google翻译的。请繁体管理员看看管理界面的翻译如果有很不和谐的地方，请指出来。如有需要，网站可以支援香港、台湾和澳门繁体的分别翻译。Bluedeck 2024年5月30日 (四) 08:15 (UTC)

感谢蓝桌照顾繁体用户，但我目前查看似乎有一些界面仍然是简体中文的，例如新建工单的部分，另查台湾的教育部字典，work order这个词在台湾可以翻译为“工令”、“工作命令”、“工作通知单”或“工作单”等，就是没有查到称之为“工单”之翻译，惟我日常生活中前开所有词汇均较为少见，平常类似功能之提交申请平台反而被称之为“电子表单”，这部分可能需要更多繁体用户来指出正确的翻译。--小过儿（留言） 2024年5月30日 (四) 15:30 (UTC)

新建工单的繁体化已经完成。关于工单这个用语的翻译，我参考了一下asus的网站，叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确，那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)

“工单”是对应“ticket”而不是“work order”，比如Zendesk香港也是叫ticket作“工单”[1]。再甚者，直接“搜索申请”也是得了，不需要特地什么ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)

@Bluedeck：怎么查阅或更改翻译？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年7月1日 (一) 19:44 (UTC)

通过改变浏览器的语言设置并刷新页面，可以查看不同的语言版本。目前要修改，可以直接留言告诉我哪里需要改。以后，会开放一个repo在github上可以pr。不熟悉sveltekit和github的用户仍然可以直接联系我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)

理论上可以开twn（translatewiki.net） project啦，不过要担心被乱改的问题。--SunAfterRain 2024年7月22日 (一) 07:02 (UTC)

工单的永久删除

目前没有这个功能。不过，根据欧盟GDPR要求，在用户请求的情况下，应该提供一种方法永久移除其个人信息。我想让管理员能够在工单上添加一个标记，被标记的工单约一个月后真正的删除。删除真正执行前可取消。这种删除只应该在特别的情况下进行（也就是用户请求）。（也可以单独只允许行政员执行真正删除，但是我觉得管理员已经足够可信，并且还有一个缓冲期间。）Bluedeck 2024年5月31日 (五) 23:04 (UTC)

这个功能不错。( π )题外话：我想知道维基百科不能删除账号是否符合GDPR，以及即使OS似乎也不是真删除，这是否符合GDPR。有人去举报一下是不是基金会就会实现这个功能了。--桐生ここ★[讨论] 2024年5月31日 (五) 23:25 (UTC)

应该是不符合的，而且显示未登录用户ip这个似乎也有一定问题。然而我们要团结一致，不要把基金会举报给欧盟。Bluedeck 2024年6月1日 (六) 05:34 (UTC)

让 IPBEG 在 Unblock-zh 上获得和管理员一样的权限

因为我觉得 IPBE 也是一大痛点，所以我觉得让 IPBEG 能够一起帮助处理会大有裨益。现在抛出几个方案讨论：

1. 让IPBEG组和管理员同在unblock-zh.org/zhwp下有一样的（或者接近的）权限。
2. 像邮件列表一样，单独新建 unblock-zh.org/zhwp-ipbe空间。
   1. 网站面向用户的界面不改变，根据用户是否需要 IPBE，自动将工单分发至 zhwp 或 zhwp-ipbe
   2. 网站设计改变，入口页面一分为二，用户需要自己选择是投递给zhwp还是zhwp-ipbe
3. 不支持 IPBEG。

我觉得，从用户体验的角度，不希望入口一分为二。另外，不管选择 1 还是 2，都需要一段时间来修改网站的代码，但是 2 所花时间会更久一点，并且会增加日后维护的工作量（主要是会出现两套表单同步的问题）。关于用户隐私，由于 IPBEG 是签署 NDA 的，应该视为可信人员，所以我比较倾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)

设立IPBEG的本意就是许可IPBEG处理该类申请邮件，理论上可以说已有社群共识支持选项2，但已有共识未必支持选项1。IPBEG不能处理unblock-zh上非申请IPBE的工单。我是认为，一般而言封禁申诉本应都是在公开场合发起，申诉内容多数都应该可被所有用户查看，实质需要使用邮件申诉封禁的仅有无法编辑讨论页的情况。如你所言，IPBEG本有签署NDA，就算看了也不应该会造成什么问题（虽然能避免最好）。如果是最后采用最简化的选项1，那我觉得您可以最低限度在处理人员的界面中加入标签工单的功能，让IPBEG能明确标记跟他们职务无关的申请，从IPBE队列隐藏，仅能由添加标记的IPBEG（直至工单标签被管理员确认）及管理员查看。--路西法人 2024年6月2日 (日) 11:58 (UTC)

如果要让IPBEG不能看到非IPBE工单，那应该执行方式2更优。如果执行方式2，那么管理员、行政员也应该自动获得zhwp-ipbe空间权限，并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)

不是“不能看到”，而是“不再跟IPBE有关的就没必要继续显示在同一队列，令其他正在处理IPBE申请的用户不小心点进去”。“看到”大概是不会有什么大问题的。--路西法人 2024年6月5日 (三) 02:22 (UTC)

分成两列或许方案2实现起来更简单？--桐生ここ★[讨论] 2024年6月5日 (三) 09:51 (UTC)

不是不行，但必须考量没签署NDA的管理人员是否有权限接触unblock-zh内的工单，一般视乎工单是否涉及IP地址等可辨识信息。如果要再这样分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)

还是那句话，我无法理解WMF要求邮件列表内的IP必须有签署NDA才能接触，但允许使用unblock模板直接把IP公开。--桐生ここ★[讨论] 2024年6月6日 (四) 09:48 (UTC)

我一开始听说IPBEG需要NDA，但管理员不需要NDA的时候，我也觉得很费解。而且你知道吗，你用的任何JS组件要是对外部资源进行请求，那么就可能有意无意泄露IP。甚至你收到一封邮件，邮件里带个图，这图也能泄露IP。虽然说IP在wiki上被当作隐私，其实整个互联网对IP的保护可以用奇差来形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)

似乎是祇有涉及IP等隐私信息时，才要求管理员签署相关协议。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月23日 (日) 02:13 (UTC)

@Bluedeck：只要不僭越社群赋予之权限，应尽可能以您自身方便为宜。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月6日 (四) 00:11 (UTC)

提供的IP问题

现在有个问题

• 如果申请者没有使用代理时使用此网站提交工单，被此网站自动带入的IP是其真实IP，而非使用代理且受到IP封禁的IP，对于IPBEG应该使用真实IP还是受到封禁的IP判断？如果有人使用代理访问此网站，有人不使用代理访问此网站，也会产生差异。
• 是否像传统邮件列表一样另外要求用户手动填入封禁界面上显示的受封禁的IP或封禁ID？这样也有好处，就是IPBEG可以看到申请者被封禁IP同时也能看到真实IP，确定申请者处于中国大陆等受限地区。但产生另外一个风险，就是如果确实提供的是中国大陆IP地址，一旦泄露可能产生严重后果。--桐生ここ★[讨论] 2024年6月6日 (四) 10:00 (UTC)
  • 技术上有很多方法可以尽量避免记录IP，比如只记录部分IP、以及对管理员不显示IP，只显示IP是否处于封禁列表中。但是这些方法无一例外的会对管理员处理造成问题。我想到的各种方法中，只有一个值得实践的，是在工单解决之后将IP相关信息从工单中清除，避免永久留存。除此之外，就只有请管理员和IPBEG不要泄露IP地址。对于代理的问题，我可以加一个提示让用户记得开代理，再者就是干脆取消自动侦测IP这个功能，让用户自己填写IP和查封ID，和邮件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)

    我有一个方案

    • 申请者不提供IP：不提交IP
    • 申请者选择提供IP：检测IP是否中国大陆或其他受限地区
      • 是：不提交IP地址，只自动提交申请者IP地区，并且要求申请者手动填写受封禁IP
      • 否：自动带入IP地址

    --桐生ここ★[讨论] 2024年6月7日 (五) 09:10 (UTC)

    补充：IP地区是提交由服务端判断，而不是在前端处理，所以实际上仍然会提交中国大陆IP，只是不会储存在服务器上。--桐生ここ★[讨论] 2024年6月7日 (五) 09:13 (UTC)

    检测IP是否中国大陆或其他受限地区 这个感觉不是长久之计，GFW未来可能会给Unblock-zh上SNI封锁，用户会不得不套代理访问，这样Unblock-zh获取到的就不是真实IP--Yuki Rutygr (留言) 2024年7月9日 (二) 13:15 (UTC)

    • 我想过geoip定位这个方案，但是ip定位数据库需要每个月更新，而且并不完全准确。连维基媒体基金会都放弃了自己的geoip API（否则我就可以利用了）。有一个折衷办法，那就是查询封禁数据库。如果用户目前的IP不再封禁列表中，大概率说明没有开代理，此时我弹窗提示开代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)

(－)反对，考虑到Unblock-zh未来极有可能受到GFW封锁。--mije meli carrot_233 -- 讨论 2024年7月25日 (四) 11:33 (UTC)

网信办说的？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月25日 (四) 15:07 (UTC)

这种网站大概率被墙。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:42 (UTC)

这反对理由太怪了，你维本来就被GFW刀了，有差吗？--SunAfterRain 2024年7月27日 (六) 04:23 (UTC)

问题在于，如果Unblock-zh被GFW封锁，则中国大陆无法直连Unblock-zh，故无法获取真实IP。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:41 (UTC)

我们本来就不是为了获取用户的国内IP，因为目前邮件列表也只是看到你的查封ID和IP地址就对你进行授权，这被查封的IP地址往往都是VPN、代理地址。如果被墙后，还能解决代理不是全局的问题。因为没有被墙，有的代理会把没被墙的网站不走代理，导致我们接收到用户的没有被查封的IP地址，反而不是我们想要的。Bluedeck 2024年7月30日 (二) 16:50 (UTC)

罐头回复

经由路西法人的建议，增加了‘罐头回复’功能。将常用的语句加入罐头回复列表，就能快速的一键回复工单。详见WP:Unblock-zh.org#罐头回复功能 Bluedeck 2024年8月12日 (一) 21:51 (UTC)

`ChooseNewName`标签

这是一个比较新的功能，当请求用户选择新的用户名时，加入`ChooseNewName`标签，同时摘掉`回复关闭`标签的情况下，工单用户界面会多出一个小工具，便于用户确认自己所选择的用户名是否可以注册。Bluedeck 2024年8月20日 (二) 08:16 (UTC)

请求社群判断已经数据过期的用户是否为傀儡

见相关SPI提报，现时最少有法国饮食文化、如懿传、册封体制受到影响（很可能还不止这些），请调查助理、管理员和其TA用户判断和彻底清查，谢谢！--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:12 (UTC)

• 外加一些账号（包括SPA），请检查是否为冏；

以上。--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:24 (UTC)

这难道不应该直接在傀儡调查页面处理？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年7月20日 (六) 17:39 (UTC)

这些Stale了的账号，即使有可疑，放上SPI也查不了，所以只能放此。--MCC214（Sign | Contributions） 2024年7月21日 (日) 05:32 (UTC)

(？)疑问-若数据过期，还能SPI吗？是否主要以人工来判断？Wetrace欢迎参与WP人权专题 2024年8月23日 (五) 01:31 (UTC)

不能，递上去监管员都是说 数据过期的（基于隐私政策，用户数据会/已在账号最后一次动作的90天后被自动删除），所以当然只能靠人工的了（除非账号又活动了）。--MCC214（Sign | Contributions） 2024年8月25日 (日) 04:27 (UTC)

本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

仲裁委员会的选举

今天看到Wikipedia talk:仲裁委员会#公示RFC结果及仲裁方针草案下早有公示过的仲裁委员会试行方案。在其之后仍有讨论关于是否有解任管理员的权力问题，但目前本人认为细节基本商榷的差不多了。目前唯一一个剩下的需要形成共识的事情就是在试行期间仲裁委员会需要多少支持率才能上任。定下这个可以直接开始筹备选举了。那么这下面先讨论支持率的问题吧？--0xDeadbeef (留言) 2024年8月2日 (五) 04:38 (UTC)

我个人认为支持率只需要50%就够了。首先考虑到仲裁委员会是一个需要社群高度信任的职务，在考量一人是否符合成为仲裁委员会的标准明显要比管理员的标准要高，于是反对的比率肯定会比管理员更高。本人希望中维能够选举出来第一届委员会，于是希望50%，这样既获取majority的支持（超过一半的人支持）也能给仲裁委员会给一个好的起点。（注：英维是采取60%以上可以任职委员会两年的机制，但因为这次试行所有人都是一年，故偏向50%。--0xDeadbeef (留言) 2024年8月2日 (五) 04:44 (UTC)

抄录前一阶段讨论情况：

• 基本同意授予仲裁委员会委员“已删除内容”、“非公开过滤器”、“IP信息”、“启用双因素验证”等权限，
  • 尚未有明确共识决定是否授予“查阅全站未受监视页面”、“创建短链接”、“查看当前转码活动的信息”、“查看标题黑名单日志”等权限；
• 尚未有明确共识决定是否限制仲裁委员会委员在委员会既有职能外行使职权；
• 基本同意仲裁委员会委员（至少第一任期）选举采相对多数（百分之五十）当选制；
  • 尚未有明确共识决定是否按支持率多寡区分当选任期（如百分之五十以上为一年、百分之六十以上为两年）；
• 基本同意仲裁委员会处理管理人员解任案件，系经调查确认存在操守违规事实后，方转交社群决议是否除权；
  • 尚未有明确共识决定如何区别或取舍仲裁委员会与社群既有解任管道；
• 基本同意仲裁委员会有权拒绝受理案件。

似乎第一届确实不需要区分任期。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月2日 (五) 05:45 (UTC)

哎，当时的讨论有点久远，所以应该是不需要讨论支持率了？那我觉得可以直接开始筹备选举事宜。RFC先删掉，之后写点时间相关的内容。0xDeadbeef (留言) 2024年8月2日 (五) 06:19 (UTC)

但似乎还有若干职权问题必须商榷？要搁置也不是不行（仲裁委员会现有职权不少，也够行使一整届了吧？），但似乎想要快速推动仲委会设置提案者，目标都是希望该会介入（调查）管理人员解任，那就又不适合搁置？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月2日 (五) 13:23 (UTC)

我选择先搁置管理人员解任问题是因为要是先选出来一批人，这一批人可以帮忙推动共识，也就是说在委员会成立之后再对于管理人员解任的事情帮忙推动共识。既然他们都选上了，他们来推动讨论、邀请社群成员来发表意见来形成共识个人觉得更合适--0xDeadbeef (留言) 2024年8月2日 (五) 14:12 (UTC)

(！)意见：对于“尚未有明确共识决定如何区别或取舍仲裁委员会与社群既有解任管道”：

1.若用户未申请仲裁，自然可直接发起罢免解任。

2.若用户申请仲裁，委员会决议不解任管理员，则社群在一段限制时间内不得以同一事由发起罢免（该段时间可议，比如半年、两年等）；当该段限制时间过后，社群若以同一事由再次发起罢免，须出具自前次仲裁后出现的新事证（也就是新纠纷事件的时间点或所出具的证明实际发生在前一次仲裁后）。

3.若用户申请仲裁，社群或相关用户对委员会的决议不满，可将委员会的决议，在具备可明确、合理、一般人所具智识即可辨识之理据或事证的前提下，向基金会投诉（也就是仲裁极其离谱，而如何为“极其离谱”，或可讨论）。

4.若用户申请仲裁，社群或相关用户对委员会的决议不满，可将委员会的决议发起公投，获特定支持比率的情况下推翻。公投结果须具备数个条件方可具效力，如：不满意仲裁结果的当事相关用户须参与联署（明言自愿放弃表态或投票者除外）；总有效票须占当时社群具投票资格用户总数的相当比例（比如至少四分之一）；公投结果出炉起一段限制时间内（该段时间可议，比如半年、两年等），不得就同一事项再发起公投；有效同意票超过不同意票。诸如此类。

5.若委员会决议遭推翻，社群自可再以同一事由发起罢免。惟为避免仲裁程序遭滥用或社群无谓虚耗空转，社群在委员会决议正常生效、用户不得以同一事由发起罢免原限制时段的二分之一期间内不得以同一事由发起罢免（该段时间可议，参见第2点，比如原本是半年或两年不能再发起罢免，这种情况下须在三个月或一年后才可再发起罢免，但不须额外出具同一罢免事由的新事证）。

6.委员会决议遭推翻后，其仲裁结果之效力即自公投结果确认起解除；委员会决议遭推翻前，其仲裁结果之效力视为有效。

个人路过随想意见，供参。--Kriz Ju（留言） 2024年8月2日 (五) 21:37 (UTC)

鉴于目前的闹剧，我不认为社群会信任仲裁委员会。--桐生ここ★[讨论] 2024年8月3日 (六) 05:57 (UTC)

同上，强烈反对以此次RFDA为由立即推动仲裁委员会上马，社群有权就必须商榷的若干职权问题进行更加深入的讨论。--🎋竹生🎍 2024年8月3日 (六) 11:50 (UTC)

首先，我并没有“以此次rfda为由”，而只是有人提到“若已有仲裁委员会，则可能此事处理能够更加妥当”的想法而选择推动。选择推动委员会选举，并不是代表不讨论职权问题，但是，早已为仲裁委员会的职权形成共识（其并不包含对于管理人员除权相关的事宜），则说明社群已有仲裁委员会上任的基础共识，所以我个人觉得你反对的理由无法站住脚的，欢迎你提出另外的理由。--0xDeadbeef (留言) 2024年8月3日 (六) 12:42 (UTC)

你可以解释一下这两者（目前的闹剧、社群对于仲裁委员会的信任）之间的关系。顺便，若是你自己表达不信任无妨，但请不要代替社群说话。--0xDeadbeef (留言) 2024年8月3日 (六) 12:34 (UTC)

一个RFDA案就已经出现某人或某些人（无法确定是不是WMLO）发送拉票（或伪装成拉票）的邮件，意图使RFDA通过或不通过。如果为解决RFDA而急于成立的仲裁委员会，难以想象是否会有更多对仲裁委员候选人的拉票（或伪装成拉票）的邮件试图让人当选或不当选。--桐生ここ★[讨论] 2024年8月3日 (六) 14:07 (UTC)

是的，所以我觉得先完善仲裁委员会的选举流程以杜绝不公平情况，然后再在这群人获得社群各方信任的情况下推动共识，是比较好的做法。至于急不急的问题，看社群可以搁置多久。我觉得久一点并无太大问题，毕竟一套完善的流程创建起来之后很多问题都会迎刃而解。--碟之舞📀💿 2024年8月3日 (六) 14:17 (UTC)

不要稻草人，我在这里讨论筹办选举又不是为了解决RFDA而急于成立的。--0xDeadbeef (留言) 2024年8月3日 (六) 14:19 (UTC)

不过这里要澄清一下就是我确实有在主群说过“在选出仲裁委员会再来调查”这一说法，实际上在我后来想过之后不现实，因为成立仲裁委员会之后估计RFDA案没有什么可调查的了。因此此次提出完全就是为了流程上继续推进而已。--0xDeadbeef (留言) 2024年8月3日 (六) 14:21 (UTC)

同样支持50%。至于相关权限等问题，个人认为仍须回归社群如何看待此权限及信任程度，如果目前的确认程度已经不需厘清所有细节，个人现无意见。--Kriz Ju（留言） 2024年8月5日 (一) 13:38 (UTC)

---

七日已过，总结一下上方的讨论。目前参与讨论的用户基本同意（至少在第一届）选举中采取相对多数当选原则，并就选举结束后继续推动仲裁委员会相关共识上基本达成共识。就此，我提议在今年9月份展开管理员选举的同时举行第一届仲裁委员会选举，七日内若无人反对或反对意见已解决的话就进行公示。--人间百态,独尊变态(讨论) 2024年8月12日 (一) 11:36 (UTC)

在确定仲裁委员会权限及仲裁程序以前，选举仲裁委员会委员没有意义。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月12日 (一) 14:49 (UTC)

赞同。我们应该等到委员之权限得到确定之后再选举。--CuSO₄ · 龙年大吉 2024年8月12日 (一) 18:25 (UTC)

@Ericliu1912: Happy to talk about this off-wiki if you want. 首先在Wikipedia talk:仲裁委员会#公示RFC结果及仲裁方针草案下WP:仲裁/方针已经通过公示，于是以下为已确定（有共识，被社群接受的方针）的仲裁委员会的职权：

中文维基百科社群委托委员会处理以下事务：

1. 在无法通过社群讨论及管理程序等常规流程解决的严重用户冲突中担任最高争议解决机关，作出具约束力的裁决；
2. 处理管理人员解任请求（自请者除外）及
3. 处理仲裁裁决有关之封禁及禁制申诉。

至于仲裁程序也在方针下“流程”的section已经定下，不知道有什么还需要确定的。而基本权限部分也在Wikipedia talk:仲裁委员会#RfC：2024年2月定好。

目前唯一存在争议的是仲裁委员是否可以经决定直接解任管理员，而这一小细节不应阻止我们选出委员会吧？--0xDeadbeef (留言) 2024年8月13日 (二) 02:51 (UTC)

不，管理员仲裁解任权（暂且这么叫它吧）关乎“处理管理人员解任请求”的实施形式，是先前讨论的焦点之一。在下相信社群对于“谁适合当选没有管理员仲裁解任权的仲裁委员”和“谁适合当选有管理员仲裁解任权的仲裁委员”这两个问题的看法是有差异的。管理员仲裁解任权问题未解决就举行选举，无异于认为这种差异可以忽略。窃以为，这种差异值得得到关注，如果在解决管理员仲裁解任权问题前就选举，就操之过急了。--CuSO₄ · 龙年大吉 2024年8月13日 (二) 07:13 (UTC)

@CopperSulfate：我并不觉得属于操之过急，因为我觉得这是一个循环依赖 (en:circular dependency)。比如说，在讨论委员会是否应当有仲裁解任权的时候，便有人以“社群不一定信任委员会而支持其有这样的权力”来反驳我个人认为应当拥有此权力的观点。但是呢，如果人已经选出来了，那么讨论委员会到底是否应当有这种权力则可以在以选出的人作为context。比如说如果我个人信任被选出来的人，我个人就会对于委员会有这种权力更放心。如果我个人不信任被选出来的人，我可能就不会希望委员会有这样的权力。

另外，根据之前的匿名问卷，貌似已有大概共识在“仲裁委员不应有仲裁解任权，而是调查查证报告给社群”这一观点，所以以“委员会在前期很有可能不会有直接解任管理员的权限”来选举是合理的。

你觉得这样的解释是否合理？--0xDeadbeef (留言) 2024年8月13日 (二) 07:42 (UTC)

可以准备公示了。--0xDeadbeef (留言) 2024年8月19日 (一) 02:15 (UTC)

公示7日，2024年8月26日 (一) 11:54 (UTC)结束--0xDeadbeef (留言) 2024年8月19日 (一) 11:54 (UTC)

想问下不考虑技术原因，你们觉得选举应该跟管理人员申请错开还是一起办？两者性质毕竟不同，我当初提个“管理人员当然席位”还一直被打枪。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月19日 (一) 14:11 (UTC)

另外连个具体流程都没有出台就公示，未免操之过急。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月19日 (一) 20:59 (UTC)

个人认为试运行为方便放在一起。仲裁系统成熟后应错开。--0xDeadbeef (留言) 2024年8月20日 (二) 03:07 (UTC)

@0xDeadbeef(！)意见：鉴于社群在仲裁解任问题上已有模糊的共识雏形，如果不给予新当选的仲裁委员“管理员仲裁解任权”的话，我不反对尽早开始选举。--CuSO₄ · 龙年大吉 2024年8月19日 (一) 20:04 (UTC)

(？)异议：应先就选举具体流程达成共识。另(？)疑问在“不需要考虑当选人有无权限决定管理员罢免”的情况下选出仲裁委员后，要进一步让社群“信任他们能够有权决定管理员罢免”岂不是更难？应先确定和细化“仲裁委员不应有仲裁解任权，而是调查查证报告给社群”的初步共识，这样岂不更快。--🎋竹生🎍 2024年8月20日 (二) 02:48 (UTC)

@Ericliu1912 @Newbamboo，那就与管理员选举相似，一周预讨论（与管理员选举同时进行），一周提名期（可自己提名也可由他人提名，每个候选人应提供自我介绍），两周意见期（可提问、讨论），两周投票期如何？--0xDeadbeef (留言) 2024年8月20日 (二) 12:55 (UTC)

公示通过。社群将会根据讨论得出的仲裁委员会职权和流程在今年9月举行第一届仲裁委员会成员选举。--人间百态,独尊变态(讨论) 2024年8月26日 (一) 13:15 (UTC)

---

社群目前业已达成举行选举的共识，然在部分流程的细节仍未敲定。就此鄙人展开对选举相关工作的讨论。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

仲裁委员会用户组

在先前的讨论中已经敲定了仲裁委员会成员具有的权限，但对是否设立该用户组尚无定论。就此对是否设立仲裁委员会用户组展开讨论，若无异议或异议已解决，将会创建设立仲裁委员会用户组的工单。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

仲裁委员会成员的人数和条件

在先前的讨论中已经确立了仲裁委员会成员的人数和条件，但不清楚目前社群对此共识是否有异议。如果没有异议或异议已解决，将会根据此共识进行选举工作。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

仲裁委员会选举的讨论场所

目前对仲裁委员会选举的讨论场所尚无定论。鄙人认为可以跟管理人员申请的预讨论一样在Wikipedia:互助客栈/其他讨论，但不清是与管理人员申请在同一章节讨论更好，还是另开一章节讨论更好。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

参与仲裁委员会选举用户的个人选举页面

目前参与仲裁委员会选举用户的个人选举页面尚无定论。鄙人认为可以参考其他的管理人员申请设立一个WP:申请成为仲裁员并将所有参与仲裁委员会选举用户的个人选举页面置于其子页面。如果没有异议或异议已解决，将会根据此方案进行选举工作。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

关于仲裁委员会选举是否公布有资格投票人数及名单

目前公布管理人员任免案投票人数及名单的提案正在公示。如果公示通过且没有异议或异议已解决，将会让未参与选举的行政员在安全投票开始前15日内公布具人事任免投票资格的用户人数及用户名单。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

仲裁委员会选举的监票工作

目前方针规定由监督员兼任选举的监票员，但参与选举的监督员是否能成为监票员尚未有定论。鄙人认为参与选举的监督员应秉持避嫌原则不应担任选举的监票员。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

仲裁委员会的RFC

目前对于仲裁委员会的职权尚存在一些争议。鄙人认为在这次选举后应展开一次关于仲裁委员会的RFC，并在RFC上厘清仲裁委员会的职权以及完善仲裁委员会的相关页面。如果没有异议或异议已解决，将会在选举结束后举行一场关于仲裁委员会的RFC。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

其他意见

此章节供社群发表杂项意见，若有重要问题提出者，欢迎于上方新置章节。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 04:58 (UTC)

引进CampaignEvents扩展

路过看到这一扩展，因本站时常举行编辑松，似乎可以引进来测试一下看看效果，不知诸位觉得如何？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月16日 (五) 02:05 (UTC)

(＋)支持：顺便把扩展主页翻译到中文了 ——即请秋安 ZhaoFJx_{（论•编）} 2024年8月16日 (五) 09:37 (UTC)

个人不反对此等引入。不过，现阶段如何运用该功能？就个人理解，本站编辑松的注册大多利用维基上的页面（如动员令）或 fountain（如亚洲月），似乎它略简单的注册功能（缺乏计分功能）未必适用本站？而它的邀请功能虽明显有利编辑松的参与度，但现在仍测试中。谢谢。--SCP-0000（留言） 2024年8月18日 (日) 13:12 (UTC)

@SCP-2000：所以正应该引进来试试操作，反正不适合就搁著不用，也无大碍。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月19日 (一) 14:02 (UTC)

---

公示7日，2024年9月2日 (一) 13:20 (UTC)结束：讨论用户就引进CampaignEvents扩展一事基本达成共识，进入公示期。--人间百态,独尊变态(讨论) 2024年8月26日 (一) 13:20 (UTC)

再议设立编者著作权调查

之前的讨论见此。

在上次的讨论中，讨论用户就设立编者著作权调查一事基本达成一致。根据此共识，鄙人在此提出编者著作权调查的草案。若草案有不足之处还请指出。--人间百态,独尊变态(讨论) 2024年8月17日 (六) 13:00 (UTC)

字句及流程问题：

1. “多次撰写”，很多侵权文字不算撰写。“多次”的断句有风险。建议“多次上传侵犯著作权的内容（文字或图片）的用户”。
2. “长期且大量的侵权行为”的长期是否能去掉呢。
3. “五处及以上侵权行为”改成“至少五例侵权行为”。
4. “（包括修订版本和图片）”的含义模糊，次数计算方式需要摸索和设置常识（如过往已结案案例与承诺；同一条目的多次或连续编辑）。
5. “已被封禁则不必通知”的含义，对于近期封禁、申诉中仍可能需要？尽可能通知仍允许？
6. “此前未参与该调查申请”的含义，支持提报或提供证据算参与吗，与“提报人以外”的差别是？
7. 未见拒绝的时间点，拒绝后如何抗议。
8. 创建子页面及填入数据的流程指南。
9. “用户如果批准了一个调查申请，那么就需”->“批准调查申请的用户需要”。
10. 已删除内容的审阅，可能需要借助站外工具或管理员，而非以?结案？

总体而言支持试行，具体流程慢慢来定，以讨论和共识为基准。--YFdyh000（留言） 2024年8月17日 (六) 13:31 (UTC)

已微调第一条的建议。--YFdyh000（留言） 2024年8月17日 (六) 14:37 (UTC)

“没有证据的调查申请可能会被认定为是扰乱行为”这句中的“扰乱行为”可以考虑链接到Wikipedia:游戏维基规则。
还有如何判定调查申请的理由是否充足，有没有相关标准？
另外还有User:YFdyh000提到的两点：被拒绝申请后如何上诉；创建子页面及填入数据的流程指南何在。--Benho7599 | Talk 2024年8月17日 (六) 13:57 (UTC)

@Hoben7599、YFdyh000：在这里统一回复下两人的问题

YFdyh000：

1. 已修改
2. 已去除
3. 已修改
4. 上次讨论中对于如何算一次侵权行为，基本认为如果用户在一个修订中有上传侵权内容行为就算一次侵权。不过含义模糊这点也确实存在，所以这处我已经改成了对侵权行为本身的举例描述。
5. 已修改
6. 已修改为提报人以外
7. 已添加相关内容
8. 已添加相关内容
9. 已修改
10. 已添加相关语句，但?确有存在的必要。例如搁置以等待管理员查阅，或表示该内容不值得审阅。

Hoben7599：

关于如何判定调查申请的理由是否充足，我已经在草案中给出了标准--看调查申请给出的证据是否能够证明该用户是否存在至少五处侵权行为。至于如何判断为侵权行为，这就不是这个草案该解决的问题了。

--人间百态,独尊变态(讨论) 2024年8月18日 (日) 06:12 (UTC)

中文现阶段可能不需要个别案件子页面（我预计此种专门调查不会如傀儡调查频繁），全部放在同一请求主页面即可。这样也可以加快立案流程，减少技术负担。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月18日 (日) 10:44 (UTC)

设立案件子页面恰恰是为了分担主页面内容。如果将贡献数据全堆在主页面的话反而会显得主页面有些臃肿，所以在设计时我才沿袭了英维的分页面处理方案。--人间百态,独尊变态(讨论) 2024年8月18日 (日) 12:29 (UTC)

支持，上次讨论就是我发起的（--0xDeadbeef (留言) 2024年8月20日 (二) 12:56 (UTC)

---

距离最后发言已过三日，就该草案 公示7日，2024年8月31日 (六) 06:29 (UTC)结束--人间百态,独尊变态(讨论) 2024年8月24日 (六) 06:29 (UTC)

为管理人员任免制度检讨等事

近期又一管理人员解任投票，甫应用安全投票之新制，技术实务运作尚难称熟稔；又逢显著外来干涉及共识形成程序疑虑，遂致前所未有之困窘，乱象丛生、弊端频出，社群矛盾对峙趋于激烈，此实无庸置疑。与此同时，定期审视更新管理人员任免制度，有助于人才新陈代谢，充实本站高级维护量能。时值仲裁委员会组织筹备停滞之际，“远水难救近火”，故谨以此话题为首，先行就管理人员任免制度若干既存问题略作检讨，望社群踊跃发表意见。改革路程自不必操之过急，但求气象有所更新尔。本人谨提出三个大问题，社群可拨冗予以回应，或自行提出其他值得专门讨论之问题。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月18日 (日) 18:29 (UTC)

安全投票问题

目前，本站之管理人员任免案，均采行安全投票制度。安全投票之匿名，优缺点一体两面，优点在于得脱离现实外力束缚，保障自由表达意见，有助于完整呈现社群意志；缺点则在于几无制衡极端之手段，如此次投票之若干附言，或因涉及与当事人之私人恩怨，极尽猥琐下流之能事，对部分群体及特定个人之攻讦、人身攻击及无理羞辱等暴言（本人不拟重述各种不堪入耳之文字于此，请自行阅读相关内容），不仅早已背离解任投票本身形成有效共识之意旨，更远远超出社群应容忍之文明底限，而显难以“可受公评”为借口。此外，安全投票虽号称得以防堵大规模公然拉票之威胁，惟迄今其效果不仅有待商榷，而社群因该制度高度封闭之特性，反而难以协助查核投票细节；如此次投票虽有严重扰乱之指控，但仅有少数电子邮箱等书面证据，社群无法对比既有编辑贡献，或额外确认许多可疑相关内容。又安全投票长期未能由本地社群完整掌握，须受制于全域社群等客观限制；投票设置程序繁琐冗长，更屡生不可抗力之技术问题，若与其他因素叠加，结果甚至可能损及管理人员任免案本身之公信力。安全投票本为预防若干外部势力之现实威胁而设，此种威胁既已有消退迹象（与本站志趣不合之同志，多已分道扬镳不复归），加之以前述安全投票之弊端，虽难谓前述恶意影响荡然无存（此处须特别强调仍不应低估危险），惟两相权衡下，认为有酌加商榷该制度应用之必要，至少亦应有些许合理讨论。谨尝试提出问题如下：

一、社群过往执行安全投票，就可自行控制之部分（不包含须迎合全域动态之技术安排等），有何应从速改善之处（如事前人事选定等筹备作业、事后点票及公告程序等）？

二、社群应是否继续于管理人员申请及管理员解任投票采行安全投票？或研议若干指标，持续评估是否沿用，乃至于采取行动，制裁投票过程可能出现违反方针与指引之举？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月18日 (日) 18:29 (UTC)

就管理员解任而言，我个人觉得非常有必要返回公开讨论的机制。

1、安全投票所带来的“隐私”实际弊大于利，共识应当是一个持有不同意见的人互相尝试说服对方的过程，而无法回复他人意见导致事实查核无法有效反驳（例：Bluedeck原话说不至于不限期封禁，在解任界面持续被说成第三方管理员不认同可构成查封理由，而Bluedeck实际上会有限期封禁。）另外，安全投票对于外部影响有混淆的负面效果，如果有人平时没有编辑的突然在解任案上发表意见，则可能是被拉票。公开投票则让社群更能够找出可能影响。

2、安全投票程序复杂，给志愿者带来不必要的工作

3、未发现公开讨论有哪些弊端，目前的恶意影响有利用信息不透明的嫌疑，因此不认为站内投票会加强恶意影响。--0xDeadbeef (留言) 2024年8月19日 (一) 02:35 (UTC)

1、可自行控制之部分之后基金会可能允许直接在本地维基上举行安全投票，有关要求可以跟基金会提。

2、安全投票可以保证意见不受干扰，虽然WP:暴力威胁风险降低，但也有公开表达意见者遭受WP:骚扰的问题，因此社群应继续采行安全投票。

3、对于制裁投票过程可能出现违反CIV、PA等投票内容，应该可以宣告辱骂他人等违反方针的投票无效，相信很多人就不会发出违反方针的内容了。必要情况下也可以请求基金会协助，因为技术上还是能找到这个人的。

4、投票前就可以讨论并尝试达成共识，投票中也仍然可以在站内讨论，也可以回复他人意见。另外也建议公开投票人名单即可找出可能的影响。

--桐生ここ★[讨论] 2024年8月19日 (一) 03:34 (UTC)

有公开表达意见者遭受WP:骚扰的问题 - 如何证明安全投票减少骚扰，或公开投票骚扰现象会更多？ 0xDeadbeef (留言) 2024年8月19日 (一) 11:18 (UTC)

使用安全投票，骚扰者不知道你的态度，所以根本不会骚扰你，因为他根本不知道你的意见和他一致还是相反。使用记名投票，骚扰者知道你的选择和他不同，自然可以骚扰你。你维现在也有邮件骚扰这种事。--桐生ここ★[讨论] 2024年8月19日 (一) 13:07 (UTC)

这个和安全投票防止暴力威胁的原理是差不多的。--桐生ここ★[讨论] 2024年8月19日 (一) 13:10 (UTC)

并不觉得这种未经证实的事情（你只是提供了“公开投票可能有更多骚扰行为”的解释，你并没有证明这实际上会发生）可以作为以投票代替讨论的理由。共识就应该以讨论来产生，安全投票只会导致原本愿意沟通的人更加两级分裂（参考此次解任案）而对于对方的合理观点不予理会。--0xDeadbeef (留言) 2024年8月19日 (一) 13:17 (UTC)

附议。甚至之于管理员选举等重要议事事项也未尝不能恢复到公开投票的模式。--SheltonMartin留言|签名 2024年8月20日 (二) 06:31 (UTC)

@SheltonMartin：可否澄清一下此附议是指哪一个留言--0xDeadbeef (留言) 2024年8月20日 (二) 12:58 (UTC)

您的。--SheltonMartin留言|签名 2024年8月22日 (四) 02:37 (UTC)

(！)意见 虽然安全投票可以很好地隐藏发言人，并且在结束前无法得知意见，但这也催生了一些可从本次投票窥见的问题。A. 安全投票能保护投票人，可能会有人抱着找不到我的心态投票，导致一些公开投票不会出现的留言；B. 依WP:投票不能代替讨论，隐藏意见对共识的取得是致命的，无疑盲人摸象。就好比辩论双方只能写意见到白板上，裁判喊321同时亮牌子并直接打分。纵观RFA/AFD投票，经常会有人被他人说服后改票。

直接取消安全投票也可，但我也想了两种不成熟的折中方案，供社群参考，抛砖引玉：

先行投票是否启用SecurePoll

在依方针举行SecurePoll前，先请各位维基人对是否启用安全投票进行投票。投票完毕后，则按照结果正常执行程序。补充：也可考虑仅允许投票选择投票方式的用户参加正式投票，此举一可以避免群发讨论页信息，二可提前筛选用户。

安全投票之优势在于避免受他人威胁与保护自我隐私，如果上述二种诉求不强烈，大可采用更便捷的公开投票。缺点则会使过程冗长。

自愿隐藏投票者

与旧投票方式无异，但是用户可自行选择隐藏投票签名者。目前能想到的办法是请求监督隐藏编辑者用户名？

优点是便于划无效票，并及时知道他人意见以供参考。缺点则会增加监督工作量。——即请秋安 ZhaoFJx_{(论•欢迎签名)} 2024年8月20日 (二) 15:52 (UTC)

不觉得两方案可行，第一方案在原本SecurePool之上更加浪费时间，而不一定就解决投票代替讨论这一问题。第二方案，首先技术层面上就很难做到，其次也阻止不了“写下歪曲事实或诽谤的意见就走人”这种情况（因为如果实际匿名，那监督员不应知道是谁留下意见，而如果监督员知道所谓匿名的意义也就消失了，与其把扰乱用户揪出来的责任交给监督员不如公开让社群看到是谁）--0xDeadbeef (留言) 2024年8月24日 (六) 07:19 (UTC)

所以直接取消掉安全投票转公开投票也挺好的，不过还是要看社群共识。对第二个方案我想补充一下，显然不符合事实的投票质询回复来来回回，自然可看出谁有理。而且可以考虑允许监督员作为受信任用户监票并记录，同时在争议情况下综合意见判断特定投票是否有效。——即请秋安 ZhaoFJx_{(论•欢迎签名)} 2024年8月24日 (六) 09:09 (UTC)

我有替代方案就是同时进行公开投票和安全投票，担心有安全风险或遭受暴力威胁骚扰报复的情况下可以登记为安全投票投票人，然后这些人使用安全投票，其他人使用公开投票。--桐生ここ★[讨论] 2024年8月24日 (六) 17:37 (UTC)

仍不能避免此制度遭滥用。另一个想法是恢复公开投票，但允许有必要者向第三方行政员（或管理员？）报备后使用未公开分身账号投票。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月26日 (一) 07:15 (UTC)

若那些留言严重到需要处理，社群完全可以请求基金会处理，而无需因噎废食。想想为什么基金会选举使用安全投票？为什么运动宪章使用安全投票？为什么UCoC使用安全投票？为什么en仲裁委员会使用安全投票？如果社群不打算彻底改革管理员任免，停止以投票决定结果，改成就某人是否能担任管理员一题不设时间限制辩论至得出共识为止，那么就不应该对投票制度倒行逆施。--桐生ここ★[讨论] 2024年8月26日 (一) 07:56 (UTC)

某些纯粹是道德低下的行为，如果换成公开投票，当事人不见得就敢如此在自己的签名前面大放厥词，就算坚持要发，至少也能公开为自己愚蠢的言论负责。我当然亦不会幻想这样做能解决所有问题，但肯定能解决不少。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月26日 (一) 15:36 (UTC)

涉及管理权限争议之过渡仲裁措施

此次投票，一大理据涉及管理权限特定争议。此种复杂之争议，本应考虑由具公信及专业之第三方维基人组织仲裁，详加审核相关操作及证据，并经深入思索提出报告供参为宜。“管理员的离任方针”亦明确强调，解任投票属最终手段，当有十足充分之考量而行之；若能借由仲裁措施或处分有效厘清双方权责过失，并借由沟通有效缓和争议、化解双方分歧，最终往往毋须诉诸解任。惟本地现有制度，尚未提供前述第三方仲裁措施之基础；如管理员布告板，向来无力处理特别严重之争端，而此次投票纵有若干管理员等社群成员就解任理据独立从事查证，惟其受时间、人力等客观限制，亦难称臻至完善，且未能获社群正式背书，效力恐有所折扣。近年来本站筹设仲裁委员会，固有就此问题予以釜底抽薪之可能，惟社群现阶段仍在讨论组织及人事细节，望其短时间内付诸运转、乃至于树立适当权威，自是天方夜谭。值此一过渡之际，实有赖社群即时研议临时仲裁措施，以处理涉及管理权限之争议。谨尝试提出问题如下：

一、社群对于现有个别管理员难以处理庞大管理权限争议之情况（如管理员布告板各子布告板等），有何协助应对之可能方案？

二、社群现阶段于严重权限争议及解任投票“决战”夹缝间，是否可能留有任何缓冲之选择？如比照相关权限方针，引进停权警惕机制？甚或搭配独立第三方调查制度，由行政员、管理员或其他有能社群成员联席组织，以停权当事人之临时处分，换取些许余裕，得为有限期而妥当之调查报告，而免于骤然跃进解任投票之地步？

注：有关仲裁委员会之组织细节，请继续踊跃参与上方相关段落讨论。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月18日 (日) 18:29 (UTC)

• “解任投票属最终手段”这话没错，而且社群也遵循了这一规则：反正都不能沟通，当然要使用战争手段，而你维的战争手段不就是拼人数吗。说了多少遍了，你们非要从众而不是从贤。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年8月20日 (二) 09:38 (UTC)

“临时”管理员任期问题

社群晚近引进“临时”管理员机制，为尚待争取社群充分信任者提供有限期权限以为锻炼。惟“申请成为管理人员方针”指出：“临时权限与一般不限期权限无异，但需在任期结束前重新申请，并经社群投票确认，才能继续保留权限。”对于所谓“投票确认”之细节语焉不详，尤未有声明此种“临时”之有限效期是否得以连续申请无条件延长（形同“任期无限”），此于本年新一轮管理人员申请前当有所解决，方得回避无谓混乱。谨尝试提出问题如下：

一、社群是否应保留“临时”管理员机制？抑或取消之，或再研议其他制度以为替代？

二、社群是否应就“临时”管理员之任期有所限制？如限定任一期或连任特定次数以后，次轮（下轮）申请累积信任须达到正式通过门槛，否则即应收回“临时”权限，越次轮（下下轮）始得重行申请？或改为逐步提高次一任期之通过门槛，直至正式通过为止？

注：特副知目前本站唯一“临时”管理员@ATannedBurger。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月18日 (日) 18:29 (UTC)

临时管理员机制既然是提供给还没取得社群充分信任的人争取社群信任，那么临时管理员就应该把握时间让大家认可他，加上临时管理员权限与一般管理员无异，代表临时管理员在下一次申请前能充分表现，若是经过一次任期仍无法取得社群足够的信任，那或许就是暂时还不适任，因此我认为临时管理员在次轮申请时需至少达到正式通过门槛，若无法达到则应收回临时权限，下下轮才能再申请。--PC 2024年8月18日 (日) 20:36 (UTC)

我认为临时管理员机制多少还是有些必要性。不论是因为当前社群对永久管理员门槛的下调程度有限，又或者是在实务上能帮助社群多认识和了解新管理员处理事务的方式，贸然取消当前制度的话很可能导致经常被诟病的管理员难产问题再次重现。

第二个问题的话大致上同PC君的观点。考量到临时管理员的当选区间（65% ~ 75%）并没有很大，逐步提高次一任期之通过门槛究竟是需要离上次当选差多少百分比（换句话说，多少的提升才无法用误差范围/临界值来解释），为了避免此类争议，我觉得倒不如选择较为干脆的处理方式会比较洽当。--$\int$（☎）dt 2024年8月18日 (日) 20:52 (UTC)

1、若现在取消临时管理员，那么这个试验期太短，无法评判临时管理员制度效果，因此建议目前保留。

2、大致认同PC意见。--桐生ここ★[讨论] 2024年8月19日 (一) 03:40 (UTC)

---

总结一下讨论。讨论用户基本就临时管理员在第二次申请权限时须达到正式管理员标准才可保留权限一事基本达成一致。根据目前共识，个人提议在申请成为管理人员方针条文中修改以下内容：

现行条文 行政员须按投票中有效的支持票占总有效票的比例（支持率）判定管理人员申请是否获得通过。支持率达75%者，将获授予申请之权限（但根据全域用户查核和监督方针，用户查核员和监督员需要25票支持才能当选）。而管理员申请支持率达65%、但不足75%者，亦得获授予为期六个月的“临时权限”；临时权限与一般不限期权限无异，但需在任期结束前重新申请，并经社群投票确认，才能继续保留权限。

提议条文 行政员须按投票中有效的支持票占总有效票的比例（支持率）判定管理人员申请是否获得通过。支持率达75%者，将获授予申请之权限（但根据全域用户查核和监督方针，用户查核员和监督员需要25票支持才能当选）。而管理员申请支持率达65%、但不足75%者，亦得获授予为期六个月的“临时权限”；临时权限与一般不限期权限无异，但需在任期结束前重新申请，并在投票中的支持率达75%，才能继续保留权限。

--人间百态,独尊变态(讨论) 2024年8月26日 (一) 10:27 (UTC)

停止以投票决定结果

具体意见与前次RFC相同。在维基百科的权限得失上用投票得结果不过是拙劣的cosplay。既然这么喜欢互煮，建议改成就某人是否能担任管理员一题不设时间限制辩论至得出共识为止。——暁月凛奈 (留言) 2024年8月21日 (三) 08:36 (UTC)

所谓“投票”是有必要的，因为以社群规模永远不可能纯经讨论得出共识，最后还是会变成“类似投票”（!vote）。其实管理人员申请及解任投票理论上一直都是“类似投票”；个人反而觉得“解任投票”目前看来很有必要降低纯“投票”的成分（尽管社群整体意见仍占有极高比重）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月22日 (四) 13:53 (UTC)

有何差异，为何RFA如此特别，应该继续“类似投票”，无需降低“纯投票”成分？--桐生ここ★[讨论] 2024年8月26日 (一) 07:58 (UTC)

不用投票决定结果，难道以反对罢免的那几个人决定结果？--日期20220626（留言） 2024年8月25日 (日) 02:15 (UTC)

RFA和RFDA是否要求提供理由

最近有些人认为应该废除RFDA要求提供理由：

• 要求提供理由如同DYKC要求必须写废话
• 判断理由是否有效造成点票困扰
• 要求提供理由引发很多问题

也有人认为：

• 要求提供理由对共识判断相当有帮助

提请社群讨论，如果要求提供理由没有意义，而且弊大于利，是否应该废除。如果要求提供理由利大于弊，对共识判断相当有帮助，是否应该也要求RFA必须提供理由。--桐生ここ★[讨论] 2024年8月24日 (六) 18:05 (UTC)

其他意见

此处供社群发表杂项意见，若有重要问题提出者，欢迎于上方新置章节。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月18日 (日) 18:29 (UTC)

除放置公告栏外，是否亦考虑寄送用户讨论页通告，俾便广大社群知悉参与？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月18日 (日) 18:29 (UTC)

同意应该寄送。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年8月20日 (二) 12:01 (UTC)

简要模仿管治讨论做了一份通告模板供参考。——即请秋安 ZhaoFJx_{(论•欢迎签名)} 2024年8月21日 (三) 06:44 (UTC)

澄清解任过程中发言的不同解读

关于0xdeadbeef阁下在讨论中提到（例：Bluedeck原话说不至于不限期封禁，在解任界面持续被说成第三方管理员不认同可构成查封理由，而Bluedeck实际上会有限期封禁。），在下认为是不当解读， 澄清可见于：澄清解任过程中发言的不同解读。 --Gluo88（留言） 2024年8月23日 (五) 09:45 (UTC)

您好，因与检讨相关制度并无直接关联，本人将此议题移至其他意见。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月24日 (六) 08:08 (UTC)

谢谢--Gluo88（留言） 2024年8月24日 (六) 13:05 (UTC)

关于管理员错误自查表/封禁补充的说明

请移步相关页面继续讨论，勿于此处别生枝节。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月24日 (六) 14:34 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

---

Bluedeck 于2017年4月28日创建这个文档:Wikipedia:管理员错误自查表/封禁，感觉目的挺好：“在中文维基百科的实践中，管理员和管理人员有时可能会因为未注意到方针指引的一些细节而出错。在此总结了一些常见的错误，以便管理员在执行封禁时更加符合方针和指引，同时也便于普通用户根据方针指引与管理员沟通，针对疑似不当封禁的类似情况提出质疑。”

有些管理员需要更加熟悉有关方针和指引， 约束自己的行为，避免长期多年做出大量违反方针和指引的封禁行为， 避免发展到需要社群启动弹劾程序。为此目的，我系统地阅读了方针指引，查找了众多案例，花费了大量时间，进行了较为详细的补充。

所增加的问题都是在实际过程中所观察到的。从目前情况来看，许多有多年经验的管理员对方针指引仍然不够熟悉。这些总结不仅有助于管理员自查，也能帮助受到不公正待遇的用户找到相关方针和指引，以分析实际遇到的问题。

更重要的是，我们希望管理员和用户都能够按照方针办事，这些总结是否能帮助管理员和用户、是否能帮助维基社群营造一个和谐公平的合作环境是我们需要考虑的重点。 希望大家关注如何帮助社群，如何帮助维基营造一个和平公正的合作环境。

有不同意见可以提出，社群可以继续补充和讨论， 有助于创建积极的中维社群环境。社群协作的关键在于理解、尊重和包容不同的观点。即使某些用户表现不佳，作为管理员，我们应该保持专业和耐心，应该保持客观、公正和理性，而不是简单地采取高压态度。公信力需要创建在合理和公正的行为基础上。 --Gluo88（留言） 2024年8月24日 (六) 13:13 (UTC)

其实在Wikipedia talk:管理员错误自查表/封禁#有关此页面新增内容，请大家协助确认及提供意见已有用rfc发起讨论，建议在该讨论页讨论即可。--Wolfch (留言) 2024年8月24日 (六) 13:28 (UTC)

谢谢您的理解， 社群需要一起合作， 进一步改善。这个补充的目的，和本次解任直接相关，涉及范围大时间长影响大，更应该在客栈的检讨此次检验程序的过程中讨论，让一切改动公开透明，广泛征求意见， 有助于避免将来再启动弹劾程序。

目前我的修改已经被全部彻底的回退。请测评用户看一看在下的补充，发表您的意见， 包括是否应该恢复在下的编辑。--Gluo88（留言） 2024年8月24日 (六) 13:48 (UTC)

(！)意见，此讨论内容已经和页面发起的rfc讨论重复，请求未参与其中的其他用户协助关闭此段讨论，谢谢。--提斯切里（留言） 2024年8月24日 (六) 13:55 (UTC)

---

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

关于新建LTA页面

如题，本人昨天依据部分经验以及日文维基百科片段创建了LTA:GNSN页面，但根据LTA创建指示，只有在破坏易误会为善意编辑时有需要创建页面。

然GNSN之破坏行为皆非常明显，不易误认，请问各位此页面是否有存在之必要？--William is Wikipedia! 2024年8月21日 (三) 07:30 (UTC)

我认为没必要，列入LTA反而让其目的达成。回退、封禁、不理会即可。--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 08:09 (UTC)

不过William指出这些破坏者应当提交全域锁定，不知道这和列入LTA是否有相关性？思考...--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 08:11 (UTC)

(～)补充：据最新资料显示，中维的原神破坏者似并非LTA:GNSN（我认为该“声明”可信度较高）。他列出的那些傀儡账号或IP，行为确实和疑似真正的LTA:GNSN创建的GoogleRitz 2行为有异。--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 08:50 (UTC)

(：)回应，如果声明没有骗人，那我们其实也没什么需要花太多时间讨论这个了...不过我想连ja那边应该也还不知道这个GNSN是假的。--William is Wikipedia! 2024年8月21日 (三) 09:37 (UTC)

ja那边有关注到我们中维的这个“假GNSN”吗？--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 10:51 (UTC)

看起来还没，不过这可能就要劳烦较为熟知日语及日语维基的人帮忙了。--William is Wikipedia! 2024年8月21日 (三) 12:36 (UTC)

我的意思是，日维那边“是否知道中维最近两个月出现了这个假GNSN”，而不是“是否已经知道中维的这个GNSN是假的”，如果是“完全没有注意到中维的这个人”的话，那应该就什么也不用做？不过看您的回复，应该是后者，即他们“已经知道了，但还不知道是假的”这种情况……--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 12:42 (UTC)

抱歉是我没表达清楚，但我从日语的破坏者记录页面发现他们也有记录到这几个假的GNSN（他们在ja也有破坏被封禁）他们似乎还不知道这些最近才出没的LTA是假的。--William is Wikipedia! 2024年8月21日 (三) 12:54 (UTC)

同意自由雨日的说法，攻击太明显了，大多数情况下长期破坏者并不需要被记录。--Nostalgiacn（留言） 2024年8月23日 (五) 08:31 (UTC)

LTA:2077、LTA:QCHM、LTA:RF、LTA:WOW等用户也是纯破坏或攻击。另WP:RBI不是正式方针。--132.234.228.192（留言） 2024年8月23日 (五) 08:58 (UTC)

他们是LTA方针修订前纳入的LTA，不一定适用新案例--—— Matt Zhuang表示有事按“此”留言 2024年8月23日 (五) 09:38 (UTC)

如Matt Zhuang所言，记录指南这个记录标准，是2023年2月才通过。很多标准在变，这个不溯及既往的规则，所以旧的不以新标准评判。--Nostalgiacn（留言） 2024年8月23日 (五) 10:06 (UTC)

@WilliamSkyWalk：如果确认是跟新规定，这个LTA可以快速删除了，免得助长他人气焰。--Nostalgiacn（留言） 2024年8月24日 (六) 05:54 (UTC)

倒也不必快速删除，保留占位页面亦可，祇需要去掉有关破坏内容之记载。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月24日 (六) 07:30 (UTC)

可被不熟悉其编辑模式的管理员简单判断为纯粹破坏者的案例就没有列入需要（LTA:WHICH），按目前规范执行行了，目前没看到有例外的必要。--Nostalgiacn（留言） 2024年8月25日 (日) 05:27 (UTC)

管理操作复核请求：被提报用户明显存在不文明行为时拒绝做出相应处理

此请求是根据Wikipedia:管理操作复核请求所提出，请先阅读相关内容。

操作： Special:Diff/83911370

执行者： Manchiu （讨论 · 贡献 · 日志）

先前讨论：Wikipedia:管理员布告板/其他不当行为#Zhenqinli

如题。 --——— 红渡厨（留言・贡献） 2024年8月22日 (四) 04:23 (UTC)

首先红渡厨阁下只对这个版本发出了警告，未见双向留言沟通。个人认为红渡厨阁下提出的每个版本里，能看到红渡厨阁下的文字，非常地很有个人风格，对比Zhenqinli的文字，两位都很有自己的直率文字格调。将心比心，在假定善意且为初次提报之下，管理员处置并无不妥，若经过沟通无效加上数次警告后，提报才是最后考虑。（另建议，中文字尽量避免使用斜体。）--提斯切里（留言） 2024年8月22日 (四) 14:25 (UTC)

斜体是AARV模板附带的，大家熟悉一下，请各位阅读Wikipedia:管理操作复核请求，这是本站第一个AARV--桐生ここ★[讨论] 2024年8月22日 (四) 14:41 (UTC)

原来是这样啊、我的误解、非常抱歉请见谅。--提斯切里（留言） 2024年8月22日 (四) 14:59 (UTC)

我认为您说的是有道理的，我这几天会找时间与被提报用户沟通，感谢您的意见。（另外，阁下说的斜体是指的“此请求是根据Wikipedia:管理操作复核请求所提出，请先阅读相关内容。”吗？）--——— 红渡厨（留言・贡献） 2024年8月22日 (四) 14:42 (UTC)

见桐生君解释后明白是我的误解，都是模板不好（?），请见谅。--提斯切里（留言） 2024年8月22日 (四) 15:02 (UTC)

没事。--——— 红渡厨（留言・贡献） 2024年8月22日 (四) 15:09 (UTC)

一般按照以往案例来说，违反CIV而采取封禁的都是显而易见带脏字的辱骂他人。--桐生ここ★[讨论] 2024年8月22日 (四) 14:35 (UTC)

我也认同，虽然言论可能有些许不妥，但离CIV还远了。--William is Wikipedia! 2024年8月22日 (四) 14:47 (UTC)

懂了，在你维可以随便阴阳怪气，随便恶意揣测他人动机。--——— 红渡厨（留言・贡献） 2024年8月22日 (四) 14:49 (UTC)

非此意，只是依以往案例，比较像AGF而已，并没有要赞同这种行为。--William is Wikipedia! 2024年8月22日 (四) 14:55 (UTC)

同WilliamSkyWalk。--桐生ここ★[讨论] 2024年8月22日 (四) 14:58 (UTC)

你们是不是此意不重要，关键是有管理员觉得可以啊，反正像《Wikipedia:管理员布告板/其他不当行为#Zhenqinli》这样恶意揣测，只会得到管理员的一句不痛不痒的提醒，那我以后也这么讲话咯。--——— 红渡厨（留言・贡献） 2024年8月22日 (四) 15:08 (UTC)

在假定善意之下，个人认为红渡厨阁下尽量试看看先跟对方沟通，请他避免自我揣测。就像现在，我觉得您直接认为管理员没有看出对方的“恶意”的发言略带有“攻击性结论”。每个人感受到不同，可能也许或者我猜您会说我就是这样说话，但对方或许也是呢。还是试着聊聊吧。--提斯切里（留言） 2024年8月22日 (四) 15:14 (UTC)

我还是希望大家多沟通为宜。--千村狐兔（留言） 2024年8月23日 (五) 22:51 (UTC)

遇到校园欺凌时，老师对受害人说“如果你不要跟坏孩子接触，如果你再强壮一点，如果你再聪明一点，如果你成绩再好一点，如果你不要激怒他们，如果穿得不是那么暴露……事情就不会发生。”这是在暗示“你也犯了错误”（[2]）。

当然性质可能不同，但是受害人的感觉与旁观者是不同的。“好警察”也够多了，也需要有人做“坏警察”。--Nostalgiacn（留言） 2024年8月25日 (日) 05:39 (UTC)

@Nostalgiacn阁下的意思是，红渡厨阁下确实受到伤害？--提斯切里（留言） 2024年8月25日 (日) 09:23 (UTC)

我又不是他，我怎么知道。当代政治正确，一个称呼不当，对方也会被感到被歧视，被冒犯，这是很主观的。退一步硬要我去猜测的话，基于善意推定，红渡厨在提报后，不服判决走复核，那就是对某些言语忿忿不平。--Nostalgiacn（留言） 2024年8月25日 (日) 14:57 (UTC)

你维很多人确实有一种愚蠢的文明观：只要不带脏字，怎么骂人，怎么冒犯，怎么诽谤都可以。但是。你要说人家是诽谤，也要说清楚为什么是诽谤吧？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年8月23日 (五) 08:51 (UTC)

(！)意见我认为有符合CIV中的轻蔑其他编辑（如果要来比较清理废话跟无事生非，浪费社群资源哪句比较不文明当然也可以讨论）。批评肯定是有的，是不是恶意的话...或许在执行层面上Manchiu希望两位还能保持一定的假定善意就是了。--$\int$（☎）dt 2024年8月26日 (一) 05:51 (UTC)

你维CIV又能这么用啦？真是充满了魔法呀。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年8月26日 (一) 08:45 (UTC)

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到复核请求关闭。欲让机器人存档，请移除本模板。留言请置于本模板上方。

请求CCI Lki5168

@0xDeadbeef，我和@User:Jonathan5566 审阅最近 @User:Lki5168的草稿发现有大量侵权，现在提请CCI流程。 -Lemonaka 2024年8月27日 (二) 00:39 (UTC)

Can you give examples of the five infringements of User:Lki5168.

可否给出User:Lki5168五处侵权的实例。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 02:10 (UTC)

敝人撰写之词条

皆为参考资料后

以自己的方式进行撰文

然 史实 "无法" = 串改

只能依照 "参考资料" 进行 = 润饰

再依照格式以及各资料予以进行总和撰文

故而 "大量" 的 = 侵权!!!

请再次查明--Lki5168（留言） 2024年8月27日 (二) 02:27 (UTC)

润饰就是侵权。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年8月27日 (二) 07:13 (UTC)

@Lki5168 这指：不是你仅在单一条目／草稿有侵权行为，而是你涉及多个页面、多次的侵权行为--Benho7599 ^{坚决拥护以芙宁娜同志为核心的枫丹} 2024年8月27日 (二) 07:34 (UTC)

1. Draft:后社角圣和宫(学甲)轶事段落。
2. Draft:大埔口(学甲)历史轶事段落
3. Draft:学甲焕昌镇寿殿建庙沿革。

-Lemonaka 2024年8月27日 (二) 13:50 (UTC)

Can you provide more examples of infringement.You have provided only three instances of infringement, whereas we need a minimum of five.

能否提供更多的侵权实例。您仅提供了三处侵权实例，而我们最少需要五处。--人间百态,独尊变态(讨论) 2024年8月27日 (二) 13:57 (UTC)

4.草稿:宅口(学甲)闻人段落。轶事传说段落。
5.后厝仔角闻人段落。 -Lemonaka 2024年8月27日 (二) 14:03 (UTC)

Thanks.I accept this CCI request.--人间百态,独尊变态(讨论) 2024年8月27日 (二) 14:16 (UTC)

@人间百态Please create a CCI page, thank you. There's some bug in my JRE. -Lemonaka 2024年8月27日 (二) 15:09 (UTC)

跟这边大家说声道歉，我当时审核草稿未臻周延，竟未发现条目内容出现侵权情况。--William is Wikipedia! 2024年8月27日 (二) 15:18 (UTC)

@WilliamSkyWalk Not so obvious, for example, the sentence in article is
"大二时即通过普考，当完兵后又考上高考，七十五年（1986年）再考上甲等特考。服完兵役的第一份工作是到经济部金属工业研究所服务"
The origin is
"大二通过普考，当完兵即考上高考，七十五年又考上甲等特考（与马英九同榜）。服完兵役的第一份工作是到经济部金属工业研究所服务，" -Lemonaka 2024年8月27日 (二) 17:46 (UTC)

P.S. This user also used lots of books for reference, I cannot check whether these are copyvio or not. -Lemonaka 2024年8月27日 (二) 18:00 (UTC)

管理操作复核请求：不对显然违反双向交互禁制的行为进行处理

此请求是根据Wikipedia:管理操作复核请求所提出，请先阅读相关内容。

操作： Special:Diff/83987281/83987339

执行者： Ericliu1912 （讨论 · 贡献 · 日志）

先前讨论：Wikipedia:管理员布告板/其他不当行为#Chinuan12623_2

不需要更多理由，以最大程度避免我自己违反禁制。 --自由雨日🌧️（留言｜贡献） 2024年8月27日 (二) 19:24 (UTC)

请注意我不是不管，而是基于夜半时分相关操作时间轴相近及禁制制度运作模式，合理认为有相当可能为误解。本人据此善意推定，先行询问当事人是否误解，我认为这是基于人性的正常操作，而且当事人什么回答都还没有，盖以玩弄技术程序问题执行封禁，亦难谓道德。另外他在我讨论页的编辑我也已经予以单独警告，但你可不可以再多等一下啊，连这也要立刻复核，仿佛一点空间都没有似的，那我下次就真的不管了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月27日 (二) 19:30 (UTC)

另外，我想除在布告板提报对方违反禁制条件外，向管理员提出禁制申诉本身应该也属于另一例外，否则要详细解释就八成会违反禁制，这就相当于禁止当事人申诉，其实也不合理吧？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月27日 (二) 20:03 (UTC)

虽然现行方针写“禁制申诉及复核应于用户讨论页提出”，但总会有外溢抗议（比方说管理员布告板那个跟现在这边这个应该都算），这些是否亦应全部禁止？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月27日 (二) 20:06 (UTC)

同意这个观点，既然提报属于合规行为，那么申诉也应该属于合规行为。--桐生ここ★[讨论] 2024年8月27日 (二) 20:09 (UTC)

@桐生ここ：由于禁制所限我无法直接对您这句话展开讨论，我只能说您后半句描述的情况并非实际发生的事情。--自由雨日🌧️（留言｜贡献） 2024年8月27日 (二) 20:14 (UTC)

补充：我还没仔细看来龙去脉，只是对Eric Liu提出的方针改革方案表示支持。--桐生ここ★[讨论] 2024年8月27日 (二) 20:18 (UTC)

(～)补充：我刚又进行了新的提报，见WP:ANM（本条评论发出时暂未有管理员处理）。--自由雨日🌧️（留言｜贡献） 2024年8月27日 (二) 20:27 (UTC)

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到复核请求关闭。欲让机器人存档，请移除本模板。留言请置于本模板上方。