维基百科讨论:IP封锁豁免权授予者

IPBE授予

本主题或以下段落文字，移动自WP:VPP。

已解决

社群讨论决议予以试行。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月22日 (四) 16:41 (UTC)[回复]

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

于Phabricator查看
编号T357991的工单
状态：已解决

于Phabricator查看
编号T358011的工单
状态：已解决

先前讨论

在意向调查中社群认为有必要建立IPBE授予员，所以现在开启进一步讨论。

由于本人不甚活跃，有意向的人可以主持讨论，以便讨论快速进行。--落花有意12138 2024年1月7日 (日) 04:26 (UTC)[回复]

@Ghren、桐生ここ、Dewadipper、0xDeadbeef、Hehua、Borschts、Steven_Sun、CopperSulfate、Newbamboo、ATannedBurger、SunAfterRain、Stang、虹色分子：参与意向调查投票的人。@桐生ここ、Yichen_Ding、ASid、Hoben7599：参与先前讨论的人。--落花有意12138 2024年1月7日 (日) 05:24 (UTC)[回复]

是否设立IPBE授予员

尽管意向调查中通过了授予员，但是其他提案仍有讨论价值，我注意到的提案有：Stang的专门系统案、SunAfterRian自动授予案。这里专门分区讨论——落花有意12138 2024年1月7日 (日) 04:37 (UTC)[回复]

UTRS正在加入对多个计划的支持，也许可以和他们沟通一下。--及时雨 ^留言 2024年1月7日 (日) 05:46 (UTC)[回复]

自动授权可以参考往期讨论 ——魔琴 [ 留言贡献新手2023计划 ] 2024年1月7日 (日) 06:01 (UTC)[回复]

我还是觉得应该先考虑从加速申请做起（现在都要直接透过电邮着实麻烦的），真的用尽手段再考虑新设权限。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月7日 (日) 07:47 (UTC)[回复]

@Ericliu1912：您作为管理员，或者你可以试一试处理，觉得用电邮处理有什么不便呢？也方便大家改进，谢谢。--Ghren 🐦🕐 2024年1月8日 (一) 17:13 (UTC)[回复]

邮箱邮件太多，导致我很早以前就退订unblock-zh了。希望有邮件以外系统能够用以处理权限审核。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月9日 (二) 04:33 (UTC)[回复]

我认为应该先试实行ipbe授予员，至少要先处理完积压看看效果。--在下荷花，请多指教（欢迎签到） 2024年1月7日 (日) 12:15 (UTC)[回复]

(＋)支持设立。--🎋竹生🎍 2024年1月10日 (三) 11:10 (UTC)[回复]

(！)意见实际上个人觉得与管理员人手不足有关。若速删页面数量太多，日后是否也有需要设立删除员？都是一个老生常谈的问题。归根结底，个人认为长远还是要解决人手不足问题-千村狐兔（留言） 2024年1月11日 (四) 15:43 (UTC)[回复]

基本上反对自动授权，这无法防范在中国大陆的破坏者利用此渠道大量建立傀儡。--桐生ここ★[讨论] 2024年1月13日 (六) 04:32 (UTC)[回复]

(＋)支持可以先试行一段时间，看看效果--Xiumuzidiao|本是青灯不归客，却因浊酒恋红尘※【留言】 2024年1月22日 (一) 01:32 (UTC)[回复]

(！)意见：似乎最近IPBE申请者变少，是否有必要设立授予员还需要再观察一个月。可能以前很多申请者都是看到IP封禁就要申请IPBE，实际上并没有编辑需求。--桐生ここ★[讨论] 2024年1月22日 (一) 14:38 (UTC)[回复]

(－)反对：观察也应该先设立再观察，不设立再观察也没有意义。--在下荷花，请多指教（欢迎签到） 2024年1月23日 (二) 03:26 (UTC)[回复]

那么IPBE授予者应该尽快设立，先试试看。--桐生ここ★[讨论] 2024年1月25日 (四) 04:12 (UTC)[回复]

是的。--在下荷花，请多指教（欢迎签到） 2024年1月25日 (四) 04:18 (UTC)[回复]

(＋)强烈支持。我曾经有过这个想法，但因为现实太忙以及找不到和我意见相同的人而作罢。那段时间在wikipedia-zh等群，经常有人提出类似“IPBE怎么申请”“什么时候通过”“你的过了没有”“我要催一催”“这也太慢了”的问题与求助。我认为选取一部分值得信赖的用户，授予单一的IPBE授予权限来协助管理员，这样更高效一些。——范博_{📧·🎤·✍🏽}^🇨🇳 2024年2月5日 (一) 15:13 (UTC)[回复]

是否需要在授予权限前识别LTA

这一问题是本案的争议焦点之一。Tiger指出这样发现的LTA很少，同时先前讨论中也提出是否需要授予者负责审查被授予者的破坏的问题。——落花有意12138 2024年1月7日 (日) 04:37 (UTC)[回复]

虽然授予权限前识别LTA有些困难，但我认为至少应该避免用户名显而易见的LTA，已知的曾被LTA使用的email。--桐生ここ★[讨论] 2024年1月7日 (日) 07:00 (UTC)[回复]

需要识别，但是不需要严格识别，其他同上。--在下荷花，请多指教（欢迎签到） 2024年1月7日 (日) 12:16 (UTC)[回复]

我认为可以作简单识别。但出事了不要怪他们。授予者本身得到的资讯根本不多。--Ghren 🐦🕕 2024年1月8日 (一) 10:11 (UTC)[回复]

相信大部分老手都能识别几个活跃的LTA，即使有LTA试图利用IPBE，授予员和管理员也完全有应变的空间。--🎋竹生🎍 2024年1月10日 (三) 11:13 (UTC)[回复]

隐私关切

这一问题是本案的争议焦点之一。具体表现为是否需要处理者签订协议等——落花有意12138 2024年1月7日 (日) 06:06 (UTC)[回复]

处理者需要签署非公开资讯协议这一点我一向支持，但实际效用存疑。--Benho7599 | Talk 2024年1月7日 (日) 06:38 (UTC)[回复]

如果IPBE授予员需要签署协议，那么可以处理IPBE的管理员也应该签署。--桐生ここ★[讨论] 2024年1月7日 (日) 06:55 (UTC)[回复]

事实上，即使是现在在处理的管理员也应该签署。我仍然认为应优先想办法恢复查核员，然后由查核员处理。——暁月凛奈 (留言) 2024年1月7日 (日) 07:59 (UTC)[回复]

感觉不是特别需要--Xiumuzidiao|本是青灯不归客，却因浊酒恋红尘※【留言】 2024年1月22日 (一) 01:36 (UTC)[回复]

不需要，因为管理员也不需要，而且这样会导致居住在中国大陆的人无法担任ipbe授予员（如果管理员也需要会导致更严重的后果）。--在下荷花，请多指教（欢迎签到） 2024年1月7日 (日) 12:13 (UTC)[回复]

同荷花。--🎋竹生🎍 2024年1月10日 (三) 11:15 (UTC)[回复]

事实上，我也觉得处理邮件申请的IPBE最好还是要有保密协议，毕竟牵涉到申请者的电邮地址，以及可能更多的个人讯息。我基本不碰这块就是一来嫌麻烦太花时间，二来不太愿意让很多陌生人知道我的电邮（特别是这几年的互联网环境）--百無一用是書生 (☎) 2024年1月10日 (三) 12:30 (UTC)[回复]

保密协议能不能用特殊的，毕竟中国大陆人士没法签NDA？如果处理者怕别人知道常用电邮的话，能不能允许用小号申请flag？ ——魔琴 [ 留言贡献新手2023计划 ] 2024年1月10日 (三) 14:03 (UTC)[回复]

我建议是用专用的email绑定维基账号，申请一个email不是很困难，WP:ANON。--桐生ここ★[讨论] 2024年1月10日 (三) 16:28 (UTC)[回复]

麻烦。 ——魔琴 [ 留言贡献新手2023计划 ] 2024年1月12日 (五) 06:52 (UTC)[回复]

应改用类似VRTS的系统处理，那么处理者的电邮就完全不会公开了。--路西法人 2024年1月10日 (三) 23:41 (UTC)[回复]

支持。——暁月凛奈 (留言) 2024年1月11日 (四) 03:03 (UTC)[回复]

如果是处理一般性的邮件封禁申诉，管理员往往也会需要知道IP地址，顺带也会知道邮箱。按这个说法，如果不签NDA，其实是连这部分的申诉也不能处理了。同时涉及IP地址的封禁申诉也不能放在讨论页。这部分我建议慎重考虑，这个逻辑会连带改变太多。--Tiger（留言） 2024年1月10日 (三) 23:22 (UTC)[回复]

啊，我说的email问题，只是我个人的问题，可能并不适用于其他人。另外，出于一些个人理念，我也不会用专门的email--百無一用是書生 (☎) 2024年1月11日 (四) 02:57 (UTC)[回复]

支持使用UTRS系统，以避免记录申请人的Email。此外由于申请表单可能会包含隐私信息，是否需要定期销毁相关数据？--Steven Sun（留言） 2024年1月12日 (五) 03:22 (UTC)[回复]

Email是防范滥用的一种方法，比方说一个Email申请很多账号是不正常的。也能证明你是一个真实用户，因为现在申请Email虽然也不困难，但一般需要手机号验证。如果不提供Email增加申请人可信度，随便填写表单就可以获得IPBE，封禁代理IP有何意义？--桐生ここ★[讨论] 2024年1月12日 (五) 20:29 (UTC)[回复]

Email什么时候“一般需要手机号验证”了？——暁月凛奈 (留言) 2024年1月13日 (六) 08:46 (UTC)[回复]

中国大陆的Email全部需要手机号验证
Gmail等基于风控至少一半需要手机号验证
付费Email可能不需要验证但注册成本更高
自建Email不需要验证但注册成本更高
即便不需要手机验证的Email也有自己的风控措施，不可能允许大量注册

--桐生ここ★[讨论] 2024年1月13日 (六) 09:16 (UTC)[回复]

提供email会提高要求，但并不很高。有的邮件服务提供者并不要求手机号，要达到您说的程度需采取白名单。--落花有意12138 2024年1月13日 (六) 15:18 (UTC)[回复]

早前个人询问基金会，当管理员处理解封和账号建立请求时接触 IP 地址及其他个资需否签署 NDA 时，基金会的回复为必须签署 NDA（原文见下）。

Some wiki sysops and also non-sysop users may access users' IP information or other PII information when processing requests for unblocking, account creation, etc. Is NDA required for these users? Or do they also need to meet other requirements?

All must sign NDAs. Legal department manages these but Trust and Safety operates them.

现时 enwiki 处理账号创建相关请求（包括受段封和公共 IP 影响而需协助创建账号）时需经过 Request an account 流程，负责处理者皆需签署 NDA。至于处理开放代理相关 IPBE 的请求，则由签署 NDA 的用户查核员负责。

无可否认，正如 Tigerzeng 君所言“这个逻辑会连带改变太多”。然而，个人认为依照目前 enwiki 的做法即可，无需绝对一刀切（比如就个人理解，enwiki 未有禁止 IP 地址的封禁申诉不能放在讨论页上）。假设 enwiki 的做法存在问题，想必早就被基金会更正。

考虑到 IPBE 积压情况甚为严重，现阶段可先处理 IPBE 授予员的隐私顾虑，即是要求处理 IPBE 的管理员及非管理员需签署 NDA。而其他涉及 IP 地址的封禁请求应如何处理，可容后再议。谢谢。--SCP-0000（留言） 2024年2月4日 (日) 13:29 (UTC)[回复]

基本同意。现在先落闸（签署NDA），之后也可以按著这个逻辑处理。--Benho7599 | Talk | 热烈庆贺恶法23条即将杀到香港 2024年2月4日 (日) 13:57 (UTC)[回复]

难受。--在下荷花，请多指教（欢迎签到） 2024年2月4日 (日) 14:44 (UTC)[回复]

ipbe申请需要提供的ip地址一般为开放代理地址，接触这一信息理应不涉及隐私，NDA真的需要吗？--在下荷花，请多指教（欢迎签到） 2024年2月4日 (日) 14:48 (UTC)[回复]

即使隐藏了真实 IP 地址，开放代理地址仍属于 “IP 地址”。而全域方针（如隐私政策、非公开资料存取政策）以至 enwiki 的方针指引中，也没有开放代理“不涉及隐私”以至“不属于个资”这说法。谢谢。--SCP-0000（留言） 2024年2月4日 (日) 15:08 (UTC)[回复]

开放代理地址亦会公开于封禁日志之中，可否以提供封禁id或元维基之封禁日志代以提供ip地址？--在下荷花，请多指教（欢迎签到） 2024年2月4日 (日) 15:12 (UTC)[回复]

只是提供 IP 段和具体 IP 地址的分别，本质上也是“IP地址”。谢谢。--SCP-0000（留言） 2024年2月4日 (日) 15:22 (UTC)[回复]

