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

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

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

公告栏

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

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

#	💭 话题	💬	👥	🙋 最新发言	🕒 (UTC+8)
1	管理操作复核请求：对Wildcursive的处理	118	25	自由雨日	2025-04-28 18:15
2	管理操作复核请求：对T407210009的两周临时封禁	33	12	Ericliu1912	2025-04-29 01:07
3	管理操作复核请求：Ericliu1912实行之双向互动禁制（Tisscherry）	31	11	Ericliu1912	2025-04-29 01:06
4	提议将Mediawiki保护改名及更改图标	18	9	WiiUf	2025-04-30 07:32
5	管理操作复核请求：Wcam关闭文件存废讨论的程序问题	12	6	Wcam	2025-04-08 23:45
6	引入临时账号功能后，谁应该能够看到 IP 位址？	60	14	SCP-2000	2025-05-06 19:56
7	非洲月	1	1	Jimmy-bot	2025-05-08 16:14
8	对各位是否了解监票员在安全投票机制中作用的简易调查	96	30	ATannedBurger	2025-05-06 13:25
9	两岸四地用词问题	3	3	PexEric	2025-04-30 00:44
10	请求保护页面	1	1	ZhaoFJx	2025-04-29 23:40
11	Sidebar问题	4	2	YFdyh000	2025-05-03 23:21
12	DYKC发生什么事了？好多提名都没处理	2	2	Manchiu	2025-05-08 18:51

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

正在广泛征求意见的议题

议题清单

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

维基专题与协作

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

管理操作复核请求：对T407210009的两周临时封禁

已解决

社群就检讨封禁时长问题略有共识，惟因指控无从确证，故不迳予复核。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 09:22 (UTC)

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

---

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

操作： [1]

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

先前讨论：[2]

对此封禁时长提出异议，简短原因在此：若是临时封禁，至少应参考不当行为持续长度，而侵犯著作权的行为（此为直接机翻来源）至少在2023年11月就开始，从而使短短两周的封禁在其编辑历史上起到微不足道的预防作用。其二：用户已经多次收到提醒，而此前也已有因侵权行为被封禁，光是去查核其此前的所有编辑以移除侵权内容就大量消耗编者时间，在T407210009上次被封禁一周后，解封后一个月又回到编辑继续添加侵权内容，此严重、持续性侵权行为明显已经无法仅仅由有限期封禁防止。 --beef [talk] 2025年1月31日 (五) 04:14 (UTC)

