跳转到内容

维基百科讨论:IP封鎖豁免權授予者

页面内容不支持其他语言。
维基百科,自由的百科全书


IPBE授予

[编辑]
已解決
社群討論決議予以試行。—— Eric Liu 創造は生命(留言留名學生會 2024年2月22日 (四) 16:41 (UTC)[回复]
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

先前讨论

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

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

@Ghren桐生ここDewadipper0xDeadbeefHehuaBorschtsSteven_SunCopperSulfateNewbambooATannedBurgerSunAfterRainStang虹色分子参与意向调查投票的人。@桐生ここYichen_DingASidHoben7599参与先前讨论的人。--落花有意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)[回复]
@落花有意12138桐生ここSteven SunTigerzengShizhaoNewbamboo魔琴LuciferianThomasHoben7599暁月凛奈Xiumuzidiao 早前個人詢問基金會,當管理員處理解封和帳號建立請求時接觸 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授予者的人就更少了 (--~~Sid~~ 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)[回复]
您也漏算我了...--~~Sid~~ 2024年2月9日 (五) 02:51 (UTC)[回复]
AINH也是漏算@AINHping一下--~~Sid~~ 2024年2月9日 (五) 02:53 (UTC)[回复]
Cookai1205一樣漏算@Cookai1205ping一下--~~Sid~~ 2024年2月9日 (五) 03:00 (UTC)[回复]
沒有什麼處理IPBE申請的經驗,但如果真的缺人我可以幫忙-某人 2024年2月9日 (五) 03:02 (UTC)[回复]
@1233AINHASidATannedBurgerBillytanghhBorschtsHamishLadsgroupLemonakaLuciferianThomasSCP-2000Superpes15Taiwania 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)[回复]
@1997kBCourcellesCéréales KillerMartin UrbanecMinoraxSotialeStangTaketaWaihoraceYOWOT868だ*ぜ悔晚斋请看上面的消息。--落花有意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)[回复]
可--)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)[回复]
埃這個想法不錯,我認為可以加入其中,原因是確實有很多人拿了權限後是沒有什麼活躍度,不過此做法可能會讓一些人覺得說被差別對待,除此之外這個做法大致上沒啥問題。--~~Sid~~ 2024年1月7日 (日) 14:27 (UTC)[回复]
同意此思路。但仍需要警惕在临时赋予期蛰伏、永久/长期赋予期爆发的“病情”。--  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申請通道之類的。這樣才能解決本質上的積壓問題。--AT 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,因此,建议要求申请者提供预计贡献内容才会授权,包括:

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

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

赞同,对于没账号/编辑的可以要求,已编辑的则看现有贡献,可以修改Wikipedia:通过Unblock-zh申请IP封禁豁免指南#示例--及时雨 留言 2024年1月18日 (四) 20:04 (UTC)[回复]
这听上去增加申请和审核的复杂程度,且潜在降低的贡献率,未见必要。除非审批所需成本明显超过上述预先审批的成本。或者,作为可选的填写内容。--YFdyh000留言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)[回复]

试行

[编辑]

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

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

关于部分用户支持的专门系统案,我认为可能需要较长时间实现,不能解决眼前的问题。实行过后如果有可用的专门系统,可进一步讨论过渡到系统。——落花有意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日后投票截止,管理员点票,符合以下条件的授权:

  1. 票数大于8票
  2. 同意票多于二分之一
  3. 弃权票少于三分之一
——落花有意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
以及下方的郵件列表的使用,還有「已成為巡查員、回退員或傀儡調查助理三個月以上」這個條文,我建議拉出來討論。把社群有共識的部分讓其先通過,細項部分則是拉出來另外討論,待確定了再加入即可。--~~Sid~~ 2024年1月31日 (三) 08:36 (UTC)[回复]
@ASid:感谢您的贡献。
我对缺漏的地方有补充,请您核对
另外,我认为还有几点意见:
  1. “泄露用户的隐私资料” -> “泄露用户的申请内容”。
  2. “账号确认或疑似被盗用”这一点是各个权限组共有的要求,这里建议移除,另开讨论。
  3. “当IPBE授予者超过六个月没有任何编辑活动”时应该会自动除权,不需要提报。
