維基百科討論:封禁申訴

應該建立

此頁面應該建立，而且現在互助客棧關於建立此頁面的討論也已經大致通過。—人神之間_{擺哈龍門陣} 2008年11月9日 (日) 09:06 (UTC)

作為創建者，我也認為應該建立。Alonso McLaren (留言) 2008年11月9日 (日) 09:13 (UTC)

附議！—汪汪 2008年11月9日 (日) 09:28 (UTC)

請問人神，甚麼時候大致通過了，我看到的是原來的討論無疾而終罷了。要是先斬後奏，建立了之後再談合理性的話，這和搶建條目有甚麼不同？我不是說這個頁面不應建立，而是要有決議要建立時才建立。—唐吉訶德的劍(風車之戰)十步殺一人 2008年11月9日 (日) 09:30 (UTC)

這個頁面的名稱容易引起誤會，因為沒有說明是針對封禁的申訴，維基百科另有未翻譯完成的Wikipedia:封禁申訴，但其內容是英文維基中遇到錯誤封禁後如何申訴的指引。—Ben.MQЖ留言Ж 2008年11月9日 (日) 09:41 (UTC)

是否可以發起一個投票，以確定是否建立條目，然後進行編輯工作，或者使用某個/temp頁面編輯出一個大概的樣子，然後投票？—Ben.MQЖ留言Ж 2008年11月9日 (日) 09:43 (UTC)

從理論上，建立一個條目是不需要投票的，只要使它成為相關方針或者指引才需要。不過對於此條目，鑑於已經有了Wikipedia:封禁申訴，我覺得應該刪除，但是至少不能速刪，因為不符合速刪的標準。—人神之間_{擺哈龍門陣} 2008年11月9日 (日) 10:12 (UTC)

根據Wikipedia:修改和創建方針，先行創建條目是合理的。在下以為，在翻譯本條目目前對錯誤封禁的申訴內容後，加入針對因破壞/傀儡/攻擊/用戶名等等理由被封禁的申訴方式，然後指引被封用戶使用其子頁面Wikipedia:封禁申訴/申訴提出請求。最後交由社群確立其為方針指引—Ben.MQЖ留言Ж 2008年11月9日 (日) 10:10 (UTC)

先把英文翻譯過來，有個底子，也可以讓我們在英文版的基礎上討論修改，便於節約人力和時間。—菲菇＠維基食用菌協會 2008年11月9日 (日) 10:26 (UTC)

投票

申訴問題至關重要.翻譯完成後就進行投票.不能再拖下去了Alonso McLaren (留言) 2008年11月11日 (二) 01:54 (UTC)

強烈要求建立申訴制度

很多人被封禁後無法辯駁。應該給他們一個機會，為此我創建了Wikipedia:申訴 希望改革政策，允許被封用戶在Wikipedia:申訴上進行申訴，這樣就不需要使用傀儡了。Alonso McLaren (留言) 2008年11月9日 (日) 08:53 (UTC)

我也希望這樣，但是目前還沒有共識要建立這樣一個制度的時候，你是不應該建立Wikipedia:申訴的。—唐吉訶德的劍(風車之戰)十步殺一人 2008年11月9日 (日) 09:00 (UTC)

要取得這種共識，應該不難吧，一直聽見有人提，另外還有誰是在具體行動的麼？沒人去推動這個事情，永遠不會有任何進展—我是火星の石榴 (留言) 2008年11月10日 (一) 06:32 (UTC)

在下剛剛準備着手翻譯Wikipedia:封禁申訴中殘留的英文部分，但是發現裡面的內容有很強的地區性，而且在中文維基找不到Autoblock的相關內容，所以不敢貿然動手了……希望有對封禁系統和工作原理比較熟悉的老用戶伸出援手……—Ben.MQЖ留言Ж 2008年11月10日 (一) 07:34 (UTC)。

自動封禁就是當一個註冊用戶被封禁後，他最近所使用的IP地址亦會被隱匿性地（即在日誌中不顯示出IP地址，只顯示出系統給的編號）封禁1天。在這一天內，使用被封禁IP地址編輯維基百科的非管理員及以上權限的註冊用戶均會被禁止編輯。—菲菇＠維基食用菌協會 2008年11月10日 (一) 09:13 (UTC)

真的應該要ㄧ個完善的申訴制度。維基要成為百科還有很大的進步空間。--Outlook8.1（留言） 2014年12月11日 (四) 13

54 (UTC)

非管理員處理封禁申訴

例如User:B dash的這一筆編輯，處理了一個封禁期已過的封禁申訴。然而封禁申訴模板上寫有「管理員已對此封禁決定作出復檢，並有以下結論：」，會否導致誤解？例如誤以為處理人是管理員？

進一步講，是否允許非管理員用戶根據方針拒絕封禁申訴？（接受申訴肯定不行，沒法調整封禁設置）--Tiger（留言） 2017年7月18日 (二) 09:02 (UTC)

顯然的不應該吧，User:B dash有些太自作主張吧。——路過圍觀的Sakamotosan 2017年7月18日 (二) 09:47 (UTC)

這不算拒絕吧...人家只是標記此封禁已到期而已。不過這裡偏個題，現在到底有什麼事情是必須管理員（或者更高權限持有人）才可以處理呢？有一些的東西個人認為沒必要非在管理員名下才可以進行，比如關閉（存廢）討論、投票完畢的結果公布、查核結案之類的。-- Stang 2017年7月18日 (二) 12:39 (UTC)

確實有一些可以不用管理員處理，WP:合併請求目前正是這種狀態。但有一些東西可能沒那麼簡單。比如自行結CU（這位用戶也做過），就可能導致查核員還沒看到就被自動存檔了。封禁申訴也類似，一旦被處理，就不會出現在Category:封禁申訴里，也沒有記錄顯示處理人。我注意到Simon君的封禁申訴被處理還是因為之前看到了，後來消失，從我自己的貢獻記錄進入討論頁，才看到結果。--Tiger（留言） 2017年7月18日 (二) 13:23 (UTC)

我原先覺得這樣沒什麼問題，但是Tiger的論述很有道理，這樣的域應該保留由管理員處理為好。Bluedeck 劉曉波 2017年7月19日 (三) 01:33 (UTC)

別搶管理員的工作。--小躍（撈出記錄） 2017年7月19日 (三) 05:39 (UTC)

有關 unblock-zh 郵件列表可能潛在的「黑箱」制度

諸位好。近來有幾名維基新手加入 QQ 群，抱怨自己發送給 unblock-zh 郵件列表申請 IPBE 的郵件遲遲得不到回復。我用新手發送給 unblock 的郵箱反查郵件，發現這些新手的郵件並沒有投遞到訂閱 unblock-zh 的各個管理員手上，遂對 unblock-zh 的收發信策略做了一些測試，發現如下狀況：

• 會丟棄郵件中的 HTML 部分，只留 plain text（純文本）。目前郵件客戶端普遍會同時發送相同內容的 HTML 和 plain text；部分客戶端只會發送 plain text；但有一部分客戶端只發送 HTML 排版過後的郵件。（當然這也視乎用戶自己的設置。）對於部分只有 HTML 的郵件，在經過 unblock-zh 轉發後，郵件就會如這裡所示，全篇郵件一個文字都沒有。這一設置在 unblock-zh 後台是可調的，但普通管理員沒有權限。除非遇到下條所示情況：
• 對於字符編碼不是 UTF-8 的郵件，會把能轉換成 UTF-8 的郵件全部轉成 UTF-8。有些有些編碼能正常處理，但有些不能。對於能處理的，其到達收件箱後效果如下：

#1：請自備base64解碼器

Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: unblock-zh-bounces@lists.wikimedia.org
Sender: "Unblock-zh" <unblock-zh-bounces@lists.wikimedia.org>

IDEuIOWkqeWcsOeOhOm7g+OAgOWuh+Wumea0quiNkgogMi4g5pel5pyI55uI5piD44CA6L6w5a6/
5YiX5by1CiAzLiDlr5LkvobmmpHlvoDjgIDnp4vmlLblhqzol48KIDQuIOmWj+mkmOaIkOatsuOA
gOW+i+WRguiqv+mZvQogNS4g6Zuy6aiw6Ie06Zuo44CA6Zyy57WQ54K66ZycCiA2LiAq6YeR55Sf
6bqX5rC044CA546J5Ye65bSR5bKhKgogNy4gL1/lio3omZ/lt6jpl5XjgIDnj6DnqLHlpJzlhYlf
LwogOC4g5p6c54+N5p2O5p+w44CA6I+c6YeN6Iql6JaRCiA5LiDmtbfpubnmsrPmt6HjgIDpsZfm
vZvnvr3nv5QKMTAuIOm+jeW4q+eBq+W4neOAgOmzpeWumOS6uueahwoxMS4g5aeL5Yi25paH5a2X
44CA5LmD5pyN6KGj6KOzCjEyLiDmjqjkvY3orpPlnIvjgIDmnInomZ7pmbbllJAKMTMuIOW8lOaw
keS8kOe9quOAgOWRqOeZvOaut+a5rwoxNC4g5Z2Q5pyd5ZWP6YGT44CA5Z6C5oux5bmz56ugCgot
LSAK6K+35Zyo5Zue5aSN5Lu75L2V6YKu5Lu25pe26YCJ5oup4oCc5Zue5aSN5omA5pyJ5Lq64oCd
ClVuYmxvY2stemjpgq7ku7bliJfooagKVW5ibG9jay16aEBsaXN0cy53aWtpbWVkaWEub3JnCmh0
dHBzOi8vbGlzdHMud2lraW1lZGlhLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmxvY2stemg=

但是無法處理的，其方式如下：

#2：請自備base64解碼器

--===============1664063874770755991==
Content-Language: zh-CN
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

ICAxLiAgzOy12ND+/FOhodPu1ua66bvEDQogIDIuICDI1dTC06/qvqGhs73L3sHQj4gNCiAgMy4g
ILquge3K7s35oaHH78rVtqyy2A0KICA0LiAg6WPwTrPJmnGhocLJhc7Ve+qWDQogIDUuICDrhfJ2
1sLT6qGhwra9WZ7py6oNCiAgNi4gIL3wyfr7kMuuoaHT8bP2jYuM+Q0KICA3LiAghKbMlr7e6kmh
odbpt1HSubniDQogIDguICC5+9XkwO7ozaGhssvW2L3my0sNCiAgOS4gILqj+3m607WtoaH3W52T
0/DP6A0KICAxMC4g/YiOn7vwtduhofhCudnIy7vKDQogIDExLiDKvNbGzsTX1qGhxMu3/tLCydEN
CiAgMTIuIM3GzrvXjIf4oaHT0NPdzNXMxg0KICAxMy4gj3TD8bel1++hodbcsGzS85yrDQogIDE0
LiDX+LOvhpa1wKGhtLm5sMa91cINCg0K

--===============1664063874770755991==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

LS0gCuivt+WcqOWbnuWkjeS7u+S9lemCruS7tuaXtumAieaLqeKAnOWbnuWkjeaJgOacieS6uuKA
nQpVbmJsb2NrLXpo6YKu5Lu25YiX6KGoClVuYmxvY2stemhAbGlzdHMud2lraW1lZGlhLm9yZwpo
dHRwczovL2xpc3RzLndpa2ltZWRpYS5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJsb2NrLXpo

--===============1664063874770755991==--

對於不能處理的編碼，unblock-zh 在轉發時全文保留了原來的 plain text 內容，並在後面加上了自己使用 UTF-8 編碼的提示。

但是，使用這種方式同樣可以接收 HTML 郵件。比如在其他郵件列表里有這樣的例子：

#3：請自備base64解碼器

--===============8211208071669730346==
Content-Type: multipart/alternative; boundary=001a114bdd4c29bee4053b32b71f

--001a114bdd4c29bee4053b32b71f
Content-Type: text/plain; charset=UTF-8

-（中间部分略）-