• (＋)推翻到不限期封禁。如上。beef [talk] 2025年1月31日 (五) 04:15 (UTC)
• (－)反对：在操作者已经证明了被封禁者近来编辑并没有故意侵权的事实之后，提请人仍然在此提请的行为如同追杀，令人不寒而栗。--MCC214（Sign | Contributions） 2025年1月31日 (五) 05:25 (UTC)

  很抱歉，但是Manchiu的说法实际上并不很准确。光是在这位用户最近的50笔编辑中，就有两笔违反原创研究：1、2，一笔抄袭原文：3。如果阁下认为两周的封禁能够让此用户回心转意，那在下自然是支持这次操作。--人间百态,独尊变态(讨论)(签名) 2025年1月31日 (五) 05:58 (UTC)

  抱歉，因为扰乱而辗转难眠的人不是造成扰乱的编者，而是需要跟在后面收拾烂摊子的编者。封禁，有效阻止侵犯著作权后我才能睡个好觉。你能把我的简单诉求说成追杀实在是让我大开眼界。我的背上已经有足够多的稻草了，每次在维基百科上看到这样子睁着眼睛说瞎话的行为就像是一个刀片在我的心脏上划过一样。伤害了我对中维编者的信任和期盼，您满意吗？--beef [talk] 2025年2月1日 (六) 09:01 (UTC)

  听到这里和下面你写的那堆文字，我总算明白你去年提名某个人当管理员的原因了，原来所有的逻辑和某个人一模一样，不读条目就要离开维基百科，派翠可夫深明得饶人处且饶人的道理，但你却没有，维基百科的用户身份和社会一样，有高低之分，你要令其不限期封禁，相当于以大欺小，人家经你一封，到了站外向着想加入本项目的人说“维基百科的用户和管理怎样严格那样严格，机会也不给人啊”，那人家会对这里的印象会好吗？为何站外会有类似伪基百科和香港网络大典那样批评维百的声音（另见对维基百科的批评)，按照某个人的逻辑，难道你不想想其中的原因吗？况且操作者说明其封禁理由所提到很重要的一点是“之后也检查过他最近的数十笔编辑，并无侵权行为，这种正常编辑与侵权编辑间杂用户，我不知道他是否了解侵权方针，因此才短期禁止以阻止其继续添加侵权行为，后续无改善方应施行更长时期封禁。”，但你不断强调的是“他以前、现在和将来都只会有侵权编辑”，是不是有点以偏概全呢？而人家用到“我不知道他是否了解侵权方针”这句话，这是假定善意的一种，AGF本身就是我们必需遵守的原则，难道操作者有错吗？--MCC214（Sign | Contributions） 2025年2月1日 (六) 09:51 (UTC)

  按照阁下的逻辑，那咱觉得到不如直接将不限期封禁删除。因为只要我们“不限期封禁”，就可能会有人到站外说维基百科的不好。那还不如让维基百科当个“好好百科”更有利于外宣。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 10:11 (UTC)

  请你不要偷换概念，不限期封禁是在极端和非不得已的情况之下才能利用的手段，而不是用来解决任何人（包括阻碍你清理扰乱的人），派翠可夫也说过似乎在他第一次被封禁后的五个月也没有人Ping过他。这样的话，时间显然对事件规模有所影响；而社群是否曾经跟他做好沟通，本人也是有疑问的，你不要假定每个维基人会明白这些有默认文字而苍白无情的罐头警告信息，也不要假定每个维基人会在没有任何人用自己的文字教育别人的情况下很自制地改善自身的问题吧。--MCC214（Sign | Contributions） 2025年2月1日 (六) 10:21 (UTC)

  那么我挺好奇您认为什么样的行为属于极端和非不得已的情况。而且如果阁下认为现在对于此用户来说比起封禁更需要的是用自己的文字教育别人，那么您是否认同现在就解封此用户并在讨论页对他的侵犯著作权行为进行劝导。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 10:34 (UTC)

  封禁和教育本身就是软硬兼施的手段，两者必须合理运用，缺一不可，规则也表明“用户可使用一系列的警告模板用以传送简单的罐头提示，但按情况量身编写的讯息更佳。封禁应为最后的手段，管理员应在封禁违规用户前确认有关用户知晓或已获告知相关的规范，并已给予足够时间让其停止不当行为。”，但我看过其的讨论页警告，一是就是罐头警告信息，一是就是意义不明的自身编写信息，对于一个维基人来说是无法从中认识到自身扰乱的行为。--MCC214（Sign | Contributions） 2025年2月1日 (六) 10:54 (UTC)

  感谢您的回复。只是在下仍存在疑惑。按照阁下所引管理员应在封禁违规用户前确认有关用户知晓或已获告知相关的规范，并已给予足够时间让其停止不当行为。，可阁下又说一个维基人来说是无法从中认识到自身扰乱的行为。我是否可以认为之前罐头提示并不符合已获告知相关的规范，从而这个封禁本身就不应该成立。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 11:16 (UTC)

  我认为如果给了罐头信息+自己撰写的警告无效之后封禁一个人那才有说服力，才有封禁一个人的正当理由，而被封的人才会觉得心服口服，但依本站情况来看，似乎只有“发了罐头信息警告后相关用户依然故我就封禁”的常识，而没有要自身编写警告信息后相关用户依然故我才能封禁的原则（虽然原理上并不能照本宣科，但你不做这个动作似乎不能成为一个封人“无可挑剔且不容置疑”的理由）。--MCC214（Sign | Contributions） 2025年2月1日 (六) 11:34 (UTC)

  如果阁下认为必须要有自己撰写的警告才有封禁一个人的正当理由，那么我建议阁下去提议修改对应的方针而不是容忍这种常识。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 11:44 (UTC)

  我本身的论点就是取自方针，所以并没有需不需要修改的问题，问题只在你有没有仔细阅读相关的内容和明白其当中的含意罢了，总而言之，封禁一个人要考虑很多事情，包括会不会遇到别人的质疑而已嘛，一个人不考虑清楚到最后就好像Longway22和Wpcpey的事情一样，封禁者以一个根本就不存在的规则而作封禁理由被质疑，最后因为了避免一案多审和重复封禁，而只能撤销相关封禁决定一样。--MCC214（Sign | Contributions） 2025年2月1日 (六) 11:50 (UTC)