--落花有意12138 2024年1月31日 (三) 16:54 (UTC)[回复]
1.3.沒問題,我直接更改了,第二點的話我是覺得說寫清楚,如果遇到這種狀況時有個條文依據會比較好,但您要如果認為沒必要的話直接移除也行我沒意見。--~~Sid~~ 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權限也不是由「解除封鎖」而來的。Sanmosa 起視四境 而秦兵又至矣 2024年2月9日 (五) 07:05 (UTC)[回复]
確實,那還是分開好了。--Borschts 歡迎外帶一碗羅宋湯 2024年2月9日 (五) 07:12 (UTC)[回复]
算是有理。那便如此亦可。—— Eric Liu 創造は生命(留言留名學生會 2024年2月10日 (六) 14:35 (UTC)[回复]

暫定結論

[编辑]

考慮到已討論一個多月,故依據上方討論以及基金會的要求(僅有簽署 NDA 者才可接觸 IP 資訊),現暫定結論如下:

  1. 設立 IPBE 授予者。
  2. 將「WP:IP封鎖豁免權授予者」定為方針。
  3. 設立名為「ipbe-zh」郵件列表專責處理 IPBE 相關請求,取代 unblock-zh 現時處理 IPBE 請求的職能。此郵件列表僅限已簽署 NDA 者存取。
  4. 給予讓申請者提供預計貢獻內容之選項。

如無異議及疑問,將稍後公示,謝謝。--SCP-0000留言2024年2月11日 (日) 14:49 (UTC)[回复]

@落花有意1213894rain魔琴Ericliu1912ghrenHehuaManchiu桐生ここ范博2004NewbambooHoben7599暁月凛奈XiumuzidiaoShizhaoLuciferianThomasTigerzengSteven SunASidcwekBorschtsATBluedeckYFdyh000Python6345SanmosaKuon.HakuWhitePhosphorusXiplus 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)[回复]
不需要立即对管理员除权,新用户组试行期间暂时保留管理员的权限,甚至长期保留管理员的权限供少数案例(如授予合法傀儡),都可以接受。--YFdyh000留言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。--YFdyh000留言2024年2月12日 (一) 04:30 (UTC)[回复]
改了描述--~~Sid~~ 2024年2月12日 (一) 04:49 (UTC)[回复]
額外一提沒有簽NDA的管理員依然可以根據過往授權紀錄,對在WP:RFR申請IPBE的用戶或於討論頁使用{{unblock}}申請IPBE的用戶,對這些用戶授權。--~~Sid~~ 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授予者即可。--~~Sid~~ 2024年2月16日 (五) 10:03 (UTC)[回复]
我更正一下我的意見,建議在上方註明「處理人員」指WP:管理員WP:IPBE授予者。--~~Sid~~ 2024年2月16日 (五) 15:51 (UTC)[回复]
@ASid这个页面叫做“通过Unblock-zh申请IP封禁豁免指南”,文中处理员应该只包含通过邮件列表处理申请的用户。
我认为“处理人员”和“处理员”没有什么区别,都可以。只是不必注明处理人员指的是那些人,因为这篇文章的目标读者是无法编辑维基百科的人,大概并不知道“管理员”,给出额外的信息可能迷惑。--落花有意12138 2024年2月17日 (六) 11:10 (UTC)[回复]
OK那依您的修訂更改吧。--~~Sid~~ 2024年2月17日 (六) 14:52 (UTC)[回复]
流程不复杂,不用特地写文档。不论通过什么方式收到申请都是这样的步骤:
  1. 确认封禁事实(通过封禁界面显示的IP地址、封禁ID等)
  2. 检查申请人是否满足授权条件(即Wikipedia:IP封禁豁免中的说明)
  3. 检查是否可以用其他方式解决问题(比如只建立账户就可以绕过的软封禁)
  4. 确认总共需要做哪些操作(只需要建立账户,还是建立账户+授权,或是其他的)
  5. 执行操作
  6. 回信说明申请结果、执行了哪些操作、还需要对方做什么
