维基百科讨论:回退功能/存檔2

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

將Wikipedia:回退功能#移動時不留重定向合併到Wikipedia:重定向#移動時不留重定向

本主題或以下段落文字，移動自WP:VPP。执行者：SANMOSA 江南好，風景舊曾諳 2021年3月17日 (三) 06:03 (UTC)。

通過。SANMOSA 江南好，風景舊曾諳 2021年3月17日 (三) 06:00 (UTC)
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

理由如下：

  1. 此權限跟Wikipedia:回退功能沒有太大的關連，個人認為純粹是回退權裡包含此權限因此寫入此處
  2. 有機率導致像是Wikipedia_talk:重定向#分类重定向的情況

-- Sunny00217  2021年2月11日 (四) 16:08 (UTC)

WP:回退员重定向到回退功能页面。“如有违反前述原则，当以除权处理。”对方针有意义，需要解决。--YFdyh000（留言） 2021年2月11日 (四) 16:12 (UTC)
Suppress redirect 也與反破壞有關，不認為完全無關聯。 2021年2月11日 (四) 16:14 (UTC)
因為連巡查員也有-- Sunny00217  2021年2月12日 (五) 06:36 (UTC)
與反破壞有關+1。但若欲改為留下連結，合併重複內文於一處，使未來容易維護，亦無不可。--Hjh474（留言） 2021年2月12日 (五) 02:34 (UTC)
現擬議修改WP:重定向、WP:回退功能、WP:新頁面巡查如下：
WP:重定向：
現行條文

移動時不留重定向

主页面：Wikipedia:回退功能 § 移動時不留重定向
快捷方式

一般來說，移動頁面時，會自動留下重定向。某些用戶組（擁有suppressredirect權限的用戶）可以通過取消選中標有「保留重定向」的框來阻止創建重定向，稱為移動時不留重定向（suppressing redirect）。目前，這些群組包括管理員、巡查員、回退員等。在某些情況下，移動頁面時自動創建的重定向是不恰當的——例如文章曾被移動破壞至不良標題。不留重定向即可節省移動後刪除重定向的時間和麻煩。

一般情況下，重定向是歷史紀錄中一個有用的條目，所以除非有充分理由移動時不留重定向（例如故意破壞，將放錯位置的內容轉移到用戶空間或釋放標題以便另一頁面佔用），最好將其留下。重定向留下幫助讀者找到舊文章一條線索，以防在其先前位置創建新文章，並防止連結失效。因此，我們通常既不移動時不留重定向，也不刪除重定向。

提議條文

移動時不留重定向

快捷方式

一般來說，移動頁面時，會自動留下重定向。某些用戶組（擁有suppressredirect權限的用戶）可以通過取消選中標有「保留重定向」的複選框來阻止創建重定向，稱為移動時不留重定向（suppressing redirect）。目前，這些群組包括管理員、巡查員、回退員等。在某些情況下，移動頁面時自動創建的重定向是不恰當的——例如文章曾被移動破壞至不良標題。不留重定向即可節省移動後刪除重定向的時間和麻煩。移動而不留重定向依舊會記錄在案，不過會加上「不留重新導向」的標示。

一般情況下，重定向是歷史紀錄中一個有用的條目，所以除非有充分理由移動時不留重定向，最好將其留下。重定向留下幫助讀者找到舊文章一條線索，以防在其先前位置創建新文章，並防止連結失效。因此，我們通常既不移動時不留重定向，也不刪除重定向。

何時可移動而不留重定向 當重定向符合快速刪除方針，特別是G3（故意破壞）、O1（應用戶要求在該用戶空間下移動頁面或從該用戶空間下將頁面移動到主名字空間），或將放錯位置的內容轉移到用戶空間，或須釋放標題（騰空頁面）以便另一頁面佔用時候，即可移動而不留重定向。

何時不可移動而不留重定向 用戶不得利用權限於命名爭議中奪取優勢、無視命名爭議而使用權限或者將權限用於破壞。巡查員、回退員如有違反前述原則，當以除權處理。

WP:回退功能：
現行條文

移動時不留重定向 移動頁面時，預設會留下重定向。然而，有時留下重定向會增加後續工作，並不理想，例如回退頁面移動破壞，又或者需要騰空頁面以便移動其他頁面。當擁有「移動時不留重定向」權限時，移動頁面時就可以於移動頁面介面取消剔選「留下重新導向頁面」框框。如此，就可以移動頁面而不留重定向。移動而不留重定向依舊會紀錄在案，不過會多一句「不留重新導向」。

何時可移動而不留重定向 當重定向符合快速刪除方針，特別是G3、O1，即回退移動破壞或應用戶要求在該用戶空間下移動頁面或從該用戶空間下將頁面移動到主名字空間。

何時不可移動而不留重定向 用戶不得利用權限於命名爭議中奪取優勢、無視命名爭議而使用權限或者將權限用於破壞。如有違反前述原則，當以除權處理。

提議條文

移動時不留重定向

主页面：Wikipedia:重定向 § 移動時不留重定向
WP:新頁面巡查：
現行條文

移動時不留重定向

主页面：Wikipedia:回退功能 § 移動時不留重定向

移動頁面時，預設會留下重定向。然而，有時留下重定向會增加後續工作，並不理想，例如回退頁面移動破壞，又或者需要騰空頁面以便移動其他頁面。當擁有「移動時不留重定向」權限時，移動頁面時就可以於移動頁面介面取消勾選「留下重新導向頁面」复选框。如此，就可以移動頁面而不留重定向。移動而不留重定向依舊會紀錄在案，不過會多一句「不留重新導向」。巡查員運用此權限時，應遵守回退功能方針相關段落規定。

提議條文

移動時不留重定向

主页面：Wikipedia:重定向 § 移動時不留重定向

以上。如通過，有關移動時不留重新導向權限的規定將統一整合至WP:重定向（包括有關除權規定），而WP:回退功能與WP:新頁面巡查則只留下章節連結。SANMOSA SPQR 2021年2月18日 (四) 01:15 (UTC)

@Sunny00217、YFdyh000、Pseudo Classes、Hjh474。SANMOSA SPQR 2021年2月18日 (四) 01:17 (UTC)
没什么意见。把“纪录”更正“记录”吧。--YFdyh000（留言） 2021年2月18日 (四) 01:27 (UTC)
@YFdyh000：完成。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 02:22 (UTC)
@YFdyh000：名詞是用「紀錄」沒錯，動詞才是「記錄」。我改的一處正是本是動詞的地方。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 02:37 (UTC)
不是名词动词问题吧，纪录用于成绩统计层面（纪录片除外），记录才是文字层面。难道有地区词差异。--YFdyh000（留言） 2021年2月20日 (六) 02:51 (UTC)
@YFdyh000：《文書處理手冊》附錄2（第60頁）。（意外發現地區詞差異）SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 03:05 (UTC)
有点搞不清，可能需另议或字词转换……在中国大陆，纪录主要是最好成绩或总结归纳，会议记录、历史记录等不会写纪录，个人健康纪录也一般是“个人健康记录”。此博客提到文书所用动词/名词分法，但评论也有不同意见。--YFdyh000（留言） 2021年2月20日 (六) 04:11 (UTC)
@YFdyh000：恐怕不能用字詞轉換處理，因為誤轉機率太高：有些地方的使用是一樣的，但有些地方的使用是完全不同的。《文書處理手冊》是臺灣官方文件，我給予的連結也是政府網站連結，我認為沒辦法質疑。繁體來說是會寫「會議紀錄」、「歷史紀錄」的（至少前者我非常肯定）。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 04:18 (UTC)
指在方针指引页（如Wikipedia:R）转换。浏览器的“历史记录”我是很确定的。--YFdyh000（留言） 2021年2月20日 (六) 04:36 (UTC)
（1）問題完全一樣，在任何地方轉換都會出現一樣的問題。（2）科技公司經常會忽略地區用詞差異，不能作準。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 07:56 (UTC)
你这一“不能作准”，中国大陆所有软件和文献就都是错的了。我非常确定99%+将History称作历史记录，历史纪录是Best record。在此题中讨论可能不大合适。--YFdyh000（留言） 2021年2月20日 (六) 08:06 (UTC)
@YFdyh000：至少在繁體不能作準吧。如果是中國大陸公司開發的browser，在中國大陸簡體下反而是可以作準的。如果沒其他問題的話，我就不再修改提案了。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 13:57 (UTC)
代為標示{{新增條文}}，請幫確認有無錯漏。--Hjh474（留言） 2021年2月18日 (四) 02:17 (UTC)
{{刪除條文}}也加上了。SANMOSA SPQR 2021年2月18日 (四) 02:26 (UTC)
原來巡查權那裏也有一段-- Sunny00217  2021年2月18日 (四) 03:10 (UTC)
是不是需要公示貼公告板？--Hjh474（留言） 2021年2月26日 (五) 02:46 (UTC)
@Hjh474：你是不是忘了WP:7DAYS？SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 10:25 (UTC)
👍 赞。--Hjh474（留言） 2021年3月1日 (一) 10:29 (UTC)
現公示7日。SANMOSA 江南好，風景舊曾諳 2021年3月10日 (三) 10:38 (UTC)
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