tr"><div>[I don't print e-mails. Do you?]<br><a href=3D"http://gplus.to/edo=
deroo" target=3D"_blank">http://gplus.to/edoderoo</a> _-=3D-_ <a href=3D"ht=
tp://edoderoo.nl" target=3D"_blank">edoderoo.nl</a><br></div></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Otrs-permissions-l mailing list<br>
<a href=3D"mailto:Otrs-permissions-l@lists.wikimedia.org" target=3D"_blank"=
>Otrs-permissions-l@lists.wikim<wbr>edia.org</a><br>
<a href=3D"https://lists.wikimedia.org/mailman/listinfo/otrs-permissions-l"=
 rel=3D"noreferrer" target=3D"_blank">https://lists.wikimedia.org/ma<wbr>il=
man/listinfo/otrs-permission<wbr>s-l</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a114bdd4c29bee4053b32b71f--

--===============8211208071669730346==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KT3Rycy1wZXJt
aXNzaW9ucy1sIG1haWxpbmcgbGlzdApPdHJzLXBlcm1pc3Npb25zLWxAbGlzdHMud2lraW1lZGlh
Lm9yZwpodHRwczovL2xpc3RzLndpa2ltZWRpYS5vcmcvbWFpbG1hbi9saXN0aW5mby9vdHJzLXBl
cm1pc3Npb25zLWwK

--===============8211208071669730346==--

上面的這種方式顯然更加適合 unblock 的需求。原先的 HTML 格式被完整地保留了下來，即使 unblock-zh 無法處理此類字符編碼，也可以發送到每個郵箱後手動解決亂碼問題。

維基媒體計劃上所有的郵件列表是基於一個叫 mailman 的程序，包括 unblock-zh 。其他的郵件列表可以做到，unblock-zh 也可以。

• 有些郵箱是自帶坑的。比如上面 #2 中，unblock-zh 沒有把所有郵件內容轉成 UTF-8 的原因不是因為不支持原郵件使用的 GB 2312 ，而是因為原來郵件用的實際上不是 GB 2312 ，而是 GBK 或 GB 18030，但是發信客戶端非得把 charset 那一項寫成 GB 2312，mailman 無法解碼內容，只得原文保留。#2 的郵件是使用 Outlook/Live/Hotmail 的網頁版客戶端發出去的。通常的客戶端都能正常讀取，但並不見得所有的都能讀出來。

當然，上面的內容還只是我自己的猜測。我不敢保證自己的敘述和推斷全部正確，因為我自己也看不到 unblock-zh 的設置到底是什麼。這也正是我開這一討論想要說明的：現在 unblock-zh 的體系有嚴重的漏洞。unblock-zh 的管理員不同於維基百科站內的管理員、郵件進入 unblock-zh 需要經過少數幾人的審批，這使得 unblock-zh 存在內部黑箱的情況成為可能。——我指出 unblock-zh 存在漏洞，但我沒說過有人一定利用過這個漏洞。下面逐條詳敘：

• unblock-zh 是一個郵件列表。郵件列表是早期互聯網中網民進行討論的重要工具之一，但隨時間流逝，郵件列表的重要性大不如前。在通常的郵件列表中，訂閱該列表的成員使用通過回復他人郵件的方式來進行類似論壇跟帖式的交流。郵件列表的服務器會將所有發送到該郵箱的郵件轉發給所有訂閱了該列表的成員。郵件列表對於維基百科意義重大。Shizhao 等早期管理員不是通過社群討論，而是利用郵件列表討論成為管理員的。
  • 用 unblock-zh 舉例子。所有中文維基百科上的管理員「訂閱」了該列表。所有發送給 unblock-zhlists.wikimedia.org 這個郵箱的郵件都會被轉發給該郵件列表所有的成員，也就是中文維基百科的所有管理員。外面的人若要進行封禁申訴，直接發送郵件到該郵箱裡，所有的管理員理論上都能收到一份該郵件的拷貝。在其中一個管理員回復申訴請求後，會抄送一份到 unblock-zh 。抄送的郵件也會被轉發給所有成員。這樣，當成員（也就是管理員）看到了抄送過來的回覆後，就知道該請求已經有人回復了。如果管理員之間需要討論封禁事宜，管理員也可以直接發送郵件到 unblock-zh ，其他管理員也都能看到。其他的管理員若是想要就該封禁案發表觀點，直接回復該郵件，並把回復的郵件發送到 unblock-zh 中，所有其他管理員也會收到由 unblock-zh 郵件列錶轉發來的回覆。
  • unblock 不能算是「用於討論問題的郵件列表」。對於討論問題的郵件列表，通常只有該列表的訂閱者才會向郵件列表中發送郵件來商討事宜。但是 unblock-zh 每天都要接收大量郵件列表外的郵箱發送過來的請求。因此，為了提升討論質量，部分郵件列表會通過限制訂閱、限制只允許訂閱者發送郵件、所有外來郵件都需要經過列表管理員審批，審批通過後才會轉發給所有訂閱者的形式來控制討論質量。論壇可以刪除帖子，但郵件送達後沒有撤回的餘地。因此很多郵件列表都很注重其中郵件的質量。讓郵件僅以 plain text 發送、限制 HTML 元素使用也是通常郵件列表為保證討論質量會開啟的設置項。但是，unblock-zh 某種意義上作為中國大陸新手參與維基百科的必經之路，卻因為上面提到的諸多限制，導致相當一部分新手的申訴郵件無法正常收取。
• 眾所周知，unblock 是允許所有管理員成員加入、獲取內容的。管理員不應該泄露其中的申訴請求。但是同樣地，凡是有意向進行封禁申訴的郵件，都應該投遞給所有訂閱了 unblock 的管理員。然而，目前 unblock 仍然在預先審查郵件，只有審查通過的才會發送給所有管理員。前面提到了，通常郵件列表審查郵件是出於為了把關內容的考慮，unblock-zh 審查郵件，依 Kegns 的說法，是為了減少垃圾郵件 。但是，就目前可知的情況來看，unblock-zh 所有具有審查郵件權限的人，只有 Jimmy Xu、Kegns、Mys 721tx 三人。無論審查者是誰，只要人數有限、沒有公開徵求他人意見，客觀上就存在黑箱操作的可能。最重要的不是現在審查郵件的這三位是否正在（或者曾經）黑箱操作，而是大多數管理員沒有這方面的意識，根本沒有意識到自己在 unblock 里看到的郵件可能有故意或者無意漏掉的、甚至故意刪掉的。
  • 另一方面，就是垃圾郵件存在誤判的可能。在 QQ 上跟我聯繫的一個新手在郵件發送三天後都沒有回應。用其郵箱、郵件標題等信息去翻存檔，發現根本沒有收到這封郵件。當時我直接給他批覆了 IPBE ，並開始調查此事。但次日，他的郵件就收到了。可能是某名列表管理員最開始誤判了這封郵件，後來其他人覆核後發現有一封郵件被誤作垃圾郵件，於是重新放行，這才導致了延後四天收到郵件的情況。
  • 最後，就是對真正的 spam 和濫用申訴者反映可能不即時。儘管濫用 unblock 發郵件的行為非常少見，但不是沒有發生過。這時候就只能讓唯一能修改設置、屏蔽 spammer 的成員，也就是 Jimmy Xu 出面屏蔽。
• 儘管 Jimmy Xu 在一封 2014 年的郵件裡面說「歡迎其他有意向參與者聯繫」（大意），但實際上新上任的管理員甚少了解此事，更不要說主動參與郵件審查事務了。

總結一下：由於技術原因導致部分新手郵件進入 unblock 困難、耽誤新手參與維基；unblock 現在郵件審查機制不透明、人手不足，進一步導致新手和其他申訴郵件延誤；目前管理員普遍缺乏對 unblock-zh 以及其他郵件列表的認識，unblock-zh 的「上層」管理者架構不透明、缺乏監督。

所以，我們要做什麼？首先，私以為所有社群成員都有權利知道這一點——每個人都有可能遭受管理員的不當封禁，unblock-zh 作為封禁申訴渠道，保證其透明是有必要的；其次，我們要改進 unblock-zh 的後台設置——不一定全部照上面說的改，但一定要保證比現在更友好；最後，有關列表管理員和具有審核權限者，也需要在社群公開化，保證人手充足、不會有郵件因為審核者個人原因而被延誤甚至拒絕。

望諸位發表意見。

--Techyan（留言） 2017年8月16日 (三) 14:14 (UTC)

（純屬拋磚引玉啦）改成全開放的ticket系統，所有出入信息全透明。實現方法有很多，其中之一：在GitHub上開一個項目，然後濫用github的issue系統來處理我們的查封。對於隱私資料，則仍然寄給unblock，或者直接寄給管理員郵箱。頭腦風暴建議，沒有細想。Bluedeck 2017年8月16日 (三) 19:31 (UTC)

我的建議：1.如果編碼問題導致mailman接收出錯的話，應該想mailman反映或者調整配置來修正。2.對於申請LIPE或新賬號的，可以考慮使用新的郵件列表處理，將配置調松以方便接收不合規格的郵件，或者OTRS也可？3.管理員應該要加入unblock-zh，而且強調或教育如何使用（需要弄一份郵件列表使用手冊）。——路過圍觀的Sakamotosan 2017年8月17日 (四) 02:39 (UTC)

（可能有問題）4.進入unblock-zh的郵件先進入一個隊列，所有op都能分揀但不能刪除。在區分是垃圾郵件後所有「垃圾郵件組」，可以被刪除和不用轉發，是正常郵件則放入另一隊列，可以轉發。不過刪除應該有記錄並可恢復，以防誤刪或故意刪。以此減少審核人員過少而導致可能的暗中操作問題。——路過圍觀的Sakamotosan 2017年8月17日 (四) 02:43 (UTC)

如果使用OTRS系統，那就必須要所有管理員都是OTRS志工，但目前申請OTRS志工與申請管理員的管道不一樣，而且目前OTRS沒看到有規定管理員必定為OTRS志工。臺灣杉在此發言 (會客室) 2017年8月17日 (四) 08:15 (UTC)

OTRS也是一套系統，只是OTRS直接沿用軟件名作為該工作組的稱呼，例如以前bugzilla，我的意思是使用OTRS系統在建立一個基於mail-ticket的unblock組。——路過圍觀的Sakamotosan 2017年8月18日 (五) 08:37 (UTC)

英文版是仿效OTRS弄了個UTRS。--Temp3600（留言） 2017年8月17日 (四) 17:51 (UTC)

全透明的最大問題是會有人惡意擾亂（例如罵人，泄露隱私等），這些東西一旦被搜索引擎索引會有不好的影響。當然可以設置成不索引，但是另外建立一套全透明的系統並不比完全使用用戶討論頁申訴好（想想為什麼要剝奪用戶的用戶討論頁編輯權限）。另外我們完全可以fork一個英文版的UTRS，但是好不好用不好說。--GZWDer（留言） 2017年8月18日 (五) 20:36 (UTC)

我覺得改良mail-list會是比較簡單的做法。UTRS要請人寫代碼才行﹐不知要弄得何年何月。--Temp3600（留言） 2017年8月21日 (一) 14:56 (UTC)

哈哈哈哈，我開玩笑的而已，不會真的搞到2049年去。Bluedeck 🤔 2017年8月21日 (一) 19:47 (UTC)

對於互聯網上的「gb2312」混雜gbk、gb18030不能解碼，按照WHATWG/W3C的《編碼》（技術建議；TR）應該算是bug了。《編碼》裡面說得很明確，gb2312、gbk、gb18030一律用一個gb18030和gbk併集的解碼器理解。——Artoria2e5_編 討論要完整，回覆請用ping。 2017年8月23日 (三) 00:55 (UTC)

phab:T173894. 剩下那個 HTML 問題請改設置。--Artoria2e5_編 討論要完整，回覆請用ping。 2017年8月23日 (三) 01:12 (UTC)

「Dark Hoel！Terrible！」--113.97.43.185（留言） 2017年8月29日 (二) 06:41 (UTC)

認同應對unblock-zh機制進行檢討。unblock-zh已是實施8年多的申訴機制，現在是合適時機去處理解決當中之缺陷。如郵件審批可能會因審核員不足而延宕，造成封禁申訴無法及時處理。--千村狐兔（留言） 2017年8月30日 (三) 09:23 (UTC)