(！)意见：如果纯粹从Deadbeef君的角度出发，不限期封禁确实是唯一选项。虽然正式的说法应以“社群”为本位，但也可以看出在这次之前，除了Deadbeef君或者人间百态君之外，没有人留意过T君的编辑。在这个场合，说Deadbeef君或者百态君的意见可以代表整个社群，并不为过。

另一方面，本人认为在确定是否不限期封禁前，有以下问题要考虑。

第一，“T君恢复权限后一个月即恢复有问题编辑”这事，查阅其贡献记录即可得知；但从这件事至他再被指侵权，好像隔了三、四个月，而本人看他的用户页的链入页面列表，似乎在他第一次被封禁后的五个月也没有人Ping过他。这样的话，时间显然对事件规模有所影响；而社群是否曾经跟他做好沟通，本人也是有疑问的。

第二，Deadbeef君指出，不限期封禁可以令社群毋需再为其可能再次破坏而耗费资源。本人认为，用户始终是人，不能排除其以滥用傀儡之类的手段作进一步破坏的可能性。当然，维基百科对于这种情况早有表述，就是回退、封禁、不理会，但是这样一来，社群还是要监察相关条目的情况或者是否有类似形式的编辑出现，而把人封了可能还要寻找新的用户名，是多了一重工夫。这样的话，本人承认自己并不知道Deadbeef君这个理据是否成立。

第三，这两天刚刚有两名用户（Ironbolt及Joker Twins）因为对社群的质询或管理员的封禁表示对抗而被不限期封禁。相比之下，T君被三次封禁都没有噤声。虽然不能排除T君拒绝沟通的可能性，但T君亦曾经回复过他人的Ping，似乎又未必如此。

由于本人未能就以上三点得出明确结论，请恕本人未能即时认同对有关用户作不限期封禁。然而，本人希望大家就Deadbeef君的理据，以及本人上面提出的三点作出思考，再决定应予何种处理为宜。

以上--派翠可夫 (留言按此) 2025年2月1日 (六) 08:05 (UTC)

第一，T407210009有充分的机会去了解复制粘贴新闻报道在维基百科上是不可接受的。在其讨论页的留言我就找到著作权相关的提醒：[3][4][5]。对于他人在其讨论页的提示，他一次都没有回复或表现出了解，反而你去说社群没有做好沟通？是请问中文维基百科应该围绕着T407210009才行吗？

第二，根据既往贡献可以得出：T407210009若重返编辑，几乎必然会持续侵犯著作权，而一般用户受WP:ABK功能影响下根本没有实际创建傀儡的技术。我严重怀疑你这种态度是站着说话不腰疼，不论是所谓封禁之后需要“监察相关条目或相似编辑”、“寻找新用户名”，或是没封禁时及时查核并清除侵犯著作权内容，我都没见你参与。请问WP:编者著作权调查/T407210009下你要不要来打扫一下呢？对实际情况不清楚，你又有什么依据得出“封禁后反而更多消耗社群时间”这样的言论呢？

第三，我见过这个差异，但是令人感到荒谬的是你能觉得从2023年11月编辑到2025年1月的历史中，只要有一次回复他人的留言或Ping就能算“并非拒绝沟通”。

对于这种编者产生圣母或拯救情结，实际是在对于辛苦总结来源中的内容从而写条目的编者不尊重、对于不知疲倦巡查最近更改的编者不尊重、对于耗费二十多分钟只查核了4个潜在侵犯著作权差异的编者不尊重。多共情干正事的编者，少共情不干正事的编者。--beef [talk] 2025年2月1日 (六) 08:55 (UTC)