我不确定这样能不能说清楚整个过程,如果有具体的问题可以再ping我。--Tiger留言2024年2月18日 (日) 06:26 (UTC)[回复]
針對此版本及上方SCP-2000君提到的四點 公示7日,2024年2月20日 (二) 11:09 (UTC) 結束,。--~~Sid~~ 2024年2月13日 (二) 11:09 (UTC)[回复]
公示期間無有效反對意見宣告通過。--~~Sid~~ 2024年2月20日 (二) 14:11 (UTC)[回复]
创建新列表需要两个邮件列表管理员,请各位有意者留言--落花有意12138 2024年2月13日 (二) 14:43 (UTC)[回复]
個人認為應由管理員擔任,@WhitePhosphorusXiplus不知常處理 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)[回复]
我對郵件列表不熟悉,還是由其他人來比較好。--AT 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整理):
--落花有意12138 2024年2月22日 (四) 06:11 (UTC)[回复]

本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

IPBE授予者试行相关

[编辑]

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

请管理员建立权限相关页面--落花有意12138 2024年2月22日 (四) 06:21 (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系統處理申請工單。理據如下:

  1. 不需在站外的個人郵件程式儲存包含他人個資的郵件。
  2. VRT系統有更專門的人去維護。
  3. 每個申請配備工單號,方便申請人查詢自己申請進度。
  4. 內建罐頭回覆系統,操作並不困難。
  5. 可在站內寫gadget,或寫瀏覽器add on協助流線化處理工單:
  6. VRTS容許可以設機器人自動將申請發上站內(也能讓公開查看積壓數字),並通過工具處理。
  7. 對內,積壓數字一目了然(系統已配備)。
  8. 個人郵箱不會被炸。
  9. 不需向申請人公開個人郵箱。

關於自目前新設郵件列表轉移至新系統:

  • 兩個系統的處理人都會是同樣的用戶,只要把指示改去新的電郵地址,然後舊的慢慢處理乾淨即可。
  • 目前六位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。--)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輔助申請

[编辑]

提議安裝mw:Extension:ContactPage,提供完整表單供用戶向IPBEG發送公式化申請。--西 2024年3月4日 (一) 15:53 (UTC)[回复]

先前讨论,可以照抄一下。之前主要的blocker就是NDA的问题,如果这个问题解决了那么非常不错 Stang 2024年3月4日 (一) 16:20 (UTC)[回复]
可以有表單那對申請的用戶會起到很大的幫助。--~~Sid~~ 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)[回复]
@StangASid94rain桐生ここ除了是否強制提交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)[回复]
@XiplusEricliu1912頁面已建立,煩請兩位參與討論的管理員協助處理介面文字,謝謝。--Hamish T 2024年9月17日 (二) 13:45 (UTC)[回复]
Special:联系/ipbe,差不多好了,有要修改的請再提出。--Xiplus#Talk 2024年9月17日 (二) 15:21 (UTC)[回复]

給予IPBE授予者「強制為全域帳號建立本地帳號」權限

[编辑]

實務上處理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)[回复]
支持,看上去有需求。--YFdyh000留言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)[回复]

提議放寬IPBE授予者申請審核時間下限

[编辑]

不需要總是至少等一週才能通過吧?—— 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)[回复]

建议修订草案:

提名发出后

  • 管理员应该核对提名人和被提名人的资格,不合资格的关闭(其他用户也可关闭)
  • 用戶可參與討論及表態是否贊同申請,並附以理由支持
  • 可用雪球法则关闭明显不受社群信任的投票

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

  1. 票数大于4票
  2. 同意票多于二分之一

投票进行三日后,符合条件者,管理员可以关闭投票并授权;如果三日后尚未符合条件,則應延長投票期至七日;若七日内未有任何用戶投票,则可延长投票期至十四日并發公告至公告栏。投票截止后,是否批准申請最終由管理员按討論內容決定。

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

