維基百科

維基百科討論:回退功能/存檔2

< Wikipedia talk:回退功能
由Jimmy-bot在話題再提重組用戶權限組上作出的最新留言：10 個月前

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

最新留言：3 年前27則留言5個人參與討論

本主題或以下段落文字，移動自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)
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

最新留言：2 年前25則留言8個人參與討論

本主題或以下段落文字，移動自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)

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

最新留言：1 年前118則留言21個人參與討論

本主題或以下段落文字，移動自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)

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

最新留言：11 個月前37則留言16個人參與討論

本主題或以下段落文字，移動自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)

再提重組用戶權限組

最新留言：10 個月前29則留言10個人參與討論

本主題或以下段落文字，移動自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"
返回專案頁面「回退功能/存檔2」。