• unblock黑箱，CU黑箱，我們普通用戶簡直是待宰的羔羊，維基就毀在這夥人手裡。--Shwangtianyuan 自強不息 厚德載物 2017年9月5日 (二) 02:41 (UTC)

有關 Jimmy Xu 對 unblock-zh、IRC 的管控權獨攬問題

在與其他一些管理員通過站外渠道溝通交流後，我得知 Jimmy Xu 目前擁有中文維基百科 unblock-zh 郵件列表和 Freenode 上名為 #wikipedia-zh 的 IRC 頻道的最高管控權。考慮到上面只介紹了 unblock 存在的問題，沒有提到 IRC ，下面再對 IRC 存在的問題作一些介紹：

IRC 群組裡的權限共有三級。最高級者，可以踢出、禁言其他 IRC 頻道里的成員。但是，能夠賦予其他用戶高級權限的權限，在 #wikipedia-zh 上卻只有 Jimmy Xu 一人擁有。這不是什麼大事，因為中文維基站內的所有管理員都擁有操控一個能夠踢人、禁言的機器人的權限，一旦有人擾亂，可以直接通過操縱機器人來進行維護操作，管理員通常不需要更高的權限。但由 Jimmy 一人獨攬權限的情況仍然客觀存在，且據一名維基人的說法，Jimmy 曾有意地不給他人更高權限。考慮到 Jimmy Xu 最近並不活躍，若是 IRC 頻道出現一些意料外的狀況，處理起來將非常耗時。因此 IRC 的問題與 unblock 一併在此提出。

至於 unblock 郵件列表，在我上面這段論述寫完之後又出了一些新的狀況：因為三名審核員都沒有即時審核、放行郵件，導致 unblock 中郵件曾出現至少五天的斷流，期間所有申請 IPBE 的新手、封禁申訴等都在極端情況下等了五天才送達——而目前有數名管理員活躍在 unblock 上，一旦郵件送到了各個管理員手中，往往只需要數小時就能答覆，時間全部浪費在了審核員上。

Jimmy Xu 作為中文維基曾經非常活躍的技術管理員，如今已經不甚活躍，他獨攬中文維基兩大系統的最高權限，並在需要做出改進時不願動作。Jimmy Xu 沒有對上文在下的指控做出回應，在下已於 Jimmy 的用戶討論頁做出通知，希望 Jimmy 出面解決目前存在的問題。對於 unblock ，在下擬邀請數名最近比較活躍的管理員作為審核員（或考慮無審核員實行一段時間）；同時請 Jimmy 按照上面的提示進行設置調整，或指明不進行調整的理由；另請另一名維基人兼任 unblock-zh 的管理員。對於 IRC ，則請 Jimmy 給有意者授予相關權限。

--Techyan（留言） 2017年9月6日 (三) 13:26 (UTC)

Unblock-zh的問題比較嚴重，亦確實希望可以引入更多管理人員，令封禁申訴電郵可以更快速到達各管理員電郵。至於IRC，據系統回報，目前共有三個群主，除了Jimmy，還有Ben.MQ及Liangent。兩人均擁有群主權限。不過兩人亦是近來都不甚活躍。這個可以再與Jimmy討論。--J.Wong 2017年9月6日 (三) 13:50 (UTC)

真兇啊，又是在對歷史遺留問題不求甚解自己揣測。本來哪位想審信找我要一下密碼就行了，技術問題也沒什麼不能解決的。你倒好，也不來對話頁也不找-owner，非要費勁寫這麼多來「指控」還不通知本人？郵件列表一直都歡迎比Techyan更懂協作的管理員參與管理。--Jimmy Xu ^論 2017年9月6日 (三) 14:52 (UTC)

嘖嘖嘖，態度好差，有則改之無則加勉。人家提個意見你懂你就回答好來。人家寫的問題也是很客觀的，你還要諷刺人家不懂。要麼弄個考試，你跟他一起考試？不要這樣，有耐心就回答，沒耐心就不要幹了，把自己耗在那裡有什麼意思來。--SP RailwayGuest 2017年9月11日 (一) 10:41 (UTC)

(！)意見：我認為Jimmy Xu閣下不宜繼續獨攬權限。去年我當選管理員之後不久的一段時間，Jimmy Xu閣下就一直在irc對我「訓政」，而我懼怕他是群主，如果為逆他會被踢走，就常常只能順從他的意志處理站務。當時作為新管理員，我感到很困擾。門可羅雀的霧島診所_{歡迎光臨維基Q群：170258339}^{神社的羽毛飄啊飄} 2017年9月7日 (四) 01:30 (UTC)

關於IRC，從未出過什麼問題，折騰它幹嘛--百無一用是書生 (☎) 2017年9月7日 (四) 01:33 (UTC)

@霧島聖：都管理員了還怕踢走。。。。怎麼感覺和新手用戶一樣啊--百無一用是書生 (☎) 2017年9月7日 (四) 01:35 (UTC)

當時在irc的確還算是半個新人沒錯。門可羅雀的霧島診所_{歡迎光臨維基Q群：170258339}^{神社的羽毛飄啊飄} 2017年9月11日 (一) 10:11 (UTC)

「偉」光正的時昭陛下，您對irc一竅不通，所以就別在這裡亂講了，即使是維基百科管理員，irc群主一樣能踢。建議時昭陛下繼續專攻您的濫權大業，切記說多錯多，傷害您「偉」光正的巨人（mo）形象。黑暗雄鷹·給我留言·請關注管理人員和資深用戶的人身攻擊行為 2017年9月7日 (四) 01:49 (UTC)

(！)意見：請理解管理員也是人，管理員也不可能什麼都知道，有問題，完全可以友好的指出，我相信一般維基人都能夠正確的對待問題，請保持善意，這樣的諷刺對於解決問題並沒有幫助。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 03:54 (UTC)

(！)意見：制度有問題就談制度，人手有不足就談人手，而不應該是借題發揮攻擊管理員濫權。--Mewaqua（留言） 2017年9月7日 (四) 02:54 (UTC)

能踢就能踢唄（我當然知道能踢），不做錯事為何要怕被踢？--百無一用是書生 (☎) 2017年9月7日 (四) 03:13 (UTC)

Jimmy Xu口中「更懂協作的管理員」，事實上似乎完全不能領會最基本的維基方針，哎。。。 上海灘維基悍將  守望者傳奇  2017年9月10日 (日) 11:42 (UTC)

希望閣下也能就事論事，大家一起建設好維基才是正道啊。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 04:27 (UTC)

「大家一起建設好維基才是正道啊」，人神之間竟然對愛孟說了這麼一句話，呵呵呵呵，大家來看看哦，黃鼠狼給雞拜年了！113.116.171.81（留言） 2017年9月11日 (一) 07:16 (UTC)

那位什麼人神之間啊。Jimmyxu諷刺別人不懂的時候，你也回應一個呀。你表面的公平好歹也要做一做。否則你就不要起勁說別人不就事論事了。我覺得Jimmyxu這種不積極參與社群服務的行為，是應該要有其他人參與進來，否則站務都要停頓了。我們不是為了證明某個人很重要，才設立這個unblock的機制的，然後就放一個管理員在那裡。還是開放的好，怕什麼，多加兩個人天塌不了。--SP RailwayGuest 2017年9月11日 (一) 10:53 (UTC)

請參考我下面說的，我同意加更多的人，乃至不需要審查。另外，大多數的參與是根本無需誰批准的，同樣如我下面所說，請呼籲其他管理員積極參與回應unblock。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 18:01 (UTC)

人神之間，您忘了我是誰了？ （打個比方而已，請勿以後面那句話再給別人扣「人參公雞」之罪名，謝謝！）好比說：殺人犯看到被害人可以裝不認得了？ 上海灘維基悍將  守望者傳奇  2017年9月12日 (二) 15:34 (UTC)

如果你都知道比喻不恰當或會被誤會，就請不要做出類似的比喻。作為一個維基人，我在維基上的留言是基於其他人留言的內容，而和那句話是誰說得沒有關係。我相信很多維基人都是這樣做的，我也希望閣下也能做到如此。--人神之間_{擺哈龍門陣} 2017年9月12日 (二) 23:15 (UTC)

如果現在人神之間的賬號是本人操縱，那麼顯然前方的比喻是合理的；如果該賬號已經不在本人手裡，那麼現在的表現不出意外。 上海灘維基悍將  守望者傳奇  2017年9月13日 (三) 11:50 (UTC)

---

先談unblock-zh：我沒搞過mailman，當然也沒權限存取unblock-zh。不過從上面的論述可以看出一點：unblock-zh的控制者，或者說維護者，他們現在並不活躍，無法及時受理郵件，也不能及時解決技術故障。再概括一點就是人手的問題（其他問題主要還是由人手問題衍生出來的）。

最近一年內，社群已經有數位能夠保持活躍、已經或者有能力掌握相關技術的管理員，例如User:WhitePhosphorus、User:Alexander Misel、User:Techyan、User:A2093064、User:Bluedeck等，因此是時候解決問題了。我建議從以下兩方面來解決問題：

1. 開放unblock-zh的技術控制權限，使這些熟悉技術的管理員能夠及時調整設定，修正技術層面的問題。同時也可以預防和及時應對其他技術故障。
2. 不再實行審核制度，或者推選數位（至少是unblock-zh上活躍管理員數量的一半吧，我覺得）值得信任的管理員作為審核員，以防信件積壓。

這樣的話就不會因為Jimmy Xu或其他人在現實生活很忙而無法及時處理維基的事情了。

unblock-zh是中文維基重要的工具之一，我們不能讓它因為無人及時處理故障而癱瘓，所以自己太忙的話多派一些維護者就行了，而且只會有好處不會有壞處。雖然我們完全可以做新系統，但是從目前情況來看這樣做並不現實。如果能把技術型管理員派進去進行修理，使得unblock-zh的技術問題能夠得以修正，我們何苦重新造輪子呢？ --逆襲的天邪鬼（留言） 2017年9月7日 (四) 04:03 (UTC)

近大半年來都在IRC掛機，或者容我說兩句吧。首先，在下不知霧島君所經歷的是什麼情況，不過現時IRC社群已經通過WP:IRCPOL，縱然有人可能不承認，但至少大半年來都沒發生過什麼Jimmy君獨攪大權，恣意妄為之事，因為正如在下上面所言，IRC群尚有另外兩位群主及社群相當活躍。基本上，現在在下作為IRC OP，亦隨時可以把其他群管踢走，不用等Jimmy君出手。但無原無故誰會去動手踢人？別說得好像昨日剛踢完一個群管似的。現在唯一困難之處，大概是因為三位事務繁忙，未能及時為新當選管理員授予群管地位。就此，在下建議把群主權力授予User:WhitePhosphorus等常駐可信用戶。在下相信此舉足可解決IRC問題。--J.Wong 2017年9月7日 (四) 06:12 (UTC)

事情在客棧掛這麼些天，有沒有進展了？反正，假如我是unblock維護者，一方面我肯定不打算讓事情有機會在客棧上面出現，另一方面，即使真的上了客棧，看到之後也該有所動作，不給你們在客棧評論的機會。--逆襲的天邪鬼（留言） 2017年9月11日 (一) 03:13 (UTC)

請善意推定，管理員只是擁有系統權限的維基人，並不是和普通維基人對立的關係（儘管我知道有些事情可能導致了這樣的看法），但我還是希望大家能夠善意推定，就事論事。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 03:54 (UTC)

人神之間：「我們要善意推定！」；永康師傅：「要建設民主法治！」；才厚將軍：「要堅持反腐強軍！」，既視感啊既視感，XD。。。113.116.171.81（留言） 2017年9月11日 (一) 09:04 (UTC)

