维基百科讨论:元维基用户查核请求
我才发现啊,元维基不允许IP用户提交SRCU
[编辑]m:Steward_requests/Checkuser/2018-04#George WK [email protected]看吧。--Liuxinyu970226(留言) 2018年5月1日 (二) 23:30 (UTC)
有关这个页面的英语缩写
[编辑]@1233:这个页面的英语缩写为什么叫HAM或者RFCUHAM呢,是Help At Meta的缩写吗?EtaoinWu 讨论 2018年5月3日 (四) 11:48 (UTC)
- @EtaoinWu:Request For CheckUser Help At Meta.。--1233( T / C) 2018年5月3日 (四) 11:53 (UTC)
- 完成,谢谢您。EtaoinWu 讨论 2018年5月3日 (四) 11:55 (UTC)
Request For CheckUser Help At Meta Chloehao(留言) 2020年2月4日 (二) 01:57 (UTC)
Wikipedia:元维基用户查核请求页面是否该加入过往Wikipedia:用户查核请求的讨论或连结?
[编辑]如题,因为发现没有过往用户查核请求的讨论或连结--Z7504非常建议必要时多关注评选(留言) 2019年5月12日 (日) 11:47 (UTC)
维基百科讨论:元维基用户查核请求
[编辑]维基百科讨论:元维基用户查核请求 Chloehao(留言) 2020年2月4日 (二) 01:54 (UTC)
编辑请求 2020-03-03
[编辑]请求已处理
【明显有规律的破坏】:Karin22530867 与 Gigilau813 疑为同一人操作,均针对刘佩玥及张彦博条目而添加侵权图像,删去原有合理使用照片。 -- 42.98.137.124(留言) 2020年3月3日 (二) 13:04 (UTC)
请求禁制某些IP
[编辑]本页稍早发生编辑战。此留言用以做纪录提醒。以减少其他编者也误操作的机率。-- 娜娜奇🐰鲜果茶☕(宇帆·☎️·☘️) 2020年3月19日 (四) 08:31 (UTC)
现时元维基查核请求页面中的请求任何人皆可以转交。然而有些时候会出现社群显然未达成共识之情况下就迳行转交之情况,更甚者会在元维基页面争论是否达成共识,这不但浪费了监管员的时间,造成观感不佳,而且也浪费了社群的时间在无谓的争论上。再者,翻译者可在元维基页面中的查核原因中添加自己个人的观点,而监管员绝大多数情况下都不会知情,这可能会构成伪造共识。是故,建议未来查核请求规定只能由管理员转交,或是由特定小组(类似机械人审核小组)转交。谢谢。--SCP-0000(留言) 2020年7月11日 (六) 04:45 (UTC)
- 另cc@Hamish、Streetdeck、Super Wang、SecureXP、Stang: @DrizzleD: --SCP-0000(留言) 2020年7月11日 (六) 04:45 (UTC)
- @SCP-2000:不能确保审核小组成员是否中立,倾向反对。--Wright Streetdeck 香港人反抗 2020年7月11日 (六) 04:48 (UTC)
- 因利益冲突,不对“管理员”一段做出评论。其余意见同上。--来自热烈庆祝贵市长沙地铁再获双线贯通的Hamish论 2020年7月11日 (六) 04:53 (UTC)
- 中立反而不是最主要要考虑的问题。这里的审核不是政治审查,而是确保语义翻译正确,避免出现词不达意的情况。来自大陆、港澳台的用户都可以加入此组。至于仅限管理员转交,我认为这是在打击非管理员参与站务的积极性,而且管理员的责任中,也没有“转交CU”这一点。更何况持续活跃于HAM的管理员并不多。--Super Wang※DC不是贪食蛇,请勿盲目刷分 2020年7月11日 (六) 11:30 (UTC)
- 这很像之前已经讨论过。争议性太大,难以设立。仅限管理员转交也无济于事:老管理员也可以把监管员和行政员搞混(原因就是看不懂英文),这叫我怎样信任管理员?ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月12日 (日) 02:42 (UTC)
- 作为创建这个火腿页面的用户,个人认为不应禁止任何用户转交,但当某人明显出现上述的行为的时候,则禁止该用户转交。此禁令应涵盖管理员。--1233 (T / C) 2020年7月15日 (三) 00:19 (UTC)
- (!)意见,我建议建立一套移交 CU 的规则或方针,不去限制特定人群才可以做这件事情。正是“规则面前人人平等”的理念,不要走上“分田圈地”那种老路。
建议
[编辑]- 我建议转交CU方面可以建立一些方针,明确如何转交、是否可以代为申请等,以避免产生歧义而无法确认正确的方法而引起争议,希望各位可以给予相关的意见,如可以,则希望能有闲暇时间的人可以协
(全)助(部)编写相关方针。--LClightcat Talk 2020年10月31日 (六) 09:56 (UTC)
- “如何转交”指什么呢,是指怎么在原味鸡说吗,还是指什么?--安忆Talk 2020年10月31日 (六) 10:08 (UTC)
- (:)回应:部分是的,可以搞个转交模板,其他的便是转交标准指引(方便判断)--LClightcat Talk 2020年10月31日 (六) 10:13 (UTC)
- 个人觉得,查核面临的情况是非常灵活多变的,还是不要太死板为好。不过,明确一下是否可以代为申请也是好的。--安忆Talk 2020年10月31日 (六) 13:55 (UTC)
- (:)回应:部分是的,可以搞个转交模板,其他的便是转交标准指引(方便判断)--LClightcat Talk 2020年10月31日 (六) 10:13 (UTC)
更多建议
[编辑]中文维基有来自不同背景的用户,如果专门建立一个小组转交SRCU,或拥有管理员权限才能转交则可能造成异议(有些有经验的用户没兴趣当管理员),不如规定编辑次数满一定次数才可以转交。 Herobrine (论🚀签) 2020年11月22日 (日) 04:45 (UTC)
- RFA就说过了“编辑次数可能因频繁的微碎编辑而膨胀贬值”。有些人就算编辑满一万次我也不放心他转交。他得懂英文,得愿意长期抓傀儡,得懂得和监管员说话的艺术。不是光编辑数多就行的。--Remaining silent is not Majority's fault. 2020年11月22日 (日) 04:52 (UTC)
提议更换用于用户查核的模板
[编辑]- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
如题。提议将用于提交用户查核的模板由{{RFCUform}}和{{checkuser}}更换为与元维基基本兼容的{{CU request}}。理由:在提交用户过多时,向元维基转交的过程中需要手动拷贝模板的参数,十分费力,而且很有可能在拷贝过程中出错。因此提议更换用于用户查核的模板。相应方案:更改Wikipedia:元维基用户查核请求/preload的内容,更改后的内容在User:Yining_Chen/沙盒/Pagex。另外,可能需要对TW进行修改。--Yining Chen(留言|签名) 2021年1月31日 (日) 03:50 (UTC)
- 应该放到技术栏比较好吧。--东风(留言) 2021年1月31日 (日) 04:59 (UTC)
- 换也可以,看起来没什么坏处。--安忆Talk 2021年2月1日 (一) 16:49 (UTC)
- (+)强烈支持:这是十分猫道的行为!解放猫爪的提案!强烈支持!--你·是·自·由·的 2021年2月3日 (三) 10:35 (UTC)
由于关注该提案的人并不多,为加快讨论进程,依照WP:SNOW,提前进行公示。在公示期间内,如有任何反对意见被提出,将停止公示并依照WP:7DAYS方针继续进行讨论。如在公示期间内无人反对,则视为通过。 公示7日,2021年2月10日 (三) 11:38 (UTC) 结束 --Yining Chen(留言|签名) 2021年2月3日 (三) 11:38 (UTC)
- 吐槽:难道逻辑不应该是因为没有多少人关注,所以才应该将讨论时间放长的吗?--东风(留言) 2021年2月7日 (日) 07:15 (UTC)
- (!)意见 如果没人关注的原因是大家没时间,那么应该延长。如果是大家没兴趣,那么走个流程、勇于编辑,有问题再回退也没啥大不了。--YFdyh000(留言) 2021年2月7日 (日) 07:23 (UTC)
该提案现已通过(时间上提前了两个小时)。对preload的更改已完成(见此),对WP:TW的更改的请求已被提交。待TW完成更改后对本讨论进行存档。--Yining Chen(留言|签名) 2021年2月10日 (三) 09:48 (UTC)
- 在2019年1月前会有这样一个供复制翻译的框,但在Special:Diff/52888821被移除了,应该请1233说明一下编辑摘要中他的意思。--Xiplus#Talk 2021年2月13日 (六) 08:25 (UTC)
- @Xiplus、Easterlies、Yining Chen、LClightcat:,当时转交的时候没记错出现了大量无关内容,导致转交的时候出现大量无关内容(如果没记错的话),所以当时有监管员私下希望我删除该些无关内容。我亦因该等内容确实无关而删除。当然,这种统一的做法我没意见。--1233 (T / C) 2021年2月13日 (六) 11:39 (UTC)
- 您可以拿这个请求作为例子,说明一下“无关内容”是指哪些内容吗?感谢。--Yining Chen(留言|签名) 2021年2月13日 (六) 12:27 (UTC)
- @Xiplus、Easterlies、Yining Chen、LClightcat:,当时转交的时候没记错出现了大量无关内容,导致转交的时候出现大量无关内容(如果没记错的话),所以当时有监管员私下希望我删除该些无关内容。我亦因该等内容确实无关而删除。当然,这种统一的做法我没意见。--1233 (T / C) 2021年2月13日 (六) 11:39 (UTC)
- CU request和RFCUform,可于Template:RFCUform/testcases点击按钮测试提交。--Xiplus#Talk 2021年2月21日 (日) 03:30 (UTC) 已准备好
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
编辑请求 2021-03-07
[编辑]请求已拒绝-- Willy1018(留言) 2021年3月8日 (一) 06:20 (UTC)
您好,请求查核Lt2818 ,原因是在虫飞飞同志的留言板下多次发起人身攻击,怀疑是某位用户的傀儡--Pavlov2(留言) 2021年3月7日 (日) 18:13 (UTC)
- 不能对单一帐号进行用户查核。--东风(留言) 2021年3月8日 (一) 02:13 (UTC)
编辑请求 2021-03-15
[编辑]请求已处理
由于有人提出要查核我,而我还不是自动确认用户,因此我在这里提出代为编辑请求,发表意见:
如果虫虫飞尽心尽力审查并否决那些恶意的VIP提报的话,我的IP段就不会被封锁,我也不需要注册帐户。今天走到用户查核这一步,是虫氏庸碌无能造成的悲剧。用户查核有结果后,有关IP段必须解封,恢复名誉。
If 虫虫飞 tries her best to review and reject those malicious VIP reports, my IP subnet will not be blocked, and I don't need to register for an account. Going to the step of SRCU today is a tragedy caused by 虫虫飞's mediocrity. The relevant IP subnet must be unblocked when the CU result comes out and restore my reputation.--温大善人(留言)— 温大善人(talk)在本主题以外只有很少或没有编辑。 2021年3月15日 (一) 06:46 (UTC)
编辑请求 2021-03-21
[编辑]请求已拒绝海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月21日 (日) 10:51 (UTC)
回退这一编辑,因为他破坏本人留言,明显恶作剧。--温大善人(留言)— 温大善人(talk)在本主题以外只有很少或没有编辑。 2021年3月21日 (日) 10:38 (UTC)
- 未完成。请您先尝试参与其他编辑,否则依据贡献记录来判断,模板添加无误。--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月21日 (日) 10:49 (UTC)
提议建立“元维基用户查核指南”
[编辑]- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
原标题为:元维基用户查核指南”(含IP傀儡查核常规化、合法化)
修改海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月31日 (三) 13:57 (UTC)
如题,现时中维本地CU权被拔了,目前我们只能通过SRCU进行查核,而本地方针又管不上,我希望建立本指引以规范用户查核的转交。
我已经综合各方针和页面,写好了一个草稿用于本次提案,我的想法是将我写的提案草稿变成正式的指引指南(在经过修订后)。
提议条文:Draft:元维基用户查核指引。
这个草稿规范了查核转交的基本原则,对新手可能滥用傀儡的第一处理方式,共识的形成等等。
同时也说明了“是否可以代为转交”这个问题。
此外,由于这是我第一次写这种指引,所以写的并不好,如果您觉得哪里可以改善,欢迎指出!
--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月5日 (五) 16:13 (UTC)
- @BureibuNeko:(1)如请求查核者非被请求查核者,但被请求查核者对查核表示同意/不反对,算不算“请求自我查核”?(2)被请求查核者能否(在有转交的共识的情况下)进行转交?SANMOSA 江南好,风景旧曾谙 2021年3月6日 (六) 00:40 (UTC)
- (:)回应:@Sanmosa:(1)不算,(2)能。 此外 感谢提醒qwq!稍后我会将其加入草稿,没考虑到....--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月6日 (六) 00:59 (UTC)
- 个人对该提议表示(-)反对。理由:1.页面内滥用bold;2.个人认为其内容更适合“说明页”而不适合成为指引。感谢。--Yining Chen(留言|签名) 2021年3月6日 (六) 04:26 (UTC)
- @Yining Chen:粗斜体的运用确实有些问题,已代改。不反对作为说明页。SANMOSA 江南好,风景旧曾谙 2021年3月6日 (六) 04:42 (UTC)
- 考虑各位的意见,将本此提案更正为“指南”(即说明页)。--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月6日 (六) 08:45 (UTC)
- (-)反对。(1)把“指引”改成“指南”,所以这到底是指引还是指南?如果就把名字改了,但从共识级别上还是指引,这有什么区别?(2)请提案者论述为什么对新手进行用户查核,是可能对新手造成伤害的行为、为什么对普通用户的请求应该“慎之又慎”。在我看来,应该“慎之又慎”的是管理员按照duck等理由封禁新手。而查核的技术证据可以在duck之外帮助判断某新账号是否为傀儡,减少误封,应该多加提倡才对。(3)现在在RFCUHAM上的一大问题是查sleeper的频率。过频繁的话,监管员不愿意查;不频繁的话,LTA作祟就没得管。这导致RFCUHAM上堆的大多数积压请求都是查sleeper。本提案没有解决这一问题,甚至没有解决任何问题,只是把当前大家的通常做法给写出来了,写得还不算完全。我没看到任何制订指引的必要。没坏就不要修,我想请提案人讲一下当前有什么问题是需要本指引来解决的。--Techyan(留言) 2021年3月6日 (六) 11:36 (UTC)
- (1)WP:CONCOVID-19不就是一个前例吗,你倒是说说这东西的级别是甚么。(2)我觉得两个都要“慎之又慎”吧。毕竟CU请求某程度上属于指控,不当的指控确然会造成伤害。(3)有总结好过没总结,新用户至少也会清楚现在的HAM大概是怎样做的。SANMOSA 江南好,风景旧曾谙 2021年3月8日 (一) 12:23 (UTC)
- 人来了(((,首先,我只是感觉名字有问题,我写的这玩应就和指南一样,用处也和指南没啥区别,所以改个名也无可厚非。第二,其实关于这个是因为我所知道的一个真实案例,因为我的误提报而导致对方(新手)想要不再编辑wikipedia,所以我感觉有些必要写入,技术查核证据虽然可以更加帮助解决相关问题,但如若遇见类似于在同一个办公室工作,使用同一版本浏览器的几个用户(这也是一个真实案例,我想Techyan您应该还记得)也是没啥用,还有就是用户查核越多,就代表用户IP知道的人就越多,诚然,有相关协议规定,可惜还是会有人故意泄露。而且就和Sanmosa君一样,两者都该慎之又慎。第三,频繁的查Sleepers这方面,本指南的态度应该是属于不支持而又不反对。而且监管员不愿意查我能怎么办?“只是把当前大家的通常做法给写出来了”,是,但是新用户、不了解查核流程的用户可能不了解这些。 而至于“没坏就不要修”,我不觉得没坏,我见HAM页从头到尾哪里写过关于“是否可以代为转交”这一类的问题,我想去告诉下因此产生异议的用户我都找不到来源,我不觉得此为“没坏”。以上。--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月12日 (五) 13:39 (UTC)
- (=)中立,虫虫飞怎么封的Jennylauk,我看傻了。故希望被查核者可以在有共识时自行转交。--E.A.Crowley666✍️ 2021年3月7日 (日) 13:10 (UTC)
- 有了虫儿飞,欢乐少不了。但WP:SRCU讲不适用自证清白。--YFdyh000(留言) 2021年3月7日 (日) 13:43 (UTC)
- @EdwardAlexanderCrowley、YFdyh000:上面提案人已经说明被请求查核者能在有转交的共识的情况下进行转交。他也说明了请求查核者非被请求查核者,但被请求查核者对查核表示同意/不反对,并不算“请求自我查核”。SANMOSA 江南好,风景旧曾谙 2021年3月8日 (一) 12:23 (UTC)
- 积极促成有滥用工具自证清白的嫌疑,欠缺利益上的避嫌、可引发争议(如“如此有信心,是不是……”),元维基也可能拒绝查证自己的请求。表达态度或许可以,转交又不差一人。--YFdyh000(留言) 2021年3月9日 (二) 02:35 (UTC)
- meta那边有前例,我认为你说的可能性不大。SANMOSA 江南好,风景旧曾谙 2021年3月9日 (二) 05:45 (UTC)
- 积极促成有滥用工具自证清白的嫌疑,欠缺利益上的避嫌、可引发争议(如“如此有信心,是不是……”),元维基也可能拒绝查证自己的请求。表达态度或许可以,转交又不差一人。--YFdyh000(留言) 2021年3月9日 (二) 02:35 (UTC)
- @EdwardAlexanderCrowley、YFdyh000:上面提案人已经说明被请求查核者能在有转交的共识的情况下进行转交。他也说明了请求查核者非被请求查核者,但被请求查核者对查核表示同意/不反对,并不算“请求自我查核”。SANMOSA 江南好,风景旧曾谙 2021年3月8日 (一) 12:23 (UTC)
- 有了虫儿飞,欢乐少不了。但WP:SRCU讲不适用自证清白。--YFdyh000(留言) 2021年3月7日 (日) 13:43 (UTC)
- 仍然(-)反对将“转交”这一事项单独列出设立指引。即便有相关需求,也可以通过在WP:CU里添加内容来解决,再立一个指引是无必要的。另外,查核IP应该是不可能的。基金会有相关政策。--Yining Chen(留言|签名) 2021年3月13日 (六) 13:13 (UTC)
- (:)回应我自认为CU页面里介绍转交方法不是什么好的想法,而至于“查核IP应该是不可能的”,写的是查核IP和用户之间的关系。而这个案例请见上次的AndyandyandyAlbert事件,已经为本指南的这一条“打下了坚实的基础”。--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月14日 (日) 06:01 (UTC)
- ... 话说没人来吗...--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月21日 (日) 10:53 (UTC)
- 除非一名监管员在元维基或中文维基百科亲自宣布“中文维基百科社群可以提交针对检查IP与用户关系的查核请求”,否则您的表述无法令人信服。因为这种行为看起来似乎很显然违反了隐私政策。--Yining Chen(留言|签名) 2021年3月23日 (二) 14:21 (UTC)
- @Yining Chen:是的,我再次查阅后,确认了这种行为违反隐私政策,相关内容稍后移除。此外,就有关相关事件我将会与OC(申诉委员会)联系,确认自举是否违反相关政策。最后,感谢您的宝贵意见!--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月27日 (六) 12:54 (UTC)
- (:)回应我自认为CU页面里介绍转交方法不是什么好的想法,而至于“查核IP应该是不可能的”,写的是查核IP和用户之间的关系。而这个案例请见上次的AndyandyandyAlbert事件,已经为本指南的这一条“打下了坚实的基础”。--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月14日 (日) 06:01 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
关于wp:srcu的讨论
[编辑]wp:SRCU要求查核用户的请求必须在本地被讨论通过后才能转向元wiki,若管理员自己滥用傀儡怎么办?他或可互相直接驳回对自己的查核请求。--祝编安|pavlov2(留言) 2021年7月17日 (六) 17:11 (UTC)
- 类似于“管理员滥权封禁怎么办”“管理员知‘法’犯‘法’怎么办”一样,这种问题在原则上是由管理员之间的相互制衡、相互制约来规避的。--Antigng(留言) 2021年7月18日 (日) 15:22 (UTC)
- 反驳,见最近wp:ANM的争论,管理员滥权封禁和解封已经导致了两起矛盾了.--祝编安|pavlov2(留言) 2021年7月18日 (日) 15:32 (UTC)
- 此外,为何不准许用户自行前往元WIKI提报可疑案例?元WIKI收回查核权不正是因为有人滥权吗?--祝编安|pavlov2(留言) 2021年7月18日 (日) 15:34 (UTC)
- 再(?)异议,法治非人治,如果不能把权力关进制度的笼子里,企图靠人和人互相制衡,如何评判这一体系是否有效?--祝编安|pavlov2(留言) 2021年7月18日 (日) 15:37 (UTC)
- @Pavlov2:赞同。元 Wiki 既已收回查核权,管理员再保留驳回、否决任何查核请求的权力,不是实际上、变相拥有甚至超过用户查核员,及在用户查核方面,超过元 Wiki,的权限吗?
- 但是我看了下,
- Wikipedia: 元维基使用者查核请求不是方针或指引,不适合在 Wikipedia: 互助客栈/方针讨论。
- “不准许用户自行前往元WIKI提报可疑案例”、要求先在本地讨论,不是华文 Wikipedia 方针或指引的规定,是元维基监管员的要求。“监管员一般不会理会未经本地社群讨论通过而直接发布到元维基上的请求”(Wikipedia: 用户查核)。
- 既然是讨论,管理员没有“直接驳回对自己的查核请求”的权力。
- 谢谢。祝 早日康复! — XComhghall(留言) 2021年7月18日 (日) 17:02 (UTC)
- (-)反对,讨论中管理员可直接duck掉与自己可能相关的提报,是为一种变相驳回。--祝编安|pavlov2(留言) 2021年7月18日 (日) 17:31 (UTC)
- 如果多人有理地反对管理员的意见,那么管理员的拒绝是无效的。管理员向来不是绝对的裁判者,管理员执行着共识。--安忆Talk 2021年7月19日 (一) 02:36 (UTC)
- 反对,见wp:SRCU中的最新一次一望而知后取消,是user:shizhao发话认为不能简单DUCK才再次提报的,如果shizhao没来呢?是不是直接就ban了?--祝编安--pavlov2(留言) 2021年7月19日 (一) 04:01 (UTC)
- 您也可以认为不能一望而知,这并不需要管理员,Wikipedia:何谓共识#共识不是什么。--安忆Talk 2021年7月19日 (一) 04:12 (UTC)
- 我认为重点是提报者应该把前因后果讲明白,而不是简单的一望而知或xxx傀儡就完了。这样的话,除非管理员非常了解提报者所说的问题,否则只能是看得一头雾水,不知道是怎么回事。其实这个问题不光是SRCU,其他地方的讨论或提报中也是经常发生,造成的后果就是如果熟悉此事的管理员没有处理的话,很大程度上就搁置了--百無一用是書生 (☎) 2021年7月19日 (一) 06:13 (UTC)
- Wikipedia:元维基用户查核请求#Windy8786是Shizhao、我和30000Lightyears重启的,即使Shizhao没看到,我俩也会重启讨论。Itcfangye(留言) 2021年7月22日 (四) 00:21 (UTC)
- 回退管理员行动/基金会行动或被误判为破坏,我不知道普通用户敢不敢重开讨论。--祝编安--pavlov2(留言) 2021年7月25日 (日) 02:34 (UTC)
- zhwiki至今暂时没有针对任何人对SRCU的编辑动作进行过基金会行动。回退管理员的操作的合理性要视乎管理员操作时使用的权限到底是管理员专有的还是普通用户都有的;如果是后者,那你把他当成普通用户就好,有需要就可以回退或重开。SANMOSA Σουέζ 2021年7月28日 (三) 11:43 (UTC)
- 回退管理员行动/基金会行动或被误判为破坏,我不知道普通用户敢不敢重开讨论。--祝编安--pavlov2(留言) 2021年7月25日 (日) 02:34 (UTC)
- Wikipedia:元维基用户查核请求#Windy8786是Shizhao、我和30000Lightyears重启的,即使Shizhao没看到,我俩也会重启讨论。Itcfangye(留言) 2021年7月22日 (四) 00:21 (UTC)
- 我认为重点是提报者应该把前因后果讲明白,而不是简单的一望而知或xxx傀儡就完了。这样的话,除非管理员非常了解提报者所说的问题,否则只能是看得一头雾水,不知道是怎么回事。其实这个问题不光是SRCU,其他地方的讨论或提报中也是经常发生,造成的后果就是如果熟悉此事的管理员没有处理的话,很大程度上就搁置了--百無一用是書生 (☎) 2021年7月19日 (一) 06:13 (UTC)
- 您也可以认为不能一望而知,这并不需要管理员,Wikipedia:何谓共识#共识不是什么。--安忆Talk 2021年7月19日 (一) 04:12 (UTC)
- 反对,见wp:SRCU中的最新一次一望而知后取消,是user:shizhao发话认为不能简单DUCK才再次提报的,如果shizhao没来呢?是不是直接就ban了?--祝编安--pavlov2(留言) 2021年7月19日 (一) 04:01 (UTC)
- 如果多人有理地反对管理员的意见,那么管理员的拒绝是无效的。管理员向来不是绝对的裁判者,管理员执行着共识。--安忆Talk 2021年7月19日 (一) 02:36 (UTC)
- (-)反对,讨论中管理员可直接duck掉与自己可能相关的提报,是为一种变相驳回。--祝编安|pavlov2(留言) 2021年7月18日 (日) 17:31 (UTC)
- 如果可以让Steward信纳有特殊状况以致请求不能先在本地被讨论通过的话,请求或许也能受理,但前提是你要先说服Steward。SANMOSA Σουέζ 2021年7月28日 (三) 11:43 (UTC)
编辑请求 2021-08-20
[编辑]请求已拒绝仁爱亲诚——Pavlov2 2021年8月22日 (日) 04:50 (UTC)]] 2021年3月21日 (日) 10:51 (UTC)
Sunlight2021做出恶意的诽谤,建立在刻意忽视事实的基础上,我的编辑条例在此 https://en.wikipedia.org/wiki/Special:Contributions/ElleShd 我在中文编辑中明确说明"最近翻译PRC的法律",而我的中文编辑也是相关由于中国法律而展开的,反华这一恶意诽谤毫无根据,在这要求对方公开正式的道歉 ElleShd(留言) 2021年8月20日 (五) 16:28 (UTC)--ElleShd(留言) 2021年8月20日 (五) 16:28 (UTC)
- wp:GAME为由被永久封禁,且编辑已做仁爱亲诚——Pavlov2 2021年8月22日 (日) 04:50 (UTC)
请求申请查核用户
[编辑]
- 麻烦看看?--拒食木瓜。〈煮〉 2021年9月18日 (六) 13:37 (UTC)
- “缺乏充分理由”(SCP-2000)。—Regards, BureibuNeko 2021年9月18日 (六) 14:05 (UTC)
元维基查核结果需要有管理员处理
[编辑]之前User:浅蓝雪以滥用傀儡封禁Tailuoatm。结合元维基的 不太可能查核结果、用户编辑和AGF原则,我们认为是纯破坏用户对Tailuoatm的陷害。目前此案尚未有管理员处理。见Wikipedia:元维基用户查核请求#Tailuoatm。--Itcfangye(留言) 2021年11月20日 (六) 09:51 (UTC)
- 在当事人没有提出申诉的前提之下您应该直接跟执行封锁的管理员反应。--Xiplus#Talk 2021年11月20日 (六) 10:29 (UTC)
- 还是原来我说的理由:“两个100编辑不到的用户在出现完全重复的文字编辑时,在我看来已经足够了,连100编辑都不够,“栽赃”在我看来不太可能”,我无法相信二人不存在任何形式的关联:“一个新的(或者你说老的也行,不过是哪位?)纯破坏用户为了栽赃另一个新用户去模仿后者”这种理由我觉得行不通。
- 如果硬要问除了那笔编辑编辑有什么相似之处,二人编辑都有非常明显的原创倾向,即在文中添加非常明显的个人总结,且在国家类条目上有一定重合。就算不是一个人,我很难相信两个人没有任何性质的关联。
- 账号创建时间有比较明显的先后顺序,不过这个也可以解释为偶然,顺便提一下,这个不重要,主要还是上面的理由。
- 另外,现在众口一词地将Lieyanhanbing标记为“纯破坏用户”,而Tailuoatm是完全无辜的受害者,不知道是谁先提出来的说法,还是有人在站外社区达成了共识?从二人的编辑来看,如果Lieyanhanbing是纯破坏者,Tailuoatm也差不远了。
- 言尽于此。反正我是不支持解封,不过有别的管理员愿意解也随意,不用再过问我的意见,不过建议需要Tailuoatm通过正常申诉渠道提交申诉请求且解释他认为二人出现相似编辑的理由,即使理由是“偶然”、“栽赃”一类,我认为需要他自己亲口保证,而非通过站外群转述。
- 最后提醒一句,核查那边本来是要本地达成共识才能核查的,理论上这次核查尚没有得到一致同意,按理说可以在元维基以本地存在争议为由撤回。--浅蓝雪❉ 2021年11月20日 (六) 12:03 (UTC)
- 可能@淺藍雪有所不知,近期冒充犯非常猖狂。此外,此案根本不需要是主动冒充:L用户完全可能是以某些方式(还挺多的)看到了T用户的编辑,然后出于破坏目的重复了其编辑。Itcfangye(留言) 2021年11月20日 (六) 14:58 (UTC)
- 最近有冒充犯这个事有记录吗--浅蓝雪❉ 2021年11月21日 (日) 11:56 (UTC)
- VIP那边有许多LTA:Kapol6360建立的冒充向傀儡的封禁记录,此外LTA:QCHM和LTA:HMGY等也建立过冒充他人的傀儡。当然此案中的L用户不一定是他们之一。Itcfangye(留言) 2021年11月21日 (日) 12:12 (UTC)
- @Itcfangye:感觉记录上哪个都不像,都不能很好解释我之前的怀疑。我是真的无相信Tailuoatm完全无辜,说实话总让我想起user:420peace。要解封真的得别的管理员看看,还是我上面说的“别的管理员愿意解也随意,不用再过问我的意见”。--浅蓝雪❉ 2021年11月21日 (日) 12:52 (UTC)
- 这事会不会和我在元维基的这次提报有一定关系?--Liuxinyu970226(留言) 2021年11月25日 (四) 06:35 (UTC)
- @Itcfangye:题外话。HAM上不是挂了不存档的模板了吗?怎么前两天存档了……--三万光年 GBAW 2021年11月26日 (五) 12:40 (UTC)
- 哦是这样,据我所知,机器人在那页并不认那个模板。--安忆Talk 2021年11月26日 (五) 12:46 (UTC)
- 同上,当时查出CRHK128的时候我也挂了那个模板,机器人理都不理( ——魔琴 [ 已经告假 留言 贡献 ] 2021年11月27日 (六) 15:04 (UTC)
- @Itcfangye:题外话。HAM上不是挂了不存档的模板了吗?怎么前两天存档了……--三万光年 GBAW 2021年11月26日 (五) 12:40 (UTC)
- 这事会不会和我在元维基的这次提报有一定关系?--Liuxinyu970226(留言) 2021年11月25日 (四) 06:35 (UTC)
- @Itcfangye:感觉记录上哪个都不像,都不能很好解释我之前的怀疑。我是真的无相信Tailuoatm完全无辜,说实话总让我想起user:420peace。要解封真的得别的管理员看看,还是我上面说的“别的管理员愿意解也随意,不用再过问我的意见”。--浅蓝雪❉ 2021年11月21日 (日) 12:52 (UTC)
- VIP那边有许多LTA:Kapol6360建立的冒充向傀儡的封禁记录,此外LTA:QCHM和LTA:HMGY等也建立过冒充他人的傀儡。当然此案中的L用户不一定是他们之一。Itcfangye(留言) 2021年11月21日 (日) 12:12 (UTC)
- 最近有冒充犯这个事有记录吗--浅蓝雪❉ 2021年11月21日 (日) 11:56 (UTC)
基于近期有用户在向元维基转交查核请求时叙述不够详细导致元维基监管员难以理解查核请求的情况多次发生,我希望能在HAM的抬头中加入对转交请求的一些要求。因为修订较多,所以在方针这边开个讨论。
|
|
兹邀请@寒吉、MCC214、Liuxinyu970226、LuciferianThomas、Timmyboger、@AINH、Newbamboo、Ruincrez、Mys_721tx、Matt_Smith等人一同参与讨论。--Itcfangye(留言) 2021年11月7日 (日) 09:26 (UTC)
方针版太长了我的提案显示不出来了QAQ!Itcfangye(留言) 2021年11月7日 (日) 09:29 (UTC)
- 如果被提请查核的是LTA那么倒是可以不用这么麻烦。--🎋竹之初生(留言)中华民国110年 2021年11月7日 (日) 11:48 (UTC)
- @Newbamboo:即使是LTA,也有今天Liuxinyu970226在转交时完全没有解释清楚为什么新涉及账户是LTA傀儡以至于无法进行查核的问题(我后来重新提交并且解释了原因)。对于LTA的新分身账户,需要解释一下新发现的傀儡是为何发现的。Itcfangye(留言) 2021年11月7日 (日) 15:33 (UTC)
- 会转交的人应该都要很清楚这些。提外话,为何不接受IP使用者的请求?--拒食木瓜卄 2021年11月13日 (六) 12:01 (UTC)
- @Jonatgan5566:最近有用户转交的时候语焉不详,给元维基查核员带来了困难,所以我想直接写在header里有助于现有和未来有意进行转交工作的用户更好的转交请求。至于ip用户的问题我不太清楚,可能要翻翻讨论页?Itcfangye(留言) 2021年11月14日 (日) 03:27 (UTC)
- 我觉得其实“如您在翻译和转交时遇到表述上的困难或者不清楚的事实,麻烦不要转交”。当然此版提案其实也可以,但觉得可以写硬一点-- Sunny00217 2021年11月14日 (日) 10:22 (UTC)
(&)建议:先要将英文查核请求写在本地,得到本地认可,再向元维基提交请求。桐生君★[讨论] 2021年11月16日 (二) 02:29 (UTC)
转交员
[编辑]- 记得之前屡次提过设立转交员,不妨再考虑一下? ——魔琴 [ 已经告假 留言 贡献 ] 2021年11月11日 (四) 04:59 (UTC)
- (-)反对:应该不需要这种明文写出的规定吧,就算有这种规定,真正实施起来也会比较复杂,判断标准也可能会比较模糊;比如某用户英语水平及平日反破坏工作做得很好,对各LTA的编辑倾向也很熟悉,但并不是“转交员”,今日忽然想帮助处理HAM积压,并且成功转交了一个请求,那这个请求是应该从元维基撤回还是留在元维基呢?这名用户又该怎么处理?如果监管员已经处理了这名用户所转交的请求呢?如果处理不当可能反而会打击社群处理相关请求的积极性。因此反对设立转交员。--Yining Chen(留言|签名) 2021年11月14日 (日) 10:02 (UTC)
- 如果设立,非转交员可以先在本地翻译完,获认可后再转发到元维基。SRCU上涉zh.wikipedia的请求应由转交员提出(可不可以要求监管员检查一下是否转交员?),否则无效。 ——魔琴 [ 已经告假 留言 贡献 ] 2021年11月21日 (日) 08:56 (UTC)
- (-)反对:应该不需要这种明文写出的规定吧,就算有这种规定,真正实施起来也会比较复杂,判断标准也可能会比较模糊;比如某用户英语水平及平日反破坏工作做得很好,对各LTA的编辑倾向也很熟悉,但并不是“转交员”,今日忽然想帮助处理HAM积压,并且成功转交了一个请求,那这个请求是应该从元维基撤回还是留在元维基呢?这名用户又该怎么处理?如果监管员已经处理了这名用户所转交的请求呢?如果处理不当可能反而会打击社群处理相关请求的积极性。因此反对设立转交员。--Yining Chen(留言|签名) 2021年11月14日 (日) 10:02 (UTC)
- 粗略看了一下之前的讨论,先看看别人意见。Itcfangye(留言) 2021年11月11日 (四) 05:47 (UTC)
(-)反对设立转交员,理由同Yining Chen,建议本地得出共识时,更改状态为“请求转交”,或使用请求转交图标,然后有人翻译为英文,先要将英文查核请求写在本地,得到本地认可(可以使用“认可,请转交”图标),再向元维基提交请求。桐生君★[讨论] 2021年11月14日 (日) 10:28 (UTC)
当然,这些图标都需要建立,也可以不用图标,直接讨论说“认可”即可。桐生君★[讨论] 2021年11月14日 (日) 10:50 (UTC)
我觉得不需要吧,大家看到帮忙转过去就好--Nrya ✰武汉肺炎两周年•Xi病毒来袭 2021年12月1日 (三) 12:05 (UTC)
- 问题是偶尔会有人不清楚情况就转发,或者转发的内容不明不白(比如原因只写一句“中维请求”),我觉得设置转交员可能可以规范转交的行为,避免类似问题发生。 ——魔琴 [ 已经告假 留言 贡献 ] 2021年12月5日 (日) 12:02 (UTC)
明文要求Wikipedia:元维基用户查核请求的申请须符合相应基本需求
[编辑]
|
|
--(☎) 2021年12月9日 (四) 17:26 (UTC)
新增条文意为避免有用户仅用“疑似傀儡投票”或“大量创立劣质条目”等其他单一间接证据来进行查核。--(☎) 2021年12月9日 (四) 02:00 (UTC)
- 比如用户只进行了傀儡投票怎么办?但应该规范详细的说哪里进行了傀儡投票,除非该投票位置一望而知。桐生ここ★[讨论] 2021年12月9日 (四) 03:14 (UTC)
- 同上,不少帐号基本上都是就那一二条高度可疑但又不足以Duck的线索。--🎋🎍 2021年12月9日 (四) 04:17 (UTC)
- 一条是肯定不够HAM,不是线索太少就是可以基本一望而知了。不过确实得视情况而定。--(☎) 2021年12月9日 (四) 17:26 (UTC)
- (▲)同上--夏雪若(留言) 2021年12月20日 (一) 10:53 (UTC)
- 一条是肯定不够HAM,不是线索太少就是可以基本一望而知了。不过确实得视情况而定。--(☎) 2021年12月9日 (四) 17:26 (UTC)
- 跟理据数量没有关系,是提报人需要提供支撑理据的实例。Itcfangye(留言) 2021年12月13日 (一) 13:10 (UTC)
编辑请求 Wikipedia:元维基用户查核请求
[编辑]请求已处理--Xiplus#Talk 2022年1月18日 (二) 06:11 (UTC)
关于Wikipedia:元维基用户查核请求,现希望补充与Legendarygirlfriend的关系:Legendarygirlfriend为Draft: Triple G内容之其中一名原作者,我与Legendarygirlfriend本人私底下认识,条目内容由我们二人在线下合作撰写,但因Legendarygirlfriend不熟悉维基的coding,所以二人线下完成后由本人代表将内容上载至维基。而Legendarygirlfriend一直有监视本条目的状况,因此在本条目被提出需要快速删除时亦留言。若致误会,在此致歉。--10385jfie(留言) 2022年1月18日 (二) 05:57 (UTC)10385jfie
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
近期发现中维缺乏一个认真调查傀儡的地方,WP:HAM只收可送往CU的傀儡调查,对于IP傀儡调查方面完全忽略掉了;放在VIP又很容易被管理员略过没看到。故此,建议将WP:HAM转化成如英维WP:SPI的用户傀儡调查页,包括但不再限于需要用户查核的傀儡调查,以进一步改善反破坏制度。同时,亦可设类似Clerks的职位,供任何愿意参与反傀儡破坏且熟悉LTA或傀儡调查的维基人参与。--路西法人☆ 2022年1月12日 (三) 09:46 (UTC)
- (+)支持 --SCP-0000(留言) 2022年1月12日 (三) 10:05 (UTC)
- (+)支持增设反破坏相关权限并进一步设立傀儡调查机制。--Kriz Ju(留言) 2022年1月12日 (三) 11:49 (UTC)
- Clerk(直译为书记)并非权限,只是类似小助理的角色,没有任何特殊权限(就算本地复原有CU权限页不会有看到CU数据的权限)。--路西法人☆ 2022年1月12日 (三) 13:32 (UTC)
@以下近期出现过在HAM相关讨论的维基人和活跃管理员看看。路西法人☆ 2022年1月12日 (三) 13:46 (UTC)
--- Clerk我目前会中立,个人不觉得有另设职位的必要。至于改为如SPI的页面(+)支持。--(☎) 2022年1月12日 (三) 13:51 (UTC)
- Clerk感觉是在中维是将个转交员包装一下的方案啊 囧rz……。--Ghren🐦🕙 2022年1月12日 (三) 14:10 (UTC)
- (+)支持--AT 2022年1月12日 (三) 14:19 (UTC)
- 是我曾经想过的一个点,而且事实上HAM也逐渐在往这个方向发展,提议合理。Clerk看需要吧,感觉好像目前不是很需要的样子,先这样扩展一下范围就可以了。--Tiger(留言) 2022年1月12日 (三) 14:31 (UTC)
- (+)支持,早就该做了。--A1Cafel(留言) 2022年1月12日 (三) 14:39 (UTC)
- 太支持了。--三万光年 GBAW 2022年1月12日 (三) 14:44 (UTC)
- 支持。Nrya 香港再无新闻🕯️ 2022年1月12日 (三) 15:27 (UTC)
- 支持。~~Sid~~ 2022年1月12日 (三) 15:31 (UTC)
- (+)支持--Lanwi1(留言) 2022年1月12日 (三) 16:09 (UTC)
- (+)支持 桐生ここ★[讨论] 2022年1月12日 (三) 17:57 (UTC)
- (+)支持。具体操作上,既然不只有使用者查核了,建议将元维基使用者查核请求并回使用者查核请求,然后改名作“傀儡调查”之类。此外,包括页面顶部header之叙述,以及一些小工具或机器人也要相应调整。至于“Clerk”这种职务本地目前应该是没有需要。—— Eric Liu 创造は生命(留言.留名.学生会) 2022年1月12日 (三) 18:35 (UTC)
- 支持。-Mys_721tx(留言) 2022年1月12日 (三) 18:43 (UTC)
- Clerk似乎相当于机器人审核小组的角色?--百無一用是書生 (☎) 2022年1月13日 (四) 02:05 (UTC)
- (+)支持。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月13日 (四) 04:16 (UTC)
- (+)支持。--绍🎇煦🌈☀️ 2022年1月13日 (四) 14:15 (UTC)
- (+)支持需要地方解决可以Duck的非LTA傀儡。--🎋🎍 2022年1月14日 (五) 07:36 (UTC)
将Clerk讨论分拆,HAM转化议案真的是难得有一致同意的议案,那我就把讨论快进,方便之后一并公示了。以下是SPI的建议置顶说明:
|
|
以上,供各位参阅,欢迎提供意见。路西法人☆ 2022年1月13日 (四) 05:19 (UTC)
--无新反对意见,🕗 公示7日,2022年1月27日 (四) 03:20 (UTC) 结束。--路西法人☆ 2022年1月20日 (四) 03:20 (UTC)
- 公示七日结束,通过。--路西法人☆ 2022年1月27日 (四) 04:30 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
调查助理(Clerk)讨论
[编辑]- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
在本地上面那个似乎一周后可以直接雪球公示,故分拆调查助理(Clerk)讨论。我来说明一下Clerk在中维的作用:
- 协助管理员判定帐号之间是否互为傀儡或真人傀儡关系
- 分辨是否适合用户查核(拒绝不符合用户查核条款的查核请求)
- 虽然这个会导致如Ghrenghren说的“转交员”,但可确保运作更顺利;且Clerk不只是负责转交查核,还有一般IP的调查应该会占更多数。
- 未来倘若在完善制度后CU权回归本地,则纯粹是同意或拒绝查核,且CU是不一定要有Clerk的同意才能查核(就是CU比Clerk还快上线的例子,不过如果Clerk是已经讲明不符合查核所需条件的话CU还查就……不知道了)。
- 负责管理SPI运作和LTA页面
- 作出判定后负责通知管理员或关闭提报(因为判定傀儡这一动作不需要管理员才能做,而HAM的部分长期都是非管理员关闭也不太妥当,故正式设立工作组
- 仍允许任何自动确认用户创建LTA页(虽然个人认为应该提升资格至延伸确认),但LTA状态({{Infobox Baduser}}的
status
)参数)预设为待确认(pending approval
),由Clerk团队确认属于长期破坏者再改为“活跃”。纯粹防止滥建LTA页,昨天清理的时候发现有这个莫名其妙的案例(这个小到不适用LTA,纯粹是一般破坏);还有避免再次出现以往LTA:LHKS的争议。
简而言之就是“可信任其调查傀儡的能力和熟悉相关程序的用户”。我认同Clerk不一定要现在引入,但个人觉得Clerk的其他作用,尤其是管理SPI运作和LTA相关资料的部分,可以确保一般性的非LTA傀儡案件也能获得顺利处理,而减少在AIV被遗漏的机会。@Shizhao:没错,就是类似BAG的角色。 --路西法人☆ 2022年1月13日 (四) 02:52 (UTC)
- 这样一个角色我觉得在实务上还是有必要设立的(管多少如何管可以再讨论)。经常破坏提报就一句“一望而知LTAxxx”,或者更干脆就一个“LTAxxx”就完事,不是熟悉这个LTA的管理员,根本无法确认。有了Clerk角色,效率上可能会好一些。所以我认为Clerk的定位就是协助管理员确认--百無一用是書生 (☎) 2022年1月13日 (四) 03:37 (UTC)
- 仍旧支持转交员方案,随便来个人都有资格转交有扰乱m:SRCU的隐患。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月13日 (四) 04:16 (UTC)
调查助理页面的翻译草稿存放于Wikipedia:傀儡调查/调查助理,欢迎查阅和提出建议。调查助理建议跟从英维格式设限额,第一批调查助理建议跟从RFR开放报名,再由管理员挑选五到七个申请者担任第一批调查助理。--路西法人☆ 2022年1月14日 (五) 13:34 (UTC)
分立案时已通知所有上方讨论持中立的用户,也有明确支持意见,同时不见任何反对意见,故同步就Wikipedia:傀儡调查/调查助理和第一批调查助理报名方式🕗 公示7日,2022年1月27日 (四) 03:20 (UTC) 结束。--路西法人☆ 2022年1月20日 (四) 03:20 (UTC)
- Wikipedia:傀儡调查/调查助理#管理员巡检看起来没翻译完啊?--Xiplus#Talk 2022年1月20日 (四) 04:59 (UTC)
- 管理员巡检本来就不是调查助理的一部分((--路西法人☆ 2022年1月20日 (四) 07:02 (UTC)
- 如果这不是方针指引草案的话。--Xiplus#Talk 2022年1月20日 (四) 09:33 (UTC)
- 不是。英维SPI也不是指引。--路西法人☆ 2022年1月20日 (四) 09:35 (UTC)
- 如果这不是方针指引草案的话。--Xiplus#Talk 2022年1月20日 (四) 09:33 (UTC)
- 管理员巡检本来就不是调查助理的一部分((--路西法人☆ 2022年1月20日 (四) 07:02 (UTC)
- 其实根本上没有必要将这个职位写得如此明确。管理员基本上只要有一定关心HAM的话应该不难判断谁的要求比较可信。完全有可能像@Yining Chen在过去说的,某些用户虽然平常关心反破坏,但是不太关心HAM的积压,这个情况是完全可能出现的。而且这个助理还要管LTA页。其实个人认为管的太宽。转交员的权力本身己经很少,而这个助理的能力还要更大。过去也有提到过转交员是为中立的问题。而且你还没有译完,我认为不可公示此案。--Ghren🐦🕐 2022年1月20日 (四) 05:31 (UTC)
- 其实我觉得吧,任何人都能协助查核的。没有必要另设一阶级。—— Eric Liu 创造は生命(留言.留名.学生会) 2022年1月20日 (四) 05:38 (UTC)
- @Xiplus、Ericliu1912、Ghrenghren:
- 管理员巡检本来就不是调查助理的一部分,未翻译完也不影响调查助理的运作。
- “管理员基本上只要有一定关心HAM的话应该不难判断谁的要求比较可信”,问题就是如Shizhao君指出不是每一个处理反破坏积压的管理员或维基人都会注意傀儡调查,不熟悉LTA或维基人是平常事,更直接点来说你也未必能认得这么多个维基人,改个用户名甚至就一个签名你就不认得了,或者来几个反破坏新秀或“反破坏新手”,你觉得管理员一定分得出来?不清楚那个LTA的管理员可能还AGF他呢。你看看前管理员多好控制就知道了。
- 固然如Eric君所言,任何人都能协助查核的,但调查助理不是作最后裁断的,而是负责维护整个流程,任何用户仍能如现在一般参与讨论,协助判断傀儡。
- 维护流程方面,调查助理要协助维护LTA页的原因是防止这些不当判定LTA、这些摆明给新LTA照着模仿伪装的乱象。
- 以上,不知能否解答你们的问题。--路西法人☆ 2022年1月20日 (四) 09:16 (UTC)
- 各种具体的流程很不明确,从选拔方式来讲,enwiki看起来是由CUer团队一起决定是否任命,而本地确定只用RFR程序?是单一管理员的决定就可以任命吗?--Xiplus#Talk 2022年1月20日 (四) 09:41 (UTC)
- 我觉得可以通过RfA的模式选举。 ——魔琴 [ 留言 贡献 ] 2022年1月20日 (四) 10:09 (UTC)
- 始终中维没有CU员。另一替代方法是由行政员选拔报名用户,现阶段未有本地CU的情况下把选拔名单转发至监管员布告板公示,确保助理受监管员信任。此会否为现阶段合理的任命流程?--路西法人☆ 2022年1月20日 (四) 10:24 (UTC)
- @Xiplus:关于选拔方式是否同意以上建议?若同意,将重新公示修订版选拔方式。--路西法人☆ 2022年1月21日 (五) 13:42 (UTC)
- 我觉得管理员就能进行选拔了吧?实际上查核流程共事的人是管理员而不是行政员,“他们应被管理员和监管员所信任”。--Xiplus#Talk 2022年1月21日 (五) 13:48 (UTC)
- 当然没问题,我提行政员的原因是因为好像高于CU员而已(囧--路西法人☆ 2022年1月21日 (五) 13:54 (UTC)
- 我觉得管理员就能进行选拔了吧?实际上查核流程共事的人是管理员而不是行政员,“他们应被管理员和监管员所信任”。--Xiplus#Talk 2022年1月21日 (五) 13:48 (UTC)
- @Xiplus:关于选拔方式是否同意以上建议?若同意,将重新公示修订版选拔方式。--路西法人☆ 2022年1月21日 (五) 13:42 (UTC)
- 再来enwiki对于调查助理的工作流程似乎没有明文写下来,依靠的是现任调查助理手把手的指导,那么本地要由谁来指导?--Xiplus#Talk 2022年1月20日 (四) 09:44 (UTC)
- 可请求英维助理团队协助作初步指导和请教当初英维设助理团队时流程的安排,再由选出来的本地助理团队明确流程。第一代就是这样了,英维第一代助理团队也是要经历这一步。--路西法人☆ 2022年1月20日 (四) 10:27 (UTC)
- 2.实话个人都不太留意HAM(一个月两三次左右?),但是我基本上可以判断到什么用户是比较可信或者是比较活跃的。问题就是Clerk就能解决这个AGF LTA的情况吗?似乎不能。毕竟Clerk的观点只是考虑的,本则上管理就应该考虑社群的观点。Clerk改个用户名一样是认不出来吧;
- 3.整个流程目前似乎就已经很顺畅。似乎是WP:没坏别修?为什么多个职位出来就会顺畅了?
- 4.用户正常就应该可以处理这个问题。维基百科不是官僚体系,除了增加积极性之外没什么特别。--Ghren🐦🕕 2022年1月20日 (四) 10:14 (UTC)
- (2) 时昭作为颇为活跃的管理员,也指出需要助理协助确认,这不是您个人觉得就是的。同时,助理正能解决误AGF长期破坏者的问题,因为他们正是能协助管理员确认的角色,是管理员可信任的用户。至于能否辨认的部分,en:Template:Clerk note,且助理列表公示于WP:SPI/C,不难辨认。(过滤器防止滥用,改名通知管理员改过滤器)
- (3) “似乎”真的是很不准确。至今仍经常出现转交不能查的过期帐号的情况,以往也有MCC214因不当使用HAM和SRCU,至今仍被禁制使用SRCU的案例,显示流程不完善,确实有漏洞。
- (4) 不是官僚体制,但仅代表用户没有特权。流程不完善就改善,正常用户可以处理清理LTA页面,但LTA:LHKS一事显示直接容许用户创建LTA页面也会造成问题(被用作POINT和GAME)。LTA的定义兹事体大,需要由社群信任的人去处理,而调查助理正适合此部分。(固然不能排除助理做这些部分,但由于助理是团队制,容易互相制衡,这个部分比没有团队更容易发现辨认”
- 以上。--路西法人☆ 2022年1月20日 (四) 10:50 (UTC)
- 维基百科不是官僚体系说的不是维基百科不能设立“官职”,而是说我们不能“盲目跟随默认的方针和程序”,“照本宣科执行规条”。 ——魔琴 [ 留言 贡献 ] 2022年1月20日 (四) 12:18 (UTC)
- 2、3点我没有什么特别意见。特别是第3点也似乎是这个流程嘛确实我也有些少误解。问题是在于你的版本和英维的版本并不是一致的,你的版本中“协助维护”中没有排除其他用户,而就算在英维中,这些工作也是没有排除其他用户完成的。也就是说,你希望这些工作只由助理完成,还是不让一般用户参与?我暂时考古了一下下午都不太找到英维助理成立的讨论存档,但是葡语大致上就是要去检查用户证据,然后再使Cuer或者元维基可以直接查,重点是确认至转交这个工作只是能有助理完成,问题在你这个议案中没有很有效的解释这一点。引致现在这个议案在我眼中有些少限制一般用户参与的味道。“Endorsing”不代表CU可以查,只是代表议案成立这个味道。另外 吐槽将talkpage当报告板非常不友好,英维考古时就有这个问题。--Ghren🐦🕓 2022年1月21日 (五) 09:12 (UTC)
- 各种具体的流程很不明确,从选拔方式来讲,enwiki看起来是由CUer团队一起决定是否任命,而本地确定只用RFR程序?是单一管理员的决定就可以任命吗?--Xiplus#Talk 2022年1月20日 (四) 09:41 (UTC)
- @Xiplus、Ericliu1912、Ghrenghren:
- 我不认同这构成限制用户参与的问题。一般自动确认用户仍能参与整个调查流程,从提案、证据整理、检查查核资格、判断是否傀儡这些工作,其他用户仍然能参与。分别在于调查助理是管理员、行政员及用户查核员(监管员)信任其熟知有关程序和规则的活跃,是让他们可更确实确认请求妥当的存在,可加速程序进行,不是阻止一般用户转交的意思,已经具备社群共同确认可行性但没有活跃助理进行转交固然仍然可以转交(WP:NOTBURO的正确使用)。--路西法人☆ 2022年1月21日 (五) 12:10 (UTC)
- 不解。一边就说Mcc的行为扰乱了HAM的秩序,一边就说一般用户也可以如常参与。我承认我对WP:NOTBURO误解了,你提案的目的是限制MCC式扰乱CU行为还是将英、葡一样解决积压?--Ghren🐦🕗 2022年1月21日 (五) 12:24 (UTC)
- ……您是否忘了有“拒绝查核请求”的部分?固然一般用户仍然可以参与,就如MCC虽然因扰乱SRCU秩序而被禁制使用SRCU,但仍然可以用HAM提报请求查核,简而言之是被剥夺转交权。把助理一角放回当时MCC不当使用HAM的情况就能挡掉这些查核请求,让转交查核的部分不至于没有人管理。一般用户可以转交这个建基于真的没人处理积压和有达成社群共识,助理未能达到“解决积压”的效果时,社群的参与并不冲突。是否能解释同时达到把关用户查核请求和解决积压的问题?--路西法人☆ 2022年1月21日 (五) 12:46 (UTC)
- 也就是说,你整个议案不会去限制任何一般去进行转交SRCU和CU的动作?因为你目前公示的没有这部份。但是这就引致当时MCC的这个情况本质上来说助理没有能力挡掉,这个是后话。也就是说目前整个方案5点都只是建议而没有排除其他用户参与,连根本转交的角色一般用户共识后都可以参与。用户看到查核不合理其实也可以即挡掉或者Duck。整个议案除了“名片”作用之外其实比较鸡肋。怎说呢?我不会反对此案,我觉得有也无不可。只是我搞不清楚你的立案动机,整个助理议案看上去很奇怪。Ghren🐦🕛 2022年1月21日 (五) 18:13 (UTC)
- 应该是在有助理处理时进行限制吧?没有助理处理时才容许非助理转交。--Xiplus#Talk 2022年1月22日 (六) 05:23 (UTC)
- 确实。--路西法人☆ 2022年1月22日 (六) 05:32 (UTC)
- 这样的话就请写明在公示内容里,不要说得含糊不清。--Ghren🐦🕒 2022年1月22日 (六) 07:05 (UTC)
- 应该是在有助理处理时进行限制吧?没有助理处理时才容许非助理转交。--Xiplus#Talk 2022年1月22日 (六) 05:23 (UTC)
- 也就是说,你整个议案不会去限制任何一般去进行转交SRCU和CU的动作?因为你目前公示的没有这部份。但是这就引致当时MCC的这个情况本质上来说助理没有能力挡掉,这个是后话。也就是说目前整个方案5点都只是建议而没有排除其他用户参与,连根本转交的角色一般用户共识后都可以参与。用户看到查核不合理其实也可以即挡掉或者Duck。整个议案除了“名片”作用之外其实比较鸡肋。怎说呢?我不会反对此案,我觉得有也无不可。只是我搞不清楚你的立案动机,整个助理议案看上去很奇怪。Ghren🐦🕛 2022年1月21日 (五) 18:13 (UTC)
- ……您是否忘了有“拒绝查核请求”的部分?固然一般用户仍然可以参与,就如MCC虽然因扰乱SRCU秩序而被禁制使用SRCU,但仍然可以用HAM提报请求查核,简而言之是被剥夺转交权。把助理一角放回当时MCC不当使用HAM的情况就能挡掉这些查核请求,让转交查核的部分不至于没有人管理。一般用户可以转交这个建基于真的没人处理积压和有达成社群共识,助理未能达到“解决积压”的效果时,社群的参与并不冲突。是否能解释同时达到把关用户查核请求和解决积压的问题?--路西法人☆ 2022年1月21日 (五) 12:46 (UTC)
- 不解。一边就说Mcc的行为扰乱了HAM的秩序,一边就说一般用户也可以如常参与。我承认我对WP:NOTBURO误解了,你提案的目的是限制MCC式扰乱CU行为还是将英、葡一样解决积压?--Ghren🐦🕗 2022年1月21日 (五) 12:24 (UTC)
- 如同Shizhao前面提出管理员不熟悉LTA的问题,常见于VIP一望而知的提报,再经过Clerk确认之后,管理员是否能够不需要再做额外确认直接封锁?--Xiplus#Talk 2022年1月22日 (六) 05:48 (UTC)
- 助理就是管理员信任其对傀儡的判断的人,理论上是可以不需额外确认就封锁(确认的步骤助理做了)。如果有助理乱来就当然是除名加封锁(GAME),我相信这个机率比较小。--路西法人☆ 2022年1月22日 (六) 06:21 (UTC)
- 另外成立SPI页面后,是否所有傀儡相关的事项都应该在SPI处理,不再允许于VIP/ANM提报,不然现在有不少VIP提报一望而知,但管理员认定需要CU辅助判断又转交HAM;或者CU完再丢回VIP,然后不附任何连结的情况。--Xiplus#Talk 2022年1月22日 (六) 05:52 (UTC)
- 不明文程序,基本上跟HAM相同但新增Clerk程序加速处理积压,但有需要的话我在这里列出。
- (1) 用户提出调查请求并提供相关证据。-此案待处理。
- (2) 用户参与讨论,管理员和调查助理审视证据。
- (3) 检查用户查核条件。
- (3.1) 符合用户查核条件的案件,由调查助理同意并转交查核请求。-有调查助理认为此案适用用户查核,已转交至元维基进行查核。
- (无需像HAM那样on hold最少两至七天再转了)
- (3.1.1) 若积压七日无助理处理,且有社群共识复查符合用户查核条件,则以社群程序转交。-社群讨论后认为此案适用用户查核,已转交至元维基进行查核。
- (无活跃助理是说@了人都没人处理,那这个就是助理团队问题了)
- (3.2) 不符合用户查核条件的案件,由调查助理拒绝查核请求。-有调查助理认为此案不适用用户查核,此案现等候比对用户行为特征。
- (3.2.1) 社群不认同的话请求另一调查助理复检请求。(可能-此案需要调查助理协助。)
- (3.1) 符合用户查核条件的案件,由调查助理同意并转交查核请求。-有调查助理认为此案适用用户查核,已转交至元维基进行查核。
- (4) 用户查核完成后回报结果。
- (4.1) 用户查核和贡献比对均确认为傀儡,助理请求管理员助理。-监管员已完成用户查核,此案现正等候管理行动(如有需要)和结案。
- (4.2) 确认为完全不相关就结案。-此傀儡调查已结案并等候存档。
- (5) 完成后进行存档(手动、机械人也可)。
- ANM程序不作傀儡提报;新程序完成查核不转交AIV直接在SPI作结并处理。AIV仍接受具破坏性的LTA扰乱行为(LTA:X43、LTA:Kapol之流)的提报,如有需要可找助理协助辨认,转SPI的鸭子处理途径。IP也是同理,能明确辨认的话且构成破坏的当然可以AIV。傀儡投票SPI请。--路西法人☆ 2022年1月22日 (六) 06:17 (UTC)
- 以上流程听起来没问题,写下来啊,WP:傀儡调查/调查助理指引之类的。--Xiplus#Talk 2022年1月22日 (六) 07:08 (UTC)
- 有明显的破坏当然很容易直接按破坏封,不需要考虑是不是傀儡,但也有不少LTA很难一眼看出是破坏,而很多人提报只会说一望而知。--Xiplus#Talk 2022年1月22日 (六) 07:10 (UTC)
- 如果有人AIV提报duck但管理员认为不清楚的话,应转SPI由助理duck再找管理员处理。--路西法人☆ 2022年1月22日 (六) 07:17 (UTC)
- 那为什么不直接SPI?我认为现在超过半数的AIV提报都不够清楚,而且统一使用SPI也是让傀儡纪录更加完善。--Xiplus#Talk 2022年1月22日 (六) 07:19 (UTC)
- 如果有人AIV提报duck但管理员认为不清楚的话,应转SPI由助理duck再找管理员处理。--路西法人☆ 2022年1月22日 (六) 07:17 (UTC)
- 不明文程序,基本上跟HAM相同但新增Clerk程序加速处理积压,但有需要的话我在这里列出。
- 还有CU完是否由Clerk负责再次比对行为证据(特别是查到原提报未列出的傀儡),才决定是否交由管理员进行封锁,这个问题跟VIP提报一望而知的问题类似。--Xiplus#Talk 2022年1月22日 (六) 05:56 (UTC)
- 如果查出另一组与主查核组不相关的,就必须由助理处理;如果像臭臭猫那样的查核结果就一般用户也可以标记checked。--路西法人☆ 2022年1月22日 (六) 06:19 (UTC)
- 我的问题是:Special:Diff/69798564,您这样ping我,我可以什么都不看直接封锁吗?--Xiplus#Talk 2022年1月22日 (六) 07:15 (UTC)
- 之后担任助理的话应该会讲明“综合用户特征和技术证据确认为傀儡,请管理员处理”这样的话,理论上是可以直接封不用看。一般用户也可转发查核结果的话,管理员可以看一看,也是可以直接处理,不过等助理确认也可。--路西法人☆ 2022年1月22日 (六) 07:21 (UTC)
- 行为证据的判断应该在CU前还是后?如果是前的话,CU后不需要再整合CU结果一起判断吗?--Xiplus#Talk 2022年1月22日 (六) 07:24 (UTC)
- 理论上,没有合理行为证据是不应该进行用户查核的,而CU后整合CU结果一起判断是需要的。在您提出今天的例子中,(1)用户特征明显,基本上是一望而知,实际上是查sleeper;(2)技术确认sleeper。在查核LTA sleeper的情况下,基本上不用看就可以直接封;在其他查核情况下,如出现查核不相关这些情况,助理应该不会直接找管理员处理。--路西法人☆ 2022年1月22日 (六) 07:34 (UTC)
- 如果查核sleeper时查到另一位有一定编辑历史的使用者?--Xiplus#Talk 2022年1月22日 (六) 07:37 (UTC)
- 那么我确信助理一定会外加复查再找管。感谢提醒,我会加进去流程表内。--路西法人☆ 2022年1月22日 (六) 07:53 (UTC)
- 如果查核sleeper时查到另一位有一定编辑历史的使用者?--Xiplus#Talk 2022年1月22日 (六) 07:37 (UTC)
- 理论上,没有合理行为证据是不应该进行用户查核的,而CU后整合CU结果一起判断是需要的。在您提出今天的例子中,(1)用户特征明显,基本上是一望而知,实际上是查sleeper;(2)技术确认sleeper。在查核LTA sleeper的情况下,基本上不用看就可以直接封;在其他查核情况下,如出现查核不相关这些情况,助理应该不会直接找管理员处理。--路西法人☆ 2022年1月22日 (六) 07:34 (UTC)
- 行为证据的判断应该在CU前还是后?如果是前的话,CU后不需要再整合CU结果一起判断吗?--Xiplus#Talk 2022年1月22日 (六) 07:24 (UTC)
- 之后担任助理的话应该会讲明“综合用户特征和技术证据确认为傀儡,请管理员处理”这样的话,理论上是可以直接封不用看。一般用户也可转发查核结果的话,管理员可以看一看,也是可以直接处理,不过等助理确认也可。--路西法人☆ 2022年1月22日 (六) 07:21 (UTC)
- 我的问题是:Special:Diff/69798564,您这样ping我,我可以什么都不看直接封锁吗?--Xiplus#Talk 2022年1月22日 (六) 07:15 (UTC)
- 如果查出另一组与主查核组不相关的,就必须由助理处理;如果像臭臭猫那样的查核结果就一般用户也可以标记checked。--路西法人☆ 2022年1月22日 (六) 06:19 (UTC)
异议解决,调查助理继续进行🕗 公示至2022年1月27日 (四) 03:20 (UTC);第一批调查助理选拔方法按照Xiplus建议修订为管理员团队选拔报名用户并转交监管员布告板公示,重新🕗 公示7日,2022年1月29日 (六) 04:17 (UTC) 结束。--路西法人☆ 2022年1月22日 (六) 04:17 (UTC)
- 我觉得程序部分没有清晰到足以公示。--Xiplus#Talk 2022年1月22日 (六) 05:24 (UTC)
- 请你将{{duck}}不要再报VIP、Clerk的工作按你的说法写清楚才再重新公示,你公示的内容中Clerk完全没有权,所有工作用户也能做。--Ghren🐦🕒 2022年1月22日 (六) 07:11 (UTC)
- WP:SPI/P,已私下通知,还请@Xiplus、Ghrenghren君确认是否能解决你们的疑虑和问题。--路西法人☆ 2022年1月22日 (六) 16:26 (UTC)
- 没意见。--Ghren🐦🕐 2022年1月22日 (六) 17:01 (UTC)
- @LuciferianThomas:也就是结果提了WP:VIP就不要再存档WP:SPI吗?--Ghren🐦🕐 2022年1月26日 (三) 05:35 (UTC)
- 首先SPI不是存档的地方,这是不同的程序。然后应该说VIP是报告破坏的地方,那报告内容的主体应该是写明破坏事实,能让管理员判定符合WP:VOA或不需警告就能直接进行封锁,在SPI成立之后,如果还是硬要把傀儡提报到VIP,然后提报内容照旧不写清楚的话,那结果也会跟现在一样被管理员忽略而已。--Xiplus#Talk 2022年1月26日 (三) 06:48 (UTC)
- 同Xiplus,不同程序,SPI的傀儡提报与AIV提报破坏无直接关联,现在只是订明AIV不接受纯粹理由是“某某某傀儡”的提报,与SPI一般傀儡调查程序没有直接关联。--路西法人☆ 2022年1月26日 (三) 08:25 (UTC)
- 没有什么意见,只是好奇为什么转了。--Ghren🐦🕛 2022年1月27日 (四) 04:00 (UTC)
- @LuciferianThomas:也就是结果提了WP:VIP就不要再存档WP:SPI吗?--Ghren🐦🕐 2022年1月26日 (三) 05:35 (UTC)
- 没意见。--Ghren🐦🕐 2022年1月22日 (六) 17:01 (UTC)
- WP:SPI/P,已私下通知,还请@Xiplus、Ghrenghren君确认是否能解决你们的疑虑和问题。--路西法人☆ 2022年1月22日 (六) 16:26 (UTC)
- 发起SPI的资格呢?跟HAM一样是自动确认吗?--Xiplus#Talk 2022年1月23日 (日) 04:27 (UTC)
- 发起资格不变,但参与讨论就不限制自动确认。--路西法人☆ 2022年1月23日 (日) 05:38 (UTC)
- 就WP:SPI/P没有意见了,不过发起提报的格式还没确定。--Xiplus#Talk 2022年1月23日 (日) 07:11 (UTC)
- @讨论参与者
- 为避免出现双重提报,一般一望而知的傀儡提报至SPI,仅将涉及需要即时处理的破坏才提报至AIV。因为有些LTA现阶段在AIV的提报颇为频密,是否同意在SPI基本完全采用英维格式?(各调查案件均于子页面进行,例如Wikipedia:傀儡调查/案件/Xayahrainie43,提报格式也大约跟从英维,可参考en:Wikipedia:Sockpuppet investigations/Xayahrainie43)
- 此外,由于移动HAM涉及大量存档页面,是否同意不移动现有HAM并改为闲置,另立Wikipedia:傀儡调查?
:经询问数名用户意见后,有关SPI的问题如下:
- 以上。--路西法人☆ 2022年1月23日 (日) 07:50 (UTC)
- 不必新造页面,理当将维基百科:用户查核请求移动至维基百科:傀儡调查,并将元维基使用者查核请求页面重新导向至该处。查核请求存档目录可一并整合,但存档页面本身不必移动。—— Eric Liu 创造は生命(留言.留名.学生会) 2022年1月23日 (日) 09:59 (UTC)
- 英维设立SPI时也是把RfCU改为{{historical}}就是了(en:Wikipedia:Requests for CheckUser),个人认为没有必要移动该页面。--路西法人☆ 2022年1月23日 (日) 10:07 (UTC)
- HAM改为SPI并不仅仅是简单的页面改名,SPI页面上的说明文字并不承接HAM的文字,将两段历史分别放置有利于日后对程序演变的调查。--Xiplus#Talk 2022年1月23日 (日) 10:21 (UTC)
- 理解二位想法,对分立页面无异议。话说使用者查核请求页面可不可以解除保护了?—— Eric Liu 创造は生命(留言.留名.学生会) 2022年1月23日 (日) 11:38 (UTC)
- 不必新造页面,理当将维基百科:用户查核请求移动至维基百科:傀儡调查,并将元维基使用者查核请求页面重新导向至该处。查核请求存档目录可一并整合,但存档页面本身不必移动。—— Eric Liu 创造は生命(留言.留名.学生会) 2022年1月23日 (日) 09:59 (UTC)
- @讨论参与者
- (+)支持:增设立案调查机制,同时可保留原用户查核页面(闲置停用)。--Kriz Ju(留言) 2022年1月23日 (日) 14:07 (UTC)
- (+)支持:简单阅读了一下,我是觉得整个SPI和助理没啥问题。就...为了防止雪球滚不过去,就当这不是个评论/表态吧。—Regards, BureibuNeko 2022年1月25日 (二) 08:55 (UTC)
设调查助理一案公示结束,公示期间的异议全部已解决,通过。选拔程序后天才公示结束。--路西法人☆ 2022年1月27日 (四) 04:30 (UTC)
- SPI什么时候启用? ——魔琴 [ 留言 贡献 ] 2022年1月27日 (四) 04:34 (UTC)
- 等助理处理好即启用(29日公示结束,预留七日报名、七日公示)--路西法人☆ 2022年1月27日 (四) 05:17 (UTC)
公示期结束,所有异议已解决,通过。--路西法人☆ 2022年1月29日 (六) 04:18 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
快速用户查核请求通道
[编辑]另建议可参考en:WP:SPI设快速用户查核请求通道处理用户查核方针的本地方针,尤其为WP:CUP#3的RFIPBE查核,可每一两日转交一次。@Tigerzeng、Xiplus:这个应该帮到你们?--路西法人☆ 2022年1月13日 (四) 05:19 (UTC)
- 印象中无论是否有本地CU的时期,CUP#3都非常少执行,反倒是#1和#2相对更常执行(但三个以绝对数量来说都很少执行),不过确实这类请求与常规CU流程有所不同,应设立不同的流程。--Xiplus#Talk 2022年1月13日 (四) 05:38 (UTC)
- 其实也算是不同的流程,en:WP:SPI也是分开§ Quick CheckUser requests章节处理这类型的查核请求。既然近期出现关于RFIPBE的问题,那绝对可以在这里附加一个方案协助管理员合理处理RFIPBE。--路西法人☆ 2022年1月13日 (四) 05:52 (UTC)
- 如果查核纪录要像enwiki按帐号分页而不是按时序分页的话,CUP#1-3不太适合这样的申请格式。--Xiplus#Talk 2022年1月13日 (四) 06:13 (UTC)
- enwiki的Quick CheckUser requests是在主页进行,不像普通用户调查一样在分页进行。基本上本地化的理想格式如下:
- h2 - 用户傀儡调查(按主帐号存档)
- h3 - 请求1
- h3 - 请求2
- h2 - 快速用户查核请求通道(按日期存档)
- CUP#1-3请求
- h2 - 用户傀儡调查(按主帐号存档)
- 以上,不知有否解答您的问题。--路西法人☆ 2022年1月13日 (四) 07:13 (UTC)
- 所以确定按主帐号存档?虽然我也觉得这样挺好的,相关的资料本来就应该放一起。不过enwiki是直接建子页面并使用状态表格,没有嵌入包含。--Xiplus#Talk 2022年1月13日 (四) 07:50 (UTC)
- 现在案子还不多,可以在主页请求,然后由bot存档至主帐号存档页,运作类似RFBA,但不用嵌入包含,直接像一般讨论一样存档即可。未来有需要的时候可以把请求页分拆回各自的子页面里面。--路西法人☆ 2022年1月13日 (四) 09:25 (UTC)
- 好啊,不过还是不同管理员尺度不一样的问题。我很乐意通过CU,而不是仅仅用户自述,来判断要不要授权。但是用户自述的封禁信息是否是必要的,在管理员中间都不一致,更何况走一趟CU还把整个过程拉长了。不过先把CU这一头的机制疏通了挺好的。
- 所以大致来说打算是,两种类别的活跃请求放在同一个页面上;普通傀儡调查请求结束会按账户分页存档,CUP 1-3 的按月份分页存档是吗?--Tiger(留言) 2022年1月13日 (四) 14:41 (UTC)
- 不过平均每周有32件IPBE的授权,量也不算少。--Xiplus#Talk 2022年1月13日 (四) 15:20 (UTC)
- @Tigerzeng:是的,您的理解没有错。@Xiplus:32宗还好,一周就一般用户查核页可以上20宗,这个不用查sleeper比一般用户查核应该快完成,纯粹是检查是否与用户描述的IP封锁相符而已。--路西法人☆ 2022年1月13日 (四) 18:33 (UTC)
- 多不多不是你说的算,是查核员能不能处理得过来。--Xiplus#Talk 2022年1月14日 (五) 02:26 (UTC)
- 见下,今年内应该CU权回归本地,期望到时候有两至三个活跃维基人当选查核员改善查核效率吧。--路西法人☆ 2022年1月14日 (五) 03:17 (UTC)
- (节删)--夏雪若(留言) 2022年1月14日 (五) 15:31 (UTC)
- CU工作太复杂繁重,海量的IPBE授权就已经让管理员负担很重,恐怕CU员不能处理这么多。而如果CU权不回归本地,那么元维基方针可能不允许这样的查核,监管员也处理不了这么多请求。桐生ここ★[讨论] 2022年1月18日 (二) 05:06 (UTC)
- “那[么]元维基方针可能不允许这样的查核”方针不容许倒是不会,但负担会不会太重我就问问监管员吧。--路西法人☆ 2022年1月20日 (四) 12:31 (UTC)
- 话说,管理员不应该天然的是调查助理么?--百無一用是書生 (☎) 2022年2月4日 (五) 08:01 (UTC)
- 一方面:是,管理员固然有调查傀儡的工作;但另一方面:不是,无论本地也好,参考的英维也好,不(很)是(小)所(部)有(分)管理员都熟悉傀儡相关的事务,故平衡以上,本地调查助理管理员也可以成为调查助理(不过好像比较少管理员会去做调查的部分),但不预设为傀儡助理列表成员。--路西法人☆ 2022年2月4日 (五) 08:09 (UTC)
- 话说,管理员不应该天然的是调查助理么?--百無一用是書生 (☎) 2022年2月4日 (五) 08:01 (UTC)
- “那[么]元维基方针可能不允许这样的查核”方针不容许倒是不会,但负担会不会太重我就问问监管员吧。--路西法人☆ 2022年1月20日 (四) 12:31 (UTC)
- 见下,今年内应该CU权回归本地,期望到时候有两至三个活跃维基人当选查核员改善查核效率吧。--路西法人☆ 2022年1月14日 (五) 03:17 (UTC)
- 多不多不是你说的算,是查核员能不能处理得过来。--Xiplus#Talk 2022年1月14日 (五) 02:26 (UTC)
- 所以确定按主帐号存档?虽然我也觉得这样挺好的,相关的资料本来就应该放一起。不过enwiki是直接建子页面并使用状态表格,没有嵌入包含。--Xiplus#Talk 2022年1月13日 (四) 07:50 (UTC)
- enwiki的Quick CheckUser requests是在主页进行,不像普通用户调查一样在分页进行。基本上本地化的理想格式如下:
- 如果查核纪录要像enwiki按帐号分页而不是按时序分页的话,CUP#1-3不太适合这样的申请格式。--Xiplus#Talk 2022年1月13日 (四) 06:13 (UTC)
- 其实也算是不同的流程,en:WP:SPI也是分开§ Quick CheckUser requests章节处理这类型的查核请求。既然近期出现关于RFIPBE的问题,那绝对可以在这里附加一个方案协助管理员合理处理RFIPBE。--路西法人☆ 2022年1月13日 (四) 05:52 (UTC)