同意。申請條件基本上使得申請的都屬可信用戶,3日我認為足夠時間收集社群同意票。-千村狐兔留言2024年3月21日 (四) 11:46 (UTC)[回复]
支持。--Kriz Ju留言2024年3月22日 (五) 21:55 (UTC)[回复]

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

[编辑]
  1. 没有签署NDA的管理员是否有权处理IPBE申请?
  2. 我看每个人授权准则似乎不一样,是否应该设定一个标准,统一第一次申请授权一年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 @AINHASidATannedBurgerBorschtsLuciferianThomasSCP-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封禁豁免权授予者的顶部图标

[编辑]
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

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

这扇门意义不明,并且在黑暗模式下看不清。--MilkyDefer 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. MilkyDefer 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.--MilkyDefer 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

[编辑]

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

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

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

可能的问题和回答:

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

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

你要先跟IPBE授予標準過低的人說,不是我們不想處理,還有授權者應該檢查新帳號的編輯這不切實際,申請人太多檢查不過來,且這相當於給人背書,不會有人想做這種吃力不討好的事,有的話我覺得很棒,一旦有人破壞卻沒有被檢查到,授權者就準備被一些人罵了,說為什麼沒有檢查到。
至於會有人問說為什麼有人會罵,這是因為中維社群很難滿足。
我提出建議有人反對,也沒人打算解決,放著爛比較快。加油 (--~~Sid~~ 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.因為現有方針沒有要求我們要檢查新帳號編輯,所以不會有這種問題。--~~Sid~~ 2024年5月11日 (六) 16:32 (UTC)[回复]
換個說法吧,一個代理IP上有已知破壞者,現在有人用這個IP申請IPBE,授權就有可能會給破壞者授權,但是沒辦法,即便有IP你也無法知道是不是破壞者。
所以能看到IP並沒有增加對是否為破壞者的判斷。--桐生ここ[讨论] 2024年5月11日 (六) 17:04 (UTC)[回复]
我提过这个好几次。由于人工检查的滞后性和精力消耗,有必要搭配机器人等机制限制行为,不然破坏者等授予者下线再用不就绕过了。--YFdyh000留言2024年5月11日 (六) 13:10 (UTC)[回复]
這給我一個新的思路,就是“考察版IPBE權限組”,利用AF限制“考察版IPBE”建立條目的權利,他們只能先發草稿然後送AFC,至於編輯條目,即使達到自動確認用戶也不能編輯半保護內容,除非達到延伸確認或獲得正式版IPBE權限。另外所有“考察版IPBE”編輯會被AF加標籤以便追蹤。--桐生ここ[讨论] 2024年5月11日 (六) 15:23 (UTC)[回复]
說句實在話與其用這種治標不治本的方式,為什麼不恢復CU讓CU來查,不要說什麼有人洩漏CU數據,所以不該恢復,那反之過往有管理員濫用傀儡,要不要把管理員全部廢掉阿...
這樣子的檢查不僅消耗社群已經所剩無幾的人力,還很沒有效率。
我不是在指這個提案不好也不是要反對,只是無法理解為什麼有治本的方法不用,要用一個治標還耗時耗力的方法。--~~Sid~~ 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申請的問題

[编辑]

哈囉大家好,我是IPBEG,我想就以下幾個問題請社群討論,給予我們明確的共識,這個是我個人發起的討論,並沒有與其他授予者討論,希望大家盡量參予。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

不強迫備案WP:RFR/IPBE

[编辑]

目前的情況是都會備案到權限申請,我希望可以不強迫,應該說不知道從何時開始有了慣例會備案至權限申請,事實上日誌都寫得很清楚,這個備案會讓我們多一個步驟,備案時所描述的內容事實上並沒有提供到多大的幫助,郵件列表只有訂閱相關郵件列表的人才能查詢。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

@ASidWikipedia:账号请求#管理员操作指南:「由賦權管理員將通過申請的使用者名稱連同申請理由,存檔到WP:權限申請/申請IP封鎖豁免權/存檔」。--Xiplus#Talk 2024年9月17日 (二) 15:35 (UTC)[回复]

授權標準

[编辑]

目前基本上都是授予永久權限,各位應該有注意到我授權會經常授予臨時權限,這是因為有人反映說授權過於寬鬆,所以我希望可以針對這一部分進行討論,在不使處理變繁雜的情況下,兼顧標準的部分。有關於這一部分我是希望本地恢復CU,交由CU來定期隨機查核使用者是否確實有需要用到IPBE,不是授予者與管理員們提高標準,即便提高也無法防止有意騙取IPBE的使用者。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

我理解有一些人可能會覺得這個討論有點多餘,然而我的目的是在於確保社群有一定的共識,不會單方面變更後有人跳出來說,你怎麼這麼做你應該這麼做:​(--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

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

IPBEG標

[编辑]

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封鎖豁免權授予者方針

[编辑]
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的除權申請。@AINHBorschtsLuciferianThomasSCP-2000だ*ぜ不好意思打擾各位,由於我的意見與各位有相關所以想請各位過來討論,如有打擾還望見諒,謝謝。
以上請社群考慮一下我的意見,十分感謝。--~~Sid~~ 2024年8月26日 (一) 14:49 (UTC)[回复]
@Hoben7599哈囉打擾了,我上面的意見如果可以的話希望您可以順便推動一下,如果社群同意這麼做的話。--~~Sid~~ 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封鎖豁免的用戶的豁免權限為短期權限、或移除錯誤的授權)

--Benho7599 堅決擁護以芙寧娜同志為核心的楓丹 2024年8月26日 (一) 15:27 (UTC)[回复]

謝謝你的幫忙,不好意思我這部分沒有說清楚「僅允許IPBEG在申請有需要賦予短期權限時才可變更」,我這部分是指說IPBEG僅可因申請信件縮短IPBE期限(例子:IPBEG在處理申請時遇到一位需要賦予短期權限的人,先透過Xiplus開發的小工具一鍵建立帳號、賦權(此處會是永久賦權,原因是小工具尚未有選擇IPBE期限的功能)與用戶討論頁通知,再直接透過Special:Userrights更改為短期權限即可),不是指說僅可移除短期的IPBE,抱歉讓您誤會了。
我建議可以寫成「不得用於處理除權申請,僅可變更無需長期或永久IP封鎖豁免的用戶的豁免權限為短期權限,或移除錯誤的授權」會比較好,當然這麼寫會讓不清楚IPBE處理狀況的人看到會覺得有點奇怪。--~~Sid~~ 2024年8月26日 (一) 16:14 (UTC)[回复]
已訂正--Benho7599 堅決擁護以芙寧娜同志為核心的楓丹 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選舉改革

[编辑]
已通过:
澄清投票资格为延伸确认用户,及管理员应关闭投票后点票,二处更改已获共识。——即请秋安 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日後投票截止,管理員點票,符合以下條件的授權:
  1. 票數大於4票;
  2. 同意票多於二分之一。
提議條文
在提出申請後,符合管理員人事任免投票資格的使用者可以支持或反對申請人的申請。管理員可用雪球法則關閉明顯不受社群信任投票;
進行7日後,如同意票數大於等於總票數的四分之三,管理員可以關閉投票並授權;
進行14日後,管理員應關閉投票,並點票,符合以下條件的授權:
  1. 票數大於4票;
  2. 同意票多於二分之一。
-Lemonaka 2024年9月29日 (日) 07:23 (UTC)[回复]
(+)支持 Benho7599 堅決擁護以芙寧娜同志為核心的楓丹 2024年9月29日 (日) 09:52 (UTC)[回复]
(+)支持 ——即请秋安 ZhaoFJx() 2024年9月30日 (一) 21:44 (UTC)[回复]
我个人认为共识制是显著好于只算票数判断是否当选的,正如目前WP:BAGWP: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:BAGWP: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)[回复]


本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。