如果本人不体谅、不尊重您，本人就不会写下引言（即认为即使您的主张能代表整个社群亦不为过）以及第二点（提问不限期封禁是否能杜绝下次这种麻烦），也不会使用{{意见}}（而非任何反对模板）了。

一、您举的三个链接是7月封禁之前的事，本人也有看到，但承认自己是集中在后面的事态发展，因为您提出复核的是前几天的封禁；而有关著作权调查之所以这么长也是因为事情累积了五个月。本人说社群没有好好沟通或留意，换个说法也可以是本人认为，事情搞到要您（和百态君）这样辛苦地调查，是社群对您（们）不起，如果能够更早留意和使他回应（如前所言，也不是没有成功的例子），可能不用等到现在就已经能作出更有效的手段。

二、如果已有机制能防止用户在被不限期封禁后滥用傀儡，那本人没有其他问题。

三、如前所言，本人“……不能排除T君拒绝沟通的可能性”。您指本人认为他“……并非拒绝沟通”，并非事实，惟本人也想指出有其他可能性。您身为最直接受影响者，当然有最大的理由对此不表认同，但请不要随便用“荒谬”来形容其他不是您预期内的意见。

事实上，本人没有认为自己提出的几点一定有效，相反更多的是本人认为自己有些地方不明白而已。本人承认在您找Manchiu时已经开始尝试调查和思考，如果结果不能令您满意，本人谨此致歉，但希望您不要默认本人的立场。

最后关于完成T君的著作权调查，本人承认自己不知道怎样做才对（本人担心自己犯错，尤其是担心自己作出伪阴性结论），本人可以私下请教您具体做法吗？--派翠可夫 (留言按此) 2025年2月1日 (六) 09:43 (UTC)

已在你的讨论页下留言，稍后我会将更完善的教程写到一个用户子界面上。--beef [talk] 2025年2月1日 (六) 10:37 (UTC)

---

另外我想多一嘴：虽然此复核属于社群讨论仍在进行中，这不妨碍任何管理员以单独管理员操作来对T407210009进行处理，谨应遵循WP:WHEEL，不过将有限期封禁改为不限期封禁是不算回退管理员操作的。beef [talk] 2025年2月1日 (六) 10:40 (UTC)

---

多天已无新留言，且仅有提案人支持，视无共识关闭之。--SCP-0000（留言） 2025年2月16日 (日) 11:43 (UTC)

• 我也认为这个案子应该推翻为不限期封禁。—— 红渡厨（留言・贡献・欢迎监督红渡厨是否仍有违反文明方针的行为，若有请点此举报。） 2025年2月18日 (二) 04:28 (UTC)

  (＋)支持，该用户之前因为相关问题而被封两次了。Пусть от победы☆к победе ведёт! 2025年2月20日 (四) 04:16 (UTC)

不见仅有提案人支持，建议重开。--$\int$（☎）dt 2025年3月22日 (六) 18:52 (UTC)

被提报人疑似被傀儡封禁，此案再讨论无意义。个人认为关闭存档掉或许可行。--花开夜 _{留言 ·签名 ·贡献} 2025年4月10日 (四) 09:37 (UTC)

(！)意见单是我打扫的44个条目中就有26个条目（其中两个他创的检查后被我直接丢著作权验证）有侵权，当初的封禁两周真的太少......--VAMPIRE VAMPIRE VAMPIRE!!!（留言） 2025年4月12日 (六) 15:42 (UTC)

(！)意见：目标用户已因滥用傀儡被不限期封禁多日且仍在创建新傀儡，已无解封可能，无需换个灯泡。--此条未正确签名的留言由Python6345（讨论｜贡献）于2025年4月2日 (三) 12:49 (UTC)加入。

---

社群对于此一封禁，倾向认为原先一月二十六日封禁，时长或有不妥，应斟酌当事人过往贡献性质予以加长；与此同时，尚曾指出过往与当事人沟通可能不足，而对于是否直接改为无限期封禁，正反意见则多有辩驳，未见绝对共识形成。惟当事人自一月五日首遭封禁后即无任何编辑，迄后再因分身账号故而别遭无限期封禁，今已殊难确证有关封禁时长不妥之指控，且纯以后见之明检讨此一操作是否适当并无意义，故不予复核而结案。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 09:22 (UTC)

