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

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

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

公告栏

• [人事] S8321414当选为管理员，Diskdance当选为界面管理员，Kanashimi同时当选为管理员和界面管理员。
• [公告] 规范序言罗列别名、修正Wikipedia:界面管理员及将禁止歧视方针替换为软重定向已经通过。
• [公告] 调整两岸四地用语格式手册中国籍表记的规定、调整两岸四地用语格式手册中“中国大陆”、“大陆地区”、“大陆”等用词的规定、提议将Mediawiki保护改名及有关日本内阁条目的命名正在公示，如有意见请尽快提出。
• [讨论] 互助客栈方针区正在讨论有关申请权限与申请解除权限的方针条文与申请区的放置问题及提升巡查员的门槛，请踊跃参与讨论。
• [讨论] 互助客栈技术区正在讨论Module:ISO 3166/data的子页面的地名设置事宜及Jpn、Kor等模板是否应改以langx等模板为基础的事宜，请踊跃参与讨论。
• [讨论] 互助客栈其他区正在讨论重新引入用户查核，请踊跃参与讨论。
• [协作] 第二十三次动员令正在讨论固化未来部分动员令筹备事项及公示本次动员令之规则及时间，请踊跃参与讨论。

• [协作] 现有142个页面需维基化，482个条目需清理，18个移动请求正在讨论。
• [奖励] 现有2名用户获提名维基奖励，欢迎投票。

#	💭 话题	💬	👥	🙋 最新发言	🕒 (UTC+8)
1	管理操作复核请求：Wcam关闭文件存废讨论的程序问题	12	6	Wcam	2025-04-08 23:45
2	引入临时账号功能后，谁应该能够看到 IP 位址？	60	14	SCP-2000	2025-05-06 19:56
3	对各位是否了解监票员在安全投票机制中作用的简易调查	118	31	Python6345	2025-05-10 20:14
4	Sidebar问题	4	2	YFdyh000	2025-05-03 23:21
5	DYKC发生什么事了？好多提名都没处理	3	3	ATannedBurger	2025-05-10 03:07
6	User:Rastinition绕过程序直接将列表重定向是否涉嫌扰乱？	2	2	Python6345	2025-05-09 20:55
7	关于翻译时遇到的WP:引注炸弹（？）	6	4	魔琴	2025-05-10 14:53
8	有关维基百科:管理员布告板/其他不当行为的条文更改	4	2	Ghostingb	2025-05-11 00:22
9	有关维基百科:编者著作权调查#调查案件的审阅流程的条文更改	2	1	DaqibaoQi	2025-05-11 08:31
10	有关维基百科:编者著作权调查#正在进行的调查案件中案件的编辑权限	3	2	DaqibaoQi	2025-05-11 08:27

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

正在广泛征求意见的议题

议题清单

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

维基专题与协作

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

管理操作复核请求：Wcam关闭文件存废讨论的程序问题

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

操作： 结案存废讨论

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

先前讨论：https://w.wiki/DNAS

管理员Wcam在参加了存废讨论的同时也关闭了该存废讨论，依据关闭存废讨论指引，“...一名未参与提删和讨论的管理员或富有经验的编者将依《关闭存废讨论指引》关闭存废讨论...”。按理其不应关闭此讨论，因此提出此复核请求。本复核针对的是结案程序问题，不一定要对存废讨论的结论作出复核，有用户在站外指出不应该提交DRV，故重新提交于此，先前讨论内容位于上方链接。此外，搜索存废讨论记录可知，这不是Wcam第一次如此操作了，谢谢。 --在下荷花，请多指教（欢迎签到） 2025年3月10日 (一) 10:54 (UTC)

补一下链接吧：Wikipedia:文件存废讨论/记录/2025/02/27 § File:HOYO-MiX - La vaguelette.ogg--深鸣（留言） 2025年3月10日 (一) 10:58 (UTC)

谢谢。--在下荷花，请多指教（欢迎签到） 2025年3月10日 (一) 10:59 (UTC)

我看后，同意wcam的说法，即他针对NFCC标准和模板的发言并不算参与存废讨论发表意见。这些发言可以看作他结案的理论依据。不过如果二位认为继续存废讨论有必要，那么我可以按共识不足来重开启讨论（如果删去wcam的讨论，那么我觉得共识是不足的）。此外，同时我觉得我们的NFCC标准可以向英维同步，如果条目中有音乐评论，就允许使用。我认为英维能够实施一段时间的方针就可以看作基金会也认为在法律上没问题。单看fair use的法律原文，严格程度目前是 中维 >> 英维 > 法条。如果您想正式提出这个提案，我会支持。Bluedeck 2025年3月11日 (二) 05:55 (UTC)

感谢评论，我觉得可以，那应该提议修改WP:NFCC还是哪条方针？--在下荷花，请多指教（欢迎签到） 2025年3月11日 (二) 06:44 (UTC)

个人感觉修NFCC就可以了。Sanmosa _新朝雅政 2025年3月11日 (二) 13:24 (UTC)

@Bluedeck：感谢您的意见，但对于英维能够实施一段时间的方针就可以看作基金会也认为在法律上没问题不敢苟同。某一维基计划的某一方针的实施时间长短，与基金会对相关方针的态度，没有必然的逻辑关系。基金会全域著作权方针明确规定“所有计划都只应该寄存符合自由内容许可协议的内容”和“（允许非自由内容的）‘豁免原则方针’必须尽可能少”，所以越少使用非自由内容越符合基金会的意愿。从现状来看，使用非自由文件的维基百科计划的数量少于半数，若算上所有维基计划，则使用非自由内容的计划更是少数。因此，我们不能无视这些事实和基金会全域方针的规定，而单看某一计划的非自由内容限制较为宽松就与之看齐。--Wcam（留言） 2025年3月11日 (二) 20:54 (UTC)

EDP这文章我第一次看，谢谢你指出。文章确实写明EDP的适用范围应该尽可能少。不过，同段内指出EDP可以接受的适用范围包括：“... or to complement (within narrow limits) articles about copyrighted contemporary works. 【中：……或者作为补充，放在描写受著作权保护的现代作品的条目里】”，我一看，这个似乎恰好适用于芙宁娜条目的情景？Bluedeck 2025年3月11日 (二) 22:54 (UTC)

其实基金会的声明本质上就是在各方妥协的情况下，作为自由文化的一面旗帜尽量倡导自由文化（可参考自由软件运动）--百無一用是書生 (☎) 2025年3月12日 (三) 01:36 (UTC)

@Bluedeck：请注意这里within narrow limits是个相当关键的限制。本案中的copyrighted contemporary work是“轻涟”歌曲，而芙宁娜条目并不是直接关于该作品本身的条目，故在within narrow limits的前提下我不认为符合您提到的可以接受的适用范围。--Wcam（留言） 2025年4月8日 (二) 15:45 (UTC)

我对我关闭存废讨论的操作有被视为违反WP:CLOSEAFD的嫌疑表示歉意，今后会多加留意。--Wcam（留言） 2025年3月11日 (二) 20:23 (UTC)

谢谢您--在下荷花，请多指教（欢迎签到） 2025年3月12日 (三) 00:14 (UTC)

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

引入临时账号功能后，谁应该能够看到 IP 位址？

通过临时账号，我们可以用新的唯一识别码替换未注册编辑者的 IP 位址。此次更改后，未注册编辑者的 IP 位址将不再对外开放。我们做出这项改变是为了加强对安全和隐私的支持，以确保我们的贡献者继续感到安全。

另一方面，在某些情况下，保护维基媒体项目（打击垃圾邮件、破坏行为、骚扰等）的用户需要查看未注册编辑者的 IP 位址才能有效地进行工作。为了平衡这些需求，我们的政策是继续向某些用户提供临时账号 IP 位址的存取权限，使用下面描述的流程。

在今年稍后我们在 本 wiki 上推出临时账号之前，我们需要明确谁可以查看临时账号的 IP 位址。我们希望征求您的意见。

问题

目前，该权限会自动授予以下用户：

1. 拥有扩充权限（例如管理员、CheckUsers、全域系统操作员、监管员——请参阅政策以取得更多示例）
2. 没有扩充权限，但其本地账号至少已使用 6 个月，并且对本地项目进行了至少 300 次编辑。

我们的问题仅仅与#2有关。在任何维基媒体项目上部署临时账号之前，我们已经选择了这些数字阈值。然而，我们清楚地认识到，这些门槛相当低，恶意行为者仍然很容易取得临时账号 IP 位址。我们听到了多个社群对此的担忧，包括第一批试点社群。我们希望临时账号能够真正改善编辑者的隐私，因此在拥有大型社群的维基上推出此功能之前，我们需要采取更严格的限制。

在与管理员、一些试点维基媒体项目的社群成员以及活跃于英语 Discord 的社群成员就其他选择进行磋商后，我们希望在最终确定这项更改之前得到您的回馈。

我们的新方法

我们建议没有扩展权限的用户可以申请查看临时账号的 IP 位址的权限，由管理员或监管员决定是否授予权限。我们的目标是更一致地限制 IP 位址存取权限，仅允许需要存取 IP 位址的人存取。这将需要人工操作，但与我们继续自动授予权利相比，负担应该会更小。

当我们将临时账号部署到更多维基媒体项目时，我们可以评估其影响并根据需要调整我们的方法。

这将如何运作

