維基百科討論:IP封鎖豁免權授予者
由Jimmy-bot在話題IPBEG選舉改革上作出的最新留言：2 天前
IPBE授予
已解決
- 下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
在意向調查中社群認為有必要建立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)
- @Ericliu1912：您作為管理員，或者你可以試一試處理，覺得用電郵處理有什麼不便呢？也方便大家改進，謝謝。--Ghren🐦🕐 2024年1月8日 (一) 17:13 (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)
- 那麼IPBE授予者應該盡快設立，先試試看。--桐生ここ★[討論] 2024年1月25日 (四) 04:12 (UTC)
- (－)反對：觀察也應該先設立再觀察，不設立再觀察也沒有意義。--在下荷花，請多指教（歡迎簽到） 2024年1月23日 (二) 03:26 (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)
- 我建議是用專用的email綁定維基帳號，申請一個email不是很困難，WP:ANON。--桐生ここ★[討論] 2024年1月10日 (三) 16:28 (UTC)
- 應改用類似VRTS的系統處理，那麼處理者的電郵就完全不會公開了。--路西法人 2024年1月10日 (三) 23:41 (UTC)
- 支持。——暁月凜奈 (留言) 2024年1月11日 (四) 03:03 (UTC)
- 保密協議能不能用特殊的，畢竟中國大陸人士沒法簽NDA？如果處理者怕別人知道常用電郵的話，能不能允許用小號申請flag？ ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年1月10日 (三) 14:03 (UTC)
- 事實上，我也覺得處理郵件申請的IPBE最好還是要有保密協議，畢竟牽涉到申請者的電郵地址，以及可能更多的個人訊息。我基本不碰這塊就是一來嫌麻煩太花時間，二來不太願意讓很多陌生人知道我的電郵（特別是這幾年的網際網路環境）--百無一用是書生 (☎) 2024年1月10日 (三) 12:30 (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)
- Email什麼時候「一般需要手機號驗證」了？——暁月凜奈 (留言) 2024年1月13日 (六) 08:46 (UTC)
- Email是防範濫用的一種方法，比方說一個Email申請很多帳號是不正常的。也能證明你是一個真實用戶，因為現在申請Email雖然也不困難，但一般需要手機號驗證。如果不提供Email增加申請人可信度，隨便填寫表單就可以獲得IPBE，封禁代理IP有何意義？--桐生ここ★[討論] 2024年1月12日 (五) 20:29 (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)
- 開放代理地址亦會公開於封禁日誌之中，可否以提供封禁id或元維基之封禁日誌代以提供ip地址？--在下荷花，請多指教（歡迎簽到） 2024年2月4日 (日) 15:12 (UTC)
- 即使隱藏了真實 IP 地址，開放代理地址仍屬於 「IP 地址」。而全域方針（如隱私政策、非公開資料存取政策）以至 enwiki 的方針指引中，也沒有開放代理「不涉及隱私」以至「不屬於個資」這說法。謝謝。--SCP-0000（留言） 2024年2月4日 (日) 15:08 (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)
- 也就是如果有封禁ID發送郵件到IPBE授予者郵件列表，如果提供IP位址發送到簽署了NDA的管理員郵件列表。--桐生ここ★[討論] 2024年2月7日 (三) 10:04 (UTC)
- 如果處理者不接觸IP位址只接觸封禁ID需要簽署NDA嗎？如果基金會的確這樣要求，那麼現行管理員處理IPBE的流程也需要調整了。--桐生ここ★[討論] 2024年2月7日 (三) 10:01 (UTC)
- 那這個IPBE授予者權限是否還有必要存在？能申請權限的人幾乎很少。--桐生ここ★[討論] 2024年2月7日 (三) 06:18 (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)
- 問題出在代理段通常不會因被濫用而被重新封鎖，基本上是沒什麼意義的，因為不會因此而獲得代理段是否曾被用於破壞的情報；只有授予員本身能存取IP位址才能通過比對而得知代理段是否曾被用於破壞。--路西法人 2024年2月7日 (三) 11:54 (UTC)
- 我指的並不是把封禁日誌連結提供給授予員，而是將封禁日誌中的封禁理由截取提供給授予員，該理由理應不會出現ip本身。--在下荷花，請多指教（歡迎簽到） 2024年2月7日 (三) 11:37 (UTC)
- 可以考慮把公開的封禁日誌也提供給授予員，以便分辨是代理封禁還是因破壞封禁，並且破壞問題似乎並不是很大，可以考慮僅授予短期ipbe看貢獻等等替代方案，總比都需要NDA好（會導致很多人無法申請此權限，甚至部分現任管理員也會受影響，反倒會拖慢處理速度），謝謝。--在下荷花，請多指教（歡迎簽到） 2024年2月7日 (三) 10:46 (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也是漏算@AINH：ping一下--~~Sid~~ 2024年2月9日 (五) 02:53 (UTC)
- Cookai1205一樣漏算@Cookai1205：ping一下--~~Sid~~ 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)
- @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)
- 可-- （☎）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)
- 當您連正在跟您說話的人（我）在名單上都沒看到，就不如不要覺得自己認識得夠多人了。--路西法人 2024年2月8日 (四) 17:25 (UTC)
- 如果要等待開發，倒不如在沒有開發新系統的情況下，先行開放申請授予員身份，並先用著現在已存在的系統去審批IPBE，有助在等待開發的同時協助處理積壓及不能簽NDA的管理員不能再處理IPBE申請的空缺。--路西法人 2024年2月8日 (四) 16:55 (UTC)
- 技術上當然可行，問題在於自動檢查僅能檢查是否代理，但無法按經驗人工辨認是否曾被破壞者濫用的代理段。--路西法人 2024年2月7日 (三) 09:25 (UTC)
- 那請問技術上能否設計一個系統，可以檢查用戶名可用性，並在後端驗證提供的ip是否為封禁的代理，然後直接將結果而不是ip地址本身發送給ipbe授予員進行處理，這樣就不會接觸到ip地址了。--在下荷花，請多指教（歡迎簽到） 2024年2月7日 (三) 09:14 (UTC)
- 不知您提到的「專門系統」是指 UTRS 還是其他。但無論如何，只要管理員及 IPBE 授予員需要接觸 IP 資訊，他們便必須簽署 NDA，謝謝。--SCP-0000（留言） 2024年2月6日 (二) 17:46 (UTC)
- 基本同意。現在先落閘（簽署NDA），之後也可以按著這個邏輯處理。--Benho7599 | Talk | 熱烈慶賀惡法23條即將殺到香港 2024年2月4日 (日) 13:57 (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授予者及新帳號建立員自身已因濫用傀儡而被封禁時，管理員應同時立即除權。
另外，當超過六個月沒有任何編輯活動時，權限將會被移除。
（部分內容移動到下方專門討論，於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)
![{\displaystyle [{\text{H}}^{+}]}](https://wikimedia.org/api/rest_v1/media/math/render/svg/7f7ce28abbf4792ac4e2cb46cc962203e59532cf)
- 看起來沒什麼問題，現在監管員助理就在做差不多的事情，只不過沒有授予權。--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)
- 上面提到那個UTRS，感覺真的很有潛力。不知道本站什麼時候有機會用到？另@Bluedeck您的二〇四九大計畫呢（ —— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月19日 (五) 13:40 (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)
- 授權可以由管理員批量處理，重點是要確認當事人條件，這才是真正需要人力的地方。要不然若只是單純機械式授權，管理員自己就可以處理。我們需要釐清的是，現行確認程序究竟有沒有要用到特定（管理）權限的地方？如果沒有，那就大可不必新設權限組。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月9日 (二) 12:18 (UTC)
- 那還是要管理員去處理，加上助理確認實際上也無法確認身份，最多把用戶名提交上去？有點多此一舉。--在下荷花，請多指教（歡迎簽到） 2024年1月9日 (二) 09:11 (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)
- 這聽上去增加申請和審核的複雜程度，且潛在降低的貢獻率，未見必要。除非審批所需成本明顯超過上述預先審批的成本。或者，作為可選的填寫內容。--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)
- (：)回應，抱歉產生歧義，在此澄清：我的意思是只要有實際貢獻即可，而不要求編輯達到一定量。Python6345（留言） 2024年1月27日 (六) 23:24 (UTC)
- 不論任何站點，授予IP封鎖豁免權的原因是容許受IP封鎖影響的非破壞用戶可以編輯，若不編輯者顯然不需要該權限，拒絕是為合適做法。維基百科不強迫任何人參與，但可以拒絕不參與的人獲取可被用作繞過封鎖的特殊編輯權限，請勿偷換概念。--路西法人 2024年1月27日 (六) 14:53 (UTC)
- (※)注意，要求編輯一定量有違WP:維基百科不強迫任何人參與，建議保持當前授予要求。Python6345（留言） 2024年1月27日 (六) 14:34 (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)
- 管理員會有安全問題，IPBE只是編輯權限--及時雨 留言 2024年1月17日 (三) 21:05 (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)
- 老號新號價值也不一樣，已經註冊半年的號只要後續達到編輯數就可以投票。IPBE不是基本沒有風險，這是可以繞過CU的權限，在其他語言可能比巡查員還難拿。--桐生ここ★[討論] 2024年1月25日 (四) 18:34 (UTC)
- 我感覺這種基本沒有風險的權限，出於便利考慮，應該時間長一點。除非有人觀察到六個月以上不編輯然後回歸的編者突然開始搞破壞？如果真要在淘寶鹹魚賣號，那我創建帳號 -> ipbe -> 銷售短時間內一氣呵成不是也可以，這個六個月政策也攔不住你。Bluedeck 2024年1月25日 (四) 09:12 (UTC)
授權時長限制補充案
User:桐生ここ提出：IPBE授予員先授予臨時權限一個月，一個月後有一些貢獻記錄申請人再申請永久權限，IPBE授予員或管理員根據貢獻記錄授予永久權限，或六個月臨時權限，或舉報到VIP。
此開專門章節討論。——落花有意12138 2024年1月21日 (日) 04:16 (UTC)
- 感覺沒有太大意義，反而會影響ipbe持有者「回坑」意願 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年1月28日 (日) 14:09 (UTC)
修訂IPBE方針
|
說明：長期權限是永久權限的意思。桐生ここ★[討論] 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)
- 怎麼沒有關係，管理員附帶這個權限就是為了更大程度保障安全，雖然這個權限可以自己去meta申請，但是由於授予ipbe也較為敏感，所以我建議加入這個權限，用來加強帳戶安全，謝謝。--在下荷花，請多指教（歡迎簽到） 2024年1月21日 (日) 06:16 (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)
- 建議正式定名為「IP封鎖豁免權授予者」，平時行文則可簡稱為「IPBE授予者」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月24日 (三) 05:33 (UTC)
- 「IPBE授予者及新帳號創建員」--在下荷花，請多指教（歡迎簽到） 2024年1月22日 (一) 00:18 (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)
- @Ericliu1912--落花有意12138 2024年1月27日 (六) 11:05 (UTC)
- 那麼是要改名「IPBE授予者」？--落花有意12138 2024年1月21日 (日) 05:44 (UTC)
- 本來這個權限組的目的就是授予IP封鎖豁免權，其他權限都是附帶的。甚至我覺得IP封鎖豁免也應該附帶，不用兼任。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月21日 (日) 05:37 (UTC)
- @Ericliu1912：提案里的「IPBE授予者及新帳號創建員」是一個權限組，或許是這有歧義？--落花有意12138 2024年1月21日 (日) 05:32 (UTC)
- 不是持有兩個權限組，是一個權限組即擁有上述權限。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月21日 (日) 05:22 (UTC)
- @Ericliu1912：這個提案就是這個意思，不知道是哪裡有歧義？--落花有意12138 2024年1月21日 (日) 04:52 (UTC)
選舉制度和申請條件
——落花有意12138 2024年1月21日 (日) 04:16 (UTC)申請條件：
- 有意願處理IPBE和新帳號申請，了解相關方針指引，能夠友善地對待他人
- 編輯數滿1000次
- 最近一年內沒有受到封禁（不合理封禁除外）
- 在過去三個月內平均每日的編輯次數多於一次
- 已成為巡查員、回退員或傀儡調查助理三個月以上
由於授予IPBE權限時應較為謹慎，所以他們應該能被社群信任妥善處理相關事務。此用戶組在處理相關內容時會查看到用戶的IP信息，授權時應注意用戶是否可信。
權限的獲取：
具投票權的用戶可在Wikipedia:IPBE授予者及新帳號建立員/申請提名滿足上述條件的用戶為IPBE授予者及新帳號建立員。
提名發出後
- 管理員應該核對提名人和被提名人的資格，不合資格的關閉（其他用戶也可關閉），合格的留言說明
- 用戶可討論，具投票權的用戶可投票
投票進行三日後，管理員可用雪球法則關閉明顯不受社群信任投票；進行7日後，如同意票數大於等於總票數的四分之三，管理員可以關閉投票並授權；進行14日後投票截止，管理員點票，符合以下條件的授權：
- 票數大於8票
- 同意票多於二分之一
- 棄權票少於三分之一
- 不同意「棄權票少於三分之一」，無意義，反而製造擾亂規則的空隙。--路西法人 2024年1月24日 (三) 06:00 (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：感謝您的貢獻。
- 我對缺漏的地方有補充，請您核對。
- 另外，我認為還有幾點意見：
- 「洩露用戶的隱私資料」 -> 「洩露用戶的申請內容」。
- 「帳號確認或疑似被盜用」這一點是各個權限組共有的要求，這裡建議移除，另開討論。
- 「當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)
- 手動把現有沒處理的郵件轉發過去應該可以做得到。順便用單獨的郵件列表也方便管理員專注處理一般的封禁申訴，現在一般申訴也跟著存了不少沒處理。但是這裡有一個問題是封禁界面要怎麼改。blockedproxy 和 rangeblock 應該要寫不同的郵箱。--Tiger（留言） 2024年1月23日 (二) 13:59 (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)
- 這倒確實，我的永久IPBE權限也不是由「解除封鎖」而來的。Sanmosa 起視四境 而秦兵又至矣 2024年2月9日 (五) 07:05 (UTC)
- 可惜。那「unblock-ipbe-zh」如何（話說感覺個人比較在意的其實是名稱欸XD）？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月8日 (四) 17:09 (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)
- 不需要立即對管理員除權，新用戶組試行期間暫時保留管理員的權限，甚至長期保留管理員的權限供少數案例（如授予合法傀儡），都可以接受。--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)
- 「本權限可查看用戶隱私資料」，而管理員並不都簽NDA。--YFdyh000（留言） 2024年2月12日 (一) 04:30 (UTC)
- 意見同SCP-2000。其實此權限之所以設立，乃是要分擔管理員的授權責任，並不是取而代之。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月12日 (一) 15:23 (UTC)
- 那Wikipedia:IP封鎖豁免權授予者中的表述
- 本提案只是不允許未有簽署 NDA 的管理員存取「ipbe-zh」郵件列表以及 IP 資訊，而非移除管理員授予IPBE的權限。建議就此另開新討論。謝謝。--SCP-0000（留言） 2024年2月11日 (日) 17:48 (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)
- 流程不複雜，不用特地寫文檔。不論通過什麼方式收到申請都是這樣的步驟：
- 確認封禁事實（通過封禁界面顯示的IP位址、封禁ID等）
- 檢查申請人是否滿足授權條件（即Wikipedia:IP封禁豁免中的說明）
- 檢查是否可以用其他方式解決問題（比如只建立帳戶就可以繞過的軟封禁）
- 確認總共需要做哪些操作（只需要建立帳戶，還是建立帳戶+授權，或是其他的）
- 執行操作
- 回信說明申請結果、執行了哪些操作、還需要對方做什麼
- 我不確定這樣能不能說清楚整個過程，如果有具體的問題可以再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)
- 個人認為應由管理員擔任，@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)
- 我對郵件列表不熟悉，還是由其他人來比較好。--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)
- 個人認為應由管理員擔任，@WhitePhosphorus、Xiplus：不知常處理 ipbe 請求的兩位，以及其他管理員會否有意擔任？謝謝。--SCP-0000（留言） 2024年2月14日 (三) 07:33 (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)
- 請管理員建立權限相關頁面--落花有意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系統處理申請工單。理據如下：
- 不需在站外的個人郵件程式儲存包含他人個資的郵件。
- 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)
- 目前而言，IPBE相關申請陸續轉到wikipedia-zh-ipbe
- 也就是說現在ipbeg有ipbeg自己的郵件列表嗎？Bluedeck 2024年3月5日 (二) 00:17 (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)
- (＋)支持，尤其是工單號個人認為不只幫助申請人查詢進度，對授予員來說也比較容易識別哪些請求需要盡快處理。若是申請人在站外詢問也比較容易找到對應的case。-- （☎）dt 2024年3月6日 (三) 05:54 (UTC)
- 支持，聽起來有助於加快處理速度。另外，此系統部署在哪裡？--落花有意12138 2024年3月10日 (日) 05:12 (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。如果像他們那樣在表格末端放個聲明文字：
這樣應該會比較好（？--路西法人 2024年3月10日 (日) 02:02 (UTC)您提供的資料均僅會用於處理申請及防止濫用之用，並只會由已簽署保密協議的志願者處理。提交此表單即表示您同意將上述資料及您當前使用的IP位址發送給對應處理人員作上述用途。
- 終究要申請者自己勾選，但我們可以寫說不勾就不處理。--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)
- 你可以禁止提交，但不能幫用戶自動提交。--Xiplus#Talk 2024年3月10日 (日) 05:15 (UTC)
- 大概不完全是？如果寫得夠清楚（比如上方所列聲明文字），那麼已經是用戶自主提交IP而不是我們去公開他和IP的關聯，而既然不交就不處理，那麼為什麼要給提交無效申請的功能給人選擇……？--路西法人 2024年3月10日 (日) 04:20 (UTC)
- 未登錄用戶在站內編輯本來就會公開IP位址，但把已登錄用戶和IP位址連結起來，就屬於CU的權限了，郵件可依此比擬。--Xiplus#Talk 2024年3月10日 (日) 04:14 (UTC)
- 個人覺得既然未登錄的用戶都預設開啟了，那麼其實分別不大。況且需避免寫出來的指示上，未登錄用戶看到「不勾選就不處理」會覺得奇怪（尤其那個選項的系統訊息不能自己定，好像是）。--路西法人 2024年3月10日 (日) 04:07 (UTC)
- 終究要申請者自己勾選，但我們可以寫說不勾就不處理。--Xiplus#Talk 2024年3月10日 (日) 03:42 (UTC)
- m:Special:Contact/stewards也是開啟了IncludeIP。如果像他們那樣在表格末端放個聲明文字：
- 經親測（我自己的站點），設置IncludeIP下，未登錄用戶雖不會顯示「包含IP位址」欄位，但發送的電郵會自動將IP位址包含在標題欄（即預設強制開啟）。這情況下，反而是要想辦法強制登錄用戶提交IP，例如通過JS強制點選提交IP位址，並隱藏該選項。--路西法人 2024年3月8日 (五) 01:44 (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日 (二) 02:32 (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授予者「強制為全域帳號建立本地帳號」權限
實務上處理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)
- 七日無異議，公示七日至2024年3月25日。--追風（留言） 2024年3月18日 (一) 15:36 (UTC)
- @ChasingAir：公示期已結束。Sanmosa 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)
- 工單T361184已創建。追風（留言） 2024年3月28日 (四) 07:10 (UTC)
- 公示通過，稍後送P站。同時結束RFC。追風（留言） 2024年3月28日 (四) 07:05 (UTC)
- @ChasingAir：公示期已結束。Sanmosa Gloire d'Yser 2024年3月28日 (四) 06:53 (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)
- 多人支持，且論之有據者，當可認定。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月25日 (日) 16:44 (UTC)
- @Manchiu：請問「明顯沒有爭議」的具體標準是什麼呢？換句話說，社群如何判定申請人是沒有爭議的且可信任的用戶？--紹🌟煦·集思廣益 2024年2月25日 (日) 07:51 (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)
- 界面管理員的申請會出現在公告欄，請問IPBEG的申請會有同樣的（受社群關注的）程度嗎？ Stang★ 2024年2月26日 (一) 10:41 (UTC)
- 支持減少為三日，例如WP:IA里這段話「
- 是不是可以考慮減少為三日以上？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月26日 (一) 09:01 (UTC)
建議修訂草案：
提名發出後
- 管理員應該核對提名人和被提名人的資格，不合資格的關閉（其他用戶也可關閉）
- 用戶可參與討論及表態是否贊同申請，並附以理由支持
- 可用雪球法則關閉明顯不受社群信任的投票
符合以下條件的可以授權：
- 票數大於4票
- 同意票多於二分之一
投票進行三日後，符合條件者，管理員可以關閉投票並授權；如果三日後尚未符合條件，則應延長投票期至七日；若七日內未有任何用戶投票，則可延長投票期至十四日並發公告至公告欄。投票截止後，是否批准申請最終由管理員按討論內容決定。
--桐生ここ★[討論] 2024年2月26日 (一) 10:52 (UTC)
- 同意。申請條件基本上使得申請的都屬可信用戶，3日我認為足夠時間收集社群同意票。-千村狐兔（留言） 2024年3月21日 (四) 11:46 (UTC)
- 支持。--Kriz Ju（留言） 2024年3月22日 (五) 21:55 (UTC)
IP封禁豁免授予者的一些問題
- 沒有簽署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)
- 我的意思是每位IPBEG授予IPBE的權限不一樣，有人直接授予長期IPBE權限，有人授予一年IPBE權限。我建議是參考en先授予短期，比如統一首次申請授權一年，再次申請根據考量可授權長期。--桐生ここ★[討論] 2024年3月10日 (日) 11:51 (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)
- 圖標中的「門」代表的是那些因網絡限制而僅能通過開放代理編輯維基百科的用戶所遭到的阻攔（此指IP封禁），而開著的「門」則指出IP封禁豁免權授予者的職權——通過授予IPBE將那些用戶受到的阻攔「打開」。至於黑暗模式下看不清的問題，容我等會修改一下圖標。--人間百態,獨尊變態(討論) 2024年4月14日 (日) 13:55 (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)
- @人間百態 I felt good. @MilkyDefer What's your opinion? -Lemonaka 2024年4月16日 (二) 15:16 (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)
- @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)
- @Cookai1205@Lemonaka,OK,I've uploaded a new version.See if you have any problems.--人間百態,獨尊變態(討論) 2024年4月20日 (六) 12:38 (UTC)
- 我想Lemonaka應該是指鑰匙大小位置同此版本不變，但鑰匙尖端指向右下角。--Cookai餅塊🍪（💬留言） 2024年4月19日 (五) 18:43 (UTC)
- like this?--人間百態,獨尊變態(討論) 2024年4月19日 (五) 14:16 (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)
- ... 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)
- 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)
該話題最近的留言距今也已過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)
- @ASid：Wikipedia:帳號請求#管理員操作指南：「由賦權管理員將通過申請的使用者名稱連同申請理由，存檔到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)
修訂IP封禁豁免及IP封鎖豁免權授予者方針
- IP封禁豁免
由於Unblock-zh.org已經試營運近50日，本人現在提出修訂現有IP封禁豁免方針（WP:IPBEPROXY部分），詳細修訂條文見下：
|
|
--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、だ＊ぜ：不好意思打擾各位，由於我的意見與各位有相關所以想請各位過來討論，如有打擾還望見諒，謝謝。
- 以上請社群考慮一下我的意見，十分感謝。--~~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封禁豁免權授予者方針，詳細修訂條文見下：
|
|
--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)
|
|
- (＋)支持 Benho7599 堅決擁護以芙寧娜同志為核心的楓丹 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)
就將條件放寬至自動確認用戶的方案 公示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)
- 本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。