---

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

我本来是在休维基假期的，看着这个我乐了。你所说的当事人自1月5日封禁后跑到了另一个账号上作出了750余（其中有许多侵权内容的）编辑，现在又是开各种新号恶心社群，现在却说“啊，虽然现在发生了这么多事情，这么多编者在这里也留下了他们的意见，原来其实我也不知道当初究竟是不限期封禁更好还是有限期封禁更好，谁也辩不出来当时究竟是不限期好还是有限期”，究竟是什么样的人会写下这样的结案语，真让我怀疑你有没有实际去读讨论，总结两边的观点，根据是否符合方针与指引作出关闭决定？真要以Moot来关闭，就以Moot来关闭，不要扯什么“无法确证”、“不予复核”这种和稀泥语言。beef [talk] 2025年4月28日 (一) 11:47 (UTC)

因为必然有人会说当事人已封禁本身不影响复核，所以不用此一理由结案。你说的那些行为都是后来发现的，不能用作检核理由。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 12:25 (UTC)

如果你能将“已经封禁，所以已无复核必要”这一逻辑贯彻到底，我倒根本不会有意见。如果你能只按复核当时T407210009本人的行为与历史，及讨论中不同观点是否符合方针与指引、哪些更有力来分析总结此讨论，我更是很高兴。

很明显，你这里尝试两个都做，结果两个都做的很差。和稀泥。--beef [talk] 2025年4月28日 (一) 12:37 (UTC)

尊重你的意见。平心而论，此案确实应该及早复核。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 17:07 (UTC)

Stab in the back.jpg?--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年4月28日 (一) 13:20 (UTC)

管理操作复核请求：Ericliu1912实行之双向互动禁制（Tisscherry）

已解决

鉴于社群共识及本人意见，认为有关操作不妥，并予以推翻。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 09:30 (UTC)

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

---

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

操作： 双向互动禁制

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

先前讨论：Wikipedia:管理员布告板/其他不当行为/存档/2024年8月#Chinuan12623 5、Wikipedia:互助客栈/其他#管理操作复核请求：不认为Ericliu1912在8月28日的双向互动禁制处理符合方针指引等社群共识

看到之前的管理操作复核请求通过了，而且Tisscherry君说过：我当时是以为，因为自由雨日和我有互相宣称，如果其中一人被封禁，那请连带处理，类似这样的发言（我没去找diff，晚点想到再找）我想Ericliu管理员是看到了，故我当时欣然接受没有其他意见。以此逻辑，自由雨日申请操作复核，我会跟随( ✓ )同意和(＋)支持。基本上我尊重管理员判断，但我希望他若要做出说明，请尽量使用浅显易懂的文字，维基百科不是官僚体系，不要刻意画线拉距离。--提斯切里，但因二人之复核背景略有不同，因此需要另开一笔复核。副知@Tisscherry、自由雨日。 --Пусть от победы☆к победе ведёт! 2025年2月4日 (二) 04:28 (UTC)

多谢费心代劳，我没有很想复核，辛苦了。--提斯切里（留言） 2025年2月4日 (二) 04:56 (UTC)

---

多天已无新留言，且仅有提案人支持，视无共识关闭之。--SCP-0000（留言） 2025年2月16日 (日) 11:47 (UTC)

无法认同此关闭合理。beef [talk] 2025年2月17日 (一) 09:26 (UTC)

+1，@SCP-2000 Пусть от победы☆к победе ведёт! 2025年2月17日 (一) 09:55 (UTC)

不妨解释一下为何认为“无法认同此关闭合理”，谢谢。--SCP-0000（留言） 2025年2月17日 (一) 10:24 (UTC)

@SCP-2000：请参考Wikipedia:管理操作复核请求#关闭提报，请说明为什么此请求与以上请求为经过充分讨论，并且达成共识或显然不会达成共识。--beef [talk] 2025年2月17日 (一) 13:03 (UTC)

@SCP-2000：请重新开启这些复核请求。--beef [talk] 2025年2月18日 (二) 11:30 (UTC)