那能申请IPBE授予者的人就更少了 (--~~S i d~~ 2024年2月4日 (日) 15:04 (UTC)[回复]

那这个IPBE授予者权限是否还有必要存在？能申请权限的人几乎很少。--桐生ここ★[讨论] 2024年2月7日 (三) 06:18 (UTC)[回复]

显然有。尤其目前以SCP-2000所提供WMF的要求下，理论上没签NDA的管理员也不能处理IPBE创建账户等可以同时得知用户账号及IP地址的工作，而就算RFA能选上几个填补此工作仍是严重人手不足。由此，我觉得绝对有需要继续推行，但仍需循WMF要求所有IPBE授予者都需签署NDA。因为特定地区人士不能做而整盘不做乃是最不具建设性的做法。--路西法人 2024年2月7日 (三) 06:32 (UTC)[回复]

如果不设立 IPBE 授予者，那么基于基金会的要求下，只有少数签署 NDA 的管理员才能处理 IPBE 请求。除非社群认为违反基金会的要求并没有问题，而继续允许未有签署 NDA 的管理员处理。谢谢。--SCP-0000（留言） 2024年2月7日 (三) 06:35 (UTC)[回复]

如果处理者不接触IP地址只接触封禁ID需要签署NDA吗？如果基金会的确这样要求，那么现行管理员处理IPBE的流程也需要调整了。--桐生ここ★[讨论] 2024年2月7日 (三) 10:01 (UTC)[回复]

也就是如果有封禁ID发送邮件到IPBE授予者邮件列表，如果提供IP地址发送到签署了NDA的管理员邮件列表。--桐生ここ★[讨论] 2024年2月7日 (三) 10:04 (UTC)[回复]

正如个人上述所言，只是提供 IP 段和具体 IP 地址的分别，本质上也是“IP地址”。谢谢。--SCP-0000（留言） 2024年2月7日 (三) 11:06 (UTC)[回复]

坏。这样只能等专门系统了。--落花有意12138 2024年2月6日 (二) 15:36 (UTC)[回复]

不知您提到的“专门系统”是指 UTRS 还是其他。但无论如何，只要管理员及 IPBE 授予员需要接触 IP 资讯，他们便必须签署 NDA，谢谢。--SCP-0000（留言） 2024年2月6日 (二) 17:46 (UTC)[回复]

那请问技术上能否设计一个系统，可以检查用户名可用性，并在后端验证提供的ip是否为封禁的代理，然后直接将结果而不是ip地址本身发送给ipbe授予员进行处理，这样就不会接触到ip地址了。--在下荷花，请多指教（欢迎签到） 2024年2月7日 (三) 09:14 (UTC)[回复]

技术上当然可行，问题在于自动检查仅能检查是否代理，但无法按经验人工辨认是否曾被破坏者滥用的代理段。--路西法人 2024年2月7日 (三) 09:25 (UTC)[回复]

可以考虑把公开的封禁日志也提供给授予员，以便分辨是代理封禁还是因破坏封禁，并且破坏问题似乎并不是很大，可以考虑仅授予短期ipbe看贡献等等替代方案，总比都需要NDA好（会导致很多人无法申请此权限，甚至部分现任管理员也会受影响，反倒会拖慢处理速度），谢谢。--在下荷花，请多指教（欢迎签到） 2024年2月7日 (三) 10:46 (UTC)[回复]

就个人来看，现在的选择有两个：其一，设立 IPBE 授予者，至少已签署 NDA 的非管理员也可以协助处理；其二，不设立，如果社群遵循基金会的要求，那可预见只有少数签署 NDA 的管理员可处理。

至于公开的封锁日志，个人上述已指出这与提供 IP 地址无异。谢谢。--SCP-0000（留言） 2024年2月7日 (三) 11:32 (UTC)[回复]

我指的并不是把封禁日志链接提供给授予员，而是将封禁日志中的封禁理由截取提供给授予员，该理由理应不会出现ip本身。--在下荷花，请多指教（欢迎签到） 2024年2月7日 (三) 11:37 (UTC)[回复]

问题出在代理段通常不会因被滥用而被重新封锁，基本上是没什么意义的，因为不会因此而获得代理段是否曾被用于破坏的情报；只有授予员本身能存取IP地址才能通过比对而得知代理段是否曾被用于破坏。--路西法人 2024年2月7日 (三) 11:54 (UTC)[回复]

不一定有明显必要性，比起NDA来说反破坏需求可能并没有那么大，并且ipbe授予这里正如上方大猫君所说并没有那么大的破坏问题。

我想可以试试看。--在下荷花，请多指教（欢迎签到） 2024年2月7日 (三) 12:04 (UTC)[回复]

除了开发人员需要签署 NDA 外（考虑到他们或需接触 IP 资讯），理论上应该不用签署。谢谢。--SCP-0000（留言） 2024年2月7日 (三) 09:36 (UTC)[回复]

这和先前留言提出的差不多，只不过开发需要时间，还不知道有没有人开发，只能麻烦申请人们再等一等了，唉。

@SCP-2000：那边没有这个功能，新开发的系统应该会考虑到这一点。--落花有意12138 2024年2月8日 (四) 16:41 (UTC)[回复]

如果要等待开发，倒不如在没有开发新系统的情况下，先行开放申请授予员身份，并先用着现在已存在的系统去审批IPBE，有助在等待开发的同时协助处理积压及不能签NDA的管理员不能再处理IPBE申请的空缺。--路西法人 2024年2月8日 (四) 16:55 (UTC)[回复]

好意见，我之前也是这么想的。只不过我去meta:Access_to_nonpublic_personal_data_policy/Noticeboard数了一数，只认出来5个本地活跃的：Stang，悔晚斋，SCP-2000，1233，ATannedBurger

不知道有没有漏的，我打算挨个问问有没有意愿处理，都没有就不必设立了。--落花有意12138 2024年2月8日 (四) 17:08 (UTC)[回复]

当您连正在跟您说话的人（我）在名单上都没看到，就不如不要觉得自己认识得够多人了。--路西法人 2024年2月8日 (四) 17:25 (UTC)[回复]

很抱歉没认出来，这次是代码筛的，应该不会错了。--落花有意12138 2024年2月9日 (五) 05:00 (UTC)[回复]

我是觉得符合条件的这么少真是没有必要设立了，这几位大多是有管理员资质的，不如直接选管理员了。--桐生ここ★[讨论] 2024年2月8日 (四) 17:26 (UTC)[回复]

您也漏算我了...--~~S i d~~ 2024年2月9日 (五) 02:51 (UTC)[回复]

AINH也是漏算@AINH：ping一下--~~S i d~~ 2024年2月9日 (五) 02:53 (UTC)[回复]

Cookai1205一样漏算@Cookai1205：ping一下--~~S i d~~ 2024年2月9日 (五) 03:00 (UTC)[回复]

没有什么处理IPBE申请的经验，但如果真的缺人我可以帮忙-某人 ✉ 2024年2月9日 (五) 03:02 (UTC)[回复]

@1233、AINH、ASid、ATannedBurger、Billytanghh、Borschts、Hamish、Ladsgroup、Lemonaka、LuciferianThomas、SCP-2000、Superpes15、Taiwania Justo：很抱歉打扰各位，现在本地IPBE申请积压严重，根据本讨论即将试行设立IPBE授予员。各位是本地签署NDA的延伸确认用户，符合申请该权限的硬性条件。请问各位是否有意处理IPBE申请。--落花有意12138 2024年2月9日 (五) 04:56 (UTC)[回复]

可以帮忙。--Borschts^™^{欢迎外带一碗罗宋汤} 2024年2月9日 (五) 04:59 (UTC)[回复]

……Superpes15、Lemonaka、Ladsgroup都不是本地用户，甚至不是zh-3以上，你ping他们干嘛？你真的消停一下好吗？--路西法人 2024年2月9日 (五) 04:59 (UTC)[回复]

另，我和SCP-2000、Borschts都是监管员助理，IPBE授予权本身就对我们作为监管员助理的工作有用途，我们仨是必然会申请的。--路西法人 2024年2月9日 (五) 05:02 (UTC)[回复]

@1997kB、Courcelles、Céréales Killer、Martin Urbanec、Minorax、Sotiale、Stang、Taketa、Waihorace、YOWOT868、だ＊ぜ、悔晚斋：请看上面的消息。--落花有意12138 2024年2月9日 (五) 05:06 (UTC)[回复]

您又ping了六个非本地用户。请停止好吗？--路西法人 2024年2月9日 (五) 05:19 (UTC)[回复]

有几位是监管员，中文可能也就zh-1。--桐生ここ★[讨论] 2024年2月9日 (五) 05:20 (UTC)[回复]

I do not read Chinese, sorry.--Céréales Killer（留言） 2024年2月9日 (五) 08:38 (UTC)[回复]

可协助，但此与申诉专员之职责存在些许利益冲突，望周知。另，请勿如此ping有签署NDA之用户，此举甚为滋扰。--だ☆ぜ (Dasze) 2024年2月9日 (五) 10:54 (UTC)[回复]

很久没见，近年专注维基新闻项目，对本地长期破坏者未必太认识。如社群有确切需要，请再联络。--HW（讨论贡献） 2024年2月10日 (六) 14:05 (UTC)[回复]

可--

\int

（☎）dt 2024年2月9日 (五) 05:36 (UTC)[回复]

可。--SCP-0000（留言） 2024年2月9日 (五) 06:12 (UTC)[回复]

可以帮忙，我在学习中文。
“新年好，龙年行大运。” -‎Lemonaka‎ 2024年2月9日 (五) 07:46 (UTC)[回复]

可-某人 ✉ 2024年2月9日 (五) 08:26 (UTC)[回复]

其实您大可直接去他们的讨论页询问的？另外建议复查一下，确定是本地使用者。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月9日 (五) 15:42 (UTC)[回复]

未复查是否会说汉语是我欠考虑了，下次通知多位用户时会事先商量。抱歉。--落花有意12138 2024年2月12日 (一) 05:42 (UTC)[回复]

具体提案

以下是先前讨论中的最后一版提案

IPBE授予者及新账号建立员是一群志愿者，通过邮件列表<待议lists.wikimedia.org>处理因政府网络限制（如身在中国大陆受防火长城限制）而仅能通过开放代理编辑维基百科的用户提出的IPBE和新账号申请。
权限包括：

添加用户组：IP封禁豁免者（用于处理IPBE申请）

不受速率限制影响（用于处理新账号申请）

移除自己账号的用户组：IPBE授予者及新账号建立员

此用户组只能处理称因政府网络限制（如身在中国大陆受防火长城限制）而仅能通过开放代理编辑维基百科的用户的申请，不能处理其他原因的IPBE申请。
此用户组不能为自己建立具有IPBE权限的新账号，或授予IPBE给自己的其他账号。
（部分内容移动到下方专门讨论，于2024年1月21日 (日) 04:16 (UTC)）
权限的丧失：当IPBE授予者及新账号建立员有滥用权限的嫌疑（例如未收到申请而授予IPBE权限、使用权限帮助滥用傀儡）时，任何用户均可以前往Wikipedia:申请解除权限举报，由一名未参与举报的管理员核查后决定是否移除IPBE授予者及新账号建立员的权限。遇紧急情况时管理员可以暂时取消IPBE授予者及新账号建立员的权限，但必须同时立即上报至Wikipedia:申请解除权限，让其他管理员进行复核。
由于被IP封禁波及的新用户只有在被授予相应权限后才能表现是否为破坏者，所以该用户组不应该因为其授予权限的新用户破坏而剥夺该用户组。
当IPBE授予者及新账号建立员自身已因滥用傀儡而被封禁时，管理员应同时立即除权。
另外，当超过六个月没有任何编辑活动时，权限将会被移除。

— User:桐生ここ

（部分内容移动到下方专门讨论，于2024年1月21日 (日) 04:16 (UTC)） ——落花有意12138 2024年1月7日 (日) 06:06 (UTC)[回复]

有一个新的想法，IPBE授予员先授予临时权限一个月，一个月后有一些贡献记录申请人再申请永久权限，IPBE授予员或管理员根据贡献记录授予永久权限，或六个月临时权限，或举报到VIP。--桐生ここ★[讨论] 2024年1月7日 (日) 07:05 (UTC)[回复]

埃这个想法不错，我认为可以加入其中，原因是确实有很多人拿了权限后是没有什么活跃度，不过此做法可能会让一些人觉得说被差别对待，除此之外这个做法大致上没啥问题。--~~S i d~~ 2024年1月7日 (日) 14:27 (UTC)[回复]

同意此思路。但仍需要警惕在临时赋予期蛰伏、永久/长期赋予期爆发的“病情”。--

[{\text{H}}^{+}]

\ >

{\sqrt {K_{w}}}

2024年1月7日 (日) 17:59 (UTC)[回复]

关于授权的时限，可以参考en，先短期（半年或一年），如果贡献活跃的话（且对方继续申请的话），加长期（五年或更多）。好像没成功见过永久的，或者可以继续检查贡献量给永久或者酌情在第二次给永久。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月8日 (一) 01:14 (UTC)[回复]

不过英维是cu给权限，如果要说审慎赋权还是稍微短一点更好。--在下荷花，请多指教（欢迎签到） 2024年1月8日 (一) 01:34 (UTC)[回复]

下方新开章节讨论。——落花有意12138 2024年1月21日 (日) 04:16 (UTC)[回复]

看起来没什么问题，现在监管员助理就在做差不多的事情，只不过没有授予权。--Borschts^™^{欢迎外带一碗罗宋汤} 2024年1月9日 (二) 01:00 (UTC)[回复]

是不是可以考虑改成助理制，以协助确认申请者身份为主要目的，这样绝对可以加速管理员授权速度，也不用额外再设权限组。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月9日 (二) 04:35 (UTC)[回复]

那还是要管理员去处理，加上助理确认实际上也无法确认身份，最多把用户名提交上去？有点多此一举。--在下荷花，请多指教（欢迎签到） 2024年1月9日 (二) 09:11 (UTC)[回复]

授权可以由管理员批量处理，重点是要确认当事人条件，这才是真正需要人力的地方。要不然若只是单纯机械式授权，管理员自己就可以处理。我们需要厘清的是，现行确认程序究竟有没有要用到特定（管理）权限的地方？如果没有，那就大可不必新设权限组。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月9日 (二) 12:18 (UTC)[回复]

设组的原因是解决申请人多，而活跃且有空处理申请的管理员少的问题，因为本身也几乎不需要什么确认，如果设这个所谓的助理完全是多此一举。

上面的识别LTA意见的讨论也只是说，至少不要授权给用户名就是“XXX殴打越南人”、“原神XXXX”这种显而易见就是LTA的用户名，而不是要处理人去分析什么，因为邮件能提供的资料很少。我觉您实际处理几个申请案就能明白。--桐生ここ★[讨论] 2024年1月9日 (二) 13:27 (UTC)[回复]

举个例子，维基百科:权限申请/申请IP封禁豁免权一样没有人处理，说明不是确认条件问题，而是处理人少。--桐生ここ★[讨论] 2024年1月9日 (二) 14:21 (UTC)[回复]

现在处理邮件申请的管理员过少导致了严重积压，这就是设立该助理的很大的原因。--在下荷花，请多指教（欢迎签到） 2024年1月9日 (二) 13:43 (UTC)[回复]

我理解上面反对的原因是即使有助理，也并不能解决没有几个管理员处理的矛盾--百無一用是書生 (☎) 2024年1月10日 (三) 12:27 (UTC)[回复]

我觉得问题正正在于邮件申请本身无论是申请还是处理上也不容易，应该另辟渠道来处理，例如对于有账号的申请者应该加大推广使用封禁申诉来申请，甚至可以考虑设立Telegram申请通道之类的。这样才能解决本质上的积压问题。--A T 2024年1月10日 (三) 12:53 (UTC)[回复]

其实从使用的容易程度来说，现在邮件申请有固定的模板，而管理员这边也有不错的邮件工具来自动从邮件中提取用户名、IP地址等等信息，然后可以一键完成注册、授权。其他方式反而可能更麻烦，还需要手动复制粘贴用户名之类的操作。目前而言，积压的主要原因确实是人少。但长远而言，就算处理的人够多，问题是不论邮件还是telegram，申请者提供的信息总是千奇百怪，需要应付各种状况才是导致处理者疲劳的原因。--Tiger（留言） 2024年1月10日 (三) 23:12 (UTC)[回复]

所以我觉得建立专门的系统（像enwiki那种）只让申请者提供特定的信息，甚至做一些初步的检查（例如用户名能否注册），把不满足条件的申请直接挡出去，省掉反复的沟通，会是很好的办法。或者就是期望堆高处理者人数，来缓解单个处理者容易疲劳的问题，但恐怕没法保证。--Tiger（留言） 2024年1月10日 (三) 23:49 (UTC)[回复]

上面提到那个UTRS，感觉真的很有潜力。不知道本站什么时候有机会用到？另@Bluedeck您的二〇四九大计划呢（ —— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月19日 (五) 13:40 (UTC)[回复]

好久以来我都因为这个计划需要处理私密信息，要小心设置服务器，要制作易用的界面等等工作，比较追求完美，然后就总卡在一些莫名其妙无关痛痒的地方。我的兴趣又比较广泛，总搞一些别的不相关的项目。现在我的想法是，先撸出来一个“能用就行”的版本，然后再行改进，如果弄的实在太烂怨声载道，那我再打回重制也行。Bluedeck 2024年1月25日 (四) 09:06 (UTC)[回复]

维护者答复说现在没有支持授予IPBE和创建新账号。——落花有意12138 2024年1月27日 (六) 10:46 (UTC)[回复]

需要什么确认程序？查下下IP过去有没有破坏或者多次申请IPBE的情况？现在的管理员到底有没有进行这些确认工作也是问题。又@Tigerzeng来问问。--Ghren 🐦🕘 2024年1月10日 (三) 13:18 (UTC)[回复]

比方说一个IP上有破坏者，但有新用户声称他受到影响，从申请用户名上不认为是LTA，邮箱也是全新未申请过的，这种情况下，是给还是不给权限？从IP上根本没法判断，除非CU一下。--桐生ここ★[讨论] 2024年1月10日 (三) 16:32 (UTC)[回复]

上次谁ping我的时候已经说过啦，找过来看一下就行。关于桐生的问题，回答是实务上会给，本站的CU资源完全不够用在这种地方。--Tiger（留言） 2024年1月10日 (三) 22:57 (UTC)[回复]

突然想到，有没有必要加一个开启2FA的权限？就是那个oathauth-enable？--在下荷花，请多指教（欢迎签到） 2024年1月18日 (四) 07:12 (UTC)[回复]

要求申请者提供预计贡献内容

目前很多申请人获得权限之后编辑次数为0，可见不需要IPBE，因此，建议要求申请者提供预计贡献内容才会授权，包括：

想编辑哪个页面时遇到了IP封禁
对上述页面打算做什么编辑
感兴趣的编辑范围（比如数学、历史、铁路）

有助于减少不必要的申请者，减轻管理员工作量，让需要编辑的人更快取得权限。桐生ここ★[讨论] 2024年1月18日 (四) 19:56 (UTC)[回复]

赞同，对于没账号/编辑的可以要求，已编辑的则看现有贡献，可以修改Wikipedia:通过Unblock-zh申请IP封禁豁免指南#示例--及时雨 ^留言 2024年1月18日 (四) 20:04 (UTC)[回复]

这听上去增加申请和审核的复杂程度，且潜在降低的贡献率，未见必要。除非审批所需成本明显超过上述预先审批的成本。或者，作为可选的填写内容。--YF dyh000（留言） 2024年1月18日 (四) 20:29 (UTC)[回复]

同意可在表单中提供栏目填写。始终无法轻易判定破坏者，做多一个步骤就会让申请IPBE用作破坏更加麻烦，尤其他们必须写的像模像样又不能重复，IPBE授予者通常可以以此作类似编辑模式比对的情况辨认可能的破坏者。此外可考虑将不活跃除权调整一下，若申请后一个月内（或申请等候时间的同等长度后）未有任何编辑也视为不需要权限而除权，避免IPBE被发给破坏者做sleeper账号。--路西法人 2024年1月19日 (五) 01:48 (UTC)[回复]

我认为作为取代，可以先给首次申请的半年期限，如果半年内有编辑贡献（是否达到一定量可以强制量或自由裁量）的话，可以允许续期时给更长期限；如果没有的话，续期时可以咨询或者拒绝。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月19日 (五) 08:32 (UTC)[回复]

(※)注意，要求编辑一定量有违WP:维基百科不强迫任何人参与，建议保持当前授予要求。Python6345（留言） 2024年1月27日 (六) 14:34 (UTC)[回复]

不论任何站点，授予IP封锁豁免权的原因是容许受IP封锁影响的非破坏用户可以编辑，若不编辑者显然不需要该权限，拒绝是为合适做法。维基百科不强迫任何人参与，但可以拒绝不参与的人获取可被用作绕过封锁的特殊编辑权限，请勿偷换概念。--路西法人 2024年1月27日 (六) 14:53 (UTC)[回复]

(：)回应，抱歉产生歧义，在此澄清：我的意思是只要有实际贡献即可，而不要求编辑达到一定量。Python6345（留言） 2024年1月27日 (六) 23:24 (UTC)[回复]

我认为是如果你只编辑一次，那么可能管理员只授予六个月权限或更短；如果你达到延期确认而且编辑内容也没有什么问题，管理员就可以考虑长期授权；如果续权时你一次编辑记录也没有，你就需要向管理员说明你有编辑需求，否则就会拒绝。--桐生ここ★[讨论] 2024年1月28日 (日) 04:39 (UTC)[回复]

参考上方意见，认同非强制要求必须提供，而作为可选项。--桐生ここ★[讨论] 2024年1月22日 (一) 16:18 (UTC)[回复]

其他意见

另外，是否可以把IPBE不活跃除权期改为一年？感觉现在每天除权的可能比授权的还多... --及时雨 ^留言 2024年1月12日 (五) 09:17 (UTC)[回复]

不支持延长，一年的期限无法确认是否为本人，也可能导致有人在淘宝/闲鱼卖号。--桐生ここ★[讨论] 2024年1月13日 (六) 04:30 (UTC)[回复]

囧rz……真有卖号的话，半年/一年除权也关系不大？--及时雨 ^留言 2024年1月13日 (六) 04:37 (UTC)[回复]

半年其实不短。管理员也是半年。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月13日 (六) 17:32 (UTC)[回复]

管理员会有安全问题，IPBE只是编辑权限--及时雨 ^留言 2024年1月17日 (三) 21:05 (UTC)[回复]

基本上我不太认为整整六个月一笔编辑都不做能算得上可预期活跃就是了。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月19日 (五) 07:27 (UTC)[回复]

另建议可以开设IRC/Telegram/Discord unblock频道（名称待议，公开），处理封禁申诉/IPBE一系列问题等，主要解答疑问，应仍在频道中要求通过邮件发送IP等隐私信息 --及时雨 ^留言 2024年1月21日 (日) 10:00 (UTC)[回复]

可以考虑。--在下荷花，请多指教（欢迎签到） 2024年1月21日 (日) 10:49 (UTC)[回复]

我感觉这种基本没有风险的权限，出于便利考虑，应该时间长一点。除非有人观察到六个月以上不编辑然后回归的编者突然开始搞破坏？如果真要在淘宝咸鱼卖号，那我创建账号 -> ipbe -> 销售短时间内一气呵成不是也可以，这个六个月政策也拦不住你。Bluedeck 2024年1月25日 (四) 09:12 (UTC)[回复]

老号新号价值也不一样，已经注册半年的号只要后续达到编辑数就可以投票。IPBE不是基本没有风险，这是可以绕过CU的权限，在其他语言可能比巡查员还难拿。--桐生ここ★[讨论] 2024年1月25日 (四) 18:34 (UTC)[回复]

另外，回退员也基本没有风险，因为Twinkle基本上可以替代，是不是也应该延长到一年。--桐生ここ★[讨论] 2024年1月25日 (四) 18:36 (UTC)[回复]

授权时长限制补充案

User:桐生ここ提出：IPBE授予员先授予临时权限一个月，一个月后有一些贡献记录申请人再申请永久权限，IPBE授予员或管理员根据贡献记录授予永久权限，或六个月临时权限，或举报到VIP。

此开专门章节讨论。——落花有意12138 2024年1月21日 (日) 04:16 (UTC)[回复]

感觉没有太大意义，反而会影响ipbe持有者“回坑”意愿 ——魔琴 [ 留言贡献新手2023计划 ] 2024年1月28日 (日) 14:09 (UTC)[回复]

修订IPBE方针

现行条文

（略）

提议条文

使用匿名代理编辑开放代理服务器会隐藏用户真实IP地址，令反破坏侦测变得困难，故仅有符合以下条件之一的用户才会获授权使用匿名代理编辑维基百科：

可提供合理理据需要使用匿名代理的可信用户；或
因政府网络限制（如身在中国大陆受防火长城限制）而仅能通过匿名代理编辑维基百科的用户。

（略）

符合条件者第一次申请IP封禁豁免权可授予临时权限三个月，之后若再次申请，管理员可根据贡献记录授予六个月临时权限或长期权限。

说明：长期权限是永久权限的意思。桐生ここ★[讨论] 2024年1月22日 (一) 15:06 (UTC)[回复]

试行

由于现在积压愈发严重，为了解决这一问题，建议试行，具体方案如下：

与基金会沟通，技术上添加此用户组
上一步完成的七天后，开放权限申请

关于部分用户支持的专门系统案，我认为可能需要较长时间实现，不能解决眼前的问题。实行过后如果有可用的专门系统，可进一步讨论过渡到系统。——落花有意12138 2024年1月21日 (日) 04:16 (UTC)[回复]

所有权限

新开专门讨论。如果七日内没有异议，将通过的提案是：

添加用户组：IP封禁豁免者
不受速率限制影响（noratelimit）
移除自己账号的用户组：IPBE授予者及新账号建立员

以上。——落花有意12138 2024年1月21日 (日) 04:16 (UTC)[回复]

注意到User:Hehua提出添加oathauth-enable，我认为这与相关的作业并无关系，不支持添加。——落花有意12138 2024年1月21日 (日) 04:16 (UTC)[回复]

怎么没有关系，管理员附带这个权限就是为了更大程度保障安全，虽然这个权限可以自己去meta申请，但是由于授予ipbe也较为敏感，所以我建议加入这个权限，用来加强账户安全，谢谢。--在下荷花，请多指教（欢迎签到） 2024年1月21日 (日) 06:16 (UTC)[回复]

@Hehua：这并不是预期作业内容的必要权限。我认为试行期是用于验证运行可行性和解决积压的，并且应该精简提案内容，尽快通过。

此权限可以稍后另行讨论。--落花有意12138 2024年1月27日 (六) 10:26 (UTC)[回复]

Ok--在下荷花，请多指教（欢迎签到） 2024年1月27日 (六) 15:41 (UTC)[回复]

不需要同时设立两个权限。只要明定IP封锁豁免权授予者预设同时持有大量账号建立权即可。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月21日 (日) 04:34 (UTC)[回复]

@Ericliu1912：这个提案就是这个意思，不知道是哪里有歧义？--落花有意12138 2024年1月21日 (日) 04:52 (UTC)[回复]

不是持有两个权限组，是一个权限组即拥有上述权限。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月21日 (日) 05:22 (UTC)[回复]

@Ericliu1912：提案里的“IPBE授予者及新账号创建员”是一个权限组，或许是这有歧义？--落花有意12138 2024年1月21日 (日) 05:32 (UTC)[回复]

本来这个权限组的目的就是授予IP封锁豁免权，其他权限都是附带的。甚至我觉得IP封锁豁免也应该附带，不用兼任。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月21日 (日) 05:37 (UTC)[回复]

那么是要改名“IPBE授予者”？--落花有意12138 2024年1月21日 (日) 05:44 (UTC)[回复]

可以啊，这没问题，把账户创建者的权限放到这个里面，不用拆分。--在下荷花，请多指教（欢迎签到） 2024年1月21日 (日) 06:17 (UTC)[回复]

不然原本是打算叫做什么？—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月21日 (日) 14:00 (UTC)[回复]

“IPBE授予者及新账号创建员”--在下荷花，请多指教（欢迎签到） 2024年1月22日 (一) 00:18 (UTC)[回复]

建议正式定名为“IP封锁豁免权授予者”，平时行文则可简称为“IPBE授予者”。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月24日 (三) 05:33 (UTC)[回复]

同意。--在下荷花，请多指教（欢迎签到） 2024年1月24日 (三) 07:16 (UTC)[回复]

同意。--桐生ここ★[讨论] 2024年1月24日 (三) 17:50 (UTC)[回复]

建议英文名ipblock-exempt-granter，忘了谁提的了——落花有意12138 2024年1月27日 (六) 10:46 (UTC)[回复]

不同意附带IPBE。

首先两者的用途不同：IPBE用于编辑维基百科，偏向于编辑；而IPBE授予员用于授予IPBE，偏向于筛查志愿者。用途不同应该区分。

其次两者的门槛不同：IPBE授予员的要求显然应该比IPBE高，他们的获得途径是独立的。而且如果附带，投票者便会考虑是否应该拥有，因而干扰投票，降低通过率。

再者期限也不同：如果IPBE授予员自动到期除权，现在mw并不支持，也不值得支持自动添加IPBE，因而徒增管理需求。--落花有意12138 2024年1月27日 (六) 11:03 (UTC)[回复]

@Ericliu1912--落花有意12138 2024年1月27日 (六) 11:05 (UTC)[回复]

同意您的看法，不再坚持。确实，不需要IP封锁豁免权的人，不一定不能做授予者。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月29日 (一) 16:38 (UTC)[回复]

提案没有为授予员附带IPBE权限啊，“添加用户组”指的是拥有为其他用户添加IPBE用户组的权限。--XtexChooser（留言） 2024年1月27日 (六) 13:06 (UTC)[回复]

@XtexChooser：是eric liu提出要附带IPBE。--落花有意12138 2024年1月27日 (六) 13:10 (UTC)[回复]

同落花有意，不赞同附带IPBE。--桐生ここ★[讨论] 2024年1月29日 (一) 14:04 (UTC)[回复]

选举制度和申请条件

申请条件：
有意愿处理IPBE和新账号申请，了解相关方针指引，能够友善地对待他人

编辑数满1000次

最近一年内没有受到封禁（不合理封禁除外）

在过去三个月内平均每日的编辑次数多于一次

已成为巡查员、回退员或傀儡调查助理三个月以上

由于授予IPBE权限时应较为谨慎，所以他们应该能被社群信任妥善处理相关事务。此用户组在处理相关内容时会查看到用户的IP信息，授权时应注意用户是否可信。
权限的获取：
具投票权的用户可在Wikipedia:IPBE授予者及新账号建立员/申请提名满足上述条件的用户为IPBE授予者及新账号建立员。
提名发出后

管理员应该核对提名人和被提名人的资格，不合资格的关闭（其他用户也可关闭），合格的留言说明

用户可讨论，具投票权的用户可投票

投票进行三日后，管理员可用雪球法则关闭明显不受社群信任投票；进行7日后，如同意票数大于等于总票数的四分之三，管理员可以关闭投票并授权；进行14日后投票截止，管理员点票，符合以下条件的授权：

票数大于8票

同意票多于二分之一

弃权票少于三分之一

——落花有意12138 2024年1月21日 (日) 04:16 (UTC)[回复]

不同意“弃权票少于三分之一”，无意义，反而制造扰乱规则的空隙。--路西法人 2024年1月24日 (三) 06:00 (UTC)[回复]

可以去除。--落花有意12138 2024年1月27日 (六) 10:52 (UTC)[回复]

不同意“已成为巡查员、回退员或傀儡调查助理三个月以上”，因为根据上方讨论IPBE授予员并没有反破坏的义务。--落花有意12138 2024年1月27日 (六) 10:29 (UTC)[回复]

根据本地的活跃度和对相关事项的关注度，建议最低票数改为4票。

另外建议此投票在公告栏（Bulletin）公示以提高参与度。--落花有意12138 2024年1月27日 (六) 11:10 (UTC)[回复]

Wikipedia:IP封锁豁免权授予者我建立了这个页面，整合了大家的意见，您们看看行不行。

另外针对荷花君提到的

启用双重身份验证（oathauth-enable）

以及下方的邮件列表的使用，还有“已成为巡查员、回退员或傀儡调查助理三个月以上”这个条文，我建议拉出来讨论。把社群有共识的部分让其先通过，细项部分则是拉出来另外讨论，待确定了再加入即可。--~~S i d~~ 2024年1月31日 (三) 08:36 (UTC)[回复]

@ASid：感谢您的贡献。

我对缺漏的地方有补充，请您核对。

另外，我认为还有几点意见：

“泄露用户的隐私资料” -> “泄露用户的申请内容”。
“账号确认或疑似被盗用”这一点是各个权限组共有的要求，这里建议移除，另开讨论。
“当IPBE授予者超过六个月没有任何编辑活动”时应该会自动除权，不需要提报。

--落花有意12138 2024年1月31日 (三) 16:54 (UTC)[回复]

1.3.没问题，我直接更改了，第二点的话我是觉得说写清楚，如果遇到这种状况时有个条文依据会比较好，但您要如果认为没必要的话直接移除也行我没意见。--~~S i d~~ 2024年2月1日 (四) 16:32 (UTC)[回复]

正于个人上述所言，IPBE 授予员应签署 NDA。谢谢。--SCP-0000（留言） 2024年2月7日 (三) 04:38 (UTC)[回复]

（原来 ASid 的提案已经增加相关说明了，那没事了）--SCP-0000（留言） 2024年2月7日 (三) 05:04 (UTC)[回复]

邮件列表

提案使用[email protected]——落花有意12138 2024年1月21日 (日) 04:16 (UTC)[回复]

直接沿用unblock-zh就行了吧？—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月21日 (日) 05:38 (UTC)[回复]

那么IPBE授予员会看到其他类型的封禁申诉，包括应该由管理员处理的。--落花有意12138 2024年1月21日 (日) 05:46 (UTC)[回复]

那积压怎么办--在下荷花，请多指教（欢迎签到） 2024年1月21日 (日) 06:21 (UTC)[回复]

手动把现有没处理的邮件转发过去应该可以做得到。顺便用单独的邮件列表也方便管理员专注处理一般的封禁申诉，现在一般申诉也跟着存了不少没处理。但是这里有一个问题是封禁界面要怎么改。blockedproxy 和 rangeblock 应该要写不同的邮箱。--Tiger（留言） 2024年1月23日 (二) 13:59 (UTC)[回复]

好喔--在下荷花，请多指教（欢迎签到） 2024年1月24日 (三) 02:26 (UTC)[回复]

建议blockedproxy写ipbe-zh，rangeblock两个都写。——落花有意12138 2024年1月27日 (六) 10:46 (UTC)[回复]

其实是不是可以保留将解封申诉邮件一律寄到unblock-zh，然后由管理员分类去不同种类邮件列表（具体分类待议），由IPBE授予者协助审核；而管理员自己可以审核的，当然也可以自己直接审核掉。这样就不用烦心到底在哪里要给出哪一个邮件列表连结。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年1月27日 (六) 13:22 (UTC)[回复]

但是转发邮件可以回复原发件人吗？--落花有意12138 2024年1月27日 (六) 14:08 (UTC)[回复]

可以。--桐生ここ★[讨论] 2024年1月30日 (二) 04:03 (UTC)[回复]

因应 IPBE 申请处理者需要签署 NDA（原因见个人上方留言），故应分拆为 ipbe-zh@ 或其他邮箱，并交由已签署 NDA 的 IPBE 授予员以及管理员处理。

至于 Ericliu1912 提到的“一律寄到unblock-zh”之建议，由于并非所有 unblock-zh 的管理员皆签署 NDA，而未有签署者不应接触 IP 资讯等个资，因此相关做法并不可行。谢谢。--SCP-0000（留言） 2024年2月7日 (三) 04:48 (UTC)[回复]

可惜。那“unblock-ipbe-zh”如何（话说感觉个人比较在意的其实是名称欸XD）？—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月8日 (四) 17:09 (UTC)[回复]

这个名称顺眼。--Borschts^™^{欢迎外带一碗罗宋汤} 2024年2月9日 (五) 04:40 (UTC)[回复]

IPBE授予不涉及“解除封锁”，邮件列表带“unblock”会误导他人。直接“ipbe-zh”已经足够清晰。--路西法人 2024年2月9日 (五) 04:43 (UTC)[回复]

这倒确实，我的永久IPBE权限也不是由“解除封锁”而来的。San mo sa _{起视四境　而秦兵又至矣} 2024年2月9日 (五) 07:05 (UTC)[回复]

确实，那还是分开好了。--Borschts^™^{欢迎外带一碗罗宋汤} 2024年2月9日 (五) 07:12 (UTC)[回复]

算是有理。那便如此亦可。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月10日 (六) 14:35 (UTC)[回复]

暂定结论

考虑到已讨论一个多月，故依据上方讨论以及基金会的要求（仅有签署 NDA 者才可接触 IP 资讯），现暂定结论如下：

设立 IPBE 授予者。
将“WP:IP封锁豁免权授予者”定为方针。
设立名为“ipbe-zh”邮件列表专责处理 IPBE 相关请求，取代 unblock-zh 现时处理 IPBE 请求的职能。此邮件列表仅限已签署 NDA 者存取。
给予让申请者提供预计贡献内容之选项。

如无异议及疑问，将稍后公示，谢谢。--SCP-0000（留言） 2024年2月11日 (日) 14:49 (UTC)[回复]

cc 曾参与是次讨论的编者以及在 unblock-zh 处理 IPBE 请求的管理员。--SCP-0000（留言） 2024年2月11日 (日) 15:01 (UTC)[回复]

~~这个结果看起来自相矛盾：允许未签署NDA的管理员授予IPBE，但是要求IPBE授予员签署NDA。是否应该将IPBE授予从管理员权限中分离？~~暂时保留管理员授予IPBE权限，之后视试行效果再行讨论（留言编辑于2024年2月11日 (日) 16:45 (UTC)）Python6345（留言） 2024年2月11日 (日) 15:31 (UTC)[回复]

首先，授予 IPBE 本身并不需要 NDA，只有接触 IP 资讯才需要签署 NDA。

而设立 IPBE 授予者主要目的是处理 unblock-zh 内大量积压的 IPBE 请求，考虑到他们需接触 IP 资讯，要求他们签署 NDA 是理所当然。另外，不只是非管理员，管理员亦需签署才可存取“ipbe-zh”邮件列表。谢谢。--SCP-0000（留言） 2024年2月11日 (日) 15:43 (UTC)[回复]

不需要立即对管理员除权，新用户组试行期间暂时保留管理员的权限，甚至长期保留管理员的权限供少数案例（如授予合法傀儡），都可以接受。--YF dyh000（留言） 2024年2月11日 (日) 16:13 (UTC)[回复]

本提案只是不允许未有签署 NDA 的管理员存取“ipbe-zh”邮件列表以及 IP 资讯，而非移除管理员授予IPBE的权限。建议就此另开新讨论。谢谢。--SCP-0000（留言） 2024年2月11日 (日) 17:48 (UTC)[回复]

那Wikipedia:IP封锁豁免权授予者中的表述当前中文维基百科有0名IP封禁豁免权授予者，而63名管理员本身已具有同等的权限，故无须重复申请。

是否应该相应修改？--Steven Sun（留言） 2024年2月12日 (一) 03:52 (UTC)[回复]

技术上管理员已持有授予 IPBE 的权限，所以他们的确无需重复申请。邮件列表的存取要求，个人认为只需在相应邮件列表的页面（e.g. [1]）提及即可。

不知阁下认为应如何修改？谢谢。--SCP-0000（留言） 2024年2月12日 (一) 04:23 (UTC)[回复]

“本权限可查看用户隐私资料”，而管理员并不都签NDA。--YF dyh000（留言） 2024年2月12日 (一) 04:30 (UTC)[回复]

改了描述--~~S i d~~ 2024年2月12日 (一) 04:49 (UTC)[回复]

额外一提没有签NDA的管理员依然可以根据过往授权纪录，对在WP:RFR申请IPBE的用户或于讨论页使用{{unblock}}申请IPBE的用户，对这些用户授权。--~~S i d~~ 2024年2月12日 (一) 04:55 (UTC)[回复]

理解了。不需要修改了。邮件列表存取要求在其它位置提及即可。--Steven Sun（留言） 2024年2月12日 (一) 11:45 (UTC)[回复]

意见同SCP-2000。其实此权限之所以设立，乃是要分担管理员的授权责任，并不是取而代之。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月12日 (一) 15:23 (UTC)[回复]

LGTM--Borschts^™^{欢迎外带一碗罗宋汤} 2024年2月11日 (日) 17:50 (UTC)[回复]

我认为可以保留管理员给LIPE组授权的能力。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月12日 (一) 04:47 (UTC)[回复]

Tiger提到过封禁界面的提示语应该修改。另外ipbemail的指引也应该修改。

建议之前授予权限的人员简述处理IPBE申请的流程，供新授予员参考。--落花有意12138 2024年2月12日 (一) 05:08 (UTC)[回复]

这点可以透过有经验的管理员写一本“处理流程手册”来处理，写好了就放上维基共享。每个新授予员都需要看一看这手册，然后再让他们自己实际操作一下。--Benho7599 | Talk | 热烈庆贺恶法23条即将杀到香港 2024年2月12日 (一) 15:01 (UTC)[回复]

blockedproxy和rangeblock都是指向了ipbemail，所以直接修改ipbemail即可--落花有意12138 2024年2月13日 (二) 14:32 (UTC)[回复]

这不是公示内容的一部分。

我起草了一份修改，主要更改内容是unblock-zh -> ipbe-zh，管理员 -> 处理员，和两个告示。

另外建议修改{{Anonblock}}，去掉具体的邮箱。--落花有意12138 2024年2月14日 (三) 14:30 (UTC)[回复]

管理员不需要改成处理员吧，管理员技术上也还是可以授予权限的，规则上也没有限制管理员授予权限，唯一的限制是没有签署NDA的管理员不能存取ipbe-zh邮件列表，没有签署的管理员还是可以“根据过往授权纪录，对在WP:RFR申请IPBE的用户或于讨论页使用{{unblock}}申请IPBE的用户，对这些用户授权。”，这部分我上面的留言就有说明到，而且方针亦无限制授予者不能处理WP:RFR及讨论页unblcok申请IPBE的部分，我想社群也没有要限制的意思吧。

我认为把管理员改成处理人员，并在最上方注明“处理人员”指WP:管理员及WP:IPBE授予者即可。--~~S i d~~ 2024年2月16日 (五) 10:03 (UTC)[回复]

我更正一下我的意见，建议在上方注明“处理人员”指WP:管理员及WP:IPBE授予者。--~~S i d~~ 2024年2月16日 (五) 15:51 (UTC)[回复]

@ASid：这个页面叫做“通过Unblock-zh申请IP封禁豁免指南”，文中处理员应该只包含通过邮件列表处理申请的用户。

我认为“处理人员”和“处理员”没有什么区别，都可以。只是不必注明处理人员指的是那些人，因为这篇文章的目标读者是无法编辑维基百科的人，大概并不知道“管理员”，给出额外的信息可能迷惑。--落花有意12138 2024年2月17日 (六) 11:10 (UTC)[回复]

OK那依您的修订更改吧。--~~S i d~~ 2024年2月17日 (六) 14:52 (UTC)[回复]

流程不复杂，不用特地写文档。不论通过什么方式收到申请都是这样的步骤：

确认封禁事实（通过封禁界面显示的IP地址、封禁ID等）
检查申请人是否满足授权条件（即Wikipedia:IP封禁豁免中的说明）
检查是否可以用其他方式解决问题（比如只建立账户就可以绕过的软封禁）
确认总共需要做哪些操作（只需要建立账户，还是建立账户+授权，或是其他的）
执行操作
回信说明申请结果、执行了哪些操作、还需要对方做什么

我不确定这样能不能说清楚整个过程，如果有具体的问题可以再ping我。--Tiger（留言） 2024年2月18日 (日) 06:26 (UTC)[回复]

针对此版本及上方SCP-2000君提到的四点

公示7日，2024年2月20日 (二) 11:09 (UTC) 结束，。--~~S i d~~ 2024年2月13日 (二) 11:09 (UTC)[回复]

公示期间无有效反对意见宣告通过。--~~S i d~~ 2024年2月20日 (二) 14:11 (UTC)[回复]

创建新列表需要两个邮件列表管理员，请各位有意者留言--落花有意12138 2024年2月13日 (二) 14:43 (UTC)[回复]

个人认为应由管理员担任，@WhitePhosphorus、Xiplus：不知常处理 ipbe 请求的两位，以及其他管理员会否有意担任？谢谢。--SCP-0000（留言） 2024年2月14日 (三) 07:33 (UTC)[回复]

可。--Xiplus#Talk 2024年2月14日 (三) 09:09 (UTC)[回复]

如果白磷君未及回复，@Ericliu1912或@AT是否能协助担任邮件列表管理员？--路西法人 2024年2月16日 (五) 06:24 (UTC)[回复]

我对邮件列表不熟悉，还是由其他人来比较好。--A T 2024年2月16日 (五) 07:36 (UTC)[回复]

我可以兼任。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月16日 (五) 07:49 (UTC)[回复]

感谢提名，不过我活跃比较随机，管理邮件列表需要经常关注，所以我就不担任列表管理了。--砜中嘌呤的白磷_{萃取打谱} 2024年2月16日 (五) 21:46 (UTC)[回复]

如有需要，本人亦可兼任。-Peacearth（留言） 2024年2月20日 (二) 16:20 (UTC)[回复]

IPBEG已经部署。请有权限人员建立如下页面（感谢ASid整理）：

MediaWiki:Group-ipblock-exempt-grantor: IP封禁豁免权授予者, IP封锁豁免权授予者
MediaWiki:Group-ipblock-exempt-grantor-member: {{GENDER:$1|IP封禁豁免权授予者}}, {{GENDER:$1|IP封鎖豁免權授予者}}
MediaWiki:Grouppage-ipblock-exempt-grantor: Wikipedia:IP封锁豁免权授予者

--落花有意12138 2024年2月22日 (四) 06:11 (UTC)[回复]

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

IPBE授予者试行相关

由于先前讨论严重过长，此开启新讨论追踪试行事宜。--落花有意12138 2024年2月22日 (四) 06:18 (UTC)[回复]

根据ASid建议，改为在Wikipedia:权限申请/申请IP封锁豁免授予权提交申请。由于无人曾对此发表意见，且符合一贯做法，现根据雪球法则

公示3日。

这是对于修改方针的公示，期间如有申请者可直接提出申请，不受影响。——落花有意12138 2024年2月22日 (四) 06:44 (UTC)[回复]

页面被移动，修改连结。--Cookai饼块🍪_{（💬留言）} 2024年2月23日 (五) 14:53 (UTC)[回复]

邮件列表正式运作后，应该将WP:IPBEMAIL的内容修改为Special:PermanentLink/81026934。同时应该上公告板，特别应该通知互联群，防止给错建议。——落花有意12138 2024年2月22日 (四) 06:44 (UTC)[回复]

使用VRT系统

我认为IPBEG应趁早期运作前探讨是否适用VRT系统处理申请工单。理据如下：

不需在站外的个人邮件程式储存包含他人个资的邮件。
VRT系统有更专门的人去维护。
每个申请配备工单号，方便申请人查询自己申请进度。
内建罐头回复系统，操作并不困难。
可在站内写gadget，或写浏览器add on协助流线化处理工单：
VRTS容许可以设机器人自动将申请发上站内（也能让公开查看积压数字），并通过工具处理。
对内，积压数字一目了然（系统已配备）。
个人邮箱不会被炸。
不需向申请人公开个人邮箱。

关于自目前新设邮件列表转移至新系统：

两个系统的处理人都会是同样的用户，只要把指示改去新的电邮地址，然后旧的慢慢处理干净即可。
目前六位IPBEG仅有两位似乎还没进过VRT，启用VRT队列后其余四位及已经在VRT的管理员即可参与处理；
使用VRT也能确保参与处理的管理员符合申请邮件列表时被点明“必须有签署了ANPDP”的要求。

因不熟悉邮件列表的运作，原先没关注到邮件列表的问题，没有特地推动使用VRT，在邮件列表设好才提出这个提案，谨此致歉。--路西法人 2024年3月4日 (一) 15:48 (UTC)[回复]

通知其余IPBEG @ATannedBurger @AINH @ASid @SCP-2000 @Borschts @Dasze及活跃管理员 @WhitePhosphorus @Tigerzeng @Xiplus @Mys_721tx @Ericliu1912 @Peacearth @Kuon.Haku。--路西法人 2024年3月4日 (一) 15:48 (UTC)[回复]

因为目前可以继续使用当前邮件列表系统，故不需急着通过；但如果没异议，也会尽快申请并开始研究VRTS系统设机器人、辅助程序等，方便尽快过渡。请诸位表明意见，如果一周内无反对意见则直接开始申请了。--路西法人 2024年3月4日 (一) 15:48 (UTC)[回复]

也@Bluedeck，看看能不能有什么相关input--路西法人 2024年3月4日 (一) 16:16 (UTC)[回复]

也就是说现在ipbeg有ipbeg自己的邮件列表吗？Bluedeck 2024年3月5日 (二) 00:17 (UTC)[回复]

目前而言，IPBE相关申请陆续转到wikipedia-zh-ipbe

lists.wikimedia.org处理。--路西法人 2024年3月5日 (二) 01:19 (UTC)[回复]

第五点“可在站内写gadget，或写浏览器add on”，如果改用VRT系统的话，现有的User:Xiplus/unblock-zh-helper-gmail可能得要整个重写？不知道Xiplus或者其他人是否有意愿协助开发？-Peacearth（留言） 2024年3月6日 (三) 02:23 (UTC)[回复]

我会尝试写，尽可能在正式改用VRT前就配备好所有工具。目前的script只能给gmail用，对于我这种维基媒体不用gmail的人来说比较麻烦；反过来大家都用VRT时就能统一体验，确保大家都能使用到便利的script。--路西法人 2024年3月6日 (三) 03:17 (UTC)[回复]

感谢。-Peacearth（留言） 2024年3月7日 (四) 21:45 (UTC)[回复]

(＋)支持，尤其是工单号个人认为不只帮助申请人查询进度，对授予员来说也比较容易识别哪些请求需要尽快处理。若是申请人在站外询问也比较容易找到对应的case。--

\int

（☎）dt 2024年3月6日 (三) 05:54 (UTC)[回复]

支持，听起来有助于加快处理速度。另外，此系统部署在哪里？--落花有意12138 2024年3月10日 (日) 05:12 (UTC)[回复]

WP:VRT。--路西法人 2024年3月11日 (一) 02:22 (UTC)[回复]

添加mw:Extension:ContactPage辅助申请

于Phabricator查看
编号T359998的工单

提议安装mw:Extension:ContactPage，提供完整表单供用户向IPBEG发送公式化申请。--路西法人 2024年3月4日 (一) 15:53 (UTC)[回复]

先前讨论，可以照抄一下。之前主要的blocker就是NDA的问题，如果这个问题解决了那么非常不错 Stang^★ 2024年3月4日 (一) 16:20 (UTC)[回复]

可以有表单那对申请的用户会起到很大的帮助。--~~S i d~~ 2024年3月4日 (一) 16:23 (UTC)[回复]

感觉不错，英维整了一个较为复杂的页面 en:Special:Contact/arbcom-blockappeal--及时雨 ^留言 2024年3月4日 (一) 16:30 (UTC)[回复]

可以，看起来很有用。--桐生ここ★[讨论] 2024年3月6日 (三) 03:53 (UTC)[回复]

建议设置大概如下：

$wgContactConfig['ipbe'] = [
	'RecipientUser' => 'IPBE-zh',
	'SenderName' => '中文維基百科聯絡表單',
	'RequireDetails' => true,
	'IncludeIP' => true, // 自動讀取申請人IP
	'MustBeLoggedIn' => false,
	'NameReadonly' => false,
	'EmailReadonly' => false,
	'SubjectReadonly' => false,
	'MustHaveEmail' => false,
	'AdditionalFields' => [
		'blockid' => [
			'label-message' => 'contactpage-ipbe-blockid', // 封鎖ID
			'type' => 'text',
			'required' => true,
		],
		'gfw' => [
			'class' => 'HTMLMultiSelectField',
			'label-message' => 'contactpage-ipbe-gfw', // 因身處中國大陸，需要使用代理才能瀏覽維基百科
			'options-messages' => [
				'contactpage-ipbe-gfwyes' => 'ipbe-gfw' // 是
			]
		],
		'accountname' => [
			'label-message' => 'contactpage-ipbe-accountname', // 如果未有帳號，請填寫希望申請的帳號名稱
			'type' => 'text',
		],
		'reason' => [
			'label-message' => 'contactpage-ipbe-reason', // 請說明申請IPBE的原因
			'type' => 'textarea',
			'required' => true,
			'rows' => 7,
			// 'hide-if' => [ '!==', 'gfw', '' ] // 我不曉得怎麽寫這個（check if ipbe-gfw is selected)
		],
		'page' => [
			'label-message' => 'contactpage-ipbe-page', // 您在哪個頁面遇到IP封鎖通知？
			'type' => 'text'
		],
		'editdesire' => [
			'label-message' => 'contactpage-ipbe-editdesire', // 您希望對該頁面作出什麼編輯？
			'type' => 'textarea',
		],
	],
	'DisplayFormat' => 'table',
	'RLModules' => [], 
	'RLStyleModules' => []
];

大家看看有没有什么问题？--路西法人 2024年3月6日 (三) 08:07 (UTC)[回复]

实测，IncludeIP仅对登入使用者有效，未登入情况下完全不会显示那个栏位。--Xiplus#Talk 2024年3月7日 (四) 12:25 (UTC)[回复]

经亲测（我自己的站点），设置IncludeIP下，未登录用户虽不会显示“包含IP地址”栏位，但发送的电邮会自动将IP地址包含在标题栏（即预设强制开启）。这情况下，反而是要想办法强制登录用户提交IP，例如通过JS强制点选提交IP地址，并隐藏该选项。--路西法人 2024年3月8日 (五) 01:44 (UTC)[回复]

确实，我没注意到带在标题。--Xiplus#Talk 2024年3月10日 (日) 00:44 (UTC)[回复]

强制点击提交IP可能会有违反隐私权政策的问题。--Xiplus#Talk 2024年3月10日 (日) 00:46 (UTC)[回复]

m:Special:Contact/stewards也是开启了IncludeIP。如果像他们那样在表格末端放个声明文字：

您提供的资料均仅会用于处理申请及防止滥用之用，并只会由已签署保密协议的志愿者处理。提交此表单即表示您同意将上述资料及您当前使用的IP地址发送给对应处理人员作上述用途。

这样应该会比较好（？--路西法人 2024年3月10日 (日) 02:02 (UTC)[回复]

终究要申请者自己勾选，但我们可以写说不勾就不处理。--Xiplus#Talk 2024年3月10日 (日) 03:42 (UTC)[回复]

个人觉得既然未登录的用户都预设开启了，那么其实分别不大。况且需避免写出来的指示上，未登录用户看到“不勾选就不处理”会觉得奇怪（尤其那个选项的系统讯息不能自己定，好像是）。--路西法人 2024年3月10日 (日) 04:07 (UTC)[回复]

未登录用户在站内编辑本来就会公开IP地址，但把已登录用户和IP地址连结起来，就属于CU的权限了，邮件可依此比拟。--Xiplus#Talk 2024年3月10日 (日) 04:14 (UTC)[回复]

大概不完全是？如果写得够清楚（比如上方所列声明文字），那么已经是用户自主提交IP而不是我们去公开他和IP的关联，而既然不交就不处理，那么为什么要给提交无效申请的功能给人选择……？--路西法人 2024年3月10日 (日) 04:20 (UTC)[回复]

你可以禁止提交，但不能帮用户自动提交。--Xiplus#Talk 2024年3月10日 (日) 05:15 (UTC)[回复]

或是提交工单时顺便问问隐私政策是否允许？如果隐私政策容许，而提交IP是处理的必要条件的，那么当然最好自动帮他们交；如果政策不容许，那么不设就是。--路西法人 2024年3月10日 (日) 12:23 (UTC)[回复]

症结点在于受理站外申请时，申请者是否“必须”提交IP地址资讯？若答案为是，才应该考虑强制提交。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年3月11日 (一) 11:45 (UTC)[回复]

不提交IP地址，那么提交封锁ID也是无用。提交IP地址和封锁ID的主要作用是核对资料正确，也要查证封锁的原因（例如检查IP是否因破坏而被封锁，这种情况属于Unblock不应该由IPBEG处理）。没有IP资讯是不应该处理IPBE申请的。--路西法人 2024年3月11日 (一) 12:59 (UTC)[回复]

@Stang、ASid、94rain、桐生ここ：除了是否强制提交IP地址外，是否对表单有任何其他建议？--路西法人 2024年3月12日 (二) 02:31 (UTC)[回复]

没的话我交工单，到时劳烦丝糖君协助配置了。--路西法人 2024年3月12日 (二) 02:32 (UTC)[回复]

建议增加下面可选项表单

您遇到IP封禁的页面是：_____

您打算对上述页面做的编辑是：_____--桐生ここ★[讨论] 2024年3月12日 (二) 05:33 (UTC)[回复]

已添加。--路西法人 2024年3月12日 (二) 05:46 (UTC)[回复]

已提交工单phab:T359998，劳烦技术帝们协助处理了。--路西法人 2024年3月13日 (三) 02:44 (UTC)[回复]

@Xiplus、Ericliu1912：页面已建立，烦请两位参与讨论的管理员协助处理界面文字，谢谢。--Hamish T 2024年9月17日 (二) 13:45 (UTC)[回复]

Special:联系/ipbe，差不多好了，有要修改的请再提出。--Xiplus#Talk 2024年9月17日 (二) 15:21 (UTC)[回复]

给予IPBE授予者“强制为全域账号建立本地账号”权限

于Phabricator查看
编号T361184的工单
状态：已解决

实务上处理IPBE申请会遇到申请者已经在其他wiki上建立账号，此时需要“强制为全域账号建立本地账号 (centralauth-createlocal)”权限才能处理，目前该权限只有管理员持有，考量该IPBE授予者在执行职务时确实有高度需求该权限、该使用者群组成员应高度可信、该权限潜在滥用性较低，建议给予IPBE授予者“强制为全域账号建立本地账号”权限。--Xiplus#Talk 2024年3月7日 (四) 15:08 (UTC)[回复]

(＋)支持：确有需求，且潜在滥用性低。-Peacearth（留言） 2024年3月7日 (四) 21:43 (UTC)[回复]

支持，就算真的被误用，实质也造成不了多大的影响（吧--路西法人 2024年3月8日 (五) 01:45 (UTC)[回复]

支持，看上去有需求。--YF dyh000（留言） 2024年3月9日 (六) 03:28 (UTC)[回复]

支持。预期不会有合理反对意见，建议先行在phab请求。 ——魔琴 [ 留言贡献新手2023计划 ] 2024年3月9日 (六) 13:35 (UTC)[回复]

支持。即使遇到上述滥用问题，可以除权。--桐生ここ★[讨论] 2024年3月9日 (六) 13:57 (UTC)[回复]

支持，不过这个权限被误用会发生什么事吗？--冥王欧西里斯（留言） 2024年3月9日 (六) 14:09 (UTC)[回复]

完全支持，有确切需要。--Borschts^™^{欢迎外带一碗罗宋汤} 2024年3月9日 (六) 15:54 (UTC)[回复]

行。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年3月11日 (一) 11:36 (UTC)[回复]

七日无异议，公示七日至2024年3月25日。--追风（留言） 2024年3月18日 (一) 15:36 (UTC)[回复]
@ChasingAir：公示期已结束。San mo sa _{Gloire d'Yser} 2024年3月28日 (四) 06:53 (UTC)[回复]
公示通过，稍后送P站。同时结束RFC。追风（留言） 2024年3月28日 (四) 07:05 (UTC)[回复]
工单T361184已创建。追风（留言） 2024年3月28日 (四) 07:10 (UTC)[回复]
已经完成。--在下荷花，请多指教（欢迎签到） 2024年4月9日 (二) 13:33 (UTC)[回复]

方针亦已修改。--在下荷花，请多指教（欢迎签到） 2024年4月9日 (二) 13:41 (UTC)[回复]

提议放宽IPBE授予者申请审核时间下限

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2024年3月8日 (五) 16:14 (UTC)。[回复]

不需要总是至少等一周才能通过吧？—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月23日 (五) 12:29 (UTC)[回复]

就无法理解为啥要搞投票。信任与否应以compelling reason去说明，单纯的投票未必能达到这个目的。如果票数过了，却有非常重要的理据不应该授权，又得被说绕过投票共识否决结果了。--路西法人 2024年2月24日 (六) 01:53 (UTC)[回复]

（目前这个话题仍然在该讨论页活跃，放那边会被注意到的几率比在这边要高吧……）--路西法人 2024年2月24日 (六) 01:54 (UTC)[回复]

仅技术上监视此页面者即至少有七百余人，月浏览量万次以上，在此提出获关注几率明显较高。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月24日 (六) 15:20 (UTC)[回复]

同路西法人，申请者在申请这一权限时有必要作出有说服力的和准确的阐述，这样才能获得社群信任让管理员授权。这可不是纯粹的投票就可以解决的事情。--绍🌟煦·集思广益 2024年2月25日 (日) 07:49 (UTC)[回复]

上面的意见很有道理，个人基本上认为授权第一条件应该是由管理员判断，就和一般权限一样，而简单的投票取得社群认可是第二条件，满足两者之后授权。这不是在选管理员，IPBEG也只是像过滤器助理、模板编辑员等一般权限，不是管理人员。--桐生ここ★[讨论] 2024年2月26日 (一) 10:09 (UTC)[回复]

@Ericliu1912：请提出明确草案和修订理由，这样才能开展讨论。

这个程序是我在有人指出必须签协议之前上上次讨论的末尾起草的，可能有些过时。--落花有意12138 2024年2月24日 (六) 05:31 (UTC)[回复]

大概只要加个“一般而言”，允许例外就好了。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月24日 (六) 12:02 (UTC)[回复]

建议雪球法则也应应用于明显没有争议的可信用户提名或自荐。—千村狐兔（留言） 2024年2月24日 (六) 15:30 (UTC)[回复]

@Manchiu：请问“明显没有争议”的具体标准是什么呢？换句话说，社群如何判定申请人是没有争议的且可信任的用户？--绍🌟煦·集思广益 2024年2月25日 (日) 07:51 (UTC)[回复]

多人支持，且论之有据者，当可认定。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月25日 (日) 16:44 (UTC)[回复]

同上。申请的多为社群活跃用户，以现时申请为例，一般都已获授其他权限。社群有一定认知、信任。-千村狐兔（留言） 2024年2月27日 (二) 15:21 (UTC)[回复]

使用共识制是很好的，贵站的机器人审核小组、调查助理都在使用共识制授权；如果这样做，那么设置一个最小关闭讨论的时间非常合理。希望提案者可以明确一下是单纯对这个一周的最小关闭时间存在疑问，还是认为授权适用于雪球法则；如果是前者，考虑到权限申请页面并不是一个很多人关注的页面，一个相对长一点的时间是合理的，（共享资源上的图片审查员需要最短48小时关闭，贵站活跃编者没这么多的话，4-5天如何？如果是后者，我不认为这种情况下用雪球原则合适，涉及到授权的东西慎重一些很合理，申请人也不是等不起那几天吧。 Stang^★ 2024年2月26日 (一) 08:06 (UTC)[回复]

是不是可以考虑减少为三日以上？—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年2月26日 (一) 09:01 (UTC)[回复]

支持减少为三日，例如WP:IA里这段话“经三日投票，简单多数支持，则可以取得界面管理员权限”个人认为非常适合IPBEG。--桐生ここ★[讨论] 2024年2月26日 (一) 10:14 (UTC)[回复]

界面管理员的申请会出现在公告栏，请问IPBEG的申请会有同样的（受社群关注的）程度吗？ Stang^★ 2024年2月26日 (一) 10:41 (UTC)[回复]

可以发公告，毕竟维基奖励也发公告。--桐生ここ★[讨论] 2024年2月26日 (一) 10:52 (UTC)[回复]

建议修订草案：

提名发出后

管理员应该核对提名人和被提名人的资格，不合资格的关闭（其他用户也可关闭）

用户可参与讨论及表态是否赞同申请，并附以理由支持

可用雪球法则关闭明显不受社群信任的投票

符合以下条件的可以授权：

票数大于4票

同意票多于二分之一

投票进行三日后，符合条件者，管理员可以关闭投票并授权；如果三日后尚未符合条件，则应延长投票期至七日；若七日内未有任何用户投票，则可延长投票期至十四日并发公告至公告栏。投票截止后，是否批准申请最终由管理员按讨论内容决定。

--桐生ここ★[讨论] 2024年2月26日 (一) 10:52 (UTC)[回复]

同意。申请条件基本上使得申请的都属可信用户，3日我认为足够时间收集社群同意票。-千村狐兔（留言） 2024年3月21日 (四) 11:46 (UTC)[回复]

支持。--Kriz Ju（留言） 2024年3月22日 (五) 21:55 (UTC)[回复]

IP封禁豁免授予者的一些问题

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2024年3月21日 (四) 08:14 (UTC)。[回复]

没有签署NDA的管理员是否有权处理IPBE申请？
我看每个人授权准则似乎不一样，是否应该设定一个标准，统一第一次申请授权一年IPBE，之后申请可授予永久权限？

--桐生ここ★[讨论] 2024年3月9日 (六) 14:02 (UTC)[回复]

1. 以我理解的来看，没有签署NDA的管理员无法看到[email protected]这个email，所以不可以处理。

2. 每个人授权的准则是一样的，都需要社群投票。--Martin 去我的签名簿签名！！ 2024年3月10日 (日) 03:44 (UTC)[回复]

我的意思是每位IPBEG授予IPBE的权限不一样，有人直接授予长期IPBE权限，有人授予一年IPBE权限。我建议是参考en先授予短期，比如统一首次申请授权一年，再次申请根据考量可授权长期。--桐生ここ★[讨论] 2024年3月10日 (日) 11:51 (UTC)[回复]

Ping各位IPBEG @AINH、ASid、ATannedBurger、Borschts、LuciferianThomas、SCP-2000、だ＊ぜ。--桐生ここ★[讨论] 2024年3月10日 (日) 11:58 (UTC)[回复]

依基金会要求，未签署NDA的管理员不应接触此类资讯，目前订阅邮件列表的管理员全部都已签署NDA。授权准则方面，这不是新问题，授权授多久真的都是自由心证，主要用途也是确保账号有活动才往后再重新申请而已，其实首次授权多久真的不是个问题。--路西法人 2024年3月10日 (日) 12:20 (UTC)[回复]

一般管理员仍得授予IP封锁豁免权（包括站内正式申请及封锁申诉等）。只是涉及敏感资讯之申请，须签署额外保密协议才能查阅。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年3月11日 (一) 02:06 (UTC)[回复]

关于IP封禁豁免权授予者的顶部图标

本主题或以下段落文字，移动自WP:互助客栈/其他。执行者：San mo sa _{全方贫工之联合} 2024年5月14日 (二) 15:11 (UTC)。[回复]

已通过：

公示期已过。--人间百态,独尊变态 (讨论) 2024年5月6日 (一) 14:17 (UTC)[回复]

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

如题。距离IP封禁豁免权授予者方针的试行已过一月有余，然而关于该权限群组的图标及其图标模板仍悬而未解。因此，鄙人初步拟定将该图标作为IP封禁豁免权授予者的图标。若有不同意见抑或改进的想法，也欢迎在下方指出。--人间百态,独尊变态 (讨论) 2024年4月14日 (日) 13:34 (UTC)[回复]

这扇门意义不明，并且在黑暗模式下看不清。--Milky Defer 2024年4月14日 (日) 13:41 (UTC)[回复]

图标中的“门”代表的是那些因网络限制而仅能通过开放代理编辑维基百科的用户所遭到的阻拦（此指IP封禁），而开着的“门”则指出IP封禁豁免权授予者的职权——通过授予IPBE将那些用户受到的阻拦“打开”。至于黑暗模式下看不清的问题，容我等会修改一下图标。--人间百态,独尊变态 (讨论) 2024年4月14日 (日) 13:55 (UTC)[回复]

已修改，更改了一下门框的颜色。--人间百态,独尊变态 (讨论) 2024年4月14日 (日) 14:35 (UTC)[回复]

@人间百态 @MilkyDefer
I have another idea, what about a golden key instead of an open door? A key is more distinguishable than the current icon. And there's lots of usage of the key icon in current computer science, meaning passkey. That idea came from the emblem of Pope -Lemonaka 2024年4月16日 (二) 10:33 (UTC)[回复]

@Lemonaka,That's a good idea. A golden key is better than an open door. I have uploaded a new version of the icon, and I hope you can comment on it.--人间百态,独尊变态 (讨论) 2024年4月16日 (二) 14:29 (UTC)[回复]

@人间百态 I felt good. @MilkyDefer What's your opinion? -Lemonaka 2024年4月16日 (二) 15:16 (UTC)[回复]

Have been busy with games, sry for not noticing. Although I think using color gradients to represent specular highlight is an outdated design nowadays, it matches the wikiglobe well, (perhaps the wikiglobe itself is an aesthetics-outdated design), and I would have no objections. Milky Defer 2024年4月16日 (二) 15:28 (UTC)[回复]

@Lemonaka @MilkyDefer
Based on Lemonaka's comments on my user talk page, I've created a new version.I hope you can comment on it.--人间百态,独尊变态 (讨论) 2024年4月17日 (三) 14:30 (UTC)[回复]

It does not match the topicon design of other user groups so I discourage the adoption of this version.--Milky Defer 2024年4月18日 (四) 02:58 (UTC)[回复]

... Your opinion is correct.The size of the key is so large that it almost covers half of the icon. In that case I'll go back to the third version.I wonder what Lemonake thinks.--人间百态,独尊变态 (讨论) 2024年4月18日 (四) 14:19 (UTC)[回复]

I mean a small golden key on the right, pointing to the right-bottom like the icon for Checkuser. Why we use such a large key.... -Lemonaka 2024年4月18日 (四) 19:47 (UTC)[回复]

like this?--人间百态,独尊变态 (讨论) 2024年4月19日 (五) 14:16 (UTC)[回复]

我想Lemonaka应该是指钥匙大小位置同此版本不变，但钥匙尖端指向右下角。--Cookai饼块🍪_{（💬留言）} 2024年4月19日 (五) 18:43 (UTC)[回复]

@Cookai1205@Lemonaka,OK,I've uploaded a new version.See if you have any problems.--人间百态,独尊变态 (讨论) 2024年4月20日 (六) 12:38 (UTC)[回复]

@人间百态 Yes, this is just the one we need.. -Lemonaka 2024年4月20日 (六) 17:46 (UTC)[回复]

该话题最近的留言距今也已过7日，故此就第六版图标 公示7日，2024年5月6日 (一) 14:11 (UTC) 结束--人间百态,独尊变态 (讨论) 2024年4月29日 (一) 14:11 (UTC)[回复]

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

附带有限追踪检查的无IP的IPBE

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2024年5月27日 (一) 16:14 (UTC)。[回复]

由于现在IPBE申请积压严重，而且新增的授予员并没有加快解决积压，因此提出新的IPBE授予员类型，希望各位提出意见。

主要内容：这种IPBEG收到的申请不包含IP信息，因而不需要签订协议。为了反破坏，授权者应该检查新账户的编辑，直到用户做出足够多多笔有贡献性的编辑，期间如有破坏则提报。

这降低了要求，并且只需要检查用户名是否合规，应该能加快处理速度。

可能的问题和回答：

破坏者可以积攒账户以供未来破坏：由于这种账户要有多笔好编辑，而破坏易于识别，所以利大于弊。并且现在的方法也没有解决这些问题
可能“抢注”用户名，占用用户名存量：如果新账户数量和名称异常可以明显察觉
要追踪的用户太多：可以通过RSS订阅集中检查

感谢桐生ここ和其他用户提供的灵感。--落花有意12138 2024年5月11日 (六) 12:37 (UTC)[回复]

你要先跟IPBE授予标准过低的人说，不是我们不想处理，还有授权者应该检查新账号的编辑这不切实际，申请人太多检查不过来，且这相当于给人背书，不会有人想做这种吃力不讨好的事，有的话我觉得很棒，一旦有人破坏却没有被检查到，授权者就准备被一些人骂了，说为什么没有检查到。

至于会有人问说为什么有人会骂，这是因为中维社群很难满足。

我提出建议有人反对，也没人打算解决，放着烂比较快。加油 (--~~S i d~~ 2024年5月11日 (六) 13:05 (UTC)[回复]

我问一个问题，您作为IPBEG，遇到IPBE申请者提供的IP是Range block，而不是Blocked Proxy，申请者用户名看起来正常，您是授权还是不授权？怎么判断出是误伤还是破坏者本人？

为什么当前的IPBEG授权后一旦有人破坏却没有被检查到，授权者为什么不会被一些人骂，说为什么没有检查到？--桐生ここ★[讨论] 2024年5月11日 (六) 15:18 (UTC)[回复]

Range block不在IPBEG的处理范围，只有Blocked Proxy我们才能处理。

1-1.通常使用者名称看起来正常，也没发现什么异常就会授权。

1-2.我们只能从申请者申请的用户名及IP看异常，用户名除了特征明显以外是无法看出什么，IP就没什么可判断异常的地方。

2.因为现有方针没有要求我们要检查新账号编辑，所以不会有这种问题。--~~S i d~~ 2024年5月11日 (六) 16:32 (UTC)[回复]

换个说法吧，一个代理IP上有已知破坏者，现在有人用这个IP申请IPBE，授权就有可能会给破坏者授权，但是没办法，即便有IP你也无法知道是不是破坏者。

所以能看到IP并没有增加对是否为破坏者的判断。--桐生ここ★[讨论] 2024年5月11日 (六) 17:04 (UTC)[回复]

我提过这个好几次。由于人工检查的滞后性和精力消耗，有必要搭配机器人等机制限制行为，不然破坏者等授予者下线再用不就绕过了。--YF dyh000（留言） 2024年5月11日 (六) 13:10 (UTC)[回复]

这给我一个新的思路，就是“考察版IPBE权限组”，利用AF限制“考察版IPBE”建立条目的权利，他们只能先发草稿然后送AFC，至于编辑条目，即使达到自动确认用户也不能编辑半保护内容，除非达到延伸确认或获得正式版IPBE权限。另外所有“考察版IPBE”编辑会被AF加标签以便追踪。--桐生ここ★[讨论] 2024年5月11日 (六) 15:23 (UTC)[回复]

说句实在话与其用这种治标不治本的方式，为什么不恢复CU让CU来查，不要说什么有人泄漏CU数据，所以不该恢复，那反之过往有管理员滥用傀儡，要不要把管理员全部废掉阿...

这样子的检查不仅消耗社群已经所剩无几的人力，还很没有效率。

我不是在指这个提案不好也不是要反对，只是无法理解为什么有治本的方法不用，要用一个治标还耗时耗力的方法。--~~S i d~~ 2024年5月11日 (六) 13:17 (UTC)[回复]

当前IPBEG的机制不能让人满意，因为实质上没有解决问题，反而让一些本该有权处理的管理员无法处理。

由于Unblock-zh.org的建立，该网站设计的申请流程似乎有不提供IP地址的选项，因此同意成立这种特殊IPBEG用户组。--桐生ここ★[讨论] 2024年5月11日 (六) 15:11 (UTC)[回复]

unblock-zh 网站设计应该符合使用需求，也就是说如果IPBE的申请要求查验IP，那么网站可以醒目的提示“要申请IPBE必须提交IP”。（这个意见已经出现在了讨论区）Bluedeck 2024年5月17日 (五) 09:01 (UTC)[回复]

“新增的授予员并没有加快解决积压”，所以料想可以解决问题的制度实际上（还）没有解决问题？—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年5月11日 (六) 18:41 (UTC)[回复]

目前，申请申请iPBE授权后发现是破坏者的个案多吗？-千村狐兔（留言） 2024年5月12日 (日) 11:52 (UTC)[回复]

给人背书可能不太合理。 ——魔琴［身份声明留言贡献新手2023］ 2024年5月12日 (日) 14:18 (UTC)[回复]

关于IPBE申请的问题

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2024年7月20日 (六) 08:14 (UTC)。[回复]

哈啰大家好，我是IPBEG，我想就以下几个问题请社群讨论，给予我们明确的共识，这个是我个人发起的讨论，并没有与其他授予者讨论，希望大家尽量参予。--~~S i d~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

不强迫备案WP:RFR/IPBE

目前的情况是都会备案到权限申请，我希望可以不强迫，应该说不知道从何时开始有了惯例会备案至权限申请，事实上日志都写得很清楚，这个备案会让我们多一个步骤，备案时所描述的内容事实上并没有提供到多大的帮助，邮件列表只有订阅相关邮件列表的人才能查询。--~~S i d~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

@ASid：Wikipedia:账号请求#管理员操作指南：“由赋权管理员将通过申请的使用者名称连同申请理由，存档到WP:权限申请/申请IP封锁豁免权/存档”。--Xiplus#Talk 2024年9月17日 (二) 15:35 (UTC)[回复]

授权标准

目前基本上都是授予永久权限，各位应该有注意到我授权会经常授予临时权限，这是因为有人反映说授权过于宽松，所以我希望可以针对这一部分进行讨论，在不使处理变繁杂的情况下，兼顾标准的部分。有关于这一部分我是希望本地恢复CU，交由CU来定期随机查核使用者是否确实有需要用到IPBE，不是授予者与管理员们提高标准，即便提高也无法防止有意骗取IPBE的使用者。--~~S i d~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

我理解有一些人可能会觉得这个讨论有点多余，然而我的目的是在于确保社群有一定的共识，不会单方面变更后有人跳出来说，你怎么这么做你应该这么做：（--~~S i d~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

稍微解释一下为什么是永久权限。曾经首次授权一般都是临时权限的，但是后来发现没有太多意义。基本上所有到期之后还想要继续编辑的都会申请续期，这里也没有太多可以审查的东西，基本上遇到申请都会转成永久权限。所以没有续期的那些，也就是没有实际编辑，到了时间就忘了的人。这部分人的除权，现在由机器人自动执行。所以永久权限和首次的临时权限本质上区别也就不大了，而且还减少处理的负担。这部分是有过讨论的，找一下的话应该是可以找到讨论的。--Tiger（留言） 2024年7月9日 (二) 14:45 (UTC)[回复]

感谢Tiger。--~~S i d~~ 2024年7月10日 (三) 06:46 (UTC)[回复]

IPBEG标

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2024年8月23日 (五) 16:14 (UTC)。[回复]

The topicon of IPBEG designed by @人間百態： and me months ago are still not used or uploaded, is there any problem for previous discussion?---Lemonaka 2024年8月13日 (二) 04:24 (UTC) 我和 @人間百態：几个月前设计的 IPBEG 主题图标到现在还没用也没上传，之前的讨论有问题吗？---Lemonaka 2024年8月13日 (二) 04:24 (UTC)---Lemonaka 2024年8月13日 (二) 04:24 (UTC)[回复]

https://smms.app/image/LkxwvMJFNuoY7Qf -Lemonaka 2024年8月13日 (二) 04:25 (UTC)[回复]

No problem with the topicon.The topicon has actually been uploaded.--人间百态,独尊变态 (讨论) 2024年8月13日 (二) 12:45 (UTC)[回复]

@人间百态：不过标志排版怪怪的，图片上方还有大片空白需要截去。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年8月13日 (二) 15:27 (UTC)[回复]

修订IP封禁豁免及IP封锁豁免权授予者方针

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2024年9月20日 (五) 16:14 (UTC)。[回复]

于Phabricator查看
编号T374504的工单
状态：已解决

IP封禁豁免

由于Unblock-zh.org已经试营运近50日，本人现在提出修订现有IP封禁豁免方针（WP:IPBEPROXY部分），详细修订条文见下：

原条文

用户可在维基百科:权限申请/申请IP封禁豁免权提交申请，若无法编辑该页则应发送电邮至wikipedia-zh-ipbe邮件列表。

修改后的条文

用户可在维基百科:权限申请/申请IP封禁豁免权提交申请，若无法编辑该页则应透过发送电邮至wikipedia-zh-ipbe邮件列表或者在Unblock-zh.org建立工单申请。

--Benho7599 | Talk ^{拥护以李家超同志为核心的党中央} 2024年8月26日 (一) 11:07 (UTC)[回复]

提案OK的。对了我有个不请之情，我做为IPBEG处理的IPBE申请相对于其他IPBEG是多很多的，再处理的时候我发现有时会需要调整IPBE的期限，然而碍于User:Xiplus/unblock-zh-helper-gmail小工具尚未有选择IPBE期限的原因，导致必须使用Special:Userrights手动给予有期限的IPBE，加上一直以来社群有个声音是希望适当的提高标准，参考其他站点meta的GIPBE或enwiki的IPBE都是给予有期限的，我希望可以给予IPBEG权限组移除IPBE的权限，以利在申请是需要赋予短期IPBE的申请时，IPBEG使用User:Xiplus/unblock-zh-helper-gmail赋予永久权限后可以直接透过Special:Userrights调整IPBE的期限，当然我知道社群有一部分人会忧心IPBEG会滥权但我想经过如此长的时间，社群对现任的IPBEG都已有相当的认识，应该是不太需要担心会有滥权的情况发生，即便有新的志愿者申请成为IPBEG我想社群也是使用高标准在看待的，这理论上来说也不太需要担心。

至于方针的部分则是软性规定（透过方针规范），非硬性（透过技术层级限制），仅允许IPBEG在申请有需要赋予短期权限时才可更改，不得用于处理WP:RFDR的除权申请。@AINH、Borschts、LuciferianThomas、SCP-2000、だ＊ぜ：不好意思打扰各位，由于我的意见与各位有相关所以想请各位过来讨论，如有打扰还望见谅，谢谢。

以上请社群考虑一下我的意见，十分感谢。--~~S i d~~ 2024年8月26日 (一) 14:49 (UTC)[回复]

@Hoben7599：哈啰打扰了，我上面的意见如果可以的话希望您可以顺便推动一下，如果社群同意这么做的话。--~~S i d~~ 2024年8月26日 (一) 14:53 (UTC)[回复]

(＋)支持。使用该网站较为方便。--WiiUf ——青龙出世，傲视苍穹 的第1000次编辑！ 2024年8月29日 (四) 04:58 (UTC)[回复]

IP封锁豁免权授予者

现在提出修订现有IP封禁豁免权授予者方针，详细修订条文见下：

原条文

不受速率限制影响（noratelimit）
强制为全域账号创建本地账号（centralauth-createlocal）
添加用户组：IP封禁豁免者
移除自己账号的用户组：IP封锁豁免权授予者

修改后的条文

不受速率限制影响（noratelimit）
强制为全域账号创建本地账号（centralauth-createlocal）
添加用户组：IP封禁豁免者
移除自己账号的用户组：IP封锁豁免权授予者
移除被授权用户权限组：IP封禁豁免者（不得用于处理除权申请，仅可变更无需长期或永久IP封锁豁免的用户的豁免权限为短期权限、或移除错误的授权）

--Benho 7599 ^{坚决拥护以芙宁娜同志为核心的枫丹} 2024年8月26日 (一) 15:27 (UTC)[回复]

谢谢你的帮忙，不好意思我这部分没有说清楚“仅允许IPBEG在申请有需要赋予短期权限时才可变更”，我这部分是指说IPBEG仅可因申请信件缩短IPBE期限（例子：IPBEG在处理申请时遇到一位需要赋予短期权限的人，先透过Xiplus开发的小工具一键建立账号、赋权（此处会是永久赋权，原因是小工具尚未有选择IPBE期限的功能）与用户讨论页通知，再直接透过Special:Userrights更改为短期权限即可），不是指说仅可移除短期的IPBE，抱歉让您误会了。

我建议可以写成“不得用于处理除权申请，仅可变更无需长期或永久IP封锁豁免的用户的豁免权限为短期权限，或移除错误的授权”会比较好，当然这么写会让不清楚IPBE处理状况的人看到会觉得有点奇怪。--~~S i d~~ 2024年8月26日 (一) 16:14 (UTC)[回复]

已订正--Benho 7599 ^{坚决拥护以芙宁娜同志为核心的枫丹} 2024年8月27日 (二) 02:21 (UTC)[回复]

最后留言距今已有五日，就Hoben7599君提请的修订 公示7日，2024年9月10日 (二) 14:20 (UTC)结束--人间百态,独尊变态 (讨论) 2024年9月3日 (二) 14:20 (UTC)[回复]

公示通过，已修改方针。--人间百态,独尊变态 (讨论) 2024年9月10日 (二) 14:41 (UTC)[回复]

IPBEG选举改革

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2024年11月7日 (四) 08:14 (UTC)。[回复]

已通过：

澄清投票资格为延伸确认用户，及管理员应关闭投票后点票，二处更改已获共识。——即请秋安 ZhaoFJx_(论•签) 2024年10月28日 (一) 00:39 (UTC)[回复]

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

各位好，在我选举IPBEG时，有一些情况发生。
1.如@ATannedBurger：，投票资格具体是自确、延确还是符合管理员人事任免投票资格？
2.在23:11, 19 September 2024 (UTC)，我4支持2反对，考虑到同意票多于二分之一，没有投票截止，为什么？ -Lemonaka 2024年9月29日 (日) 07:18 (UTC)[回复]

现行条文

在提出申请后，具投票资格的使用者可以支持或反对申请人的申请。投票进行三日后，管理员可用雪球法则关闭明显不受社群信任投票；进行7日后，如同意票数大于等于总票数的四分之三，管理员可以关闭投票并授权；进行14日后投票截止，管理员点票，符合以下条件的授权：

票数大于4票；
同意票多于二分之一。

提议条文

在提出申请后，符合管理员人事任免投票资格的使用者可以支持或反对申请人的申请。管理员可用雪球法则关闭明显不受社群信任投票；
进行7日后，如同意票数大于等于总票数的四分之三，管理员可以关闭投票并授权；
进行14日后，管理员应关闭投票，并点票，符合以下条件的授权：

票数大于4票；
同意票多于二分之一。

-Lemonaka 2024年9月29日 (日) 07:23 (UTC)[回复]

(＋)支持 Benho 7599 ^{坚决拥护以芙宁娜同志为核心的枫丹} 2024年9月29日 (日) 09:52 (UTC)[回复]

(＋)支持 ——即请秋安 ZhaoFJx_(论•签) 2024年9月30日 (一) 21:44 (UTC)[回复]

我个人认为共识制是显著好于只算票数判断是否当选的，正如目前WP:BAG和WP:CLERKS目前实际操作中也是以共识作为判断标准。如果本站认为管理员缺乏总结共识的能力，我也可以退而求其次的支持这一对方针的修订，但投票人标准我更倾向于放宽至自动确认用户，因为这样没有显著的坏处。 Stang^★ 2024年10月1日 (二) 05:27 (UTC)[回复]

(＋)滋磁，建议投票资格放宽至自确或延伸确认。--Taco很好吃 | 时代在变我们的征程是星辰大海 2024年10月2日 (三) 04:09 (UTC)[回复]

@Lemonaka：不知您对将投票人标准放宽至自动确认用户有没有什么意见，如果没意见我会就放宽至自动确认用户得方案公示七日。--人间百态,独尊变态 (讨论) 2024年10月6日 (日) 09:29 (UTC)[回复]

@人间百态没有 -Lemonaka 2024年10月7日 (一) 07:37 (UTC)[回复]

就将条件放宽至自动确认用户的方案 公示7日，2024年10月16日 (三) 14:31 (UTC)结束--人间百态,独尊变态 (讨论) 2024年10月9日 (三) 14:31 (UTC)[回复]

我个人是反对将人事投票权放宽到所有自动确认用户，就7天50次编辑的自动确认门槛，部分LTA的傀儡成功擦到自动确认而没有被及时发现及处理。WP:BAG和WP:CLERKS不能比照WP:IPBEG，前两者本身没有获授予额外的权限，相关用户如没有自带更高级的权限，BAG仅为对程序码作技术判断的意见提供者，CLERKS只是对呈报个案作初级判断的中介人，IPBEG显然和前两者不同，IPBEG获授予一般注册用户没有的权限，并且需要签署NDA，在甄选上理应较为严谨才是，即使想放宽投票权最尽也是延伸确认，否则就会把人事授权的投票门槛下降到和DYKC、GA、FPC等一般站务的投票没有分别。--Uranus1781（留言） 2024年10月10日 (四) 10:49 (UTC)[回复]

同上，自动确认的门槛对于需要签署NDA的职位选举来说实在是太低了，至少应以延伸确认作为标准。--🎋竹生🎍 2024年10月11日 (五) 14:09 (UTC)[回复]

感谢回应，观点有一定的道理。我不反对将门槛设置为延伸确认，但我在潜意识里还是觉得IPBEG这个组没有那么那么重要到需要这么严谨（ Stang^★ 2024年10月13日 (日) 02:30 (UTC)[回复]

已阅上面两位对放宽至自动确认用户可能造成的滥用傀儡成本降低以及安全隐患的忧虑，据此鄙人姑且暂停此公示，若结束后七日内无人对延伸确认用户的方案反对或反对已解决，那么我会再行公示。--人间百态,独尊变态 (讨论) 2024年10月11日 (五) 14:30 (UTC)[回复]

(＋)支持。--在下荷花，请多指教（欢迎签到） 2024年10月14日 (一) 00:54 (UTC)[回复]

就延伸确认用户方案 公示7日，2024年10月27日 (日) 12:56 (UTC)结束--人间百态,独尊变态 (讨论) 2024年10月20日 (日) 12:56 (UTC)[回复]

我觉得至少应该是延确，但是我更支持管理任免资格 Bluedeck 2024年10月22日 (二) 16:25 (UTC)[回复]

公示通过，已修订方针。--人间百态,独尊变态 (讨论) 2024年10月27日 (日) 14:27 (UTC)[回复]

权限申请处已一并更新。——即请秋安 ZhaoFJx_(论•签) 2024年10月28日 (一) 00:35 (UTC)[回复]

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