• 当没有扩展权限的用户需要查看临时账号IP地址时，需要申请加入“临时账号IP查看者”群组。他们会向管理员（当地社群将能够决定该流程）或监管员（对于没有当地管理员的维基媒体项目）提交请求。
• 该功能要求用户至少有 300 次编辑且账号使用时间至少为 6 个月。管理员和监管员将无法向不符合该标准的账号授予临时账号 IP 存取权限。这是最低限度，我们鼓励社群——特别是较大的社群——执行更高的门槛。根据临时账号试点社群的评论，我们建议至少将 600 次编辑作为门槛。
• 审查请求的用户将检​​查申请权利的用户是否符合要求以及是否提供了有效的理由。权利本身将通过 Special:UserRights 授予。
• 授予权利请求的用户同时将拥有删除处理的权利。

请注意，存取 IP 信息功能的要求与存取临时账号 IP 位址的要求相同。

我们考虑过的其他选项

我们考虑过一系列选项，包括：

• 仅向具有扩展权限的用户授予权利。
  • 优点：从用户安全的角度来看，这是理想的，因为只有经过社群审查的用户才能获得存取权限。  
  • 缺点：限制性太强。许多巡查活动都是由没有扩展权限的编辑进行的。如果我们这样做，就会增加具有扩展权限的用户的巡逻负担。
• 增加编辑次数和/或账号年龄的门槛。该权利仍将自动授予。
  • 优点：从技术上来说，这是一个简单的改变。
  • 缺点：恶意编辑者取得临时账号 IP 的风险仍然较高。恶意用户可以在自动化工具或脚本的帮助下达到任意阈值计数，无论多高。这同时将使小型项目的善意编辑更难通过常规编辑获得此存取权限。

我们的问题

• 新的提案是否充分解决了隐私问题？
• 当我们执行这项政策时，是否应该知道这会对您的社群产生什么影响？我们希望在 2-3 周内更新该政策。

在接下来的几周内，我们将向您提供有关临时账号和相关功能的更多更新信息和素材。

我们在此再次感谢所有帮助我们找到不同选择的成员。如果您希望了解有关该项目的更多信息，请阅读 Diff 部落格，访问我们的项目页面和常见问题解答。请订阅新闻通讯以保持联系。谢谢！NKohli (WMF) 与 SGrabarczuk (WMF)（留言） 2025年3月11日 (二) 23:45 (UTC)

六百次编辑够多吗？虽说现在本来谁都可以看就是了（ —— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年3月12日 (三) 04:01 (UTC)

Hey @Eric Liu. If I interpret your comment correctly, you doubt if a higher number would be a better solution? Yeah, it's fairly easy for people with bad intentions to meet the criteria if these are just numbers of this or that. The essence of the change is that users who are not admins, CheckUsers, etc. would need to be granted the right manually by people, as opposed to a script.--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 08:34 (UTC)

@SGrabarczuk (WMF)： I think he means that 600 edits may not be enough for this flag.But that is not the key point.The key point, as you say, is that it should be up to the community to judge whether or not to grant this flag based on the credibility of the user, and the number of edits is only one of the criteria used to assist the judgment.--人间百态,独尊变态(讨论)(签名) 2025年3月12日 (三) 14:46 (UTC)

Thanks @人间百态!--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 15:35 (UTC)

不展示实际地址，而只允许查看ISP、用户间IP相似度等简要信息，不是更好吗。--YFdyh000（留言） 2025年3月12日 (三) 04:19 (UTC)

@YFdyh000, for almost everyone, only temporary account name (like ~2025-12345) will be visible. People with access to IP addresses of temporary accounts will also have access to IP Info, and that tool gives this data - just like on this screenshot.--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 16:26 (UTC)

傀儡调查助理很有必要能获授予此类权限，检查IP地址及后面的电信商、地理位置等信息的关联显然是傀儡调查的核心之一。只查看相似度就变成另类CU，还要搞另一轮。--路西法人 2025年3月12日 (三) 09:49 (UTC)

我觉得应该反过来思考，足以取得前述权限者乃为傀儡调查助理之基本条件。不过其他人说得也对，标准或许定得低一点也非全然坏事。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年3月12日 (三) 16:09 (UTC)

确实有这么一回事，认同你的反向思维。--路西法人 2025年3月13日 (四) 04:49 (UTC)

我说临时用户的IP和ISP的相似度，展示相对距离而非明文。--YFdyh000（留言） 2025年3月12日 (三) 22:27 (UTC)

要搞相似度也还是一件很难搞的事情，究竟什么为之“相似”什么是“无关”并非自动化程序可以判定。--路西法人 2025年3月13日 (四) 04:46 (UTC)

就是例如弄一个在线程序，显示临时用户A与B的ISP是否相同，网段距离（比如同一或相近D段内），辅助判断傀儡而不揭示真实归属，以满足权限下放而不敏感。--YFdyh000（留言） 2025年3月13日 (四) 08:58 (UTC)

zhwiki特有的IPBE授予者应自动加入此组。--Akishima Yuka（留言） 2025年3月12日 (三) 13:40 (UTC)

不见得IPBE授予者在哪个步骤需要用到这个查看的权限。--路西法人 2025年3月12日 (三) 15:20 (UTC)

Thanks for your comment, @Akishima Yuka. In my opinion, users with IPBE don't have that much in common with this topic, because they (passively) benefit from something, whereas this topic is meant to be about users who (actively) need information about other users' IP address. For example, I have the IPBE flag on Spanish Wikipedia, but I'm not really involved in fighting vandalism there. Does that make sense? What do you think?--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 17:55 (UTC)

@SGrabarczuk (WMF)：Hi there, I believe what Akishima talked about is 'IPBE Grantor' instead of IPBE, which is a special user right that only exists in zhwiki due to high backlog of IPBE request. Though, I think it's stil not relevant because granting IPBE doesnt matter with viewing temp accounts IP Address(es), and if it's the qualification of viewing temp accounts IP Address, it would be too high obviously.--Aqurs 2025年3月12日 (三) 18:03 (UTC)

You may regard the public proxy IP address as a verification of their request, or else the IPBE granting would have no threshold at all. The technique and possible money cost of using a proxy can be a threshold for the uninvited.--Akishima Yuka（留言） 2025年3月12日 (三) 18:24 (UTC)

Thanks both! Google or DeepL translated the comments as IPBE grantee, not IPBE grantor, that's why I didn't understand initially. The requirements for IPBE Grantor are higher than the ones which we'd like to apply to IP reveal - that's good.

I think that technically, the easiest solution will be for the community to adopt a local (just for zhwiki) policy that all IPBE Grantors are given IP reveal (as an integral part of 权限申请/申请IP封禁豁免授予权), and then whoever grants the IPBE Grantor permission, would also grant IP reveal. So it would be the manual way.

Why the manual way? I seriously doubt if, for the sake of several users, our team would adjust the global policy and the global script adding the rights.--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 23:22 (UTC)

个人认为巡查回退员必须拥有此“查看临时账号ip”的权限。临时账号大多是一次性用，若此权利获取难度太高会严重影响用户巡查工作。个人不反对600次编辑可以自动获得此权利，毕竟目前所有人都是可以查看未注册维基人的ip地址。--Aqurs 2025年3月12日 (三) 15:35 (UTC)

个人支持将获取权利的门槛定为延伸确认用户。--Aqurs 2025年3月12日 (三) 15:41 (UTC)

(▲)同上 ——敬颂冬绥 ZhaoFJx_(论•签) 2025年3月12日 (三) 23:50 (UTC)

基本上能假定申请回退权的用户是为了进行反破坏，可以查看账号IP没什问题，但是无法假设所有延伸确认用户都在进行反破坏，我不认为需要让延伸确认用户自动获得权限，用户应该自行申请权限。--2402:7500:93E:31F0:C42C:BB2F:8912:A99C（留言） 2025年3月13日 (四) 16:33 (UTC)

@Aqurs1、ZhaoFJx：延伸确认用户只需注册达90天即可自动被授予，此与“临时账号IP查看者”的最低要求“账号使用时间至少为6个月”不符。个人认为部署初期可先人手授予，如果往后有实际需要可届时讨论是否改为自动授予。谢谢。--SCP-0000（留言） 2025年4月3日 (四) 03:33 (UTC)

赞同，延伸确认用户可以在权限申请页面申请查看临时账号IP。——ZhaoFJx(Talk) 2025年4月3日 (四) 18:48 (UTC)

只有符合“临时账号IP查看者”的最低要求（600次编辑且账号使用时间至少6个月）才行吧。--SCP-0000（留言） 2025年4月4日 (五) 01:05 (UTC)

技术上是否可以同时满足延伸确认用户+注册后6个月自动授予权限？或者考虑提高延伸确认用户条件至6个月？当然个人不反对初期人工授权。--Steven Sun（留言） 2025年4月4日 (五) 01:39 (UTC)

@Steven Sun：理论上授予“临时账号IP查看者”条件可改为500次编辑 + 注册满6个月。谢谢。--SCP-0000（留言） 2025年4月4日 (五) 12:26 (UTC)

@SGrabarczuk (WMF)：Hello, I would like to know the reason why the recommended threshold is more than 600 edits, rather than 500 or 1000 edits. It seems that it is simply double the minimum requirement of 300 edits?