@0xDeadbeef、阿南之人： 其一，就个人对社群的理解，当一个讨论展开十多天后仍没有任何新留言，通常最后只会成为不活跃的讨论，更遑论可以达到“充分讨论”的条件。个人此做法某程度上是WP:SNOW的体现。但如果社群认为管理员只能够在“充分讨论”的情况下才能关闭，那么个人不反对重新开启。

其二，参考本站及英维过往复核，通常只有一定人数支持/反对复核的情况下才会视为达成共识，而上述复核仅有少数人参与及表示支持，故个人认为未至达成共识。当然这一部分原因可归咎于讨论时间较短，但正于个人上述指出当一个讨论不活跃一段时间，那可预期只会一直不活跃，自然不可能出现一定人数参与的情况。

另外，尽管管理操作复核请求已运作一段时间，但实质上有效及达成共识的请求仍属少数，在缺乏前例及明确指引的情况，管理员惟有只能依靠自身的经验作出判断（这也是一部分原因为何只有极少数管理员愿意处理此类请求）。所以个人以管理员角度来看，期望社群能够提供更多意见及指引，指出我们应如何操作及才能实现社群的共识。谢谢。--SCP-0000（留言） 2025年2月19日 (三) 02:16 (UTC)

@SCP-2000：我不想消磨你对于处理这些请求的耐心，因为相比其他管理员之下，至少你还愿意去处理这些事情。但是这些关闭已经体现很多问题了：首先，本站没有英维那么多编者参与，就不应该要求英维那么多的人来参与才算有共识。英维可以做到大型RFC有68个人发表意见，你维之前的管理人员改革也就做到英维的三分之一。像上面红渡厨提出来的，这么多天无人反对，应当认定已有共识而不是“无共识”。

至于其他的请求这样结案只能说明社群再一次失能，该讨论出结果的东西讨论不出结果，T40再一次让Manchiu认为自己的操作合理，导致临时封禁被继续错误地使用，造成已封禁多次的用户还能在今天蹦蹦跳跳，左手创建一个侵权条目，右手再随意复制粘贴新闻来源中的内容。没事，今天有这个“ㄨ”，明天就能有很多个这样的用户。他们都根本不屑于你们这些人这些年来留下多次的警告，各种临时封禁，让我感觉可笑的是还有人认为要是我们不去人家门口跪下求他不要再侵权了还显得我们中维社群没有诚意。

从我观察发现，中维好像至少有两个很擅长掩耳盗铃的管理员，有些时候别人直接指出问题所在的时候都能直接把眼睛闭上，一个是Manchiu，一个就是Eric。但是我没意见。指出问题是我，提出解决方案也是我，至于问题是否真的能得到解决，就看看中维究竟还剩下多少说人说的话，干人干的事的人了。--beef [talk] 2025年2月19日 (三) 09:37 (UTC)

( π )题外话其他的话我不发表意见，关于社群失能的问题我认为根源在于人太少＋管理员数量不够。理想状态下，中维至少需要现在三倍活跃的核心维基人(我定义为指延伸确认用户且一个月内编辑超过50次)，才能维持类似英维的运转。中维很大程度上依靠直接民主，导致很多弊端和乱象难以解决。--花开夜 _{留言 ·签名 ·贡献} 2025年2月19日 (三) 11:36 (UTC)

谢谢批评。非常遗憾。我无意掩耳盗钟欺骗任何人，擅长更不知从何谈起；但一切批评都虚心接受。关于封禁时长，社群可以深入讨论。@Ericliu1912作为管理员表现是有目共睹。

但求无愧，非敢请尔，固所愿也。再次谢谢你的意见。--千村狐兔（留言） 2025年2月20日 (四) 10:13 (UTC)

ㄎㄎ —— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年2月20日 (四) 12:28 (UTC)

以上两位有时间在这里回复却选择不去处理我提出的长期侵犯著作权的用户实在让我遗憾。

不过能够无视别人指出的实际问题当然也能够无视别人指出的实际批评啦。--beef [talk] 2025年2月21日 (五) 04:19 (UTC)

就在20分钟之前又继续侵权。管理员多一天不作为，维基百科就多一天的复制粘贴垃圾。别忘了这里首先是一部百科全书。--beef [talk] 2025年2月21日 (五) 04:43 (UTC)