• 我不常在IRC，但是對於unblock-zh我可以發表一些個人意見。我去年下半年一直在處理日常unblock-zh的請求，儘量保證在收到請求的1-2天內處理，具處理詳情可以見我的貢獻記錄。去年底也在參加北美維基會議的時候見到了JimmyXu本人，並當面討論了關於unblock-cn的情況。會議後一直太忙，未向社群反饋此事，這可以算是我的一點疏忽。正好趁此機會向大家匯報一下：
  • 首先，我不了解審核權，但是我支持讓更多的人擁有審核權限，甚至向提議內所說，可以試着無審核員進行。但是un-block人手確實不夠，我剛才大致統計了一下，不是很精確，但是一個月的郵件少則100，多則200。而活躍的管理員只有個位數，而絕大多數操作都是集中於2、3個管理員之手。根據我的經驗，處理一天的申訴，包括閱讀郵件，判斷理由是否合理，解除封禁及後續處理等，大概會耗掉一個管理員每天一個小時時間。所以，當然歡迎更多的管理員加入。而據我所知，所有的管理員都應該能夠處理郵件列表，並沒有什麼權限限制，只要有時間有意願，就可以前來處理。如果有管理員無法處理郵件列表，請告知，我會幫忙解決。
  • 第二，現在的申訴列表中的絕大多數請求，都是來自大陸的VPN IP封禁所導致的，管理員做的幾乎都是重複性勞動。在會議期間我和JimmyXu以及其它一些中文維基人討論過這個問題，JimmyXu向我表示維基軟件正在做出一些改進（我不是搞技術的所以對詳情記得不是那麼清楚），到時候我們應該可以批量的處理這些請求，現在也過去一年了，中途我一直沒有機會向JimmyXu跟進此事。但既然這裡提出了，不知道各位技術人士能否在這裡討論一下可行性乃至如果建立起批量處理的方法。不過至少在能批量處理之前，人工處理的無法避免的，所以也呼籲更多的管理員參與處理unblock-cn。
  • 第三，也藉此機會希望大家在考慮問題的時候能夠理解管理員在背後的付出（有幾個管理員是堅持每天花一小時自願來處理這些重複性勞作的），JimmyXu本人也是在完全利用自己的業餘時間來幫助完善維基百科。希望各位維基人能儘量的就事兒論事兒和善意推定，而不是動不動就進行人身攻擊。如果有問題，完全可以在這裡正式的提出討論，而用上「指控」就有點太不善意推定了吧？
    • 謝謝，祝各位維基愉快！--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 03:51 (UTC)
      • 關於第二點，A24 搞了一套模板：user:A2093064/unblock-zh，足夠應付大部分重複的情況。 --碸中嘌呤的白磷_{萃取 打譜} 2017年9月11日 (一) 03:54 (UTC)
        • 我自己也有這樣一套模板，但感覺還是很累（也許是因為我太老了吧...），因為回覆郵件之後，還得去註冊頁註冊以及去用戶頁更改權限，並且在用戶討論頁歡迎並加上已授權的通知。更別提有一些特殊情況得反覆確定為啥該賬號在中文不能註冊或者權限放不開一類的。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 03:57 (UTC)
          • 關於中國大陸新手求救的問題，本頁後面還有一個討論。現在問題都攢到了一起，而且攢到了需要到客棧貼大字報的程度，實在遺憾。--逆襲的天邪鬼（留言） 2017年9月11日 (一) 04:04 (UTC)
            • 謝謝提醒，不過沒有什麼遺憾的，互助客棧本來就是為了解決維基百科遇到的各種問題而存在的，更不用上升到什麼貼大字報的程度，請平靜一些參與討論，謝謝。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 04:10 (UTC)
              • Techyan、逆襲的天邪鬼，想要改進的各位，都小心！人神之間又要如以前幾次那樣了，成事不足敗事有餘。凡是他摻和的事情，最後多半沒啥好的結果，最後大家一起跟着倒霉。113.116.171.81（留言） 2017年9月11日 (一) 07:22 (UTC)
                • 這位IP用戶，如果你認為通過理性的討論之後得出的結論是一起倒霉，那麼只能說明一開始就有錯誤所以需要糾正錯誤。並且請就事論事，說這些話對這個話題並沒有建設性意見。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 08:12 (UTC)
                  • 呵呵呵呵呵呵呵呵。113.116.171.81（留言） 2017年9月11日 (一) 09:04 (UTC)
                • 提出解決問題的方法，比只會指責更有用。隨着一批老人漸漸不活躍，現在的管理員更需要一本接手的工作清單（類似user:A2093064/unblock-zh的快速手冊），而不是各種的抱怨。或者覺得那些更需要讀讀User:Hat600/essay/主觀唯心。——路過圍觀的Sakamotosan 2017年9月11日 (一) 08:50 (UTC)
                  • 「不活躍」？這用詞錯誤。正確的用詞是「不貢獻」，但還活（gao）躍(shi)。113.116.171.81（留言） 2017年9月11日 (一) 09:04 (UTC)
                    • 活躍不一定是寫條目，還包括各種看不到的工作，當然你認為那些看不到所以不是，那就罷了（攤手）。——路過圍觀的Sakamotosan 2017年9月11日 (一) 09:36 (UTC)
                      • (？)疑問：那閣下到底想表達什麼？是「他們不活躍」，還是「他們活躍，各種看不見的工作」？門可羅雀的霧島診所_{歡迎光臨維基Q群：170258339}^{神社的羽毛飄啊飄} 2017年9月11日 (一) 10:04 (UTC)
                        • 如果說活躍就是多寫條目的話，那不就說成不活躍？如果不只是寫條目，或者是不是在做我們看不到的工作，然後外人覺得「噢，他們不活躍」？——路過圍觀的Sakamotosan 2017年9月11日 (一) 11:38 (UTC)
                          • 所以閣下到底想說他們活躍還是他們不活躍？門可羅雀的霧島診所_{歡迎光臨維基Q群：170258339}^{神社的羽毛飄啊飄} 2017年9月11日 (一) 11:48 (UTC)
                            • 問題是那位捅簍子的IP用戶怎麼看？或者就是薛定諤的貓？——路過圍觀的Sakamotosan 2017年9月12日 (二) 00:55 (UTC)
    • (？)疑問：「善意推定」這四個字是維基的方針麼？聽到有些人反覆搖着這面旗，我還以為成為方針了。--SP RailwayGuest 2017年9月11日 (一) 10:22 (UTC)
      • 一個字，是。第四大支柱：「請不要為闡釋觀點而擾亂維基百科，並假定其他維基人是善意的。」--Antigng（留言） 2017年9月11日 (一) 13:27 (UTC)
      • 善意推定是應該的。根據善意推定原則，如果非善意地指責別人「你沒有善意推定」，進而要求別人「你得給我善意推定」，本身就違反了「善意推定」。你應該善意推定他人都是善意推定，而不是非善意推定他人沒有善意推定。先有雞呢，還是先有蛋呢？哪能感覺嘞蓋繞口令啦。 上海灘維基悍將  守望者傳奇  2017年9月11日 (一) 15:12 (UTC)
        • 簡單一句話：總要求「別人要善意推定」的人，自己最沒有善意推定。 上海灘維基悍將  守望者傳奇  2017年9月11日 (一) 15:17 (UTC)
        • 送您一個論述，看完就知道錯哪裡了。WP:AGF佯謬。--Antigng（留言） 2017年9月11日 (一) 15:18 (UTC)
          • 從「空格」看，Antigng上面那句話是回復我的。而上面我的話是回復京滬線的，沒有回覆Antigng。雖然Antigng是不請自來，但既然，來而不往非禮也，那我就禮節性地回復Antigng一次：我早就和Antigng閣下說過了，我不想看到你，以後也不想和你有任何交集，請您以後不要不請自來回答我，就算你再跟我說什麼，我都不會回應，因為我不會和出賣用戶信任、泄露私人聊天信件的人有任何來往，請您好自為之。 上海灘維基悍將  守望者傳奇  2017年9月11日 (一) 15:26 (UTC)
            • 1、VPO是公共場所，任何用戶都有回覆的權利。「不要不請自來回答我」是做不到的，任何的留言中只要存在有意義的問題，我就有可能回應。2、您是否回復是您的權利，我管不到，畢竟維基百科不強迫他人參與。--Antigng（留言） 2017年9月11日 (一) 15:33 (UTC)
  • 比起上一個問題，還會討論如何解決。這個問題好像有股惡意的感覺。還不如提出有問題，我有解決方法可以這樣做，這樣省得質疑來質疑去，和平解決不就更好？——路過圍觀的Sakamotosan 2017年9月11日 (一) 11:54 (UTC)

我覺得這個問題沒什麼惡意，就是質詢一下。難道做的好不好還不讓人評論了？和平解決是什麼意思，就是大家睜隻眼閉隻眼咯？裝睡？--SP RailwayGuest 2017年9月11日 (一) 12:25 (UTC)

很簡單，提出解決方案（加人手或者做調整），at人過來問是否還存在技術原因。非要用點煽動的字眼，好像嫌事不夠大的樣子，我覺得這就不太好了。——路過圍觀的Sakamotosan 2017年9月11日 (一) 12:44 (UTC)

用的詞，那是語言藝術的問題。事情大了麼？怕什麼？人家也是想讓社群注意到事情的重要性，出發點是好的。要讓人說話，不要都做拍手黨。要拍手誰不會啊，如果心理素質差，不想被質詢，沒有被質詢的覺悟，那我覺得還是做個普通編輯好了。那就沒人來質詢你，那多舒坦。這裡是客棧，是提出問題的地方，不是開表彰大會的地方。人家才提了那麼點點意見，你怎麼就急眼了。別急，又沒說你，着什麼急。--SP RailwayGuest 2017年9月11日 (一) 12:51 (UTC)

(＆)建議用詞的問題的確是語言藝術的問題，但是我建議提議需要對事不對人。比如這件事情，可以說是現在unblock-zh可能缺乏一個開放的審核機制，這個我嚴重同意。但是推到JimmyXu獨斷專權上我個人覺得不太合適。如果有人事先和他討論過，而他拒絕交流，這樣描述也還行，問題是之前並沒有人直接和JimmyXu討論這個問題。很多問題人手不夠是客觀存在的，而之前很多工作集中於一兩個人，並不是他們願意獨斷專權，而是人手不夠的直接後果，希望大家能夠理解這一點。更多的管理員願意加入維護是一個好事情，我個人非常贊成！--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 18:29 (UTC)

用詞當然很重要，就是有些人喜歡挑用詞問題來發難的。本來可以不用說重口氣，非要加多幾程重。——路過圍觀的Sakamotosan 2017年9月12日 (二) 00:55 (UTC)

所以啊，漢語言一定要學好。這是我們的母語，我們有這個責任和義務，把語言學習給搞上去。孔子有云：「不學詩，無以言」，那就證明了語言的重要性。現在的很多人就是覺得語文麼，都會說的，不需要認真學，所以說的話往往詞不達意。樓上這個問題講的很好，對於大家都起到了督促的作用。--SP RailwayGuest 2017年9月12日 (二) 15:25 (UTC)

(：)回應人神之間：有人提出Jimmyxu獨斷專權的事情，本質上還是愛護他的，指出問題，對不對的話可以討論嘛，先提出來。你看這樣一討論不是效果很好嘛。順帶把語言問題也搞明白了。大家愛護關心Jimmyxu的發展，那才會提這些意見。用《私人訂製》裡的那句話，「越是經常批評您的領導才是真正愛護你的。不跟你拍桌子了，對你客氣了，也就不拿你當自己人了。現在誰跟誰隨便交心吶」。--SP RailwayGuest 2017年9月12日 (二) 15:33 (UTC)

(：)回應如果是出於愛護，我表示感謝，但是我建議下次用一個更好的方法，比如先和對方直接交流，如果無效，再這樣說也來得及。其次，我也很高興能把語言問題搞明白了，希望以後大家都能用很合適的語言來處理類似事件，這樣也有助於大家能更好的為維基百科做出貢獻。最後，如何和人交流是一個動態的，我不認為一個方法就能包治百病，但至少我相信在維基里，保持善意肯定是最基本的需求。--人神之間_{擺哈龍門陣} 2017年9月12日 (二) 23:22 (UTC)