Secondly, the threshold for the extended confirmed user in Chinese Wikipedia is more than 500 edits, and the account must be at least 30 days old. Based on the above comments in this discussion, it seems that the community may want the threshold similar to that of the extended confirmed user. Therefore, I am curious to know if it is possible to access a temporary account's IP address if the account has more than 500 edits (instead of the recommended 600 edits) and is at least 6 months old. Thank you!--SCP-0000（留言） 2025年4月4日 (五) 12:28 (UTC)

Hey @SCP-2000, thanks for pinging me. 600 edits is the softer part of our recomendation. Technically, we will be requiring 300 edits, and that's it. The key however is the manual granting (instead of the automatic way), and the requirement for providing a reason for asking for the right. Not everybody who is active and fairly experienced really needs access to other users' data - this is the point we would like to make.

So, personally, I guess it would be best to not connect this right with extended confirmed. Even though the requirements are similar, the purposes for these groups are not related, really. On the other hand, SPI Clerks (傀儡调查助理) and maybe maybe IPBE Grantors (IP封禁豁免权授予者) - that sounds related. Thanks,--SGrabarczuk (WMF)（留言） 2025年4月4日 (五) 16:30 (UTC)

@SGrabarczuk (WMF)： I noticed from a screenshot that you attached above – what is this "Users on this IP" thing? Is it just for "Temporary users on this IP" (I hope it is)?--路西法人 2025年3月13日 (四) 04:48 (UTC)

@LuciferianThomas It means "The average number of clients that have been observed on this IP address by Spur. It takes into account all activity from this IP address. This is calculated over a 24 hour period." If you click "ⓘ" next to "Users on this IP", you can see the above description. You may visit this page to learn more about this feature. Thanks.--SCP-0000（留言） 2025年3月13日 (四) 10:22 (UTC)

So "all activity" would include those from registered users? Even if it is only across a 24-hour period, I would strongly oppose this right being allocated to any user without a necessity to view such information. Please clarify whether registered activity is also accounted for in this data. --路西法人 2025年3月14日 (五) 00:49 (UTC)

@LuciferianThomas: The source of this data is from Spur, an external service, rather than from Wikimedia. So the data does not include any on-wiki users.--SCP-0000（留言） 2025年3月14日 (五) 00:55 (UTC)

What and how exactly does it count as a client to the IP? If that is not clarified, I could only taken into account the textual description of "all activity" (including any registered user editing Wikipedia).--路西法人 2025年3月14日 (五) 01:15 (UTC)

Great questions, @LuciferianThomas. I've asked the team because I wasn't sure myself :D

SCP-2000 is correct. IP Info only presents data about IPs pertaining to 1. IP users on wikis without temporary accounts 2. temp accounts on wikis with temp accounts.--SGrabarczuk (WMF)（留言） 2025年3月14日 (五) 15:06 (UTC)

Thank you for your response. Please ask the team to clarify such information at mw:Trust_and_Safety_Product/IP_Info#Information_available to avoid further misunderstandings, as the current wording seems to imply that registered account traffic is also accounted into "all" activity. Thanks!--路西法人 2025年3月14日 (五) 15:46 (UTC)

Yup, 100%. You can join the discussion here: IPInfo: Update confusing label for "Users on this IP".--SGrabarczuk (WMF)（留言） 2025年3月14日 (五) 16:30 (UTC)

Thanks!--路西法人 2025年3月15日 (六) 00:37 (UTC)

目前政策好像是除WP:LTA外，需要广域封禁的IP段无法WP:VIP上公开报告，以后应该如何报告这种IP段？Python6345（查论编） 2025年3月29日 (六) 14:57 (UTC)

“Appropriate venues for such disclosures include pages dedicated to Long-term abuse. ”这是指包括但不限于。个人认为只要在有需要的情况下（例如是无法在不披露 ip 及仅提及某临时账号的情况下制止有关破坏行为），任何用于提报违反方针指引的页面，皆可于该处公开提报 IP。谢谢。--SCP-0000（留言） 2025年4月3日 (四) 03:45 (UTC)

(～)补充：本人提报/16主要从单一破坏IP发现，现有政策There must be a valid reason to investigate a temporary user. Note that using multiple temporary accounts is not forbidden, so long as they are not used in violation of policies (an example of a violation includes to evade blocks or bans).是否禁止仅因单一临时账号破坏查/16下编辑，必须合理怀疑其使用傀儡？--Python6345（查论编） 2025年5月3日 (六) 05:29 (UTC)

这句仅是指出使用多个临时账号并无问题，除非目的是用来违反方针指引。个人未见必须要求“合理怀疑其使用傀儡”才能检查，只要有合理理由（valid reason）就可以了。谢谢。--SCP-0000（留言） 2025年5月3日 (六) 07:35 (UTC)

一个问题：这个引入会让Wikipedia:常年提案#限制IP创建条目提案过时吗？我看英维的说法，似乎有影响到类似提案，但我不是很确定里面的“这份提案在演变中”的意思、还有他们如何应对。

Is the introduction of Temporary Accounts makes prohibiting unregistered users from creating article proposal obsolete? Looks like a similiar proposal on the English Wikipedia also affected by the introduction of temporary accounts, but I am not sure the meaning of This issue is currently evolving and how they react.--Saimmx（留言） 2025年4月23日 (三) 23:14 (UTC)

@Saimmx：就个人理解，临时账号和IP用户本质上都是“未有注册”的用户，尽管技术和实务上有所不同，但未至使该提案过时或无效。当然，个人认为可参照 en 的做法，在常年提案页面补充相关变化。但无论如何，该提案的状态应该是由社群决定，而非基金会。谢谢。--SCP-0000（留言） 2025年4月24日 (四) 02:56 (UTC)

小结

@Ericliu1912、人间百态、YFdyh000、LuciferianThomas、Akishima Yuka、Aqurs1、ZhaoFJx、Steven Sun、Python6345、Saimmx：依照上方讨论，社群似乎倾向支持500次编辑以上（参照延伸确认用户（extended confirmed user））及账号使用时间至少6个月（基金会方针规定）才能获得“临时账号IP查看者”（Temporary Accounts IP viewers）权限。而 SGrabarczuk (WMF) 指出（见上留言），尽管延伸确认用户与“临时账号IP查看者”的申请门槛相近，但其用途并不相同，故不建议采用相同的门槛（即500次编辑）。我个人认为或可考虑采用回退员（Rollbacker）的门槛（即1000次编辑）？

再者，除编辑次数这门槛外，要求申请者说明有反破坏等实际需要，账号最近一年内未有被封禁；且需通过人手授予（参见“我们考虑过的其他选项”段落），这几点应该没太大意见？副知所有曾参与讨论的编者。谢谢。--SCP-0000（留言） 2025年4月26日 (六) 03:40 (UTC)

支持试用初期人工授予，反对永久，不过这可以之后再谈。另外巡查及回退用户组必须包括此权限。--Aqurs 2025年4月26日 (六) 04:41 (UTC)

@Aqurs1：巡查员的申请门槛为编辑至少250次和参与本站至少30日，不符基金会方针规定的临时账号IP查看者的最低要求。个人认为巡查员的门槛至少应提升至与本站的临时账号IP查看者相等要求，如果只符合基金会方针但不符本站要求，未免有人借巡查来得到查看临时账号IP的权限。谢谢。--SCP-0000（留言） 2025年4月26日 (六) 05:17 (UTC)

如果申请人有担任巡查的资格，个人认为不应该剥夺其查看IP的权利。刻意借巡查而查看，但又没有应有的能力，自然可以雪球关闭。--Aqurs 2025年4月26日 (六) 06:02 (UTC)

“如果申请人有担任巡查的资格，个人认为不应该剥夺其查看IP的权利。”然而在基金会的方针下，基本上只有两个解决方案：一、将巡查的申请门槛提高；二、查看IP的权限不包括在巡查员，而需另外申请。不然会出现申请人有担任巡查的资格，但因不符基金会方针要求而不能授予巡查之情况发生。谢谢。--SCP-0000（留言） 2025年4月26日 (六) 06:36 (UTC)

是否默认开放回退员持有此权限（我不确定有没有这回事）？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月26日 (六) 07:53 (UTC)

@Ericliu1912：个人较早前在英文 Discord 询问将查看临时账号IP的权限加入至现有权限组（如回退员）的可能性，对此基金会的开发人员回应称，他们不愿这样做，这会令现有权限组的用户因存取临时账号IP（即非公开个人信息）而承担额外风险，而那些用户并未对此表示同意（consented to）。

但如果是自动为回退员增加“临时账号IP查看者”权限组的可能性，考虑到他们似乎有相应 global script，似乎未必不行就是了，但我需要询问一下。谢谢。--SCP-0000（留言） 2025年4月26日 (六) 10:22 (UTC)

刚才 Aqurs1 在英文 Discord 询问能否为现有权限组的用户（如回退员）自动授予“临时账号IP查看者”，得到的回应是法律上并不可行。似乎现在还需要讨论的只有编辑次数这门槛？谢谢。--SCP-0000（留言） 2025年4月26日 (六) 17:30 (UTC)

以下提议条件为在基金会要求基础上新增，符合任意一项管理员即可授权：

• 甲：需编辑至少600次，最近一年内没有受到封禁（不合理封禁除外），于反破坏工作中保持活跃。
• 已：需已是巡查员或回退员，最近一年内没有受到封禁（不合理封禁除外），于反破坏工作中保持活跃。
• 丙：需已是傀儡调查助理，最近一年内没有受到封禁（不合理封禁除外）。