@0xDeadbeef 但似乎你还没有提报ANM……Пусть от победы☆к победе ведёт! 2025年2月21日 (五) 04:51 (UTC)

提报ANM是处理问题用户的必要条件吗？所以为什么说管理员这么喜欢在问题面前选择闭眼。我不提报，不去提删修订请求，管理员就是无能的了吗？管理员有没有能力在社群成员没有请求操作的时候，单独执行应当的操作呢？--beef [talk] 2025年2月21日 (五) 04:54 (UTC)

大家都是志愿者，管理员没有必要长期盯着最近更改做巡查/反破坏，以至于我们有巡查员回退员去做这些，提报在目前看来就是最好解决办法。看到侵权用户不提报然后要管理员长期盯rc/某些人的贡献也太不实际。--Aqurs 2025年2月21日 (五) 05:00 (UTC)

我又没有要求管理员去一直盯着最近更改。我在原本的留言中，除了点名批评这两位管理员之外，也附上了实际侵权内容的链接。看到我那个留言的管理员至少有三个了，但却没有任何人去对这些侵权编辑作任何处理。我没意见，我只是说与其闲得没事干去回复我的批评，不如去干点实际有益的事情。看到了批评你无视去干活我实在无所谓，选择回复了又不去处理，这不是无视问题是什么呢？

或许我对所谓常识的理解有问题，但是如果我被这样批评，我至少会先看看链接里的内容有没有真正需要处理的东西。如果真有反思、接受批评的意愿，那就用行动来体现，在这里拉拉扯扯的很浪费时间。beef [talk] 2025年2月21日 (五) 05:08 (UTC)

---

看了看原来禁制时给出的原因：基于严重冲突，实施为期一周之双向互动禁制，以遏止情势继续恶化，但原讨论中使事态不断升级的只有Chinuan12623，如果只是为了防止恶化，单向互动禁制或许已经足矣。此次操作不合理，故我认为应该(＋)推翻此操作。cc @Eric Liu。beef [talk] 2025年2月23日 (日) 13:38 (UTC)

同beef，支持(＋)推翻此不合理禁制。 ——自由雨日🌧️❄️ 2025年3月5日 (三) 15:22 (UTC)

倾向该案件保留至仲裁委员会处理。 -Lemonaka 2025年3月30日 (日) 10:11 (UTC)

Tisscherry是否傀儡不影响此复核。Пусть от победы☆к победе ведёт! 2025年3月30日 (日) 10:24 (UTC)

---

本人承认此一操作以今日情况视之或有不妥，且社群就互动禁制行使要件似略有共识，我想就不必浪费诸位时间及客栈篇幅，自行复核而推翻为宜。但仍想重申，彼时局势诡谲，本人不认为有关操作无助于降低双方（或其他各方）冲突，而单向互动禁制不过是独许某方发言，亦难称绝对公平。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 09:30 (UTC)

---

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

---

@Ericliu1912：请问阁下所言“复核”是否指“推翻决定”？“复核”指“审查核对”，正是本讨论串存在的目的，即让社群参与这一“审查核对”过程，故不为讨论关闭的理由。再者“管理员在所牵涉事宜中应避嫌”，如此径行关闭，恐怕不合方针本意。建议阁下重开本复核案，在操作完成后汇报社群，由另一管理员核对阁下的操作是否符合本次共识。副知@阿南之人、Tisscherry、自由雨日。1F616EMO（喵留言～回复请ping） 2025年4月28日 (一) 09:59 (UTC)

避嫌不包含对自己做出不利的决定吧？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 10:07 (UTC)

像是推翻，结果还是double down（本人不认为有关操作无助于降低双方（或其他各方）冲突、亦难称绝对公平（而且这个公平更是在诡辩：社群中有一些人被不限期封禁，有一些人不被不限期封禁，这公平吗？））。所以你到底清楚不清楚管理员是负责执行社群共识的？--beef [talk] 2025年4月28日 (一) 12:23 (UTC) ❤️1

社群共识是推翻本人操作，此何有问题？另外，后面那段是我的个人意见，因为并非社群共识，故两顶帽子分开。可能我上面结论措辞写得不太好而且挤在一起，那就在这里把意思说清楚了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 17:06 (UTC)