不對呀，愛護的是Jimmyxu怎麼你來感謝了，太客氣了，不用謝啊。方法有好有壞，最重要麼就是能不能說清楚問題，再客氣方法再好，說不清楚問題總歸也是不行的。語言問題是個漫長的過程，用詞的準確需要慢慢的磨練出來，不能急於一時。自古像蘇學士、歐陽文忠公都是日積月累才寫出了振聾發聵的文章。像賈島，更是為了僧推還是僧敲月下門糾結了半天，甚至撞上了韓愈的坐騎。所以說，語言的矛盾將持續並且長期持續在維基里，大家都要有耐心。當然，語言問題中不能包含罵人這個成分，這已經超出了語言用詞的問題了。是關乎個人修養和家庭教育的因素了，反映了一個人的世界觀、人生觀和價值觀。在對於語言問題大容忍的情況下，我們對於罵人還是要零容忍。尤其是管理員更不能罵人，否則給外人感覺維基編輯的素質都不高了，這樣不好，百弊而無一利。最後，大家都是善意的，沒有惡意啊，就是說話難聽點，但是心都是好的。最後還是希望大家逐漸提高文學水平，畢竟漢語是我們的母語，語言工作還是很重要的。--SP RailwayGuest 2017年9月14日 (四) 00:46 (UTC)

完全同意閣下一個觀點，對於罵人還是要零容忍的，特別是在沒有交流的情況下無端的對其它維基人扣帽子這種行為，個人覺得在維基百科上還是越少越好。--人神之間_{擺哈龍門陣} 2017年9月15日 (五) 06:15 (UTC)

那你的手下烏拉跨氪他們罵人罵了那麼多次，每一次罵人都很嚴重，你不照樣視而不見了嘛。 上海灘維基悍將  守望者傳奇  2017年9月15日 (五) 14:09 (UTC)

• 現在有人都能直接代表社群決定一個管理員能不能被信任了，厲害，厲害。你不信任他是你自己的事，少擅自扯上及代表社群。218.19.207.157（留言） 2017年9月13日 (三) 11:07 (UTC)

被轉移至此的218.19.207.157於2017年9月13日 (三) 11:07 (UTC)的留言是回應User:守望者愛孟於2017年9月12日 (二) 15:19 (UTC)的留言。--Mewaqua（留言） 2017年9月13日 (三) 13:26 (UTC)

謝謝Mewaqua發現的及時，否則其它維基人就看不到這一段被某人刪除的留言了。--人神之間_{擺哈龍門陣} 2017年9月13日 (三) 22:48 (UTC)

「人神之間」賬號露出了很多明顯破綻，因為該賬號不知道人神之間和我在過去的大量通信往來。我已經知道是誰在背後控制了，可以了。 上海灘維基悍將  守望者傳奇  2017年9月14日 (四) 11:12 (UTC)

如果不和你爭論便是不知道過往以及有破綻的話，我也只能呵呵了，這種推理誰也只能甘拜下風。既然閣下已經解封，就多做點貢獻，少參加這種無謂的爭論，更不要隨意的刪除其他維基人的留言。--人神之間_{擺哈龍門陣} 2017年9月15日 (五) 06:15 (UTC)

更不要隨意的刪除其他維基人的留言，被我看破了所以著急上頭了？你叫別人「少參加這種無謂的爭議」，那你自己現在和我對話是在幹嘛？我說你也是怪可憐的，堂堂一個管理員，非要借別人的賬號來參加討論。你加入維基也已經快十年了吧，人家十年磨一劍，你怎麼十年了還是毫無改變呢？十年前就不屑承認自己的身份（home town），非要假裝自己是某個東部大城市的人，到今天也不敢堂堂正正用自己的賬號來討論，非要借個馬甲。你的姓氏說明了你的祖先是很霸氣很有地位的，希望你不要數典忘祖。行了，我和你繼續廢話真是多餘，我寫條目去了，拜拜，希望你好自為之。 上海灘維基悍將  守望者傳奇  2017年9月15日 (五) 14:09 (UTC)

哎...你要怎麼想我也改變不了，只是還好你的想法並不能改變事實。不爭論最好，你能專心寫條目更好的，拜拜。--人神之間_{擺哈龍門陣} 2017年9月15日 (五) 16:18 (UTC)

反正呢，我記得兩年前的時候，人神之間這個賬戶傳聞被盜號，然後從頭到尾，人神之間都沒出現，都是AddisWang一手搞的，如果人神之間不玩了，把賬戶給了AddisWang，然後再折騰也不是不可能的。愛孟你要拿出點乾貨來才行啊。黑暗雄鷹·給我留言·請關注管理人員和資深用戶的人身攻擊行為 2017年9月22日 (五) 05:26 (UTC)

---

我覺得這次發起討論的幾位是出於社群較為長遠的發展考量，是很好的一個議案，請各位回歸討論正題：如何解決「目前Jimmy Xu對Unblock和Irc管控的權限獨攬」的問題，撕別的話題沒意義。謝謝合作。實在想撕請到橫線上面去撕，橫線下面請討論正題。如發現繼續撕其他關聯不大的事情，醜話說在前頭：恕無禮，我將把關聯不大的其他內容移動到橫線上面。 上海灘維基悍將  守望者傳奇  2017年9月11日 (一) 15:30 (UTC)

• 贊成橫線下不討論與這個提議無關的內容，理論上整個互助客棧都不應該討論與相關提議無關的內容。關於unblock-zh的問題，根據我上面說的，我支持放開unblock的審核權，甚至於不審核。其它各位還覺得有什麼需要補充的？其次，更大的問題是維護人手的問題，我在此呼籲更多的管理員加入對unblock的處理，否則等待時間難免加長。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 18:07 (UTC)
• 必須注意WP:IRC並非中文維基百科官方群，任何站內的討論對IRC無效，任何IRC上的討論也對站內無效。站內遵守方針指引，IRC遵守WP:IRCPOL，所以在這裡討論IRC的問題是沒有意義的。--Antigng（留言） 2017年9月12日 (二) 01:19 (UTC)

具體規劃

首先，我希望 Jimmy Xu 能夠按照上方論述的要求對 unblock-zh 的後台設置做出必要的改動。否則請給出理由。除此之外，我提名在 unblock-zh 上很活躍的 A2093064、Wcam、WhitePhosphorus、Antigng、Alexander Misel 和我自己為列表的主持人（moderator）。考慮到 unblock 應該對所有管理員開放，因此如有其他希望擔任主持人的管理員，也請在下面留言提出。如果上方提到的被提名人願意接受，也請在下面留言表態。--Techyan（留言） 2017年9月11日 (一) 18:21 (UTC)

• (＋)支持，我已經在JimmyXu用戶頁留言表達了這個意思。同時我也報名，希望能加入維護列表。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 18:32 (UTC)

  請查收郵件。--Jimmy Xu ^論 2017年9月11日 (一) 18:46 (UTC)

  謝謝Jimmy，我已加入維護列表，如果還有JimmyXu未聯繫到的管理員，麻煩請直接前往Jimmy的對話頁請求密碼。--人神之間_{擺哈龍門陣} 2017年9月11日 (一) 19:03 (UTC)

  這Jimmy和人神之間唱雙簧也太直接了，(－)反對如此unblock管理權還是按Jimmy個人意志決定，同樣反對目前unblock繼續被非華人地區人士壟斷的情況。另外也沒有證據證明人神之間是被社群信任的管理員，該用戶曾經利用unblock黑箱，製造過社群的重大爭議性性封禁——京滬線和愛孟的封禁事件，因此不信任該用戶。unblock郵箱列表管理權應該由社群討論或投票決定，要求撤回目前無共識的授權。從當下討論的情況看，也沒有一個人表示信任人神之間。若Jimmy Xu和人神之間等人執意完小圈子控制，那麼我(＆)建議其他管理員另立新的受社群信任的unblock郵件列表，並考慮讓社群選出若干非管理員用戶作為觀察員，監督unblock運作。門可羅雀的霧島診所_{歡迎光臨維基Q群：170258339}^{神社的羽毛飄啊飄} 2017年9月12日 (二) 00:39 (UTC)

  (：)回應首先，管理員本身就是受社群信任的維基人。其次，我否認使用過unblock黑箱操作，所有unblock郵件往來都是可以查證的，任何在任管理員均可以查詢。第三，沒有任何人要小圈子控制，就像上面所述，任何管理員都可以找Jimmy拿到密碼。當然，如果有維基人願意開發，我完全支持開發一個新的unblock郵件列表，多總比不夠的好。--人神之間_{擺哈龍門陣} 2017年9月12日 (二) 01:14 (UTC)

  你也可以問拿鑰匙的，問不到大可以再來問責。而且也有一些新當選的管理員加入，除非你覺得那些也是不可信的。——路過圍觀的Sakamotosan 2017年9月12日 (二) 01:01 (UTC)

  人神之間確實不被信任，該用戶曾經以偽造的聊天記錄作為「證據」，逼迫本人道歉認錯，騙我說「道歉就解封」，結果我在沒有任何違規的情況下，為了避免撕逼，違心地被他逼迫得道歉了，但他馬上出爾反爾，拿我的「道歉」進一步作為給我扣罪名的「證據」，給本人和其他用戶的心靈造成了極大的創傷。人神之間本來就是以玩「unblock黑箱」出名的，而他和本討論所質疑的Jimmy Xu以及長期打壓社群發展的AddisWang都關係很好（所謂近朱者赤近墨者黑，人神之間曾經為AddisWang衝鋒陷陣，帶頭打壓大陸維基社群，現在還是老樣子），而人神之間脫離中文維基社群也已經很久了，甚至出現過6個月來「打一次卡」的情況[1]，所以該用戶取得Unblock管理權顯然不合理。另外，從來沒有所謂「是個管理員就永遠被信任」的道理。請其他受社群信任的管理員站出來維護，取得Unblock管理權限，維護方針，謝謝！ 上海灘維基悍將  守望者傳奇  2017年9月12日 (二) 15:19 (UTC)

  我認為維基百科最好的一點，就是所有的貢獻和編輯都有跡可循，所有unblock郵件列表也都是對所有管理員公開的。有心想要了解事件詳情的維基人，我相信他們能從編輯歷史以及各種存檔中了解到清晰的來龍去脈並作出自己的清晰判斷。另外相信了解我的維基人都應該知道我對大陸維基社群的態度和貢獻。最後，我非常贊同你的最後一點，我也希望更多的管理員前來加入維護unblock。--人神之間_{擺哈龍門陣} 2017年9月13日 (三) 22:55 (UTC)

• 願意接受。--1=0，歡迎加入WP:維基百科維護專題 2017年9月12日 (二) 01:16 (UTC)

  請查收郵件。--Jimmy Xu ^論 2017年9月12日 (二) 02:19 (UTC)

  已收到Jimmy Xu關於unblock-zh管理接口的郵件。--1=0，歡迎加入WP:維基百科維護專題 2017年9月12日 (二) 02:41 (UTC)

"觀察員"是一個很好的提議。可是會不會太複雜?--Temp3600（留言） 2017年9月12日 (二) 01:31 (UTC)

也許我是最好作為觀察員的，因為我曾經多次被Unblock黑箱作業/偽造的證據所害。 上海灘維基悍將  守望者傳奇  2017年9月12日 (二) 15:19 (UTC)

我還是傾向增加審核員的數目。設立觀察員，又要寫個新的方針，行政上會多出不少工序。--Temp3600（留言） 2017年9月12日 (二) 17:36 (UTC)

雞米許閣下是好像除了在互助客棧上留了幾個請查收郵件的言之外別的一句話都沒說？請問上面那些閣下修改的設置改沒改？讓Temp3600等人好像都去你討論頁上留言了還當看不到？還有techyan說了和我自己，為什麼沒見閣下聯絡techyan賦權？揭了某些人的老底就把當事人給搞得火氣和針對性這麼大。。--黑暗雄鷹·給我留言·請關注管理人員和資深用戶的人身攻擊行為 2017年9月12日 (二) 05:51 (UTC)

附議--雲間守望 · 留言💬 2017年10月2日 (一) 06:35 (UTC)

所以問題到底解決沒解決？—拖到機器人存檔就是勝利（留言） 2017年10月12日 (四) 01:29 (UTC)

增加unblock-zh票據工單系統站點的意見調查

目前我們的站外查封申訴以郵件列表的形式處理。我作為處理的管理員不太喜歡郵件列表這個系統。我想弄一個類似英文維基百科UTRS的票據工單系統，並加以美觀的設計。