Python6345（查论编） 2025年4月26日 (六) 17:51 (UTC)

@Python6345：个人认为可简化成这样：

申请者需符合基金会方针的最低要求，且需符合以下任一条件

1. 需编辑至少600次，最近一年内没有受到封禁（不合理封禁除外），且活跃于反破坏工作，或有其他存取临时账号IP之需要。
2. 现任巡查员、回退员、傀儡调查助理、过滤器助理或过滤器编辑者，最近一年内没有受到封禁（不合理封禁除外）。

不知意下如何？谢谢。--SCP-0000（留言） 2025年4月27日 (日) 07:22 (UTC)

无异议。Python6345（查论编） 2025年4月27日 (日) 12:40 (UTC)

7日无新留言，准备公示？Python6345（查论编） 2025年5月4日 (日) 03:41 (UTC)

就个人所知，基金会正更新相关政策，个人认为可稍等一下。谢谢。--SCP-0000（留言） 2025年5月6日 (二) 11:56 (UTC)

异想天开，能不能把当前回退员变成一个祖父用户组“回退员（旧）”，新设“回退员（新）” ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月3日 (六) 17:10 (UTC)

这有点异想天开了（--SCP-0000（留言） 2025年5月3日 (六) 17:31 (UTC)

对各位是否了解监票员在安全投票机制中作用的简易调查

截至本讨论发布时，根据一项在站外（主要是 Telegram 自动确认用户群组和维基人的私人群组）的调查结果显示，在收到的35张投票中，约有49%的用户不了解监票员可以查看投票者的IP地址、XFF和用户代理等信息（与用户查核员在进行用户查核时可查看的信息相同）。

因此，我在此邀请各位参与此调查，以便更加完整地确认中文维基百科社群对安全投票功能的了解。同时，在一段时间后，如若结果同在站外群组中获得的结果相同或不了解的人更多的话，那么我认为我们应当重新考虑是否在未来的管理人员选举中使用此功能。

谢谢。Iming 彼女の爱は、甘くて痛い。 2025年4月23日 (三) 11:03 (UTC)

所见画面长这样（即下方Stang提到的那张截图，经询问同意放在共享资源上）

--SunAfterRain 2025年4月23日 (三) 13:08 (UTC)

调查区

我了解监票员可以查看投票者的IP地址和用户代理信息

1. Iming 彼女の爱は、甘くて痛い。 2025年4月23日 (三) 11:03 (UTC)
2. Stang^★ 2025年4月23日 (三) 11:21 (UTC)
3. ZhaoFJx(Talk) 2025年4月23日 (三) 12:58 (UTC)
4. -Peacearth（留言） 2025年4月23日 (三) 13:42 (UTC)
5. 除此之外，倒是更希望顺便讨论监督员是否适合继续监票（抑或能转交其他适当人士负责）？这毕竟是一种非常的现象，而目前社群此一方面信任，更多是对于持有权限的维基人（以及有监管员辅助等因素），而非真切认为“监督员”此一权限实体应持久负责监票程序。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月23日 (三) 13:44 (UTC) 👍2
6. Hamish T 2025年4月23日 (三) 13:58 (UTC)
7.  ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月23日 (三) 16:04 (UTC)
8. 一直知道监票员相当于CU员，只是不知到确实能拿到什么（本来以为可以看投票意向）1F616EMO（喵留言～回复请ping） 2025年4月24日 (四) 05:40 (UTC)
9. (▲)同上。Python6345（查论编） 2025年4月25日 (五) 00:15 (UTC)

我不了解监票员可以查看投票者的IP地址和用户代理信息

1. 自由雨日🌧️❄️ 2025年4月23日 (三) 11:05 (UTC)
2. Aqurs 2025年4月23日 (三) 11:10 (UTC)
3. 在下荷花，请多指教（欢迎签到） 2025年4月23日 (三) 11:23 (UTC)
4. 维基病夫_{❤️边缘人小组·签到} 2025年4月23日 (三) 11:26 (UTC)
5. 用户名能看到吗？-某人✉ 2025年4月23日 (三) 12:09 (UTC)

   @AINH：安全投票是用户名 => IP，不是 IP => 用户名--SunAfterRain 2025年4月23日 (三) 12:12 (UTC)

   所以只可以看到ip，不能看到谁投哪票？--某人✉ 2025年4月23日 (三) 12:14 (UTC)

   只能看到谁投了票，且投票人员的IP与用户代理信息，不能看到用户具体投了什么票。--beef [talk] 2025年4月23日 (三) 12:17 (UTC)

   (？)疑问：如果看不到投了什么票，之前的安全投票如何排除无效票？Python6345（查论编） 2025年4月27日 (日) 03:58 (UTC)

   FYI: 截图（CC-0@0xDeadbeef） Stang^★ 2025年4月23日 (三) 12:27 (UTC)

6. SunAfterRain 2025年4月23日 (三) 12:12 (UTC)
7. Пусть от победы☆к победе ведёт! 2025年4月23日 (三) 12:21 (UTC)
8. August_{讨论‧签名‧回复请ping} 2025年4月23日 (三) 13:53 (UTC)
9. CuSO₄ · 龙年大吉 2025年4月26日 (六) 08:30 (UTC)
10. Shawwww（留言） 2025年4月26日 (六) 08:38 (UTC)
11. 花开夜 _{留言 ·签名 ·贡献} 2025年5月2日 (五) 01:05 (UTC)

讨论区

• 另请参阅英文维基百科近期预备展开之有关征求意见；本地社群日后或可用作参考。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月23日 (三) 14:39 (UTC)

  静待本地部署安全投票.jpg ——ZhaoFJx(Talk) 2025年4月23日 (三) 15:11 (UTC)

  为啥不了解，就要重新考虑是否使用此功能？--百無一用是書生 (☎) 2025年4月24日 (四) 02:22 (UTC) +11

  @Shizhao：因为你维目前依然是没有CU存在的，上次恢复的议案好像也不了了之了，而安全投票这个看到的数据就是CU的数据。※我是认为如果有人有质疑这件事锅应该推给WMF，而不是现在在这里“调查”“重新考虑”就是 囧rz……--SunAfterRain 2025年4月24日 (四) 02:55 (UTC)

  换个说法：我们知道目前本站仍对于本地处理用户查核请求存在疑虑。根据调查可以看到，半数用户并不了解监票与用户查核本质上是一致的，那“本地来进行监票”对于这些不了解的用户就是一种信息的不透明，所以有必要考虑是否应该停止让本地来进行监票操作。 Stang^★ 2025年4月24日 (四) 07:32 (UTC)

  但实际上当初引进安全投票时，“常见问题”已明言指出：“所有人（包括选举管理员）在选举期间都不会看到谁投给了谁，选举管理员在选举期间也只能看到谁已经投票。在选举结束后，选举管理员会看到包括投票者在投票当刻的CU Data（例如IP地址），目的是用作解决拉票或傀儡投票的问题。”所以本人认为，除非社群当年投票时泰半眼瞎或不负责任，否则恕不能认为大部分参与社群的维基人对此一事实毫无认知（这安全投票有多达八百余人参加，应该是个记录）。而前述所谓“半数用户”倚靠样本极小，亦显不能与之相比。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月24日 (四) 12:15 (UTC)

  当然，这不能代表社群同时认为授权监督员长久负责这一任务妥当，因为那时“常见问题”亦仅指出“选举管理员由监管员担任”，监督员之兼任当始自后来，故严格论之，祇能视作彼时社群明白负责可能管理选举者所肩负的权限。不过，早在第一场安全投票，也就是引进投票本身的表决之际，本地监督员即有参与，时日已久，已为成例；而自那时至今，社群就此亦未有多论，大抵是因为编者普遍信赖监管员及监督员共同执行监票工作。另外，单纯忘记此事的可能也是有的（我认为上面投“不了解”者，除当年未投票者外，应多数属之）。无论如何，这些事实都不妨碍社群重新讨论安全投票机制如何运行（甚至包含用户查核权恢复等议题）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月24日 (四) 12:16 (UTC)

  除非社群当年投票时泰半眼瞎或不负责任：什么时候给到Eric君“社群会负责任地分析情况再投票”的印象了……不就是什么都是风向而已。--路西法人 2025年4月24日 (四) 23:53 (UTC)

  啥啦== —— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月25日 (五) 02:07 (UTC)

  虽然但是，刚刚看到当年的讨论，我还是要吐槽一下：

  Stang added 2 subscriber(s): Wong128hk, jimmyxu.Dec 2 2021, 12:54

  Do we yet know who these people will be? :)

  We decided to set local oversights @Wong128hk and @jimmyxu as election admins, representing the community.

  所以您应该也算是“忘记”的那一边（ —— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月25日 (五) 06:40 (UTC)

• 讨论重构：尝试处理电脑端示范图像超出可显示范围的问题。1F616EMO（喵留言～回复请ping） 2025年4月24日 (四) 05:31 (UTC)

重新引入CheckUser

监督员的职责明显跟“监票”不相关，纯粹请求有签署NDA的监督员担任此工作，导致参选监督员的候选人需要回答“CU技术性问题”也不理想。个人在此询问社群两个问题，而决定是否有需要再举行相关的RfC。

1. 本站是否有重新引入CU的需要？
2. 本站是否信任当选的CU执行所有用户查核工作（包括查核、监票等等）