下放移動主頁面時一併移動子頁面權限

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2021年10月13日 (三) 16:14 (UTC)。

我在上方#提议设立维护员权限的討論中提到可以下放move-subpages權限予巡查員、回退員等用戶，現在我會提出具體提案，內容如下：

  • 權限內容：移動主頁面時一併移動最多100個子頁面
  • 下放對象：巡查員、回退員、介面管理員
  • 下放原因：方便回退員更有效率地回退涉及子頁面的移動爭議及破壞，方便巡查員、模板編輯員、介面管理員於為存在子頁面的頁面更名時更有效率地完成更名操作

就以上內容，現提出新增以下方針：

Wikipedia:介面管理員
Help:页面重命名（設為章節方針）
Wikipedia:新頁面巡查、Wikipedia:回退功能、Wikipedia:模板編輯員

以上。可分別討論巡查員、回退員、模板編輯員、介面管理員是否適合擁有此權限。Sanmosa Outdia 2021年9月25日 (六) 03:31 (UTC)

(＝)中立，但建议给有suppressredirect的。--安忆Talk 2021年9月25日 (六) 05:15 (UTC)
註：有suppressredirect權限者包括管理員（本已有move-subpages權限）、巡查員、回退員。Sanmosa Outdia 2021年9月25日 (六) 08:01 (UTC)
看了看后续讨论，感觉这个权限比较适合用来批量移动Mediawiki:xxx/* User:xxx/*，而不是用在和条目有密切关系的空间。--安忆Talk 2021年9月26日 (日) 16:19 (UTC)
(＋)傾向支持：有時候移動一個頁面還要檢查一大堆子頁面真的很痛苦。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年9月25日 (六) 12:53 (UTC)
由於本功能的問題，使用本功能仍然要檢查一大堆子頁面，因此並沒有方便許多。--Xiplus#Talk 2021年10月4日 (一) 03:31 (UTC)
先想想有什麼具體情況會用到這個權限，才會知道對不同使用者群組的是否真的有幫助，找找曾經動用過本權限的具體案例對討論應相當有幫助。例如提案中「回退涉及子頁面的移動破壞」，破壞者通常沒有移動子頁面權限，我移動破壞還給你乖乖按著子頁面結構移動？當然是給你亂移動啊，因此「回退涉及子頁面的移動破壞」根本不切實際。--Xiplus#Talk 2021年9月26日 (日) 01:16 (UTC)
@Xiplus：或許我更正一下字眼：「移動爭議及破壞」。我不排除有LTA真的會按著子頁面結構移動，但考慮到更多情況下是編輯爭議所引發的移動戰，參與移動戰的用戶自然會按著子頁面結構移動，因此為回退移動戰，有必要授予此權限予回退員。Sanmosa Outdia 2021年9月26日 (日) 01:25 (UTC)
不反對您的說法啦，但無法說服我...移動子頁面的功能其實限制多，所以很難用，只有簡單的情況我才會去用它，不然都是一個一個移動比較穩當，所以我覺得很難用來處理移動戰。退一步來說就算能夠處理，回退員沒有足夠的權力來制止移動戰，只有管理員才有（即保護），回退員使用此權限也只是參與移動戰而已，而不是處理移動戰。--Xiplus#Talk 2021年9月26日 (日) 12:28 (UTC)
容許我舉之前的一個解除權限申請的案例：Antigng的提請理由是“在沒有附上編輯摘要的情況下回退爭議性編輯，有違回退方針對這種回退僅限於明顯非建設性編輯的限定”，我當時給的意見是“恢復編輯戰發生前的最後一個穩定版本是標準的編輯戰處理程序，基本上就是等管理員來保護而已”，結案的管理員Shizhao在我的意見的基礎上否決了除權申請。我認為只要回退員盡其所能恢復編輯戰發生前的最後一個穩定版本，那就已經算是某程度上的“處理”了，就算不是“處理”，也肯定是協助處理。Sanmosa Outdia 2021年9月26日 (日) 14:26 (UTC)
不同意，Wikipedia:保護方針#使用和处理编辑请求：「若頁面出現編輯爭議需要全保護，管理員可以在執行保護之後，由保護的管理員本人將頁面回退到爭議發生前的較早版本」，僅有執行保護的管理員本身可以決定是否要回退，若執行保護的管理員決定不回退，其他管理員也沒有權力回退，更不用說保護前回退員的回退行為，認定為處理編輯戰完全不正確。--Xiplus#Talk 2021年9月26日 (日) 15:23 (UTC)
劃綫：“執行保護之後”。如果回退員在管理員施行保護前已經恢復編輯戰發生前的最後一個穩定版本，那管理員自然在施行保護後不會進行回退，這可以算是為管理員省工夫，因此應該被認定為“協助處理”。Sanmosa Outdia 2021年9月29日 (三) 05:51 (UTC)
回退員不能保證在封禁/保護前是否會被再次回退，除非破壞內容相當嚴重（需要OS之類的），否則回退員不應堅持持續進行「反破壞戰」，僅沖刷頁面歷史而無明顯益處，使用該權限對大量頁面進行「反破壞戰」我更要反對了。--Xiplus#Talk 2021年9月29日 (三) 08:45 (UTC)
剛剛試了一下。大家應該都知道目標頁面存在時是無法移動過去的，管理員在移動介面會有一個額外選項是「移動同時刪除目標頁面」，但在移動子頁面時，就算勾了這個選項，只要某個子頁面目標頁面存在，該子頁面的移動會在沒有任何提示的情況下失敗，而其他頁面會移動成功，造成部分頁面未移動而分隔兩地，就算回退員發現該情況，也沒有刪除權限來修復，只會讓情況變得更糟。--Xiplus#Talk 2021年9月26日 (日) 12:45 (UTC)
@Xiplus：理論上可以通過把目標頁面臨時移開來解決（回退員有suppressredirect權限）。不知道能不能跟PHAB提議一下在使用移動主頁面時一併移動子頁面權限時，如果某個子頁面的目標頁面存在而導致移動失敗，系統能給個失敗提示。Sanmosa Outdia 2021年9月26日 (日) 14:26 (UTC)
我自己是反對這樣的操作，就算回退員移動開頁面，仍然需要管理員來執行刪除，回退員搶先操作並沒有減輕管理員的工作量，反而將頁面移動到不相干的名稱，讓刪除日誌保存在其他名稱之下，變成一個缺點。雖然問題很小，但我仍然認為這是對suppressredirect的濫用。--Xiplus#Talk 2021年9月26日 (日) 15:31 (UTC)
這個要直接上報phab了吧？-- Sunny00217  2021年10月5日 (二) 14:56 (UTC)
另外，也考慮到回退員有suppressredirect權限，可以協助處理移動請求（巡查員同），因此授予此權限予回退員亦可令回退員在協助處理移動請求上更為便利（我預想到的情況是{{Infobox road2}}）。Sanmosa Outdia 2021年9月26日 (日) 01:28 (UTC)
至少我能確定模板編輯員不會用到這個權限，如果要移動受模板保護的模板，必須待社群有共識才能移動，那麼由管理員執行就夠了，反正移動的積壓也不嚴重，更不用說同時移動子頁面。就需求來說，模板編輯員應該比較需要轉換內容模型的權限，畢竟光是測試CSS就要從模板移動到使用者頁面（我不相信CSS沙盒），太累了。 2021年9月28日 (二) 12:33 (UTC)
那可以把模板編輯員排除掉。Sanmosa Outdia 2021年9月29日 (三) 05:51 (UTC)
已去除，不存檔至Wikipedia talk:模板編輯員。 2021年9月29日 (三) 14:37 (UTC)
應該正面表列「可以使用的情況」，這才能做為支持該提案成立的理由，「為存在子頁面的頁面更名時更有效率地完成更名操作」是對於該功能的描述而不是下放權限的理由。--Xiplus#Talk 2021年10月4日 (一) 03:37 (UTC)

再提拆分回退員之私密過濾器源碼閱讀權至另一用戶組

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年2月11日 (六) 16:14 (UTC)。

過往多次討論見Wikipedia_talk:防滥用过滤器#提议修改维基百科:防滥用过滤器。簡介:鑑於目前回退員中有內鬼，過往數年洩漏過濾器詳情，導致反破壞工作受到不少影響。此事亦進一步影響到回退員可否兼領其他權限(如LTA private wiki的閱讀權限)的質疑，導致反破壞權限改革無法推進。

為此，再次建議拆分回退員之AF源碼閱讀權(abusefilter-view-private)，以收緊其獲得人數。該新用戶組的成員應高度可信，且在反破壞工作中保持活躍。

請諸君討論。--Temp3600（留言） 2022年10月30日 (日) 12:24 (UTC)

個人傾向(＋)支持，但應該考量到之前提出的問題（如對過濾器並沒有那麼了解的回退員間接造成接觸到的資訊差異）。我是有想過一折衷方案（前提是技術上可行）：過濾器觸發時只截取出觸發的部分，而非顯示過濾器完整結構。這樣也能幫助看不懂AF是做什麼的回退員比較能夠理解觸發原因。--（☎）dt 2022年10月31日 (一) 01:50 (UTC)
哇你这想法有点天方夜谭诶，过滤器做不到这一点，或者说我就没见过哪儿有能展示这种信息的东西。GDB和LLDB我都没印象有这种工具诶（--MilkyDefer 2022年10月31日 (一) 02:09 (UTC)
如果连回退员都看不懂触发器语法的话，要这个权限有什么意义，还不如支持AF助理方法，让懂得人自己去检查或者协助修改AF。而且展示出触发的语法部分估计现在AF的实现根本没有这样的功能，还要mw开发组来实现（或者自己推修改补丁）。只能说有点异想天开。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月31日 (一) 02:19 (UTC)
程序上极难实现，只能人工处理，那似乎等同条文上允许某种“查阅请求”。--YFdyh000（留言） 2022年10月31日 (一) 02:28 (UTC)
那算了（看到時全域有沒有這個需求、mw開發出來再說，原本只是想有沒有人寫個小工具就可以解決），就把abusefilter-view-private去掉就好。「另一使用者群組」可以考慮由回退員之間選出，之後由管理授權吧。--（☎）dt 2022年10月31日 (一) 03:49 (UTC)
(＋)强烈支持。--路西法人 2022年10月31日 (一) 03:31 (UTC)
(！)意見：上一次讨论进行了近四个月，最终也没能达成共识。“共识是可以改变的，但如果你要提出类似的提案，应该解决过去的反驳意见”（WP:常年提案）。个人想知道此次讨论较上次讨论有何变化？另外，似乎最近由过滤器详情泄露引起的破坏有所减少？--Yining Chen（留言|签名页） 2022年10月31日 (一) 05:53 (UTC)
上一次的討論一開始沒有考慮分拆，而直接將權限收回管理員，引起不滿；後來又因為ip masking導致困難重重。這次只處理核心部分，即AF分家。其他問題容日後再處理。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)
更改一下说法，IP masking方面问题不大。 Stang★ 2022年11月11日 (五) 19:10 (UTC)
感謝補充，但仍建議下一步再處理此問題。--Temp3600（留言） 2022年11月17日 (四) 04:35 (UTC)
我記得上次諸位就是同意居多，問題似乎在技術阻礙？個人對此提議自然是(＋)支持。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年10月31日 (一) 07:27 (UTC)
上次是提到了phab:T309318。如果不考慮IP masking的話就應該沒事。 ——魔琴 [ 留言 贡献 ] 2022年10月31日 (一) 08:01 (UTC)
对建立反LTA类型的用户组无异议，但希望同期建立有效、便捷渠道或规则为可信用户处理相关咨询，如回退员的合理询问和建议，以解决部分用户的偶发需求。--YFdyh000（留言） 2022年10月31日 (一) 07:37 (UTC)
這方面我有一計，但暫時想不出要怎樣配合中維的情況來實施：強化维基百科:反破壞工作小組的職能，將建立為「反破壞專家」的公會。--Temp3600（留言） 2022年10月31日 (一) 14:42 (UTC)
能不能提出什麼具體議案或者說服力的理據，「彷彿劇團每隔一段時間重複演出同樣的戲碼」，我是比較無奈的。上次不是說要將IPInfo和IP masking合併到這個新的用戶組，然後就沒下文了。--Ghren🐦🕓 2022年10月31日 (一) 09:09 (UTC)
這次希望先解決目前的問題，IP masking目前還沒有起色，合併進來的話就搞不下去了。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)
之前的討論參考了YF君提供的意見，我提出的意見的確有捨本逐末之嫌。既然回退員主要工作是快速回退破壞，那麽側重點應當是對回退相關方針的理解程度至少可以讓社群信服做與反破壞相關的工作。而不是技術（例如私密濫用過濾器）能力，因爲其側重點無法保證回退員具備此種能力或與其相對應的操守。所以(＋)支持拆分權限。--紹💓煦集思廣益 2022年11月5日 (六) 07:44 (UTC)
(＋)支持拆出Wikipedia:過濾器助理。--冥王歐西里斯（留言） 2022年11月5日 (六) 12:37 (UTC)
感谢X43现身说法证明拆分的需要。--Ghren🐦🕙 2022年11月26日 (六) 14:48 (UTC)

名字與細則

過往的方案見Wikipedia:過濾器助理。歡迎各位討論。--Temp3600（留言） 2022年11月5日 (六) 17:25 (UTC)

(＋)支持以上提案。--冥王歐西里斯（留言） 2022年11月7日 (一) 03:05 (UTC)

題外話

( π )题外话 如果有查看已删除页面的权限（browsearchive、deletedtext，deletedhistory不确定）或用户组，可能更方便某些任务（侵权、G5、破坏等历史页面的核查）。--YFdyh000（留言） 2022年11月8日 (二) 13:38 (UTC)
您是不是要找：WP:删除员，WP:维护员。[開玩笑的]--Yining Chen（留言|签名页） 2022年11月8日 (二) 14:11 (UTC)
准确说，去掉删除/恢复权限的“删除员”。不知道社群是否有兴趣加在新用户组上。目前是通过WP:AR，但时效性不好。--YFdyh000（留言） 2022年11月8日 (二) 14:59 (UTC)
？？去掉刪除/恢復權限還算是什麼刪除員。--Ghren🐦🕓 2022年11月11日 (五) 08:45 (UTC)
你的逻辑是不是有点混乱？这也没说这是要启用删除员，这只是探讨一个与删除员类似，在具体权限上有所限制的<未知>而已。--MilkyDefer 2022年11月11日 (五) 12:42 (UTC)
所以我说的不是删除员，而是能查阅私有（非公开）记录的另一组权限，是否能合进去，参考蓝桌图书馆、已删百科等需求。已知新权限开放给高度可信用户，唯低于管理员。大多数已删除页面，只是出于维护，可能没有保密需求，需要保密的要监督。权限组可以命名如“非公开记录查看员”（Non-public record viewer）。--YFdyh000（留言） 2022年11月11日 (五) 13:31 (UTC)
你这个“非公开记录”很容易让人联想到真的要签字且具有法律效力而且大陆人不能签的NDA欸，你要不改个名字吧。--MilkyDefer 2022年11月11日 (五) 15:35 (UTC)
这是考虑到私有对应的private与“隐私”相同，担心误解。要不然，“私有记录查看者（Non-public record viewer）”，中英非一致译法。或者，进阶记录查看者，但表意很模糊。--YFdyh000（留言） 2022年11月11日 (五) 16:12 (UTC)
查閱員這個名字如何？可以查看AR，也可以查看過濾器。桐生ここ★[讨论] 2022年11月12日 (六) 04:19 (UTC)
很难，或者你需要让这个组拥有类RfA的授予标准（社群页面公布请求、不少于7天的投票云云）。 Stang★ 2022年11月11日 (五) 19:10 (UTC)
建議先完成分柝，再進一步調整，避免再次流產。--Temp3600（留言） 2022年11月14日 (一) 02:37 (UTC)
最近不授予回退权是不是和这有关？Evesiesta 2022年11月27日 (日) 17:07 (UTC)
不清楚，但應該沒有關係。--Temp3600（留言） 2022年11月27日 (日) 18:53 (UTC)

初步方案

按舊稿修改了一份草稿:過濾器助理，請諸君討論。--Temp3600（留言） 2022年11月15日 (二) 16:35 (UTC)

题外话#2：全域的m:Abuse filter helpers就是「过滤器助理」，不知道为什么要翻译成「防滥用编辑器帮助者」，是时候正名一下了（叫全域过滤器助理？会不会误以为是「全域过滤器」的助理？） ——魔琴 [ 留言 贡献 ] 2022年11月15日 (二) 16:46 (UTC)
@Liuxinyu970226：還在嗎--Temp3600（留言） 2022年11月15日 (二) 17:14 (UTC)
赞成更名，“全域过滤器助理”挺好的。“帮助者”应只是粗译遗留。--YFdyh000（留言） 2022年11月16日 (三) 11:03 (UTC)
问题一：對比中維和英維的兩個過濾器助理頁面，英維是只有admin以上的用戶有abusefilter-view-private權限，那在中維，abusefilter-view-private的權限應該是像現在一樣，回退員也有，還是管理員以上的才有這個權限？
問題二：查看垃圾链接阻止列表日志這個權限在英維得是過濾器助理以上的用戶才有，但是中維只要是個User就有了，要不要調整之類的。一直不理解為什麼為什麼過濾器39、92是不公開的，但是黑名單的閱讀權限就放得這樣低。（這算是個無關問題，只是剛好看到而已）
問題三：启用双重身份验证有這個需要嘛？在我的眼中這不是一個很重要的權限，不一定要雙因素驗證。--Ghren🐦🕘 2022年11月16日 (三) 01:53 (UTC)
1. 英维的管理员数量多很多。讨论的不就是该权限从回退员移到低于管理员的新用户组吗。2. 不了解这个权限。3. 有一定必要，已知需求源自“潜伏”风险，而查看过滤器不留日志，可能难以感知账号被盗用？--YFdyh000（留言） 2022年11月16日 (三) 11:07 (UTC)
啊，抱歉，我看錯了。問題一應該是這樣：對比中維和英維的兩個過濾器助理頁面，英維是只有admin以上的用戶有abusefilter-log-private權限（查看标记为私密的过滤器的过滤日志），那在中維，abusefilter-log-private的權限應該是像現在一樣，回退員也有，還是管理員以上的才有這個權限？我複製的時候沒看清楚。不好意思。我想知道「查看标记为私密的过滤器的过滤日志」這個權限是也是收回，還是繼續保留在回退員上比較好。--Ghren🐦🕘 2022年11月16日 (三) 13:04 (UTC)
一起移入新用户组。--YFdyh000（留言） 2022年11月16日 (三) 22:05 (UTC)
現在完全沒有討論要取消回退員abusefilter-log-private權限。也看出不出這個方案打算這樣辦。過去共識看來也不打算這樣辦。那是否要重複給這新用戶組這個權限就是個問題。要从回退員手中收回這個權限，要更深的討論。--Ghren🐦🕚 2022年11月17日 (四) 03:36 (UTC)
本提案讨论的是解除回退员的abusefilter-view-private权限；英维也是User持有，为什么放的这么低请参阅gerrit:405670；“须有良好账户保安操守，例如开启双重认证（2FA）、设立高强度密码、电脑不受恶意程序感染等”。 Stang★ 2022年11月16日 (三) 12:37 (UTC)
  • 感謝各位的回應。「拆分回退員之私密過濾器源碼閱讀權至另一用戶組」指的是移除回退員的abusefilter-view-private權限，並邀請社群中仍希望保留該權限的用戶申請加入新用戶組。回退員的abusefilter-log-private權限不在本討論範圍，但由於新用戶組的成員可獲得log-private權限，該權限獲得人數將可能上升。--Temp3600（留言） 2022年11月17日 (四) 04:45 (UTC)
    方案草稿中“资格要求”的第六点，在实际实行中似乎很难做到。缺乏有效的方式证明某用户是否可信。--Yining Chen（留言|签名页） 2022年11月17日 (四) 11:12 (UTC)
    我看英維這一條也是自由心證而已，總之沒有人對這一點提出質疑就算是過關。--Temp3600（留言） 2022年11月17日 (四) 14:54 (UTC)
    显然是基于共识，消除合理质疑。可能需要如一周或两周的公示期。--YFdyh000（留言） 2022年11月17日 (四) 15:25 (UTC)
    确实缺乏有效的方式，共识制要求社群成员的绝大多数对于何为可信任有良好的认知，并有良好的说理能力。但我不认为我们的社群能达到这个要求。英文维基百科以我有限的观察也只能说是勉强达到。实际做起来，做还是能做的，但多少会把问题积累起来到以后产生比较大的麻烦。--Tiger（留言） 2022年11月22日 (二) 17:03 (UTC)
    坦率說，在中維上高度可信要求可能無法嚴格地執行。但考慮到目前回退員持有view權是"沒有要求"，本項至少能收緊一些限制，並為解除不適合者的權限提供法規上的支持。--Temp3600（留言） 2022年11月27日 (日) 16:55 (UTC)
    尚且不谈中维潜在的地区（组织）割裂（不信任）问题，假若将标准放得如此低，那么是否反面说明不可信用户（潜在的破坏者）也可顺利担任回退员？换言之，假若该方案能够实施，那么就根本没有必要另设权限，只要找到“社群成员”对当前回退员列表逐一审查，把所有“不可信用户”都移权+封禁，即可解决问题。又若模拟权限设立后的“公示”，那么只要现在开放一个讨论，所有用户都可在其中指认自己认为“不可信”的回退员，最后统一公示一段时间以后直接移权即可，完全没必要设立新权限嘛。如果在措施不完善的情况下贸然设立一个新权限，恐怕无益于反破坏问题的解决，反而不如不设立AFH权限，而由管理员代为处理源码阅读请求。--Yining Chen（留言|签名页） 2022年11月28日 (一) 11:12 (UTC)
    首先，目前已經有破壞者現正擔任回退員，這在上次的討論已經有不少用戶和管理員表達過。您所指的「排查回退員」方案，上次也有人提議過，但執行十分困難——部份回退員並不活躍，或已經退出一線反破壞工作多年，現行方針並無任何規則可用於解任他們，而且單憑猜疑，解任用權恰當但沒有參與反破壞工作的回退員在實務上也不可行。現行機制的弱點，正是破壞者可以先混到回退員，然後保持低活躍狀態，以此逃避反破壞小組的監視，而使用abusefilter-view-private權限亦無任何紀錄可查，導致無任何方法可以找出此等內奸。其次，直接由管理員查閱的方案上一次也有討論過（應該先上一次最先就是討論此方案），並已經被社群駁回。--Temp3600（留言） 2022年11月29日 (二) 14:39 (UTC)
    您所说的“单凭猜疑”解任回退员，与“单凭猜疑”拒绝AFH申请有什么区别呢？--Yining Chen（留言|签名页） 2022年11月30日 (三) 01:55 (UTC)
    拒絕AFH申請的主要原因應是「用戶不符合資格要求」，即身為回退員但未有在反破壞工作中活躍；自稱將維護AF但沒有兌現承諾等。這些都是客觀的理由。至於分別，則在於AFH與回退員所需的信用等級不同。回退員如無法取閱敏感資料，則其權限可造成的破壞十分有限，要求先有違規行為後再解任依然合適；但AFH可以取得敏感資料，且缺乏監察途徑，即使沒有過違規行為，仍有可能不適合獲權。--Temp3600（留言） 2022年11月30日 (三) 03:25 (UTC)
    那么该如何处理地域问题呢？作为例子，2022年9月管理员选举中有两名候选人被质疑“與WMC關係千絲萬縷”“前與WMC的關係緊密”“WMC仍潛伏於社羣中”，可见某些人至今仍不能做到对WMC成员在处理隐私信息（广义）方面的基本信任。该如何才能确保此类偏见在AFH的申请过程中不会出现，并且不会对申请过程造成干扰呢？或是说AFH权限不接受WMC成员（即大陆用户）的申请？--Yining Chen（留言|签名页） 2022年11月30日 (三) 05:22 (UTC)
    另设用户组仅是遵循最小权限原则。对于双面人问题，目前权限机制（无日志）不能解决，要依靠其他方法。--YFdyh000（留言） 2022年11月30日 (三) 07:05 (UTC)
    我承認這個問題很難回答。維基百科的底層邏輯是信任社群共識，而您的說法意指社群共識本身就存在偏見，要求以另一種權力來源來平衡共識，這涉及複雜的權力平衡設計，恐怕不是我幾天內就能想像出來的。但或許我以下的觀點可稍為安慰：大體而言，社群的權限投票還是講證據的，在RFA的明票年代更是如此。計劃中AFH的申請不是投票，也不會使用securepoll，申請人無須擔心被流言暗箭攻擊而無從反駁。--Temp3600（留言） 2022年12月3日 (六) 15:23 (UTC)

Kriz Ju的建議：提高對AFH的技術要求

  • (！)意見：個人支持方案草稿，綜觀上方站友討論，個人對相關條文微調意見如下：
  • 「申請程序」：「如果您有意申請過濾器助理的權限，請親自到Wikipedia:權限申請/申請過濾器助理權限申請。申請時，經由至少一名已擁有此項權限的回退員，或者具備過濾器相關站務經驗的管理員具名支持後，由具備過濾器相關站務經驗的管理員綜合評估授權；進行授權的管理員不可和前述的具名支持者為同一人。申請者若由於合理因素而無法完成申請條件，可考慮提出具體事由，在客棧尋求協助或發起討論，而擁有相關站務經驗的管理員應對於獲得客棧討論認可的申請者直接完成授權。」
  • 「資格要求」：
  • 6.「經社群討論，認可為高度可信之使用者」
  • 7.「申請者應對正则表達式有基本認識，並且須由擁有相關站務經驗的管理員授權。」個人意見，供參。--Kriz Ju（留言） 2022年12月9日 (五) 19:33 (UTC) --Kriz Ju（留言） 2022年12月13日 (二) 11:12 (UTC)--Kriz Ju（留言） 2022年12月19日 (一) 17:38 (UTC)
( π )题外话 & (...) 吐槽：您所编写的草案条文似乎使用了太多文言表述，导致其理解时有一定难度 囧rz……--Yining Chen（留言|签名页） 2022年12月11日 (日) 01:53 (UTC)
(！)意見：OK，已嘗試直接依站友意見對上方條文進行異動。--Kriz Ju（留言） 2022年12月13日 (二) 11:12 (UTC)
(！)意見：個人的想法是，無論是否考評，只有同時具備專業能力和社群信任度的用戶能獲權，因此亦僅能由具備該領域能力的管理員授權，才具備某種程度之公信力，否則管理員自己本身一無所知又何以評估是否授權呢？至於具體考評，是比照其他權限可能出現的審核考評，其實也是考給社群看，以獲公信，個人無甚意見，已依站友意見對上方條文意見調整文字，供參。--Kriz Ju（留言） 2022年12月19日 (一) 17:38 (UTC)
個人感覺這一要求略顯嚴格，唯亦不失為確立其地位的策略。看看社群諸君還有沒有什麼意見了。--Temp3600（留言） 2022年12月27日 (二) 16:27 (UTC)
  • (！)意見：1.整个授权过程中涉及到两名以上管理员的参与，在实际实行过程中可能存在相当大的困难；2.“具備過濾器相關站務經驗”在判断标准上可能存在问题。仅对过滤器进行小范围的修改并不能证明这名管理员就具备操作过滤器的能力。3.假若该提案通过，想要判断某名管理员是否进行过与过滤器相关的站务处理将变得比较困难。某些管理员可能主要编辑private过滤器，这样普通用户就无法对相关问题进行查证。另一方面来说，想要找到某名用户编辑过滤器的所有记录也相当困难，除非由社群仿照Wikipedia:监督/统计维护一个“管理员参与过滤器编辑的记录列表”。--Yining Chen（留言|签名页） 2022年12月31日 (六) 04:00 (UTC)
  • 既然社群沒有進一步意見，暫時不提高要求。--Temp3600（留言） 2023年1月8日 (日) 14:27 (UTC)

第一階段公示：確認分拆

現按上方的共識，進行第一階段公示，確認將AF源碼閱讀權(abusefilter-view-private)從回退員權限中移除。本項的實施則預計在整套方案通過後一次過執行。現就此 公示7日。

新用戶組的細則則仍屬討論階段，誠邀各位就獲權細則，除權條件等細節作深入討論。--Temp3600（留言） 2022年11月27日 (日) 17:01 (UTC)

看来公示期结束了。那就等上边了。--Ghren🐦🕕 2022年12月6日 (二) 10:29 (UTC)
卡。--Temp3600（留言） 2022年12月19日 (一) 03:01 (UTC)

第二階段公示：成立過濾器助理用戶組

現按上方的共識，進行第二階段公示，將草稿:過濾器助理確立為方針。通過後將成立相關的用戶組。現就此 公示7日。先再討論一下。--Temp3600（留言） 2023年1月9日 (一) 14:20 (UTC)

回退員的除權安排將在新用戶組開放申請後再決定細節。--Temp3600（留言） 2023年1月8日 (日) 14:57 (UTC)

(－)反对：上方讨论显然不够充分，未能达到形成共识的程度。仅有三人参与的讨论，且其中还有未能解决的反对性意见，是否能称作“形成共识”？没人参与是否等于全部支持？如果反复在未能形成充分共识的情况下强行推进讨论，虽有WP:AGF，但恐怕仍有游戏共识形成程序的嫌疑。--Yining Chen（留言|签名页） 2023年1月9日 (一) 01:34 (UTC)
繼續討論當然很好，但得有人前來。看看下星期如何了。--Temp3600（留言） 2023年1月9日 (一) 14:34 (UTC)
(－)反对：根本就没明白过滤器助理究竟只是用来查看不公开过滤器的，还是用来修改过滤器的。申请所需要求远高于该组所具备的权限。--广雅 范★ 2023年1月9日 (一) 09:04 (UTC)
很明显没有修改过滤器的能力啊？--Ghren🐦🕓 2023年1月9日 (一) 09:06 (UTC)
补充了一下我的回复。想表明的是只是查看过滤器日志根本就没必要对正则表达式有基本认识、计划协助维护中文维基百科的过滤器等。--广雅 范★ 2023年1月9日 (一) 09:10 (UTC)
如希望查看日誌（即abusefilter-log-private），按現行程式申請回退員權限即可。申請abusefilter-view-private才需要申請這一新權限。此外，回退員如果積極參與反破壞工作，及符合其他基本要求，即可獲批。--Temp3600（留言） 2023年1月9日 (一) 14:34 (UTC)
还是那个问题吧，单纯的查看是否需要这么高的要求。--广雅 范★ 2023年1月10日 (二) 02:34 (UTC)
至少必須高於回退員，以排除目前向破壞者提供資料的回退員內鬼。--Temp3600（留言） 2023年1月11日 (三) 14:52 (UTC)
但是只是单纯查看没必要硬性要求会正则吧，以及不能编辑的话对过滤器有认识计划维护过滤器是有什么意义？--广雅 范★ 2023年1月12日 (四) 02:53 (UTC)
呃，要看的權限但看不懂正則，那怎麽看懂過濾器的條件？要來幹嘛？--路西法人 2023年1月12日 (四) 03:36 (UTC)
能改过滤器的管理员都没这个要求，只能看的助理却有这个要求吗？--广雅 范★ 2023年1月13日 (五) 06:45 (UTC)
管理员未必会去看和接触过滤器，但助理则一定要能理解过滤器。如果助理需要其他人帮助来解读，不还是“泄密”了。“基本认识”要求似乎不高。--YFdyh000（留言） 2023年1月13日 (五) 06:50 (UTC)
问题在于，“基本认识AF”的要求比“基本认识Regex”要高。比如第51号过滤器，第27号过滤器等，即使某名用户“基本认识”regex，如果没有相应基础，也很难理解其工作原理。--Yining Chen（留言|签名页） 2023年1月13日 (五) 11:21 (UTC)
我说的“基本认识”指过滤器功能方面，能判读多数过滤器就符合查看过滤器的基础条件（之一），不考虑复杂语法或编辑特征等检测。不太明白广雅范的“单纯查看没必要硬性要求会正则”，是适用哪些人群。--YFdyh000（留言） 2023年1月13日 (五) 12:21 (UTC)
建議對正则表達式有基本認識。如果沒有認識但有必要看到源碼（例如是其他維基的管理員希望抄一份中維過濾器的源碼），自然符合申請原因。--Temp3600（留言） 2023年1月12日 (四) 09:56 (UTC)
这是在基本资格下列出来的欸，而且是要怎样维护过滤器呢？--广雅 范★ 2023年1月13日 (五) 06:45 (UTC)
按我所知，目前部分回退員會在站外聯絡管理員，向對方提出修改建議。基本资格方面，的確是希望申請者先了解regex，確認權限對自己有幫助才來申請。然而，如果是抄對碼到其他維基等作業，未必需要懂得regex也可進行，故這不是強制要求。沒有寫成“基本认识AF”應是希望將條件寫得具體些，畢竟有些人看得懂AF的介面也會說自己「基本」懂得AF。--Temp3600（留言） 2023年1月14日 (六) 14:21 (UTC)
@Temp3600、Yining Chen：我覺得倒不如直接問現任的回退員他們之中哪些人是真的用得上AF源碼閱讀權的（至少我在卸任之前完全用不上），然後我們對所有自稱用得上AF源碼閱讀權的回退員逐一詳細審查，確定哪些用戶是可以獲得AF源碼閱讀權的，最後直接分拆權限，把所有獲確認可獲授權的用戶全部批量授權就可以了。我之所以這樣説，不只是因為自己在卸任之前完全用不上AF源碼閱讀權，也是因為在使用“如果不通過就不給人吃飯”的方式後也沒啥回退員前來討論的緣故，這個情況讓我懷疑是不是真的有那麽多人需要AF源碼閱讀權。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年1月12日 (四) 14:16 (UTC)
我個人預期只有幾十位回退員最終需要這個權限。待過濾器用戶組建立後，我支持在除權先發出通知，讓回退員前來報名，批准後再對回退員組除權。--Temp3600（留言） 2023年1月14日 (六) 14:21 (UTC)
假若讨论能够通过，或许可以提前开放申请，仿照IA和查核助理的方式，列出一个“由社群共识委任的第一批AFH”名单。----Yining Chen（留言|签名页） 2023年1月14日 (六) 14:42 (UTC)
我也支持這樣做。--Temp3600（留言） 2023年1月15日 (日) 03:22 (UTC)
在权限设立后初期，恐怕很少有两名以上管理员能站出来为一名申请人“担保”。即使到了后期，AFH人数逐渐增加，恐怕也很难找到愿意为自己投票支持的用户。毕竟这种“担保制”申请权限的方式应该是第一次在中文维基百科应用，谁也不知道会变成怎样。--Yining Chen（留言|签名页） 2023年1月14日 (六) 14:46 (UTC)
未见“担保”条文，也未理解为何不会有担保。--YFdyh000（留言） 2023年1月14日 (六) 17:28 (UTC)
草案要求“一名管理员具名支持，一名管理员授权”，这不是在变相要求申请该权限要一名管理员“担保”？--Yining Chen（留言|签名页） 2023年1月15日 (日) 00:14 (UTC)
Draft:過濾器助理和Wikipedia:過濾器助理草案页面中，我没看到这种要求，烦请指明原文？--YFdyh000（留言） 2023年1月15日 (日) 03:00 (UTC)
Yining Chen所指的任命條件經討論後，最終沒有納入方針中。--Temp3600（留言） 2023年1月15日 (日) 03:20 (UTC)
敝人在此對個人構想稍作澄清。首先，請站友切勿曲解並詮釋為「擔保」，敢問怎麼擔？怎麼保？要拿什麼擔保呢？若這樣講，所有的「提名」或「推薦」、「支持」通通都算是擔保了嗎？其次，最初的設想，之所以會存在可先由一名管理員提名或支持，是為了解決若將該權限直接拆分，第一位獲權者如何產生的問題；換言之，往後的申請者不須非得由管理員支持或提名才可申請，因此自不存在所謂一定要「兩位管理員」才能申請一說。再次，即便真需要兩位管理員，也不過是執行層面的問題而已，如果社群中不存在足夠的具備相關經驗和技術之管理員（真沒有嗎？）或門檻過高，自可再議，否則動輒以不具實質證明之「恐怕如何如何」之預想或預設立場（邏輯上和「恐怕不會如何如何」是差不多的意義，眾人都用「恐怕這樣那樣」，其他人也可以說「其實不會」，各說各話），個人認為於討論上難有裨益。最後，若社群認為此類門檻過高，自可調整降低，個人無甚意見。真正重要的地方在於，獲權者彼此間若都會協同經手維護過濾器的話，能看到內部設計的人就是那一群而已，理想上多少自當相互信任，而不是互相懷疑，這樣的門檻就是為了確保能獲權的用戶是具備相當信任度和技術能力的，而且人數是否真的需要那麼多，仍部分取決於實務需求和社群之信任，講白了以後若有其他問題導致相互懷疑，也是持權用戶間的爭議了。--Kriz Ju（留言） 2023年1月15日 (日) 14:10 (UTC)
还希望您能保持冷静。首先，本人只是将个人经过思考，预想可能会发生的事情用某种方式写出来，供大家来参考，并没有以此为理由故意阻碍社群通过讨论。如果有人认为我在胡言乱语，杞人忧天，可以选择忽视。毕竟前人说“实践是检验真理的唯一标准”，如果大家都同意，完全可以现在就把这个方针草案立刻付诸实践。这样就彻底消除了别人说“恐怕”的所有机会（但这样是否是WP:POINT还有待商榷）。其次，有了第一名AFH，那选第二名时会不会变成“与第一名AFH关系好坏的评选”？如果第一名AFH直接站出反对候选人该怎么办？如果您的提案被社群初步认可，这些问题或许都要更深入的思考和讨论。( π )题外话：本人在语句中掺入大量的“恐怕”“或许”等词汇这种行为，是早期在某种特定环境下写作的产物，希望您能谅解。--Yining Chen（留言|签名页） 2023年1月15日 (日) 14:53 (UTC)
(！)意見：無妨的，您不用擔憂，我相當冷靜，亦無任何強求。個人只是期待，眾人對他人未指明之概念，或未明言之事，請盡可能避免替他人註記或視為他人所言，甚而持續延伸，何況所謂「擔保」與這裡的實務實在相差甚遠，試問這裡的誰願意為誰拿出什麼條件真正擔保過什麼呢？至於個人對任何提案或構想，一向抱持可參考、可討論之態度，若（已）無興致或共識，隨意看看即可，有興趣參考、沒興趣拉倒，無傷大雅的。敝人並非認為是所謂杞人憂天之類，只是不喜歡太多所謂訴諸恐懼的訴求（當然您也有合理的考量），此類訴求和手法顯然氾濫使用於社會中，任何構想適合或適當與否，討論即可，當然這種說法也只是我個人偏好罷了（笑）。
至於您提到“与第一名AFH关系好坏的评选”之擔憂，確實有道理，不過第二名申請者（或之後的任何用戶）仍可透過兩位管理員（或之後的其他獲權回退員）支持，或是如敝人提及的，自認能力和信任度皆具備的用戶，若認為受到不公待遇，導致無法獲得任何適當支持，亦可考慮於客棧請社群品評，做為可能的救濟途徑；而這也是為何個人認為理想上應該直接於申請時進行公開考評之故，當然必然也會存在有人作弊或找代打之類的疑慮，然而哪項申請又可以完全杜絕所有疑慮呢？回過頭來，若要僅僅提及「关系好坏」，個人傾向以兩個層面觀之，表面而言，與任何特定用戶之關係深淺，的確影響是否具備信任度，然而這部分還是得回歸管理員之專業判斷和操守，若管理員不吃這套，試問關係好又如何呢（自然這點除了挑戰人性，也必然永遠有爭議）？另一方面，信任度的基礎其實有相當部分來自於社群對特定用戶的「熟悉度」，而熟悉度又來自於用戶平日於平台的公共領域（如社群活動、競賽、站務、榮譽表揚，或公開討論等領域）之實質貢獻、投入和活躍與否（自然包含曝光度之類），換個角度看，或許較有機會獲得社群信任的用戶，在公領域常具備至少部分用戶對其擁有之熟悉度，這是可以透過人為努力達成的。無論如何，正因總有爭議，個人才傾向或許可以考慮設定申請考評，如此而已。其實說實話，不論是這裡，抑或現實社會，所謂「靠關係」，實為常態，即便這裡的管理人員選舉和信任度亦無法避免此種爭議（講白了就是只要我看你不順眼你再厲害我也不會投給你或支持你什麼的），但吾人是否應該放棄其他可能性呢？
退一步而言，不論制度如何設定或規劃，皆難以排除各種或所有疑慮，又或是總有各種「不公」（不論是否真實存在或真是如此），於社群中始終存在難以有效消除、緩解之隔閡或爭議，那麼個人認為此即可視為當下社群風貌和需求的「現實表現」了（現實世界中此類情事亦然）。--Kriz Ju（留言） 2023年1月15日 (日) 19:59 (UTC)
AFH需由管理員授權，這與目前其他權限的授權方式相同。這只代表管理員確認了社群達成的共識，難言是管理員對此的擔保。「管理员具名支持」方面，考慮到目前管理員團隊有不少活躍成員，幾可肯定會有管理員維基人參與AFH申請的討論，如擔心AFH討論過於寛鬆，可先實行一兩個月後再檢討。--Temp3600（留言） 2023年1月24日 (二) 17:26 (UTC)

再議回退員的角色（是否可以與巡查員進行簡併？）

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年7月22日 (六) 00:14 (UTC)。

最近我在授權時再次想到一個以前想過的問題，那就是回退員實際上現在處於一個有些尷尬的位置。設置某種職權而不是把權限下放給所有的確認用戶，其初衷自然是防止權限遭到濫用。然而，就事實上而言，標記新頁面為已巡查確實是巡查員才能做的一件事，但在Twinkle工具早已普及的今天，事實上的版本回退卻不是回退員的專利，大部分情況下回退員的回退功能比起Twinkle也沒有很大便利性。回退員事實上高於確認用戶的權限幾乎只剩下查看防濫用過濾器這一項。因此，個人認為，是不是有必要稍微改革一下回退員的申請方式呢？以下提出了兩種想法，想請教一下大家的意見：

  1. （較緩和）申請巡查員時，鼓勵符合回退員授權條件的用戶在申請成為巡查員欄目申請巡查權時一併申請獲得回退權，管理員在任命權限時可一併進行考察，能很大程度上減少授權的行政工作。
  2. （較激進）把回退員的防濫用過濾器查閱權限和回退權都授予巡查員。畢竟防濫用過濾器在新條目巡查時可能也用得上。之後原則上回退員只授予少部分同時進行反破壞的巡查豁免者。--クオン·千の海を越えて·愛おしき欠片 2023年6月29日 (四) 23:05 (UTC)
我傾向剝奪回退員的防濫用過濾器查閱權限（包括現任的）後採較激進提案（甚至乎完全廢除回退員，把回退權也打包送給巡查豁免者也可），原因是防濫用過濾器查閱權限有私隱安全風險。較緩和提案我認為也可行，但成效不會太大。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年6月29日 (四) 23:09 (UTC)
巡退合併，但申請資格使用回退員的條件如何？--冥王歐西里斯（留言） 2023年6月29日 (四) 23:58 (UTC)
可以考虑。——Sakamotosan路过围观 | 避免做作，免敬 2023年6月30日 (五) 00:14 (UTC)
個人感覺回退員比巡查員好當。回退員有能力判斷明顯破壞就行，而判斷這點並沒有很大難度。但新頁面巡查員就要知道哪些條目該刪、哪些條目可留，對於可留的條目，還應該清楚當前條目的最大問題是甚麼（然後正確地標記維護模板）。拋開故意濫用權力造成危害的事情不談，我覺得巡查員的應該不低於回退員的門檻。兩權合一用較高的門檻我認為也可以。--洛普利寧 2023年6月30日 (五) 07:28 (UTC)
提高門檻個人無異議，畢竟大部分申請人實際獲得巡查權時編輯數量已大於1000。--クオン·千の海を越えて·愛おしき欠片 2023年6月30日 (五) 07:53 (UTC)
(＊)提醒一下，社群已经达成了剥夺回退员防滥用过滤器查阅权限的共识。见Wikipedia:維基百科政策簡報/存檔/2022-12“方针与指引重要变动”第三条。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年6月30日 (五) 02:00 (UTC)
但后续的新建用户组好像没有下文。——Sakamotosan路过围观 | 避免做作，免敬 2023年6月30日 (五) 02:20 (UTC)
而且“abusefilter-log-private”（看隐藏过滤器触发的日志）还是保留的。——Sakamotosan路过围观 | 避免做作，免敬 2023年6月30日 (五) 02:22 (UTC)
系统回退是可以绕过过滤器（可能是没配置对应action？）、黑名单的，而且更快（不像Twinkle那样是编辑盖版本）。除了隐藏过滤器的查看外，回退员的功能已经有点鸡肋了。不反对，但隐藏过滤器的查看的确需要一个安放的用户组。——Sakamotosan路过围观 | 避免做作，免敬 2023年6月30日 (五) 00:14 (UTC)
那麼綜合這些意見，可否單獨把回退權下放給巡查員然後二權合一，技術上把回退員這個權限改為防濫用過濾器查閱員（舊回退員不直接轉換為過濾器查閱員），原則上只開放給極少數有需要的用戶申請（類似於大量訊息發送員）？或者索性完全廢棄回退員這個職權，查閱防濫用過濾器的權限授予給模板編輯員（因為兩者很大程度上都是技術方面的問題）--クオン·千の海を越えて·愛おしき欠片 2023年6月30日 (五) 07:53 (UTC)
过滤器问题并不能简单总结为“技术问题”，而应是“反破坏”。您已经担任了管理员职务很久，相信您比大家要更熟悉过滤器的相关工作流程。而模板编辑员显然与反破坏工作关系不大。--Yining Chen（留言|贡献） 2023年6月30日 (五) 14:04 (UTC)
只是一個簡單的設想，具體方案還要再討論。走前面一種方案把回退員變成原則上只授予少部分編者的過濾器查閱員個人認為也是可取的。--クオン·千の海を越えて·愛おしき欠片 2023年6月30日 (五) 17:01 (UTC)
我贊同這個方向。我的想法是將「回退員」的中文名稱改為「過濾器查閱員」，並只留下防濫用過濾器查閱權（沒回退權），回退權授予所有巡查員（與巡查豁免者）。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年7月2日 (日) 04:46 (UTC)
建議僅授予巡查員，巡查豁免者拿這個似乎有點沒辦法解釋為什麼要這個權限。--冥王歐西里斯（留言） 2023年7月2日 (日) 12:54 (UTC)
我覺得或許可以假定巡查豁免者通曉回退權的使用時機，所以我才提議可以讓巡查豁免者有回退權，但這也只是我的其中一個設想，我也不是説我就一定要主張這個。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年7月4日 (二) 15:13 (UTC)
我感觉回退员权限中就一个suppressredirect对写条目有帮助，并且这也是我一贯的要求。像是unwatchedpages、rollback显然属于维护需要。----Cat on Mars 2023年7月5日 (三) 17:58 (UTC)
如果如Kuon所言使用TW回退相比回退功能已无多差异，那么应当做的是直接搁置或废弃回退功能，而不是简单就把这东西丢给巡查员。->>Vocal&Guitar->>留言 2023年7月2日 (日) 12:37 (UTC)
回退員的回退可以繞過濫用過濾器與黑名單，還是有差。--冥王歐西里斯（留言） 2023年7月2日 (日) 12:52 (UTC) +1
所以，立题的根本如果有问题，那也无从讨论废除回退员这一可能。->>Vocal&Guitar->>留言 2023年7月3日 (一) 03:37 (UTC)
某日我在SWV上回退中文版的破坏，结果我没有本地回退被过滤器阻挡操作失败……所以差别还是相当大的……--And ALLAH said, “Together we unite!” And there’s power. 2023年7月7日 (五) 02:09 (UTC)
回退權限始終包含「復原」以外的特性，不可整個廢除；併入巡查員也並不合理（我過往曾提過類似巡退合併的提案，但現在想到相反的論點）：各人有不同專長，回退員是反破壞，巡查員是檢查內容品質，完全是兩個不同範疇的權限。合併兩個權限總會出現有人只用其中一半的問題，不如維持分拆更好。--路西法人 2023年7月3日 (一) 05:20 (UTC)
問題在於這個「有人」具體有多少，我當回退員時根本未曾用過隱藏防濫用過濾器查閱權，這理論上也是「有人只用其中一半」的問題，因此我認為以「有人只用其中一半」來反對合併不能服眾。我認為有必要知道同時是巡查員與回退員的用戶的具體人數。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年7月3日 (一) 23:41 (UTC)
不全然認同「未曾用過隱藏防濫用過濾器查閱權」算是用一半。「回退員」顧名思義主要權限是系統回退，防濫用過濾器查閱權只是因為同屬反破壞權限才勉強附於回退員組別權限中吧，只能稱得上「附邊」的權限。巡查權跟回退權就是兩個非常常用且主要的權限，回退併入巡查，想申請權限做反破壞的用戶就真的只用一般了。經查，現時192名回退員、172名巡查員，其中有130名用戶同時持有二權。合併權限後，假設所有用戶過渡至新權限，會有234名巡退員，即每九個巡退員就有四個只用一半。--路西法人 2023年7月4日 (二) 13:38 (UTC)
就算是現在的巡查員的各種權限，理論上也是「有人只用其中一半」的。巡查員表面上的權限是巡查權，但實際上還有巡查豁免權，此外還有不留重新導向移動權，而（包括我在內）好一部分的巡查員巡查頁面的頻率很低，可能每三個裏只有一個是真的會經常巡查頁面，而剩下兩個就是為了那個附設的不留重新導向移動權，但為此特地把不留重新導向移動權分成一個獨立的權限也不合理（當然，我個人更傾向把這個權限下放），所以我仍然認為以「有人只用其中一半」來反對合併不能服眾。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年7月4日 (二) 15:09 (UTC)
我倒是觉得巡查员是否要附带巡查豁免权存疑，现在巡查员的条件似乎比巡查豁免员低，而且感觉部分巡查员（或者巡查+回退）不一定能保证自己所写是否无需巡查。--在下荷花，请多指教（欢迎签到） 2023年7月6日 (四) 11:23 (UTC)
这是老问题，好像是技术原因。也因为理念上可能认为能自我控制才有能力巡查别人，但复审其实很有价值。不过复审未必要关联到新页面巡查。--YFdyh000（留言） 2023年7月6日 (四) 11:29 (UTC)
有技术问题？导游就是巡退一体然后豁免分开。--在下荷花，请多指教（欢迎签到） 2023年7月6日 (四) 16:15 (UTC)
不過導遊的巡查員只有rollback、patrol跟suppressredirect三種權限就是了，如果真的合併，改成這樣也不是不行。--冥王歐西里斯（留言） 2023年7月6日 (四) 23:41 (UTC)
葡萄牙语版上的回退者同时持有封锁权限（详见此处）。不过实际使用上似乎也有所限制，好像原则上只允许不超过24小时短期封锁……我不了解葡萄牙语，其他细节可能没有察觉到。--And ALLAH said, “Together we unite!” And there’s power. 2023年7月7日 (五) 02:01 (UTC)
但這個同時要修封鎖方針，以中文維基百科目前的封鎖方針來說大概不能直接這樣給權限。--冥王歐西里斯（留言） 2023年7月7日 (五) 02:28 (UTC)
这个感觉在中维不太可能实现就是了。--在下荷花，请多指教（欢迎签到） 2023年7月7日 (五) 11:19 (UTC)
我認為就現階段而言，鼓勵巡查員同時申請回退員是可行的。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年7月10日 (一) 09:37 (UTC)
總結：結合以上的討論，那麼是否可以在這裡提出兩個提案呢？一是設立過濾器查閱員並剝奪回退員過濾器查閱權，二是鼓勵巡查員同時申請回退權。--クオン·千の海を越えて·愛おしき欠片 2023年7月11日 (二) 21:37 (UTC)
前者已在下方討論。後者沒意見，但考慮到私隱問題，我不建議在剝奪回退員私有過濾器查閱權前鼓勵巡查員同時申請回退權。Sanmosa In vain 2023年7月11日 (二) 22:34 (UTC)

再提重组用户权限组

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年7月28日 (五) 16:14 (UTC)。

以下列出中文维百常年不通过，但非常需要的更改权限提议：

  • 降低自动确认用户的门槛
  • 巡查员与回退员合并为巡退员
  • 设立高级巡退员以查看私密过滤器
  • 给界面管理员授予编辑被保护页面的权限
  • 与基金会协商重新引入用户查核员--Firedoge2023（留言） 2023年7月13日 (四) 14:24 (UTC)
请勿在讨论版直接引用个人沙盒，这会使您此后的更改直接反馈到该页面，使讨论内容无法确定。此外关于用户组权限的调整，还请您不要自顾自地不给出任何理由直接提出自己的一系列想法，这无助于发现问题和解决问题，只是在创造问题。——暁月凛奈 (留言) 2023年7月13日 (四) 14:41 (UTC)
回复@暁月凛奈：这些想法也不是我提的呀，之前都有讨论--Firedoge2023（留言） 2023年7月13日 (四) 14:50 (UTC)
以上提议我觉得会因安全原因而不会通过，例如反对降低自动确认用户的门槛的原因是有长期破坏者喜欢通过刷编辑数来破坏被半保护的页面。--Lanwi1Talk 2023年7月13日 (四) 15:56 (UTC)
可以限制为条目命名空间编辑--Firedoge2023（留言） 2023年7月14日 (五) 02:02 (UTC)
可能和mw技术实现有关，至少在P站申请得到mw开发人员支持改进出这个功能才能讨论。不过如果看自动确认和延伸确认两种类似机制下的授权方式有明显差异，感觉这个授权部分是屎山，没人想动。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:05 (UTC)
“再议回退员的角色（是否可以与巡查员进行简并？）”、“提議重組現有的用戶權限組”不是已经在讨论有关部分问题（包括合并巡查和回退，将回退看私密AF的权限正式转给另一个用户组）。至于其他（如“降低自动确认用户的门槛”、“界面管理员编辑被保护页面”），只是举出常年理由并不足够说服吧，至少说明现在为什么要这么做。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 01:11 (UTC)
“界面管理员”本来就是防止管理员被盗后修改界面空间（例如Mediawiki空间的js脚本、css等）而将相应编辑权限拆出来提高安全性，“编辑被保护页面”如果指全保护的话应该是管理员就可以吧？——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 01:15 (UTC)
PS，虽然现在来看，除了AnYiLin外，剩下的也是管理员（乐），有点脱裤子放屁的感觉，而且申请难度也和管理员接近。如果说好处的话， 就是收窄修改界面空间用户的范围，一些专注页面管理、用户管理的管理员通常不需要这个编辑能力。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 01:20 (UTC)
那就剥夺几个界面管理员的管理员身份[開玩笑的]--Firedoge2023（留言） 2023年7月14日 (五) 02:07 (UTC)
这不是开玩笑，毕竟这几位的确是偏向技术维护的管理员。虽然从所谓安全性而已，是提出了拆分组别的要求，而基于其角色，他们看上去又好像没有丢失了这些权力。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:24 (UTC)
看了一下，应该给界管授予以下权限
editprotected
editcontentmodel
delete（仅限Mediawiki命名空间或CSSJS页面）
undelete（仅限Mediawiki命名空间或CSSJS页面）
suppressredirect（仅限Mediawiki命名空间或CSSJS页面）--Firedoge2023（留言） 2023年7月14日 (五) 02:24 (UTC)
反對，界面管理員不應該有更改界面以外的任何權限，以上五個權限全部沒有技術上的命名空間限制，全部不應授予界面管理員。--路西法人 2023年7月14日 (五) 02:39 (UTC)
「界面管理员的可信程度不应亚于管理员，甚至应该更高。」可信程度更高，权限也应更高。--Firedoge2023（留言） 2023年7月14日 (五) 02:51 (UTC)
所以我曾经认为这句话说得不好，产生界面管理员组别的意义是为了隔离界面空间编辑功能而产生（或者说是拆分出来），实际上它的权限少于管理员，没有什么“可信程度不应亚于管理员，甚至应该更高”的意义。除了可以加些js脚本（可能引入隐私泄漏的破坏脚本），或者恶作剧性质的css外，远不如管理员能删除页面、保护页面、或者封锁用户更麻烦，前者直接用API也能绕开页面修复。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:10 (UTC)
我把这句话删了--Firedoge2023（留言） 2023年7月14日 (五) 03:24 (UTC)
从技术上，有类似控制特定用户组对特定页面空间的动作控制插件：mw:Extension:Lockdown，不过可能需要确定基金会会不会允许使用这个插件。“editprotected”（编辑全保护页面）感觉没必要给，因为这本来是管理员主要权限之一、“editcontentmodel”可能可以考虑。至于其他要看插件功能来确定。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:20 (UTC)
须证明日常工作中常用、必需，否则放在管理员权限组、双人完成就好（活跃者少是另一问题）。可信程度高不代表要授予非必要的权限。--YFdyh000（留言） 2023年7月18日 (二) 13:20 (UTC)
請深思熟慮以後再提案，不要一股腦提出來。這些提案「常年不通過」是有原因的。從使用者查核員問題就可以看出，顯然提案人沒有對本站權限體系發展事先做過研究。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年7月14日 (五) 13:13 (UTC)
我研究过--Firedoge2023（留言） 2023年7月14日 (五) 13:39 (UTC)
@Ericliu1912：雖然我個人也同樣不認可這次Firedoge2023的做法，但你用“這些提案‘常年不通過’是有原因的”來批判他我也不認可。這樣説吧，我一開始在2018年重提設立編輯禁制方針（現稱“禁制方針”）的時候也沒有怎麽“深思熟慮”過，而且編輯禁制方針當時也是常年提案，但那時最終我的提案通過了。Sanmosa In vain 2023年7月14日 (五) 13:52 (UTC)
我自已也不认可我的观点。--Firedoge2023（留言） 2023年7月14日 (五) 14:03 (UTC)
提案人應對提案脈絡及意義有充分掌握，這是基本道理。操之過急而缺乏準備的提案不值得社群多花精力去「幫」提案人額外考慮。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年7月14日 (五) 14:12 (UTC)
我的意思是説你先不要一來就假設對方完全沒有“對提案脈絡及意義有充分掌握”，這某程度上可以算是冒犯。Sanmosa In vain 2023年7月14日 (五) 14:28 (UTC)
我只是就事論事。提案人如果明確知道為什麼要提案、怎麼解決過往討論未能解決的問題並合理說服社群，就不會出現「自顾自地不给出任何理由」等情況以及上方某些不明就裡的意見；如果認真、嚴肅地對待討論，就更不應該出現「那就剝奪幾個介面管理員的管理員身份[開玩笑的]」這種發言。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年7月14日 (五) 15:40 (UTC)
😅--Firedoge2023（留言） 2023年7月16日 (日) 02:52 (UTC)
取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:回退功能/存檔2&oldid=80314420”