我認為這樣做的好處有幾個：用戶界面可用性增加（對管理員和用戶都是這樣）、可以自定美觀的用戶界面、安全性增加（全程HTTPS、HSTS）、可以讓用戶自行選擇那些信息可以公開，哪些信息需要保密、增加條理性，等等。

雖然如此，不知道大家的想法如何。因為建立這個系統這個工作量不小，我怕建出來了沒人用，或者大家可能提出我還沒有想到的問題。所以我現在這裡問一下。

若您感興趣技術細節：User:Bluedeck/etc/sandbox/box1515612315922

另：這個系統可以和當前的郵件列表系統並行運作。

Bluedeck 2018年1月10日 (三) 14:11 (UTC)

• 支持支持支持！藍桌說的我都支持！反正我又不是濫權管理員--Yangfl（留言） 2018年1月10日 (三) 15:01 (UTC)

好大一個坑。為啥不host在toollabs？--百無一用是書生 (☎) 2018年1月11日 (四) 03:20 (UTC)

因為聽說性能太糟糕而且申請條件苛刻所以懶得申請，反正我手頭有空轉的服務器資源，所以就自己host。Bluedeck 2018年1月11日 (四) 03:25 (UTC)

工單系統的數據備份會怎麼做？--菲菇＠維基食用菌協會 2018年1月11日 (四) 03:27 (UTC)

OS-wise snapshot、根目錄手動gzip、SQL dump、API 導出。Bluedeck 2018年1月11日 (四) 03:36 (UTC)

網站必須開設在wmf的服務器上。如果有這個系統的話，這個系統應當被認為是官方性質的申訴系統。開在wmf的服務器下，維護服務器的終極權限掌握在wmf的手裡，這與系統的官方性是相稱的。相反，如果在個人服務器上架設網站，維護服務器的終極權限掌握在特定用戶手裡，沒有人有權監督該站的運行，這可能會導致問題。--Antigng（留言） 2018年1月11日 (四) 08:59 (UTC)

這個要求（或者這個要求的精神）是出自哪裡的，wmf有過主動維護toollabs上搭載的非wmf的服務的情況嘛？Bluedeck 2018年1月11日 (四) 14:46 (UTC)

「wmf有過主動維護toollabs上搭載的非wmf的服務的情況嘛」，出於技術原因強制終止部分出問題的程序，這樣的案例比比皆是。--Antigng（留言） 2018年1月11日 (四) 15:26 (UTC)

原來如此。Bluedeck 2018年1月11日 (四) 17:57 (UTC)

理論上有官方性質的系統不應該放在wmf控制以外的地方；toollabs申請很簡單，性能雖然糟糕但是做這個功能夠了。--哪位維基人能夠一下打死五個？ 2018年1月11日 (四) 15:41 (UTC)

已經從tooladmin申請了membership，那麼，我試試這個VPS。如果可以，我就在這裡host。另外還發了郵件問問WMF的想法。Bluedeck 2018年1月11日 (四) 16:48 (UTC)

1. WMFLabs上的東西原則上不允許存儲隱私內容，而WMF運營的mailman跟WMFLabs是相互獨立的；
2. 自建服務器缺乏保障隱私的方式；
3. 自建服務器難以保證穩定；
4. 看了下你的sandbox，拖庫了怎麼辦？最起碼沒看到這方面的考慮，好歹也得hash幾遍；
5. 帶這麼個系統就意味着跟隨配套的所有教程（站內的以及站外的，比如你們經常用的那個解決IP封禁問題的截圖等）、指南（WP:IPBE等）、模板（T:Block review等）、用戶頁面（MediaWiki:Blockedtext等）都得改；
6. 如果不能保證穩定性，並試圖用郵件列表作為備用選項的話，那麼上面這些就準備天天改吧；
7. 同上，反而增加新手使用成本；
8. 會有很多人用？快去查查今天unblock裡面總共才幾封郵件
9. 這玩意上線第一天就來幫你進行一下壓(D)力(D)測(o)試(S)
10. 順便心疼你花了的域名錢
11. 這麼有錢的壕直接上keyless SSL多好（笑）

--Techyan（留言） 2018年1月11日 (四) 19:06 (UTC)

如果建好了之後反而增加使用成本的話那我太失敗了，我肯定是為了讓使用更容易才建設這個的。sandbox里的數據結構是讓你知道結構而已。安全方面，user.secret = SHA256(server_salt(m)), m=SHA256(client_salt(passphrase))，其中m的計算在客戶端進行。穩定性方面，和服務器關係不大，現在哪個服務器不是99.999 uptime，關鍵是內存泄漏和exception別飛出去，這是我要解決的問題。最後我在這裡問的是如果我做的好，大家用不用。如果我做出一堆垃圾來，那當然沒人會去用 : /，你不用擔心我做出垃圾之後逼着大家使用.... Bluedeck 2018年1月11日 (四) 20:35 (UTC)

是啊那你準備怎麼解決#5、#6的問題？一般那VPS的uptime能上三個九就怪了，母雞關幾十分鐘維個護都不帶提前通知一聲的；更何況機器穩定又怎麼樣，zhmrtbot都壞了多少次了

反正我感覺你如果實在閒就搞，但我個人不是很支持。並且技術上的討論結束了之後不意味着社群就同意用這個東西（部分）替代現在的unblock機制了。--Techyan（留言） 2018年1月12日 (五) 16:50 (UTC)

「並且技術上的討論結束了之後不意味着社群就同意用這個東西（部分）替代現在的unblock機制了。」，我問的目的調查一下就是做出來之後社區用不用，不用我就不做了，不是為了討論技術。「更何況機器穩定又怎麼樣，zhmrtbot都壞了多少次了」，所以說了不是機器的問題，而是軟件的問題。還有，為了防止誤會，再強調一遍，我調查的問題是：如果我做的東西好用，大家用不用，而不是如果我做出一個成天掉線的服務，還會硬要大家遷移到這上面。Bluedeck 2018年1月12日 (五) 20:51 (UTC)

是啊，我知道你的問題是這個，但是現在很明顯沒人在研究到底是用還是不用，反而都去計較技術方面的問題了。沒什麼人願意出來研究到底用不用的原因一方面是話題被帶跑了（鍋當然我也得背）；另一方面則是現在沒個成品，或者一個像樣的雛形，大多數人也很難定奪。這麼說也只是提醒你一下，按照現在的討論，完全有可能你做出來了東西但是社群不肯用。畢竟現在沒有人明確地說支持。順便，#5和#6的問題還希望解釋一下，把話題往正道上帶一帶。--Techyan（留言） 2018年1月13日 (六) 12:19 (UTC)

1. 5，那就改唄，用模版改，這樣只有改第一次比較費時。#6：上線之後肯定先騰出一段時間做穩定性測試啥的，沒問題才投入使用。Bluedeck 2018年1月13日 (六) 20:26 (UTC)

直接用wiki賬號認證登錄不就好了--百無一用是書生 (☎) 2018年1月12日 (五) 03:44 (UTC)

我研究一下api。Bluedeck 2018年1月12日 (五) 16:18 (UTC)

老實說，我覺得unblock-zh不便性讓不少管理員卻步，不太願意處理（至少我是這樣）。如果有更人性化的系統的話，處理上也比較容易。—AT 2018年1月12日 (五) 16:58 (UTC)

不能做一個建立在郵件列表之上的人性化的系統嗎，而不是重新做一個新的系統出來。——꧁༺星耀晨曦༻꧂（留言） 2018年1月12日 (五) 17:45 (UTC)

是吧，我也是這麼想的，但是郵件列表能做的事情不多。只能美化一下界面，而且沒有很多人用我這個模版。Bluedeck 2018年1月12日 (五) 21:12 (UTC)

真要搞的話不如重啟引入OTRS系統的討論。--雲間守望（對話） 2018年1月13日 (六) 10:53 (UTC)

備註：在下十分信任Bluedeck的技術水平，只是考慮到隱私問題，建議還是放在維基媒體計劃的服務器上。--雲間守望 2018年1月13日 (六) 11:34 (UTC)

實際上這個系統的隱私和郵件列表的隱私沒有區別，都是隱私內容所有管理員可見。Bluedeck是開發者兼管理員，所以本來就可見隱私內容。要說的話由於傳輸層安全的使用，這裡只比郵件列表安全，而不是反過來。Bluedeck 2018年1月13日 (六) 20:33 (UTC)

什麼叫好用什麼叫不好用，沒有一個客觀的標準。空對空討論「如果我的東西好用你們用不用」可能意義並不大，就像討論「如果有一個完美的智能管理員機器人你們用不用」那樣。所以還是建議先做出一點東西來再開展進一步的討論。項目拿風險投資的時候也不是單純有一個概念就可以的。--Antigng（留言） 2018年1月13日 (六) 14:27 (UTC)

討論的目的是為了知道有沒有除了易用性之外的原因而會讓大家不想使用的。比如上面有人提到的隱私問題，政策問題或者需求問題。如果有這樣的問題存在，大家可以提出來，如果我覺得非技術性障礙太多，可以提前拉到，就是這個意思。Bluedeck 2018年1月13日 (六) 20:24 (UTC)

三個問題：

1. 想不想使用：普通用戶不會太關注這個問題，除非經常被封需要申訴；經常處理unblock的管理員討論討論就好了。
2. 放在哪裡：如果決定要做，把系統放在wmf控制的服務器上是比較合理的，而非個人的服務器，以免有一天這個人變成了破壞者。
3. 實現方式：OTRS是不是有現成的代碼？可以把郵件對接到這個系統裡，這樣對於用戶來說既可以郵件也可以上系統，而管理員有個統一的處理界面？

--哪位維基人能夠一下打死五個？ 2018年1月16日 (二) 14:03 (UTC)

• (－)反對：沒有必要，畫蛇添足，粉飾鍍金。galaxyharrylion（留言） 2018年1月15日 (一) 14:34 (UTC)
  • 事實上unblock也沒有必要，這個黑箱早已飽受詬病，而且一直都是被濫用的狀態。galaxyharrylion（留言） 2018年1月15日 (一) 14:38 (UTC)
    • 好奇unblock怎麼濫用？--百無一用是書生 (☎) 2018年1月16日 (二) 01:19 (UTC)

您好像沒有在維基文庫發送此通知，是否是因為該系統不適用於維基文庫？--Midleading（留言） 2018年1月21日 (日) 10:07 (UTC)

可以使用的，我忘記了：/ Bluedeck 2018年1月21日 (日) 20:12 (UTC)

• @Bluedeck：上述討論似乎有支持需要增加該系統站點，應可公示，謝謝你--Z7504非常建議必要時多關注評選（留言） 2018年1月28日 (日) 09:00 (UTC)

這是意見調查，完成時產品還沒有做出來呢，產品完成後才需要公告吧。Bluedeck 2018年1月28日 (日) 21:50 (UTC)

建立封禁申訴的本地共識

早在2008年就提出要建立本地的封禁申訴指引，但之後數年就再也沒有任何進展了，儘管已經有相關內容擴充。為了使解封更為程序化，以便後續有被封用戶更好了解封禁申訴指引，我提議再次建立封禁申訴的本地共識，將此內容列為正式的指引，最好參照英文指引作進一步擴充（可以讓路君先參考一下）。--Shwangtianyuan 不忘初心 牢記使命 2024年4月2日 (二) 16:08 (UTC)

認為可以詳加討論。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月2日 (二) 19:10 (UTC)

封鎖申訴是跟執行封鎖/解封相對獨立的議題，也是需要一個獨立的方針，我分拆一下討論議題。另外我合理相信這倆議題不會小，@Shwangtianyuan：要不要考慮移去方針討論頁走RFC？--路西法人 2024年4月3日 (三) 04:56 (UTC)

大體上認同增修的方向。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月3日 (三) 07:51 (UTC)

在封鎖申訴、解除封鎖等事宜上，務必明確限制被封鎖人在申訴期間及解封過後的部分言行舉止。過往已經出現過好多次在管理員認定封鎖理據妥當但用戶已不需要再被封鎖的情況下，獲解除封鎖的用戶後續宣揚「原封鎖理據欠妥」的觀點騷擾管理員，WMLO如此（站內行為）、Wpcpey如此（在站外宣揚擾亂觀點）、近期解封的Chinuan12623（申訴期間）亦是如此。