另修改了下结案措辞。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 10:09 (UTC)

（修改链接见此。） ——自由雨日🌧️❄️ 2025年4月28日 (一) 12:06 (UTC)

提议将Mediawiki保护改名及更改图标

我认为目前Mediawiki保护的名称不够准确、且图标无法同模板保护区分。希望能改成较为直观的“界面保护”等名称，并设立相关图标。如有共识可设立相关投票。--WiiUf 2025年3月8日 (六) 04:38 (UTC)

(＋)支持--August_{讨论‧签名} 2025年3月8日 (六) 04:45 (UTC)

不能认同界面保护的名称。该名称抛弃该保护的本质原理，易导致后续含义失准。此外，由MediaWiki自动施加的JSON保护亦为此保护，但JSON不应视作影响界面。--MilkyDefer 2025年3月9日 (日) 15:30 (UTC)

Mediawiki其实就是系统配置文件，那么叫做“系统保护”应该会比较合适。Bluedeck 2025年3月10日 (一) 06:43 (UTC)

这个名字还不错。--碟之舞📀💿 2025年4月6日 (日) 03:24 (UTC)

@August.C@Bluedeck@Diskdance@MilkyDefer若无异议， 公示48小时，稍后将举行投票。--WiiUf（留言） 2025年4月6日 (日) 09:24 (UTC)

@August.C@Bluedeck@Diskdance@MilkyDefer投票页面已创建。--WiiUf（留言） 2025年4月7日 (一) 14:35 (UTC)

反对投票... 目前社群有人反对“系统保护”吗？为什么不讨论出共识而要投票？--Aqurs 2025年4月7日 (一) 14:38 (UTC)

我想组织投票是因为有类似先例（之前决定各类保护用名及图标都用的是投票）。--WiiUf（留言） 2025年4月8日 (二) 10:12 (UTC)

同Aqurs，可以用共识通过的就不必投票了--August_{讨论‧签名‧回复请ping} 2025年4月7日 (一) 14:41 (UTC)

(▲)同上，反对投票。既然投票的本质其实是问卷，常规共识方法能够解决之事，何必诉诸投票？--1F616EMO（喵留言～回复请ping） 2025年4月7日 (一) 14:44 (UTC)

投票是共识达不成退而求其次的方案，这里大家并没有达不成共识吧。--碟之舞📀💿 2025年4月8日 (二) 10:09 (UTC)

所以这种保护究竟能保护什么？若像诸位所说，似乎Bluedeck建议的“系统保护”是个好方案。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 09:39 (UTC)

公示7日，2025年5月6日14：22（UTC)通过。--WiiUf（留言） 2025年4月29日 (二) 14:20 (UTC)

@WiiUf：新图标在什么位置？？--Aqurs 2025年4月29日 (二) 14:26 (UTC)

公示的方案是？界面保护还是系统保护？以及下次公示请一并更新Template:Bulletin。——ZhaoFJx(Talk) 2025年4月29日 (二) 15:35 (UTC)

抱歉，重新公示“系统保护”名称7日，2025年5月6日23：35（UTC）结束。--WiiUf（留言） 2025年4月29日 (二) 23:32 (UTC) 👍1

管理操作复核请求：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相比差得远。
— [6]

这样一句话，我觉得有点危言耸听，不能一个人随便吹牛说大话就能让整个社群人心惶惶吧。--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)

我说难听一点啦，你翻墙出来本来就要保护好自己了，就算没有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)

参考资料

两岸四地用词问题

仍然有大量人物条目的出生地点使用的是中国而非中华人民共和国，是否应当一致使用PRC？（当然，mos:信息框旗帜）--KurGenera^(留言) 2025年4月28日 (一) 23:39 (UTC)

若未提到“中华民国”或“台湾”等词汇，或当事人本为一九四九年以后出生， 或可斟酌使用“中国”。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月29日 (二) 05:55 (UTC)

写就“中国某省某市”云云，很显然地读者能辨明此地（在人物生时）属何种政治实体管辖，没有歧义的来由。--PexEric 2025年4月29日 (二) 16:44 (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)