--Aqurs 2025年4月25日 (五) 09:06 (UTC)

肯定会有人因为User:PMDdeSN而反对。我也是觉得很奇怪啦，2017年9月在任的本地CU，到2022年1月无一人隐退，WMF居然觉得CU还回来没事了。如果他们都没问题，那WMF拔权限做什么？如果他们还有有问题的可能，那我们把有问题的人选回来怎么办？WMF还不告诉我们解决没解决，让我们猜谜吗？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月25日 (五) 11:07 (UTC)

原有CU团队泄露过任何信息不代表整站都有问题吧，当然了WMF有什么其他疑虑不知道，至少开了绿灯目前还是先看社群意见。--Aqurs 2025年4月25日 (五) 11:31 (UTC)

2017年时是CU的人，不把他们再选成CU不就行了。相信社群有办法选出来受信且有技术能力的用户。--beef [talk] 2025年4月25日 (五) 11:45 (UTC)

既然你说“2017年时是CU的人，不把他们再选成CU不就行了”，那能否基于此直接否定所有2017年时是CU的人的CU参选权？Sanmosa _新朝雅政 2025年4月29日 (二) 12:43 (UTC)

不应该，因为管理人员申请本身就是一套信任机制。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月30日 (三) 06:14 (UTC)

我的意思是有这方面的疑虑的人完全可以合理地将2017年的事情作为反对理由。也会有人认为已经过了8年，而应该给人一次机会。我不觉得直接否定参选权是一个公平的决定。--beef [talk] 2025年5月1日 (四) 02:02 (UTC)

引用个人过去的意见“尽管基金会不愿透露相关事件是否解决，但既然已允许 CU 重新引入，可合理推断基金会认为本地可安全地进行 CU（前提符合基金会提出的条件）。”

现时最大的问题是社群互相之间的信任程度，正如魔琴君早前在 ac 群引用来自 WMF T&S 主管于 2022 年一次会议中的说法“the challenge really is whether the local community trusts itself, that the people trust each other, together elect such a group and then trust the volunteer serving in the group on the broad community’s behalf,”，而 2017 年的事件有否解决已非重要，谢谢。--SCP-0000（留言） 2025年4月28日 (一) 15:18 (UTC)

其实应该添加第三个问题（或第一个问题，看优先层级）：若本地未有用户查核员，是否应允许监督员继续代行此一任务？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月25日 (五) 13:29 (UTC)

@Ericliu1912：议案不通过就是维持现状，那也是默许了，所以我觉得不用特别列出来没关系。--SunAfterRain 2025年4月30日 (三) 14:32 (UTC)

仅从我之前协助处理火腿的体验来说，我个人觉得重新引入CU是有必要的，但是CU牵扯到太多事情了。。。。--Hamish T 2025年4月29日 (二) 00:24 (UTC)

还有人记得这个吗？2021年之前的用户查核数据有可能（而且是大概率）已经被泄露光了。。。--2A14:7581:8400:0:0:2:0:A30A（留言） 2025年4月30日 (三) 14:20 (UTC)

请注意这不是贵站的问题。--Aqurs 2025年4月30日 (三) 14:39 (UTC)

2017年查核信息被泄露，随后中国大陆维基人用户组领导人守望者爱孟被基金会全域封禁；2018年基金会剥夺了本地所有查核员的权限；2021年基金会禁止中国大陆用户签保密协议（也就是禁止授予中国大陆用户监督权与查核权），随后就是震惊全网的OA2021，中国大陆维基人用户组第二任领导人Techyan被封、曾任用户查核员与监督员的Alexander Misel被剥夺管理员权限。

我们再看看基金会给出的理由“以及有证据表明被除权者滥用站务工具支持该组织某些被禁制成员的活动，包含人肉搜索”，以及某人在站外的口出狂言“举报”，可想而知，重新引入查核权会给本站所有用户（尤其是中国大陆和中国香港用户）带来极为严重的安全隐患。--2A14:7581:8400:0:0:2:0:A30A（留言） 2025年4月30日 (三) 14:48 (UTC)

除此之外，还有个问题：如果重新引入查核权，Jimmy Xu和Cdip150是立刻复职呢，还是重新选举呢？--2A14:7581:8400:0:0:2:0:A30A（留言） 2025年4月30日 (三) 14:49 (UTC)

本人倾向于所有用户查核员都应该重新选举。--beef [talk] 2025年5月1日 (四) 02:05 (UTC)

（意见同上）—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月1日 (四) 09:08 (UTC)

我不觉得社群能够再给予足够的信任了，保护人身安全比抓到傀儡更重要。Elvaaae（留言） 2025年4月30日 (三) 17:47 (UTC)

IP君跟Elvaaae君，我想问一个问题，2017发生的事故要所有人背锅吗？贵站曾经发生事故就代表了不信任来自中文社区的“用户查核员”？目前有参与到中文社区的用户，有だ＊ぜ跟0xDeadbeef分别担任申诉专员跟英维用户查核员，请问他们获得用户的CU信息会对社群的隐私造成有什么影响吗？请不要因为过去曾经发生事故而带有偏见。--Aqurs 2025年4月30日 (三) 19:02 (UTC)

根据本地WP:CUP#1下列出的所有方针，若引入本地用户查核，所有使用用户查核的情况都必须在WP:SPI提出，完全无法发生用户查核员随便获取任何人的IP地址信息的现象，本地的其他用户查核员会时常关注查核日志并检查每一次查核是否有理有据，所以若发生滥用查核权的现象相信能够很快发现。

至于cuwiki相关：cuwiki只存储长期破坏者（WP:LTA、长期在WP:SPI出没的用户）的信息，此前cuwiki信息泄露，无法代表本地查核日志就被泄露，也无法代表任何人就能直接进行用户查核。

至于此前的

至少3个管理员，说过：把自己的管理员账号给我。但都被我拒绝。我回答：等你们什么时候混成CUer了，再把账号给我。现在CUer才是王道。管理员虽然也重要，但可CUer相比差得远。
— [1]

这样一句话，我觉得有点危言耸听，不能一个人随便吹牛说大话就能让整个社群人心惶惶吧。--beef [talk] 2025年5月1日 (四) 02:22 (UTC) 👍1

想问下查核日志（不包含敏感信息的）有公开给所有人查看的可能吗？--Elvaaae（留言） 2025年5月2日 (五) 15:25 (UTC)

或许可以，但是难以设计。比如说如果只公开针对用户的查核日志，也有可能会公开链接账号和IP地址的联系，我觉得我们应该先讨论一下让选举出来的查核员互相监督是否可行，又或者可以由其他方案，例如设立新的用户组仅有只读权限起到监督的作用（然而实际上只读权限需要的信任也是很高的）--beef [talk] 2025年5月3日 (六) 02:38 (UTC)

监管员执行本地查核时需要临时授予自己查核权限，查核完毕后应除权，这会体现在用户权限日志，可通过GRStalker工具查询。这可能相当于某种“公开的查核日志”。--dringsim 2025年5月8日 (四) 16:55 (UTC)

我觉得他问的是“假如有本地CUer的话”...--$\int$（☎）dt 2025年5月8日 (四) 22:22 (UTC)

我说难听一点啦，你翻墙出来本来就要保护好自己了，就算没有CU人家想抓你依然有办法抓好吗...--SunAfterRain 2025年5月2日 (五) 03:31 (UTC)

且不说翻墙的中国人怎么样，很多香港用户本就没有用VPN编辑你维的习惯好吗--Elvaaae（留言） 2025年5月2日 (五) 15:26 (UTC)

@Elvaaae：这个我真的只能说自己的国情就是那样请多小心，如果你自己都不注重保护自己的话就算基金会今天下了一百道保护也拦不住政府搜到你--SunAfterRain 2025年5月3日 (六) 14:45 (UTC)

@SunAfterRain 嗯，那监督员也不应该删掉侵犯隐私的内容，毕竟是“你自己不小心被人肉的”；基金会也不应该OA2021，毕竟保护自己是你自己的事；可供查证方针也应该取消，因为上维基的人应该学会自己辨认内容的真实性--103.196.21.39（留言） 2025年5月3日 (六) 13:43 (UTC)

请不要自己无限上纲。--SunAfterRain 2025年5月3日 (六) 14:45 (UTC)

如果是仅因需要监票的话，那可以考虑另设立electionadmin（监票员）而非直接引入CUer。在当前SPI转交元维基查核没有系统性问题的情况下，无需仅因监票（毕尽CUer也不是只监票而已）而将之前已证明有问题的体制重新引入。WP:没坏别修（指SPI）。--$\int$（☎）dt 2025年5月2日 (五) 00:07 (UTC)

@ATannedBurger：我记得你说的这个监票员是被技术问题本地安全投票的任务卡住了--SunAfterRain 2025年5月2日 (五) 03:29 (UTC)

英文维基百科那边正在讨论，等他们讨论完，技术阻碍应该就清得差不多了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月2日 (五) 15:49 (UTC)

“之前已证明有问题的体制重新引入”当基金会已经处理了 WMC 相关用户时（且 OA2021 已是四年前的事），他们也愿意让社群重新引入 CU 时，那还有什么潜在的问题社群尚未解决？谢谢。--SCP-0000（留言） 2025年5月2日 (五) 15:53 (UTC)