我認為有必要在給予解封機會的同時說清楚解除封鎖僅是因為給予機會改善，而非認定原先封鎖不妥。管理員在解除封鎖時應清楚說明「接受申訴」是基於「原封鎖理據錯誤」、「給予改善機會」（即認定原封鎖理據合理）還是「原封鎖例句失效」（改為認定行為合理，但在原規則下確實違規）。第二種情形下，若獲解除封鎖錯誤宣揚自己行為無誤或管理員封鎖有誤的觀點，應視為「不認為自己有錯，即仍有繼續擾亂行為風險」而恢復封鎖；第三種情形下四處宣揚「管理員封鎖有誤」（即便管理員原先封鎖符合當時規則），亦應視為騷擾管理員、對管理員假定惡意再被封鎖。--路西法人 2024年4月3日 (三) 09:12 (UTC)

我覺得你這裏提到的第三種情形可能還要視乎當時的規則本身是否合理。如果當時的規則是因為本身不合理而修訂的話，那再修訂落實前對該規則的處理應該適用IAR，因此在這種情形下把說「管理員封鎖有誤」的人直接視為騷擾管理員、對管理員假定惡意可能不妥當。但是，如果當時的規則並非因為本身不合理而修訂的話，那我贊同提議的舉措。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月3日 (三) 10:24 (UTC)

管理員按照當下方針執行封鎖，那麼就不能說是管理員的封鎖有誤，那是方針的問題不是管理員的問題，管理員只負責執行方針。管理員不需也不應為方針指引過時而被指責「有誤」。把方針的問題歸在管理員身上顯然毫不合理。這也是為什麼我認為在任何情況下，就算方針改了，也不能因此追溯認定管理員當時判斷有誤，因為這是方針寫的。被解封用戶說「當時方針設計有問題」是完全合理的，但說成「當時管理員封鎖有問題」則顯然是在追究錯誤的責任。--路西法人 2024年4月3日 (三) 10:31 (UTC)

如果你在2024年4月3日 (三) 09:12 (UTC)提議的說明獲加入至WP:封禁申訴的話，我傾向認為「被解封用戶說『當時方針設計有問題』是完全合理的」這點需要被明確，但是請容許我對於「管理員按照當下方針執行封鎖，那麼就不能說是管理員的封鎖有誤」這句話持一定的保留意見。如果所有（或大部分）管理員都很清楚當時的規則顯然有誤的話，那管理員完全可以根據IAR選擇不執行當時的規則，在這種情況下管理員明知規則顯然有誤但依舊執行，損害的是維基百科社羣的和諧，因此說依顯然有誤的規則執行封鎖的管理員完全沒有責任是不合理的，但我認同這種情況下主要的責任在於不合理的規則而非管理員，而我也認同在這種情況下把主要責任歸結給管理員可以視為騷擾管理員、對管理員假定惡意。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月3日 (三) 10:41 (UTC)

根本不應該會出現全部人都知道規則有誤但沒人提出修改該規則的情況。「有誤」跟「社群不再認同」是兩回事，管理員按照當下方針執行「當下社群相對不認同的方針」是不可以追究管理員責任的，「不認同方針」不是不執行方針的合理理由，不認同就該獲取共識修改方針，管理員執行這些方針不能被追責。如果方針本身有誤，而管理員刻意鑽這個漏洞去作出常人都能判斷不符合總體利益的封鎖操作，這叫WP:GAME。

此處僅是針對被封鎖人宣揚此類觀點，但理論上任何其他用戶亦應受類似的管轄（構成輕率指控），防止任何人單純因不滿管理員操作而借別人的口來騷擾管理員。--路西法人 2024年4月3日 (三) 15:12 (UTC)

雖然未必會出現全部人都知道規則有誤但沒人提出修改該規則的情況，但這不意味有人提出修改該規則後該規則就必定能成功修訂（比如WP:OA2021前蟲蟲飛經常性地阻撓大部分WP:7DAYS的修訂提案通過，因此在7DAYS成功獲修訂前，已經有若干管理員在執行7DAYS上應用了IAR，比如KirkLU），你這裏混淆了「提出修訂」和「執行修訂」兩種情形。我認為桐生ここ下方所言也局部代表了我的意見，而基於WP:5P5，我認為社羣應該要求管理員使用常識，而非要求管理員教條式地執行方針。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 00:01 (UTC)

此外，我有必要澄清一點：我説的是「有誤」而不是「過時」，我考量的是當時的條文本身的合理性，而不是條文的時效性。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月3日 (三) 10:42 (UTC)

我覺得分三種

1. 責任在用戶，管理員給予改善機會。用戶不應去控訴管理員。
2. 責任在管理員，管理員解除錯誤的封禁。用戶可以控訴管理員。
3. 方針不合理，管理員依照社群討論解除封禁。在於社群要求管理員是使用常識，還是教條式的執行方針，如果是前者，那麼管理員也有少量責任，如果是後者，管理員沒有任何責任。

--桐生ここ★[討論] 2024年4月3日 (三) 15:13 (UTC)

回@Sanmosa、桐生ここ：「使用常識」最大的問題出在社群往往會鑽這個漏洞，事無大小都訴諸常識。比如苗君除權案中，WMLO及Cangjie6在禁制方針討論中，曾有用戶在吵「允許提報對方違反禁制應是常識」，但最終發現根本與常識沾不上邊，甚至在過往討論中有非常明確且更有力的論點去否定該想法。正是因為社群用戶總在不合意時訴諸常識，並試圖以此將責任歸咎於管理員，我才強烈反對將「常識」列為追究管理員責任的條件。

在這個討論中「要求使用常識」的「常識」其實根本不「常識」：「方針有社群共識支持」和「管理員負責執行方針指引」是絕對的常識，「管理員認為方針有問題所以不執行」這叫酌情而不是常識。只要方針是這樣寫，理論上應該有當初設立時的道理，在假定善意原則下，應假定方針有社群共識支持，如此管理員執行有社群共識支持的方針指引不能被追究責任。管理員自然有使用常識的義務，在使用常識的背景下錯誤理解方針，這個情況下管理員固然有一定責任；但在沒外人干預的背景下管理員執行假定有社群共識的方針，這可不可以成為追究管理員合理執行方針指引的責任。「社群要求管理員」怎樣怎樣往往只會變成一個經常被鑽的漏洞。--路西法人 2024年4月4日 (四) 02:01 (UTC)

不認同這個見解。我就拿DYKC一度存在的「所有投票須附理由」規則來説吧，在改成現在的「支持票不須附理由」前，簡單規定為「所有投票須附理由」的原因是對於再更之前「投票理由未涉及條目如何滿足DYK推薦資格的票無效」的規則如何理解的爭議，2015年時因為社羣無法就「涉及條目如何滿足DYK推薦資格」的定義達成共識而不再要求投票理由需要「涉及條目如何滿足DYK推薦資格」，但這也造成了2015年至2019年間大部分的DYK支持票都清一色寫上了「符合標準」、「達標」之類的字眼。然而，就算看回2015年的討論背景，即使維持要求投票理由需要「涉及條目如何滿足DYK推薦資格」，我說的問題依然存在，因為無論是2015年前的規則還是2015年至2019年間的規則都是希望能「遏制水票」，但如我在2019年的討論所説的，「寫『符合標準』當作理由並不能遏止水票。大家有目共睹，2015年方案是一個徹底的失敗」。在這種情況下，「只要規則是這樣寫，理論上應該有當初設立時的道理」這個條件是被滿足了，但不見得那樣寫的規則實際上就肯定那麽有道理。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 02:32 (UTC)

（還有，DYKC規則的這個例子可能也某程度上反駁了LuciferianThomas所説的「不可能存在『所有人都知道某個方針有問題卻不去修』的情況」。）Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 02:43 (UTC)

所以管理員執行這個看似明顯有問題的方針怎麼了？IAR是管理員基於自己判斷而作出特別情況，你只能要求管理員按照當下方針、程序行事，但你不可以在修改方針前要求管理員「必須IAR按照你認為的常識行事」。在方針修訂前，任何不成文的規定都只是IAR或者「慣例」，稱不上「常識」。--路西法人 2024年4月4日 (四) 03:06 (UTC)

見下。此外，我還是這句話：個別用戶認為的「個別用戶認為的」與真正的「個別用戶認為的」也是不等同的，在一有人提出「按常識行事」時直接把他打成他要求「按照（僅）他認為的常識行事」並不妥當。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 05:20 (UTC)

「常識」本來就是不一致的，唯一一致的標準是方針指引。如果連執行方針指引都應被質疑行為動機，甚至追究責任，我相信就會出現過往Tigerzeng所說的問題。當時他也清楚指出，應由社群擔起指示管理員操作的責任，制定、修訂方針顯然是一種方式，而不應該是期待管理員行使任何形式的「裁量權」去IAR不執行方針。現在在你的想法下，符合某些人意思的就是常識，不符合同樣那些人意思的就不符合常識、需要追究，顯然就的確是「按照（僅）他認為的常識行事」。--路西法人 2024年4月4日 (四) 13:01 (UTC)

我提7DAYS的例子主要是希望説明存在社羣希望指示管理員進行恰切的操作，但被現行（或當時實行）的規則阻撓的情形，這種情況下管理員應該合理判斷社羣到底希望指示甚麽給管理員。我認為你這裏對我的觀點的總結與我的實際想法並不相符。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 15:20 (UTC)

簡而言之：個別用戶認為的常識不等於是常識，常識是指「客觀上所有正常思維的人都能得出相同的結論」的才叫「常識」，但我確信不可能存在「所有人都知道某個方針有問題卻不去修」的情況，即使有也是社群的問題而非執行方針的管理員的問題。--路西法人 2024年4月4日 (四) 02:03 (UTC)

你還是沒有回應我説的7DAYS的例子，而且你還是混淆了「提出修訂」和「執行修訂」這兩種不同的情形。我並不是想要抬槓，但我認為你應該也清楚個別用戶認為的「個別用戶認為的」與真正的「個別用戶認為的」也是不等同的。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 02:40 (UTC)

方針修訂前的IAR正是真正「個別用戶認為的」情況。方針修訂前，執行原有有漏洞方針是基本要求，不按條執行是個人意志。7DAYS的例子我不熟悉，無法作出評價，但顯然禁制方針中一經體現社群經常出現「個別用戶認為的常識」而非真的常識的情況。管理員有權IAR，但按條執行是他們的責任也是理論上方針僅容許他們做的事，按條執行是不可能追責。--路西法人 2024年4月4日 (四) 03:12 (UTC)

請參閱WP:訴諸常識：當形成某一立場或解釋某一行為時，要根據已有的共識、社群基本原則、百科全書的利益作為立論之基礎，而不是你的個人常識。方針指引再怎樣，還是社群共識通過的，管理員執行就有他的道理。en:malicious compliance是不能追責的，因為他確實遵守了社群共識通過的方針。管理員遵守了（目前社群廣泛不認同也好、就質疑者不認同也好的）方針指引就還是遵守方針指引，問題在於方針指引，不在管理員。社群可不要習慣自己的問題全卸在管理員身上，管理員按照方針行事這才是最廣泛、最必須的「常識」。--路西法人 2024年4月4日 (四) 03:18 (UTC)

請務必謹記WP:IAR方針是說「如果有規則妨礙您恰當地改進或維護維基百科，請忽略該規則」而不是「你必須忽略該規則」。管理員不忽略「某些人認為不合常理」的方針是道理，行使IAR是情理。請分清楚道理和情理。

這裏說不能追責是說管理員遵守方針指引下不能被追責，如果管理員運用IAR脫離方針指引框架的決定有問題，當然就是管理員本人的問題；但管理員遵守、不忽略方針，是道理、是方針、是原則。--路西法人 2024年4月4日 (四) 03:26 (UTC)

依舊不認同，請參閲v:槍口抬高一厘米，要是社羣確實打算追責的話，那社羣已經有足夠的正當理由去這樣做了。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 05:18 (UTC)

維基百科無此方針、無此共識，這不是常識。--路西法人 2024年4月4日 (四) 12:29 (UTC)