您如果要认为这种事是偶发性事件也罢，虽然我自己是比较没有信心就是了。一次（2017）还好说，两次（2017 + 2021）恕我没办法认为不存在系统性的问题，而系统性的问题（你要把这个称为“特定群体对CU的不信任”也好，虽然我认为这是表现出的结果，不是问题本身）可不是只能靠处理几名用户解决的。

我认为的问题无非就是当前CU当选门槛过低且缺乏监管（监管员有申诉专员定期监督，申诉专员则是直接由WMF指派），当然我也认知到有其他问题我先前是还没想到的，比如上方提到的隐私，以及对CU数据泄露0容忍的立场。“如何客观的确保CU数据不会被泄露，尤其是在缺乏CU本身公开透明的情况下”这我认为是个很好的问题。--$\int$（☎）dt 2025年5月2日 (五) 17:26 (UTC)

基金会将会定期稽核中文维基之用户查核活动至少一年，此举包含一年后是不是要继续持续这样的稽核机制等 - WMF都说他们愿意监督中维的查核使用，为什么不可以引入CU呢？

你所说的系统性问题，究竟是什么系统性问题？据我所知，我们现在讨论的是可否引入CU，而不是如何引入CU，“当选门槛过低”是第二阶段的问题，见我RfA的留言。

如何客观的确保CU数据不会被泄露，尤其是在缺乏CU本身公开透明的情况下 你觉得这是一个合理的问题吗？没错，只要没有本地CUer，那么本地CU数据就不会泄露给除监管员或其他全域权限用户之外的人。至于CUwiki上的远古中维数据，也是任何项目的CU都可以访问，反正不讲中文的人获取本地数据我们无所谓，只要说中文的人中维社群就不信任了吗？

公开透明与数据泄露又有什么关系呢？“公开透明”的理由还能说成“为了防止数据泄露”吗？

既然大家都是人类，我们是在人类与人类之间的对话，我就这样和你说吧，不管怎么样你都无法防止数据泄露。唯一的方法就是选出社群足够信任的用户。但是，抛开有没有能被社群信任而担任CU的用户不提，对于本地引入CU你还有什么意见吗？--beef [talk] 2025年5月3日 (六) 02:48 (UTC)

由于讨论已偏离到私人恩怨，本框内讨论文字已关闭，相关文字请在本页面保留并不再编辑。

如有异议，请咨询互助客栈或其他管理员。执行人：--SunAfterRain 2025年5月5日 (一) 02:52 (UTC)

真不知道您是在急什么，急到只选择性回复部分的论点，其余的则被随意归类为属于“如何引入CU”。我认为呢，在我上方提到的问题没有得出对应且可被接受的解答前 (不论事实上还是方针而言) 是不能引入CU的。另外，我并没有要把CU搞公开透明的意思。尽管我不曾担任过CUer，但作为SPI助理也是略懂一二这方面的红线。

还有，我不认为这样拆成几个阶段的方式是好的。像我的话一旦到了某个环节就会反对，然后可能因那项的相对多数搞到出局，但这种事对我来说是个dealbreaker (指没这个我就反对设立了)。环节越多，越多这样的情况就会发生，最后导出你或许like但不一定代表多数的结果，因为反对意见都在这个过程中被逐渐filter掉了，这也是为什么我认为尽管ARBCOM是有经过讨论，有你口中的“共识”，但到实际执行的时候不少用户仍有微词的原因。--$\int$（☎）dt 2025年5月3日 (六) 03:17 (UTC)

真不知道您是在急什么，急到只选择性回复部分的论点 我的天哪，为了防止我第二次被你在讨论社群程序时的发言恶心到而导致我又没有心态去参与中维社群讨论，以后只要有你参与的讨论我都不会发言了，很抱歉，但是我实在看不出任何其他的办法。一而再再而三地顾左右而言他，说话说不到重点上，我真的受够了。--beef [talk] 2025年5月3日 (六) 15:02 (UTC)

毕竟能写出 你那时候又在做什么？的，今天便能说我很急。那你跟不急的人讨论吧。你也说了，一次还好说，两次就没办法了。没错，我2024犯了认为和你能正常、心平气和、就事论事讨论的错误，那么2025再犯一次我就知道不会再犯了。--beef [talk] 2025年5月3日 (六) 15:25 (UTC)

哎呀这说到底还是道德问题，虽然我很不想这么说，社群应该也挺多人不会认同我这个观点的。我为什么说是道德问题呢?因为规则是死的人是活的，人只要自身道德上的自制力不够高，一旦处在阴影下或规则无法顾及之处，又有特定诱因(如达成某种目的)，此时隐私泄漏问题就很容易发生，至于规则无法顾及之处，当规则写的不够全面，一或者是文字上可以以另外一种方式解读，此时就会出现“文字游戏”这种情况。：（

申明一下：我不是说规则不重要。--~~Sid~~ 2025年5月3日 (六) 14:02 (UTC)

剩下恢复信任的心理建设吧？因为终究是人身安全问题，难以用所谓理性彻底排除疑虑。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月5日 (一) 12:55 (UTC)

回到我先前的论点，我自己是高度怀疑因监督员的职责明显跟“监票”不相关，纯粹请求有签署NDA的监督员担任此工作，导致参选监督员的候选人需要回答“CU技术性问题”也不理想所以需要引入CU的必要性。你要说这是纯粹的心理建设不足也罢，起码我认为我下面提到的方案接受度会比较高一些。先一步一步来，试试水温也好。--$\int$（☎）dt 2025年5月5日 (一) 16:14 (UTC)

这可以算是其中一个推动的原因，但是引入CU是不必要吗？你没有提出合理原因去表达这是不必要，终究是“过去的人有问题不代表体制有问题”。如果你说引入CU有什么必要，可以自行去看一下SPI现在处理得有多慢。--Aqurs 2025年5月5日 (一) 16:24 (UTC)

现在SPI处理慢的原因不是因为监管员不愿查或不活跃（监管员通常在转交后24小时内就能给出结果，除非需要更多信息），而是因为本地助理人手不足以尽速转交请求，请先搞清楚真正的问题在哪里再拿出来说。就算有本地CUer，在助理人手不足的情况下仍无法有效提高SPI处理效率。--$\int$（☎）dt 2025年5月5日 (一) 18:36 (UTC)

本地CU当然可以直接接受/拒绝查核请求。。。至少比现在要助理审核一次，然后转过去元维基效率来得更高。这反倒是取决于CUer办事能力，你没有回答我为什么引入CU是不必要。--Aqurs 2025年5月6日 (二) 02:36 (UTC)

我认为在此处提起是否需要CU是杀鸡焉用牛刀...另设electionadmin反而是更practical的解决办法，这样清楚了么。你提到的处理SPI效率来的更高也并不代表引入CU具有必要性。

监票并不是只能CUer来做，也不存在“参选监督员的候选人需要回答“CU技术性问题”也不理想...[所以]本站是否有重新引入CU的需要”这一命题，参选人在选监督员前应当清楚监督员当前的职责，而非事后因候选人自身的能力不足，反而对制度进行全方面的检讨。当初社群决定监督员来负责监票或许事后看来是个无奈之举，但不代表为了监票就应该引入CUer。

然后你说是因为SPI处理慢好了，请问一下假设我现在去SPI把所有请求都处理了 (该转交meta的转交meta，该请管理处理的挂请管理处理)，那是不是就不用引入CU了呢？--$\int$（☎）dt 2025年5月6日 (二) 03:32 (UTC)

你的不信任源自于过去曾经发生“数据泄漏”事件，但是用户查核这一套系统有问题吗？所有有用户查核权限的用户都有可能会泄露数据，偏偏只有贵站会有这一问题？你上面说CU欠缺监管，WMF都会来亲自监督了，你的不信任难道不就是你的偏见吗？--Aqurs 2025年5月6日 (二) 03:52 (UTC)

我总觉得你还卡在“我不信任CU”这种偏见来看我的言论。不过说真的，我能叫你不要这么做吗？CU有没有问题不代表本地需不需要。--$\int$（☎）dt 2025年5月6日 (二) 04:15 (UTC)

设立“electionadmin”的问题是监票得到的信息是跟用户查核一样，那么不是同样会有泄露的风险吗？为什么你认为“换了个包装”就代表安全呢。--Aqurs 2025年5月6日 (二) 03:54 (UTC)

可差的多了，没投票的话就不会被记录相关信息。用户查核可是只要一登录就会被记录相关信息了。这不仅是换了个包装，连内容物都不一样了呢。--$\int$（☎）dt 2025年5月6日 (二) 04:12 (UTC)

根据本地WP:CUP#1下列出的所有方针，若引入本地用户查核，所有使用用户查核的情况都必须在WP:SPI提出，完全无法发生用户查核员随便获取任何人的IP地址信息的现象，本地的其他用户查核员会时常关注查核日志并检查每一次查核是否有理有据，所以若发生滥用查核权的现象相信能够很快发现。请看一下上面的内容，恕至少个人认为纯监票的风险跟用户查核没两样，甚至更高。--Aqurs 2025年5月6日 (二) 04:16 (UTC)

我是觉得没有可比性。纯监票只有在选票投下的时候才会看的到投下选票当下的技术资料，而用户查核能看到查核当下过去90天的所有资料。--$\int$（☎）dt 2025年5月6日 (二) 04:26 (UTC)

监票员（即你提出的electionadmin）有权限查阅“投下选票当下的技术资料”就代表有泄露的风险吧，风险是对等的，不是说这资料重要度较低就没有风险。那么如果“引入CU有信任问题”，为什么社群会信任监票员？不认为这是更practical的解决方法。--Aqurs 2025年5月6日 (二) 04:33 (UTC)

本地需要监票人(不管是现在的监督员、之后的监票员或CUer）来报选票。Practical指的是这个不会囊括其他当前不需要用的权限这样的practical。

如果是要解决监督员的选票问题的话，那就是分拆监票员，专门报选票。

如果是要含括SPI的话，那就是CUer。

至于说SPI看的到的资料和安全投票看的到的资料的差别，我上面已经提到了。要不然就是将监票正式列入监督员的responsibility。

当然，如果本地要放弃安全投票的话，那不妨也是个解决方式。--$\int$（☎）dt 2025年5月6日 (二) 04:50 (UTC)

重点其实是如果本地信任引入CU的话就应该引入去处理“监票+SPI”，不信任的话没问题，但不应该弄一个新用户组去监票或是让监督负责这工作。--Aqurs 2025年5月6日 (二) 05:02 (UTC)

尽管我认为监票和SPI还是有本质上的不同，但同意你不应该弄一个新用户组去监票或是让监督负责这工作的结论。@Elvaaae：你觉得呢？貌似不能既要又要的样子。

其实也可以根据这点重新再办个投票 (不管是否要用安全投票来进行投票)，我记得最初谈及是否该启用安全投票的时候，最后也是通过投票的方式决定的。--$\int$（☎）dt 2025年5月6日 (二) 05:25 (UTC)

(～)补充我认为在此处提起是否需要CU是杀鸡焉用牛刀，CU涉及到太多争议了。另设electionadmin反而是更practical的解决办法。--$\int$（☎）dt 2025年5月2日 (五) 17:33 (UTC)

英维的electionadmin只负责配置，而scrutineer（能看到用户数据的）则只能由CU处理，这里和这里的讨论怎么没见你参与？

CU涉及到太多争议了 - 那咱们就特定争议讨论争议可以吗？--beef [talk] 2025年5月3日 (六) 02:33 (UTC)

什么时候我说中维的electionadmin和英维的electionadmin职责相同了？还有，既然你说scrutineer（能看到用户数据的）则只能由CU处理，那为何本地监督员能在技术上兼任scrutineer?--$\int$（☎）dt 2025年5月3日 (六) 03:20 (UTC)

不能认同这是“没坏别修”，这不是现在转交元维基没有“系统性问题”就一直拖延下去的，CU体制没有问题，有问题的是人。--Aqurs 2025年5月5日 (一) 16:20 (UTC)

不要SecurePoll还是引入CU

目前大概的症结点就是这个了：要SecurePoll的话就要引入CU，否则监票将难以进行。前几天我也顺便查阅了先前SecurePoll的讨论，貌似当初原本是要请监管员监票的 (类似英维ARBCOM的选举模式) ，但后来不知为何改由本地监督员负责。由于当初是否启用SecurePoll最终是以投票决定，在现在可合理怀疑当时投票存在信息不对等的情况下，我想提请重新投票决定是否应该继续使用SecurePoll并 (若有需要的话) 加入引入CU的部分。副知参与讨论的@Aqurs1、ASid、0xDeadbeef、SunAfterRain、Elvaaae、沈澄心、Ericliu1912、SCP-2000、Sanmosa、Hamish、LuciferianThomas、Stang、Shizhao、ZhaoFJx、Iming、Peacearth、魔琴、1F616EMO、Python6345、自由雨日、Hehua、AINH、阿南之人、August.C、CopperSulfate、Shawwww、花开夜：--$\int$（☎）dt 2025年5月8日 (四) 22:39 (UTC)

答案不是很明显吗，不使用SecurePoll是不可能的，毕竟那方面的风险仍然客观存在。Sanmosa _新朝雅政 2025年5月8日 (四) 22:43 (UTC)

本人在本次人事任免投票中观察多个以无关理由反对和诽谤留言，但鉴于人身威胁和操纵真人傀儡之可能仍存，本人认为管理人员任命除CU因基金会要求使用安全投票外，应同时废除安全投票和实票当选制，社群讨论后由行政员决定。本人提议试行行政员在70~50%区间决定管理人员任免。Python6345（查论编） 2025年5月9日 (五) 02:20 (UTC)

行政员决定导致的争议可能会更大XD，其实之前忘记谁提的双轨并行制可以参考。我设想的是进行两轮投票，第一轮SP半数支持则进入第二轮，第二轮实名投票>75%。这样第一轮中“可能不敢发言的人”可能留言或者反对，即使能过第一轮，留言也会给第二轮参考。至于如果我们担心的SP烂票太多导致第一轮没有过，我只能说很遗憾管理员也是需要社群信任的，半数反对即使有很多烂票大概也并不特别适合上任，免增社群争议——或者可能考虑调低到40%？但是并不治本。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月9日 (五) 02:35 (UTC)

当然正如地球君一直说的，不要美化SP之前的公开投票，当时只是没有这么多甚至是明目张胆违反方针的理由。即使有（“屁 股 不 正”），其实只要一句“不值得信任”就能避免被划。SP只是把一些人内心的龌龊端上台面而已，在某些程度上来说甚至不算是坏事。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月9日 (五) 02:43 (UTC)

魔琴的双轮投票想法很有趣……这样可以解决当前安全投票意见不公开的痛点——投票结束后才能看见其他选民对候选人的意见。不过有点关切两轮投票会不会徒增工作量，而且因为投票过多，分散总票数和选民精力。——ZhaoFJx(Talk) 2025年5月9日 (五) 02:54 (UTC)

这个是个特别又新颖的想法，社群可以考虑这么做。--~~Sid~~ 2025年5月9日 (五) 06:54 (UTC)

本人认为当前RFA的主要问题是不负责任的反对票（如与权限无关的理由）和对候选人的诽谤。本人的观点是RFA应和RFR一样主要看理由，只在支持和反对理由经过讨论且均有道理时才通过票数决定。

管理员无法访问CU和OS数据，能对个人造成的危害可逆且通常可被立即发现和除权，因此本人认为管理员即使有100张反对票如无合适理由且支持票有合适理由，这100张反对票也应被忽略。Python6345（查论编） 2025年5月10日 (六) 12:14 (UTC) 👍1

安全投票在近期还要不要继续用之前煮过好几遍了.jpg 很多人都担心被威胁，所以安全投票大概率还会被继续使用。况且当前的监督员监票其实已经足够妥善，毕竟监督员本身就受社群信任处理敏感信息。

可能的( π )题外话，翻了翻phab，至少从2022年开始，便是监督员担任votewiki上的计票员了。——ZhaoFJx(Talk) 2025年5月9日 (五) 03:00 (UTC)

“要SecurePoll的话就要引入CU”，其实光这点就有疑问。若社群同意监督员（继续）临时兼任的话，还真不一定吧？最近几次申请，他们都能正确行使职责。其实这根本都算是伪命题，至少也不应该全绑在一起，真要讨论就一项一项来。我看社群既对用户查核问题僵持不下，不如就先让他们继续兼任。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月9日 (五) 03:18 (UTC)

为什么不参考英维做法，参选人自己选择是走Request for Adminiship（公开讨论、投票）或是Administator elections（分批选举、安全投票）？在现在已经存在仲委会的情况下，“被威胁”的问题已经开始逐渐减淡，两者或许就是通过门槛的不同了。如果两机制同时运作，那比较容易出现乱投票、乱评论还不用负责的安全投票的当选门槛要比公开投票低就行。--路西法人 2025年5月9日 (五) 03:23 (UTC)

社群似有开放并行的共识，往下可以讨论。不过这要等安全投票召集权归于本地（也就是废除强制定期申请制）较好，比较容易协调制度。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月9日 (五) 04:50 (UTC)

不知道要等基金会积压多久才能处理，我觉得机制上完全可以先行，然后安全投票本地化再因应而修订就可，等别人修东西的过程总是很漫长。--路西法人 2025年5月9日 (五) 08:40 (UTC)

其实快了，上面就讲过英文维基百科要推。基金会敢无视他们吗？XD —— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月9日 (五) 14:58 (UTC)

如果社群对只采用公开投票仍然有疑虑的话，(＋)支持魔琴/路西法人提案，反对只采用SecurePoll，SP现在沦落成恶心别人的工具了。重新引入CU的话，可以同时另外讨论。--Aqurs 2025年5月9日 (五) 04:10 (UTC)

如同Aqurs1、ATannedBurger与0xDeadbeef上方的讨论，双边我认为各有担忧的点，同样的我也有担忧的点，但我还是希望有本地CU，原因是傀儡查核这种事情牵扯到行为证据的部分，有本地CU我想很多事情应该会有不一样的结果，至于担忧的部分怎么处理很看社群的自治能力与当选者的自制力。

我目前的想法是除了社群处理以外，我建议赋予仲裁委员已经签属NDA的成员监察的权限，并且再有任何信息泄漏的疑虑或情况，规则上赋予仲裁委员会可以停权CU的权限，直到事情处理完毕，如果结果是要解任则不需要任何操作，如果是要复任则恢复权限。为什么我会建议赋予仲裁委员已经签属NDA的成员监察的权限，因为CU日志是属于不公开的，有仲裁委员会成员看着，可以避免事情进入到不可控的地步，而不会事情不可控，社群才注意到隐私信息疑似或已经泄漏。--~~Sid~~ 2025年5月9日 (五) 07:12 (UTC)

申明一下我的建议不包含让arbcom任命CU，仅是监察，确保事情在本地处理，而不是WMF或m:omb来处理本地隐私泄漏问题，当然如果社群喜欢让WMF与omb来处理，我没异议。--~~Sid~~ 2025年5月9日 (五) 07:27 (UTC)

(－)反对路西法人提案：SP并不是反对票涌现的原因。反对意见本身就已经存在，并不会因为SP而突然从石头爆出来。只不过是原本用户碍于人情、同济压力等原因不便反对票。因为反对票而反过来去掉SP无异本末倒置。且如果参选人可以自行选择走哪一种形式，如果真的仍然存在“威胁”情况，只要参选人选择公开投票不也一样可以防止跑票？SP岂不是名存实忙。更何况现在sp也不见得使得当选门槛过高。这期选四人上两人，此外还有一人超临界。完全未见删SP的原因-某人✉ 2025年5月9日 (五) 12:21 (UTC)

@AINH：遗憾的是现在在安全投票里人身攻击/诽谤没有得到妥善的处理，有什么解决办法吗？让候选人自行弹性决定是否采用安全投票方为上策。--Aqurs 2025年5月9日 (五) 13:15 (UTC)

旧版就没有人身攻击和诽谤？最著名的“屁股不正”不就是好例子？如果社群真的认为这少数几列的人身攻击真的是这么大问题 (which I don't)，那么直接删掉附言部分不就行了。如我所说，真的要防拉票的话，让候选人自己选还有什么意义？--某人✉ 2025年5月9日 (五) 15:11 (UTC)

参考资料

Sidebar问题

长久以来，有大量计划和帮助页面罗列超过一个sidebar，这实在是让我难以理解的中维传统。在我看来这样不仅难以起到索引作用（索引的事应交给navbox），反而大大影响页面布局。Sidebar应该只加入范围最小最相关者即可，真的犯不着什么都来个{{policylist}}。恳请就此事达成共识，不想我清理一回就被回退一回。--PexEric 2025年5月3日 (六) 12:49 (UTC)

“Sidebar应该只加入范围最小最相关者即可”是否有共识基础。是有人当成自定义目录（大纲）在用？底栏与侧栏的navbox，我没有特别的偏好。布局是否好看，可能看情况、与访客分辨率相关？类似于图文混排是否好看。--YFdyh000（留言） 2025年5月3日 (六) 13:04 (UTC)

试举几例：WP:NOT中，因非要保留sidebar致使只能加入{{clear}}产生近乎整屏的留白，即使限制页面宽度还是有空白。而不加入clear则有可能像WP:BLP那样把{{shortcut}}被挤得分不清哪个是哪个；WP:条目用了3个sidebar，WP:IUP用了4个。除了这些极端的，其实还好。--PexEric 2025年5月3日 (六) 13:24 (UTC)

“整屏的留白”是特定分辨率下适配问题？820*1180px的设备仿真能看到，912x1368的仿真则没有出现留白。具体技术原理不太清楚。本站是否没有访客推荐（常见）分辨率及相关适配要求的检查单。--YFdyh000（留言） 2025年5月3日 (六) 15:21 (UTC)

DYKC发生什么事了？好多提名都没处理

（今天早上看到有人给我的页面写了点建议，后来才反应过来应该早就结束了？）4月30日提名的“列支敦士登大选列表”，最后留言是5月3日，票数达标也没有什么问题，都已经到第8天了，从这一条往下一直到5月4日还有不少提名都是这样，发生什么事了？--Nanhuajiaren（留言） 2025年5月8日 (四) 07:33 (UTC)

看到了并手动通过部分（）--千村狐兔（留言） 2025年5月8日 (四) 10:51 (UTC)

@Cdip150：好像之前是您在处理吧。。。问一下有没有什么头绪。--$\int$（☎）dt 2025年5月9日 (五) 19:07 (UTC)

User:Rastinition绕过程序直接将列表重定向是否涉嫌扰乱？

见Rastinition于5月7日的编辑[2]，Rastinition仅因为华语剧台内存在一句不知真伪的“2019年1月1日起，本频道不再播放首播剧集”就把所有“华语剧台电视剧列表”重定向至华语剧台（变相删除），被回退后，昨天又故意在被重定向的列表内添加Template:收录标准重定向模板[3]，然而这些列表根本就没有被提报至Wikipedia:收录标准/提报的记录，更没有因此被提删，擅自绕过程序重定向条目的行为已经与末期的LTA:SiuMai如出一辙，恳请管理员关注。--218.166.20.53（留言） 2025年5月9日 (五) 06:07 (UTC)

请先与用户交流。Python6345（查论编） 2025年5月9日 (五) 12:55 (UTC)

关于翻译时遇到的WP:引注炸弹（？）

Песня распространилась среди «дворовых» гитаристов и уличных музыкантов, даже далёких от творчества Егора Летова.

---

标题

---

所以这是否符合WP:引注炸弹的定义？应当如何处置？--KurGenera^(留言) 2025年5月9日 (五) 15:13 (UTC)

中文维基百科本就不是中文版X语维基。原版有问题就应该在创建条目的时候一并改进，而不是把问题连带一起翻译到中文--某人✉ 2025年5月9日 (五) 15:19 (UTC)

首要问题是“如何改进”，不是WP:ENWP!吧...主要是不知道要怎么处理这个东西--KurGenera^(留言) 2025年5月9日 (五) 15:37 (UTC)

这样没头没尾，又没有译文没有context我也不知道怎样评论。但如果只是很普通一段话的话，那么只拿最可靠以及最贴切的两个来源，其余删掉不就行了--某人✉ 2025年5月9日 (五) 17:40 (UTC)

@AINH：原文在这节里：ru:Всё_идёт_по_плану_(песня)#Популярность。至于译文应该是User:Kurgenera/Test101这里吧。--$\int$（☎）dt 2025年5月9日 (五) 19:02 (UTC)

可以在一个ref里写多个cite模板。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月10日 (六) 06:53 (UTC)

有关维基百科:管理员布告板/其他不当行为的条文更改

有不少多次侵权的用户被提报至WP:ANM，提报侵权行为的地点是WP:CCI。遂建议修改以下条文：

现条文

破坏、编辑战、滥用傀儡等用户不当行为应分别至WP:AIV、WP:ANEW、WP:SPI提报。

修改后条文

破坏、编辑战、滥用傀儡、侵权等用户不当行为应分别至WP:AIV、WP:ANEW、WP:SPI、WP:CCI提报。

现右侧列表

• {{Blocked}}
• {{GLocked}}
• {{GBlocked}}
• {{VIP}}
• 当前的破坏
• 编辑争议
• 傀儡调查
• 请求保护页面
• 封禁日志

修改后右侧列表

• {{Blocked}}
• {{GLocked}}
• {{GBlocked}}
• {{VIP}}
• 当前的破坏
• 编辑争议
• 傀儡调查
• 编者著作权调查
• 请求保护页面
• 封禁日志

如有意见请提出，谢谢！--DaqibaoQi（留言） 2025年5月10日 (六) 03:25 (UTC)

问题是CCI除了我基本没有人理......

Xindoor的case我从4月尾提报后到现在也没有人开case--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月10日 (六) 08:07 (UTC)

还是在布告板上的内容....... 多一个链接是不是也能吸引点人？--DaqibaoQi（留言） 2025年5月10日 (六) 08:18 (UTC)

也对，(＋)支持修改--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月10日 (六) 16:22 (UTC)

有关维基百科:编者著作权调查#调查案件的审阅流程的条文更改

为防止破坏等行为，遂建议以下条文更改：

现条文

如果用户想要参与调查案件的审阅工作，可以在正在进行的调查案件中选择一个案件进行审阅。我们欢迎所有未有过侵权记录的用户参与调查案件的审阅工作，也鼓励那些已设立调查案件的用户协助清理自己的侵权内容。

修改后条文

如果用户想要参与调查案件的审阅工作，可以在正在进行的调查案件中选择一个案件进行审阅。我们欢迎所有未有过侵权记录的延伸确认用户参与调查案件的审阅工作，也鼓励那些已设立调查案件的用户协助清理自己的侵权内容。

若有建议请提出，感谢！--DaqibaoQi（留言） 2025年5月10日 (六) 03:33 (UTC)

延伸确认用户的资历比自动确认用户及以下的用户 相比之下是高不少的 而另一方面也许能增强延伸确认用户的责任感 @Ghren--DaqibaoQi（留言） 2025年5月11日 (日) 00:31 (UTC)

有关维基百科:编者著作权调查#正在进行的调查案件中案件的编辑权限

为防止破坏，遂建议以下更改：

原状态

任何人都能编辑

修改后状态

仅有延伸确认用户（及以上）才能编辑

若有建议请提出，感谢！--DaqibaoQi（留言） 2025年5月10日 (六) 03:35 (UTC)

能否告知大家，上案在做什么？为什么？能否按User:Antigng#个人意见整理你的意见。另一项也同。--Ghren🐦🕛 2025年5月10日 (六) 16:48 (UTC)

现在的状态是IP用户甚至是临时账号持有者都能来进行案件调查 而破坏者常见于这两类人群 所以建议修改--DaqibaoQi（留言） 2025年5月11日 (日) 00:27 (UTC)