按你的邏輯，「按照（僅）他認為的常識行事」是不可取的，然而你現在做的事情不就正是在要求我「按照（僅）你認為的常識行事」嗎？我不認為單憑你説一句「這不是常識」，然後這就不是常識了。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 15:11 (UTC)

既然你已經完全認定了你自己所想的（包括「槍口抬高一厘米」的概念）就是常識，那麼我無話可說。我有說「維基百科無此方針、無此共識」，所以才「不可能構成社群內的『常識』」，但你決定選擇性閱讀並說出「單憑（我）説一句」這樣的話，那我只能說你根本沒在理解「常識」是什麼，而是仍然將自己所想的視為常識。--路西法人 2024年4月5日 (五) 01:39 (UTC)

還是這句話：我認為你這裏對我的觀點的總結與我的實際想法並不相符。如果你實在無法妥為總結我的觀點的話，你並不用勉強自己這樣做。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月5日 (五) 02:39 (UTC)

我是完全難以理解上方兩名用戶的思維。管理員方針訂明管理員「唯能實現社群討論所得的共識」，這說明「執行方針」是他們行使權限時唯一能做的事，僅有在管理員本身認為方針不合理時自主行使忽略規則的權利時才會存在例外情況。WP:IAR是說「如果有規則妨礙您恰當地改進或維護維基百科，請忽略該規則。」為什麼現在可以被扭曲成「如果社群認為規則不合理，你必須忽略該規則」？在規則不合理時，討論修訂的責任在於社群，管理員沒責任無視社群不認同的方針，既然沒責任何來追責？

我觀察到的情況是，當管理員按照方針執行職務，如果不合某些用戶的意思就叫做「請使用常識」。這完全是事後孔明的表現，卻完全忽略了管理員本身是按照方針指引給予的權利行事，就算有問題也是出在方針上。Sanmosa指出7DAYS和DYKC，若有人反對、阻攔修訂討論，不就代表那不是「常識」了嗎？如果阻攔的意見是毫無道理的，現行的方針自然已經保護提案人可以忽略這些意見；若阻攔的意見是真的有道理、甚至有其他方針指引支撐的，那完全稱不上常識。--路西法人 2024年4月4日 (四) 03:47 (UTC)

所以您的解答已說明是後者，管理員需要當一個方針執行機器人。--桐生ここ★[討論] 2024年4月4日 (四) 04:11 (UTC)

然而我不認同這個見解。如果管理員僅僅是執行方針指引的機械人的話，那我找個訓練有素的AI來代替管理員執行方針指引也無不可，不過這樣把管理員非人化真的好嗎？Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 05:12 (UTC)

此外，針對「若有人反對、阻攔修訂討論，不就代表那不是『常識』了嗎」這個説法，我想提以下兩點：

• 根據我之前的觀察，社羣其實不乏脫離實際情形思考的法條主義者，然而法條主義並不是常識。WP:共識#什麼是共識甚至也開宗明義地説了「共識應當考慮到所有正當合理的意見」，如果我們無視了「正當合理」這個元素來判斷一件事情是否「常識」，這是非常危險的舉措。
• 上面我提到的7DAYS雖然符合「有人反對、阻攔修訂討論」的條件，但OA2021與此後7DAYS修訂的成功通過恰好反映了「有人反對、阻攔修訂討論」不能代表那不是「常識」，甚至在此期間除我以外有很多用戶都多次反映修訂前的7DAYS的不合理之處，那當時真正的「常識」到底是甚麽我認為值得大家思考。

Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 05:32 (UTC)

用戶被禁制跟其過往參與討論期間的觀點是否有效並不衝突，被禁制後他的觀點仍然可以是有效觀點，只是他無權再繼續推動他的觀點，「後來他被禁制後議案獲得通過，所以他的論點是無效的」是完全不恰當的。除非他是因為exactly那一個論點被判斷為擾亂，他的論點則仍然是有效論點，綜上自然不會因他被禁制、議案通過，所以存在常識。你最近才因exactly這一個「因人廢言的傾向」吃過禁制，現在又故態復萌了？--路西法人 2024年4月4日 (四) 12:36 (UTC)

7DAYS的情況是在蟲蟲飛被禁制前已經有（除我以外的）用戶明確表達過當時7DAYS的規定與蟲蟲飛對當時7DAYS的規定的理解的不合理之處，這甚至是在7DAYS的原始規定一開始通過的時候就已經有的了，具體你可以看WT:共識在2020年至2021年間的存檔紀錄（畢竟你自己在上面也承認你不熟悉7DAYS的具體情形），因此我反對你把我對於OA2021前的情況的陳述打成「因人廢言」。我相信你很清楚輕率魯莽地指控他人行為不當屬於不文明行為，而且我也不是第一次跟你説這點了。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 15:09 (UTC)

你動輒就稱蟲蟲飛「對方針理解錯誤」，卻是裝作看不到目前方針加入的註釋的原先提案中除了蟲蟲飛還有多人提出合理異議理據，顯然不存在「常識」，也只是恰好多數異議者後來因其他擾亂行為被封鎖、禁制，提案最終才得以通過。你所指「（用戶被禁制）後修訂獲通過反映有人反對不代表不是常識」則是將「是不是常識」和「修訂通過」關聯至「用戶被禁制」下，實際是你連你自己因人廢言了也不知道。

你所指「有人反對、阻攔修訂討論」不能代表那不是「常識」即你認為「有人反對仍可以代表存在常識」、上方也是一來就說「對方理解錯誤」，就算撇除用戶禁制的因素，你認為你的修訂提案「存在常識」，即反對的人都沒有你所謂的「常識」嗎？你從頭到尾在引用WP:常識，卻只選擇性引用符合你利益的部分，完全無視同一章節下WP:訴諸常識要求不要以個人常識去評斷他人行為、引用方針與指引比起訴諸常識更為有效，甚至將訴諸常識視作失禮行為。

WP:IAR方針只是容許在合適情況下忽略方針，而沒有賦予要求他人忽略方針的權利，更沒有賦予要求他人使用自己所認為的常識的權利。--路西法人 2024年4月5日 (五) 01:36 (UTC)

「有人反對、阻攔修訂討論」本身不構成「不是常識」的充分條件，此外你這裏還是忽略了我上面提及到的「共識應當考慮到所有正當合理的意見」。我有必要特別聲明我這裏所說的「正當合理」應該由社羣按不同情況作判別（故此我不能僅因你自己一個人說「還有多人提出合理異議理據」、「顯然不存在常識」就必須相信「還有多人提出合理異議理據」、「顯然不存在常識」就是實情），因此你把我所說的總結為「要求他人使用（我）自己所認為的常識」並不妥當。要是我真的「要求他人使用（我）自己所認為的常識」的話，我大可以直接說你上方說的東西全部不符合常識，而用不着在下方請求其他人的意見，我之所以沒有做前者的事情正是因為我自己並不贊同「要求他人使用（我）自己所認為的常識」。既然現在我們在做的事情是訂立方針指引，那我們倆在上面說的話都不能作準，這一切還是要看接下來社羣的討論共識如何。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月5日 (五) 02:49 (UTC)

@桐生ここ、LuciferianThomas：要不這樣：既然這裏對於「社羣要求管理員是使用常識，還是教條式的執行方針」這點，以至於「方針不合理，管理員依照社群討論解除封鎖」的情況下管理員是否存在一定責任有不一致的意見，那不妨就邀請更多用戶來就著這點深入討論，看看社羣到底是怎樣的看法，畢竟現在我們在做的事情就是訂立方針指引，這本來就需要廣泛的社羣共識基礎。（具體要邀請哪些用戶，我暫時沒有想法，可能可以放Bulletin請求用戶關注。）Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 15:32 (UTC)

這裏也ping發起討論的@Shwangtianyuan與有參與討論的@Ericliu1912。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 15:37 (UTC)

一般而言，方針與指引即代表社群共識，內容通常也符合常識。所以我並沒有見到「使用常識」及「教條式執行方針」存在根本衝突。至於後者，我想這本質上是基於「忽略所有規則」而為之處置，同時也能促進社群變更共識，修訂方針與指引（其實前者也一樣——所謂「使用常識」去「凌駕」方針與指引，也不過就是「忽略所有規則」一種體現）。其實無論如何，管理員都應該就任何操作負責，但這所謂「負責」顯然僅限於操作本身，而不應該超出其他管理員自身無法控制的因素之外。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月4日 (四) 15:40 (UTC)

@Ericliu1912：那甚麽是「管理員自身無法控制的因素」？給個定義吧？再不然舉例説明也可以。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 15:42 (UTC)

我稍微思考一下，明日再回覆，今日先休息了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月4日 (四) 15:43 (UTC)

雖然還沒想到具體案例，但我認為所謂不可抗力因素，可以是不涉及管理員操作本身（例如線下現實社會動態），或管理員操作當下無法知悉或未經嚴格查證難以明悉（例如某人曾因故在站外透過社群媒體與他人合理溝通，但站內管理員不見得知道）者。若有額外想法，或再補充。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月7日 (日) 08:44 (UTC)

@Ericliu1912：容我再追加一條問題：你既然提到你並沒有見到「使用常識」及「教條式執行方針」存在根本衝突，那作為現行方針的「忽略所有規則」可以如何「教條式執行」？Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 15:34 (UTC)

那應該是唯一不適合「教條式」執行的準則吧？畢竟該政策本身的宗旨就是有必要時可以不「教條式」執行其他政策（這裡說的自然是前面所說的例外情況，而不是常態），是以為「維護百科全書」所為之最終手段。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月10日 (三) 03:07 (UTC)

若然社羣真的要求管理員教條式地執行方針，那「忽略所有規則」就會事實上失效，因為一定會有人想把所有的例外情況都給排除掉。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月11日 (四) 02:41 (UTC)

至於方針合理且責任在用戶，以及方針合理且責任在管理員這兩種情形，我認為這裏應該已經存在共識了，也就是責任在用戶時用戶不應控訴管理員，而責任在管理員時用戶可以控訴。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 15:34 (UTC)

Eric Liu說的不錯，提出了另一種觀點。

其實無論如何，管理員都應該就任何操作負責。

而且，責任是否在用戶其實也不是一個人能決定的，因此用戶有權利在任何時候提出討論，但在任何時候都不應該騷擾管理員。--桐生ここ★[討論] 2024年4月5日 (五) 03:10 (UTC)

我並不反對這個意見，但我認為這裏討論的是甚麼情形能被認定為「騷擾管理員」。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月5日 (五) 03:24 (UTC)

舉例來說：

• 提出申訴不算
• 不斷的Ping管理員算
• 發起一次討論請大家評理不算
• 反覆的對同一個問題發起討論算
• 在社群一些人認為管理員有錯的情況下，提出RFDA不算
• 在沒有任何人支持，一意孤行的提出RFDA，意圖報復或施壓管理員算
• 其他WP:HA、WP:PA等行為算

--桐生ここ★[討論] 2024年4月5日 (五) 03:52 (UTC)

你這裏說的「申訴」和上面說的「控訴」具體上有沒有甚麼差別？「在社群一些人認為管理員有錯的情況」有沒有任何例外情形？Sanmosa _{Szégyen a futás, de hasznos} 2024年4月5日 (五) 04:25 (UTC)

申訴是進行封禁申訴

控訴是在客棧公審管理員--桐生ここ★[討論] 2024年4月5日 (五) 05:37 (UTC)

感謝澄清。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月5日 (五) 08:17 (UTC)

@Shwangtianyuan：你還打算原案推動嗎？Sanmosa _{Szégyen a futás, de hasznos} 2024年4月17日 (三) 13:00 (UTC)

沒有打算了。--Shwangtianyuan 不忘初心 牢記使命 2024年4月17日 (三) 13:04 (UTC)

@Shwangtianyuan：那我給個建議：從enwiki現版重新翻譯一次。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月18日 (四) 05:45 (UTC)

可以這麼做，英文版的話，指引內容更為完善些，我當時就是這麼想的，以英文現行版本為基礎。但是某些內容可能與中維其他方針指引不符，所以我還沒有翻譯。--Shwangtianyuan 不忘初心 牢記使命 2024年4月18日 (四) 05:58 (UTC)