維基百科:互助客棧/其他

互助客棧： 消息  方針  技術  求助  條目探討  其他 |  知識問答

發表前請先搜尋存檔，參考舊討論中的內容可節省您的時間。

公告欄

• [公告] 第一屆仲裁委員會選舉方案、微調放寬中文名註明位置及提議引入CollapsibleToggle作為預設啟用可選擇關閉的小工具已經通過。
• [公告] 設立編者著作權調查、新聞動態/重複發生的項目中的領導人更替、引進CampaignEvents擴充功能、公布管理人員任免案有資格投票者人數及名單及寄送檢討管理人員任免制度的通告正在公示，如有意見請儘快提出。
• [公告] 討論頁話題索引現正重投測試。如有意見、建議或報錯，請至互助客棧的討論串提出。
• [討論] 互助客棧方針區正在討論為非原創研究方針翻譯章節部分新增補充說明，請踴躍參與討論。
• [討論] 互助客棧條目探討區正在討論末任中華民國大陸時期一級行政區行政首長列表是否應即時撤銷FL資格的問題，請踴躍參與討論。
• [討論] 互助客棧其他區正在討論管理人員任免制度檢討等事及第一屆仲裁委員會選舉方案細節，請踴躍參與討論。
• [討論] 快速刪除方針討論頁正在討論快速刪除方針O4款的調整，請踴躍參與討論。
• [討論] Unblock-zh.org正在試運行。同時互助客棧繼續對於其各項細節徵求意見。
• [通知] 深色模式現已供所有行動版及桌面版網站（Vector 2022和Minerva皮膚）的使用者使用。如有任何問題，歡迎在討論頁或透過頁面右側的回報功能提出。
• [協作] 第二十二次動員令於7月6日至9月8日間舉行，歡迎踴躍參與！

• [協作] 現有129個頁面需維基化，335個條目需清理，24個移動請求正在討論。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	Unblock-zh.org	85	16	Ericliu1912	2024-08-29 18:14
2	請求社群判斷已經數據過期的使用者是否為傀儡	6	3	MCC214	2024-08-25 12:27
3	仲裁委員會的選舉	55	11	AINH	2024-08-29 21:22
4	引進CampaignEvents擴充功能	6	5	WiiUf	2024-08-29 12:46
5	再議設立編者著作權調查	9	5	人間百態	2024-08-24 14:29
6	為管理人員任免制度檢討等事	44	15	Ericliu1912	2024-08-29 18:12
7	關於新建LTA頁面	16	6	Nostalgiacn	2024-08-25 13:27
8	管理操作覆核請求：被提報使用者明顯存在不文明行為時拒絕做出相應處理	21	8	UjuiUjuMandan	2024-08-26 16:45
9	請求CCI Lki5168	14	6	人間百態	2024-08-28 09:42
10	管理操作覆核請求：不對顯然違反雙向交互禁制的行為進行處理	9	3	Ericliu1912	2024-08-29 00:44
11	為何WP:XRV需要在本頁提出？	3	3	0xDeadbeef	2024-08-28 18:23
12	提議完善MediaWiki:Spamprotectiontext	2	2	ZhaoFJx	2024-08-29 21:25

發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面 或完成討論之議題
手動設定
當列表出現異常時， 請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注：（重新整理）

維基專題與協作

目前此主題無正在討論的議題

Unblock-zh.org

Unblock-zh.org網站的樣子

很久以前討論過的一個專案，也就是unblock-zh的網站版，我最近給他做出來了，如果對測試版軟體感興趣的話，請去 https://unblock-zh.org 這裡去看看。（注意測試版軟體，你的使用者最後很可能被刪掉！）7月7日update：軟體進入試運行階段，此時產生的工單等數據將永久保留。Bluedeck 2024年7月8日 (一) 19:21 (UTC)

附帶一個教學視頻 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外使用者申請帳號的方式是Wikipedia:帳號請求發送郵件，其實也沒有太不方便。但是這個途徑我覺得還是更直觀一點，比郵件列表好用一點，尤其是管理員處理的時候。我的想法是網站可以和郵件列表並存，或者以後達成互聯。歡迎提出意見。Bluedeck 2024年4月29日 (一) 04:05 (UTC)

PS. 已經收到tigerzeng的意見，允許使用者自訂提供的IP位址欄位，以解決部分代理的問題。Bluedeck 2024年4月29日 (一) 04:22 (UTC)

超 英 趕 美 —— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月29日 (一) 08:09 (UTC)

我最期待的畫面出現了。--AT 2024年4月29日 (一) 09:14 (UTC)

好吧，終於把這個弄出來了——是藍桌弄的？那就不出奇了。 讚——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)

非常好UX。至於是否方便了使用者，我好奇能否在合理的範圍內收集一些統計數據作對比，這樣最有說服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)

另外這個工具讓我想到了我很久之前做的維基媒體伺服器連通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)

非常好軟體。

不必要的功能建議：1.通過遍歷封鎖日誌的摘要有無對應模板，顯示是否是ip封鎖。2.通過接口調用在介面一鍵建立帳號（和授予ipbe？）

另外問一下數據託管在哪裡？將來投入使用的話需要作為存檔使用，所以數據需要備份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)

一鍵建立帳號/授予PIBE的話，有兩種途徑。第一，管理員通過oAuth授權unblock-zh.org，通過管理員帳號操作，然後從本地日誌看來，操作者是管理員。第二種途徑是，成立一個機器人帳號，比如名叫 unblock-helper-abot，並且賦予機器人管理權限，然後通過機器人操作，並在摘要里說明是根據哪個管理員的指令操作的。讓我來決定的話，我傾向於使用第二種方式，因為我希望儘量不要向第三方授權我自己的帳號，但是第一種方式的日誌更加清晰。請問一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)

使用OAuth可以只需要簡單的身份識別獲得權限，用於確認是不是登入系統的對應是wiki的哪個使用者。然後代理操縱的機器人可以標記操作人員的wiki使用者名稱（通過前面獲得的資訊）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)

如果不改變單管理員授權模式，我傾向於第一種，這樣和原先的工作模式保持一致，便於查詢。

mw:OAuth/For_Developers稱應用做的操作會有標籤。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)

在這裡沒有看到可以使用oauth給使用者添加組別的選項，那麼也是說IPBE的授予只能透過abot進行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)

的確只能這樣。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)

咱好像記著這種權限似乎不需要特別勾上某個選項就預設擁有，您要不嘗試一下？ Stang^★ 2024年5月8日 (三) 01:14 (UTC)

真的假的，在授權的時候不聲明卻可以操作改變使用者群組這麼重要的操作？如果是真的那也是個bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)

用API能查IP有沒本地封或者全域封，好像不是必要。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)

讚 讚 讚 牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)

@Bluedeck：話說可給管理員布告板抄送一份通知連結至此？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月1日 (六) 08:43 (UTC)

@Bluedeck：想好奇請問是否有考慮過部屬在wikitech:Help:Cloud VPS？如果有，為什麼不選擇部屬在該處？--SunAfterRain 2024年6月4日 (二) 09:30 (UTC)

管理員通告版：不知道效果會怎麼樣啊。等上線後在ASN通告一下，然後TG呀IRC呀廣播一下應該就行。CloudVPS：他的介紹說自己是標準的VPS，但是又有跡象表明他不是完全標準的環境，導致我不想把時間花在部署，測試，更換環境，以及踩坑上面。對我來說，寫軟體是趣味十足的事情，而調試環境則是讓我胃腸不適的事情。目前我沒有換環境的需求，因為開銷太小。如果有我再考慮cloudvps。cloudvps的另一個問題是只有在virginia有DC，但這不是一個大問題。Bluedeck 2024年6月8日 (六) 04:00 (UTC)

以我個人看法，部屬在CloudVPS的隱私疑慮絕對會比一個外部網站好很多，當然你維社群願意接受那我也沒什麼意見就是了。雖然不清楚是筆誤還是什麼的，如果開銷太小的話我自己是會考慮換過去啦。--SunAfterRain 2024年6月10日 (一) 17:54 (UTC)

可以理解你所說的。我可以把cloudVPS當作一個長期目標，最終遷移到那上面去。Bluedeck 2024年6月14日 (五) 05:29 (UTC)

試運行

在過去的幾周里，我增加了最後的一些的功能，分別是1）按日期搜尋排列工單；2）郵件回復模板；3）管理員刪除工單、刪除消息介面；4）使用者改名功能。我想知道大家覺得還缺少哪些網站本身的功能（郵件伺服器、機器人授予IPBE除外）。如果感覺差不多了，那麼可以進行試運行。試運行期間，再對可能發現的新的功能需求進行補充。試運行的提議正在進行公告。如果通過，將會將網站首頁文字改為試運行，並暫時移除一些只具有展示效果的連結，然後在使用者無法註冊的提示頁面加入網站的連結，這些操作大概最多需要一天就能完成。在試運行決議通過前，如果對網站有任何問題，歡迎在此討論。Bluedeck 2024年5月13日 (一) 23:30 (UTC)

功能方面，個人認為管理員不應該有刪除工單的能力，這個應該由維護者來做，比如遇到spam/擾亂性工單就打上相應的標籤，若干天后自動刪除；可不可以出個statistics大概寫一下某月某人處理了多少工單之類的；反spam方面怎麼樣，你覺得需要加個recaptcha嗎；模板建議是放到Github或者類似公開的地方，需要改的人發pr；可以考慮加一個link/merge功能麼，比如一個使用者就一個問題發了多個ticket，這個時候可以把它們關聯起來；感覺可以把login改的小一點，或者讓非管理人員意識到不需要登入就可以發ticket。

另外就是建議放到toolforge或者cloud VPS上。順便問個問題，你覺得這個系統需要承擔unblock-zh最原始的封鎖申訴職能嗎 Stang^★ 2024年5月14日 (二) 01:47 (UTC)

• 謝謝提議！簡短回應：

• 刪除工單就是為了應對擾亂才設計的功能。刪除之後可以恢復或檢視。（UI需要另外添加）工單的永久保留或刪除問題在下面討論。
• 反spam：UTRS目前是阻止同一個IP位址多次發送工單。但是我的方案不記錄IP位址，無法阻止。我可以考慮一下記錄ip地址的hash，並由此進行rate limit。我個人完全不喜歡captcha，除非不得已，我可能會考慮上captcha。在此之前我會儘量用其他手段處理spam問題。我有一些asymmetric proof of work的方法能防止自動化的spam。如果有人無聊到要手工spam，那麼唯有記錄IP並進行區段查封這一個辦法。（但是這樣一來，不就把本身的目的給擊敗了？？）
• 郵件模板：我不會放在github，畢竟不是每個管理員都會開PR，我簡單的開一個使用者頁面存儲目前的模板，誰想添加，給我留個言即可。郵件模板都是非常簡單的純文字模板。當然，如果你喜歡用gh，那麼在前端的repo里有一個檔案，你也可以直接PR這個檔案。
• link/merge：race condition太多，最多做成stack overflow/github issues那樣，「標記為#109的duplicate。關閉」這種解決方案。
• login改小：我肯定會讓新使用者看到不login就能發工單，這是一個重要的因素。
• statistics：這個我一定會做，因為這會讓處理工單變得很有趣，我的設想是做一個leaderboard，能夠激發人們對於處理工單的無限潛能，哈哈哈哈。
• Hosting：toolforge不能滿足我的要求，CloudVPS不熟悉。將來打算支持圖片上傳，需要一個能掛載S3的環境，另外多區域host允許你把伺服器託管在東京/首爾/LA。目前，伺服器託管在Vultr的新澤西區上面。
• 這個網站做成網站的形式，是為了新使用者方便的註冊+IPBE（也就是unblock-zh-ipbe的功能）。處理被長期封鎖的使用者在郵件列表中50-100封郵件那麼長的申訴，並不是網站初衷。如果有人就是要在網站上申訴，管理員也選擇在網站上處理，那我不會站出來阻止，但是如果網站上出現了對維基百科歷史有一定意義的討論內容，我覺得有應當抄送一份到郵件列表。

Bluedeck 2024年5月14日 (二) 04:12 (UTC)

update: 已經增加了檢視和恢復已刪除工單的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)

另外還有兩個別的需要討論的問題：

1. 工單是否永久保存？永久保存是目前的預設，而且郵件列表也是永久保存的。但是我覺得比如掛上「處理結束」標記90/180天之後永久刪除相關資訊這個是更安全的做法，想徵求一下大家的意見。
2. 開源：從一開始我就設想開源。這個專案有4個repo，其中3個可以在最近開源。一個需要我檢查一下有沒有API Key之類的物品遺落在代碼中，然後才能開源。請期待。
3. 共同參與：如果您想共同參與開發，或者參與對伺服器的運維，歡迎在這裡提出來。Bluedeck 2024年5月14日 (二) 04:49 (UTC)

感謝貢獻，整體非常完善。如有需要可以協助維護。--Borschts^{™ 歡迎外帶一碗羅宋湯} 2024年5月14日 (二) 13:32 (UTC)

存檔應保留，只是可以限制普通使用者存取。另外，也應考慮先行在站內撰寫說明頁面，或補充現有方針與指引不足，以便利用。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月14日 (二) 15:05 (UTC)

注意到兩點可以改善：

• 無法建立帳號者不應提供「我不想提供郵箱」的選項，建立帳號時需填寫對方電郵地址才能安全發送臨時密碼。如果不想提供郵箱則難以協助建立帳號。
• 需要添加提示文字，若不提供IP位址則申請有可能不獲受理（始終審批IPBE時需要驗證使用者是否使用proxy）。

--路西法人 2024年5月15日 (三) 07:52 (UTC)

我腦海中預想的不提供郵件的處理方式：網站生成一個強的隨機密碼並記錄在工單中，使用者通過隨機密碼登入。優點：使用者不需要郵箱地址。缺點：不提供郵箱的使用者等於需要不斷的刷新頁面檢視處理進度，是一個糟糕的體驗。對於管理員，需要複製粘貼網站生成的密碼來建立帳號，也是多了一個步驟。上面我只是說明了操作的可行性，至於這個功能是否保留，可以繼續討論決定。對於第二點，IPBEG如果有這個要求，那我完全可以添加這個提示文字（甚至可以在維基百科設定一個頁面，比如Template:Unblock-zh/strings/new-ticket-notice，然後網站可以反映這個頁面的任意文字。）Bluedeck 2024年5月19日 (日) 06:22 (UTC)

我的想法是只要有任何第三方人員可以接觸到任何密碼的方案都是不安全的，尤其在發送郵件時在此類第三方網站留存臨時密碼亦是相當危險的；即使我信任你會盡力保障網絡安全，但顯然不安全的操作應儘可能完全避免。郵件、代理IP位址等都尚算不太危險的資訊，密碼真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)

我想了一下覺得你說得很有道理。如果有的使用者收到臨時密碼後不加變更，那麼等於這個使用者的密碼永遠的掛在一個所有管理員都能看到的地方，是不妥的。我已經把介面改成如果請求帳號，必須提供郵箱，否則無法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)

一些minor的建議：about一頁，Puzzle Globe似可譯為「拼圖球」，Wikibooks譯名應為「維基教科書」非「維基圖書」。不提供郵件的提示，「一串30幾位的工單」應作「三十幾位」。login介面沒有明顯的返回按鈕，側欄也消失了。lookup介面可以考慮加注工單號和郵箱擇一提供即可。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年5月21日 (二) 03:01 (UTC)

另外我在想讓其選擇點選提交IP的選項是否也應該把UA也提供給審核使用者檢閱（方便反破壞比對）。--路西法人 2024年5月23日 (四) 07:54 (UTC)

統一回復。1）login介面有意如此設計。2）必須同時輸入工單號和郵件，否則任意人士可以通過廣泛查詢郵件探知私密工單。3）UA資訊只有CU才能訪問，所以顯然不能提供。另外就算使用者主動提供了，那麼IPBE處理者拿什麼進行比對呢？畢竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)

2) 啊那就是提前提示建立工單時未提供電子郵件的須放空？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年5月27日 (一) 06:29 (UTC)

沒有提供電郵的工單號會比較長，所以我可以改一下軟體，讓這種工單號不論是否輸入電郵都能夠正常查詢。這樣可以不破壞介面簡潔易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)

好的 讚 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年5月29日 (三) 07:32 (UTC)

---

將開始試運行。公示已經進行了一個多月，收集到了很多改進意見，並實施了很多更新。今天起，我將正式修改MediaWiki軟體介面，在網站上標註試運行字樣，並在公告欄和ASN中對社區和管理員們進行公告。Bluedeck 2024年7月7日 (日) 16:26 (UTC)

@Bluedeck：請問IPBEG們可以如何存取工單？--路西法人 2024年7月10日 (三) 03:25 (UTC)

@LuciferianThomas：我正在編寫為IPBE權限持有者提供權限的功能。完成後，IPBE將獲得和管理員基本一致的功能。目前編寫的功能是對於下方討論中方案一的實現。編寫完成後，我將會在使用者討論頁面通知IPBEG權限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)

@Bluedeck：能更新進度嗎？--路西法人 2024年7月22日 (一) 02:49 (UTC)

現在IPBE已經能取得權限使用了，但是目前使用者介面和IPBE權限能做的事情不吻合，比如IPBE無權刪除工單，但是會顯示刪除按鈕，我正在改這些小問題。Bluedeck 2024年7月29日 (一) 07:08 (UTC)

@Bluedeck：預計試行多久？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年7月20日 (六) 17:44 (UTC)

不知道，但是目前肯定不是一個完善的狀態。比如我就發現了好多好多想要改進的地方，寫在Roadmap中。Bluedeck 2024年7月29日 (一) 07:08 (UTC)

IPBEG的權限基本設定完成，測試可用，在此通知IPBEG組成員@user:AINH，@user:ASid，@user:Borschts，@user:LuciferianThomas，@user:SCP-2000，@user:だ＊ぜ。Bluedeck 2024年8月1日 (四) 01:43 (UTC)

感謝。希望未來能添加罐頭回覆（請求提供更多資訊如封鎖訊息、已授權〔時長〕）等。--路西法人 2024年8月1日 (四) 02:21 (UTC)

是的，我自己在處理中，也發現了罐頭回復的重要性。我將會加入這個功能。Bluedeck 2024年8月2日 (五) 20:35 (UTC)

繁體支援

這個網站估計主要的受眾是大陸梯子人士。但是，由於很多管理員是繁體使用者，那麼我就增加了一系列的繁體支援，但是都是Google翻譯的。請繁體管理員看看管理介面的翻譯如果有很不和諧的地方，請指出來。如有需要，網站可以支援香港、台灣和澳門繁體的分別翻譯。Bluedeck 2024年5月30日 (四) 08:15 (UTC)

感謝藍桌照顧繁體使用者，但我目前檢視似乎有一些介面仍然是簡體中文的，例如新建工單的部分，另查臺灣的教育部字典，work order這個詞在臺灣可以翻譯為「工令」、「工作命令」、「工作通知單」或「工作單」等，就是沒有查到稱之為「工單」之翻譯，惟我日常生活中前開所有詞彙均較為少見，平常類似功能之提交申請平臺反而被稱之為「電子表單」，這部分可能需要更多繁體使用者來指出正確的翻譯。--小過兒（留言） 2024年5月30日 (四) 15:30 (UTC)

新建工單的繁體化已經完成。關於工單這個用語的翻譯，我參考了一下asus的網站，叫做「請求支援」、「搜尋案件」。不知道這算不算合適的翻譯。如果覺得「案件」聽其來正確，那麼我就把繁體語言的工單改稱案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)

「工單」是對應「ticket」而不是「work order」，比如Zendesk香港也是叫ticket作「工單」[1]。再甚者，直接「搜尋申請」也是得了，不需要特地什麼ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)

@Bluedeck：怎麼查閱或變更翻譯？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年7月1日 (一) 19:44 (UTC)

通過改變瀏覽器的語言設定並刷新頁面，可以檢視不同的語言版本。目前要修改，可以直接留言告訴我哪裡需要改。以後，會開放一個repo在github上可以pr。不熟悉sveltekit和github的使用者仍然可以直接聯繫我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)

理論上可以開twn（translatewiki.net） project啦，不過要擔心被亂改的問題。--SunAfterRain 2024年7月22日 (一) 07:02 (UTC)

工單的永久刪除

目前沒有這個功能。不過，根據歐盟GDPR要求，在使用者請求的情況下，應該提供一種方法永久移除其個人資訊。我想讓管理員能夠在工單上添加一個標記，被標記的工單約一個月後真正的刪除。刪除真正執行前可取消。這種刪除只應該在特別的情況下進行（也就是使用者請求）。（也可以單獨只允許行政員執行真正刪除，但是我覺得管理員已經足夠可信，並且還有一個緩衝期間。）Bluedeck 2024年5月31日 (五) 23:04 (UTC)

這個功能不錯。( π )題外話：我想知道維基百科不能刪除帳號是否符合GDPR，以及即使OS似乎也不是真刪除，這是否符合GDPR。有人去檢舉一下是不是基金會就會實現這個功能了。--桐生ここ★[討論] 2024年5月31日 (五) 23:25 (UTC)

應該是不符合的，而且顯示未登入使用者ip這個似乎也有一定問題。然而我們要團結一致，不要把基金會檢舉給歐盟。Bluedeck 2024年6月1日 (六) 05:34 (UTC)

讓 IPBEG 在 Unblock-zh 上獲得和管理員一樣的權限

因為我覺得 IPBE 也是一大痛點，所以我覺得讓 IPBEG 能夠一起幫助處理會大有裨益。現在拋出幾個方案討論：

1. 讓IPBEG組和管理員同在unblock-zh.org/zhwp下有一樣的（或者接近的）權限。
2. 像郵件列表一樣，單獨新建 unblock-zh.org/zhwp-ipbe空間。
   1. 網站面向使用者的介面不改變，根據使用者是否需要 IPBE，自動將工單分發至 zhwp 或 zhwp-ipbe
   2. 網站設計改變，入口頁面一分為二，使用者需要自己選擇是投遞給zhwp還是zhwp-ipbe
3. 不支持 IPBEG。

我覺得，從使用者體驗的角度，不希望入口一分為二。另外，不管選擇 1 還是 2，都需要一段時間來修改網站的代碼，但是 2 所花時間會更久一點，並且會增加日後維護的工作量（主要是會出現兩套表單同步的問題）。關於使用者隱私，由於 IPBEG 是簽署 NDA 的，應該視為可信人員，所以我比較傾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)

設立IPBEG的本意就是授權IPBEG處理該類申請郵件，理論上可以說已有社群共識支持選項2，但已有共識未必支持選項1。IPBEG不能處理unblock-zh上非申請IPBE的工單。我是認為，一般而言封鎖申訴本應都是在公開場合發起，申訴內容多數都應該可被所有使用者檢視，實質需要使用郵件申訴封鎖的僅有無法編輯討論頁的情況。如你所言，IPBEG本有簽署NDA，就算看了也不應該會造成什麼問題（雖然能避免最好）。如果是最後採用最簡化的選項1，那我覺得您可以最低限度在處理人員的介面中加入標籤工單的功能，讓IPBEG能明確標記跟他們職務無關的申請，從IPBE隊列隱藏，僅能由添加標記的IPBEG（直至工單標籤被管理員確認）及管理員檢視。--路西法人 2024年6月2日 (日) 11:58 (UTC)

如果要讓IPBEG不能看到非IPBE工單，那應該執行方式2更優。如果執行方式2，那麼管理員、行政員也應該自動獲得zhwp-ipbe空間權限，並進行工單自動分發。Bluedeck 2024年6月3日 (一) 08:34 (UTC)

不是「不能看到」，而是「不再跟IPBE有關的就沒必要繼續顯示在同一隊列，令其他正在處理IPBE申請的使用者不小心點進去」。「看到」大概是不會有什麼大問題的。--路西法人 2024年6月5日 (三) 02:22 (UTC)

分成兩列或許方案2實現起來更簡單？--桐生ここ★[討論] 2024年6月5日 (三) 09:51 (UTC)

不是不行，但必須考量沒簽署NDA的管理人員是否有權限接觸unblock-zh內的工單，一般視乎工單是否涉及IP位址等可辨識資訊。如果要再這樣分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)

還是那句話，我無法理解WMF要求郵件列表內的IP必須有簽署NDA才能接觸，但允許使用unblock模板直接把IP公開。--桐生ここ★[討論] 2024年6月6日 (四) 09:48 (UTC)

我一開始聽說IPBEG需要NDA，但管理員不需要NDA的時候，我也覺得很費解。而且你知道嗎，你用的任何JS組件要是對外部資源進行請求，那麼就可能有意無意洩露IP。甚至你收到一封郵件，郵件裡帶個圖，這圖也能洩露IP。雖然說IP在wiki上被當作隱私，其實整個網際網路對IP的保護可以用奇差來形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)

似乎是只有涉及IP等隱私資訊時，纔要求管理員簽署相關協議。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月23日 (日) 02:13 (UTC)

@Bluedeck：只要不僭越社群賦予之權限，應儘可能以您自身方便為宜。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月6日 (四) 00:11 (UTC)

提供的IP問題

現在有個問題

• 如果申請者沒有使用代理時使用此網站提交工單，被此網站自動帶入的IP是其真實IP，而非使用代理且受到IP封鎖的IP，對於IPBEG應該使用真實IP還是受到封鎖的IP判斷？如果有人使用代理訪問此網站，有人不使用代理訪問此網站，也會產生差異。
• 是否像傳統郵件列表一樣另外要求使用者手動填入封鎖介面上顯示的受封鎖的IP或封鎖ID？這樣也有好處，就是IPBEG可以看到申請者被封鎖IP同時也能看到真實IP，確定申請者處於中國大陸等受限地區。但產生另外一個風險，就是如果確實提供的是中國大陸IP位址，一旦洩露可能產生嚴重後果。--桐生ここ★[討論] 2024年6月6日 (四) 10:00 (UTC)
  • 技術上有很多方法可以儘量避免記錄IP，比如只記錄部分IP、以及對管理員不顯示IP，只顯示IP是否處於封鎖列表中。但是這些方法無一例外的會對管理員處理造成問題。我想到的各種方法中，只有一個值得實踐的，是在工單解決之後將IP相關資訊從工單中清除，避免永久留存。除此之外，就只有請管理員和IPBEG不要洩露IP位址。對於代理的問題，我可以加一個提示讓使用者記得開代理，再者就是乾脆取消自動偵測IP這個功能，讓使用者自己填寫IP和查封ID，和郵件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)

    我有一個方案

    • 申請者不提供IP：不提交IP
    • 申請者選擇提供IP：檢測IP是否中國大陸或其他受限地區
      • 是：不提交IP位址，只自動提交申請者IP地區，並且要求申請者手動填寫受封鎖IP
      • 否：自動帶入IP位址

    --桐生ここ★[討論] 2024年6月7日 (五) 09:10 (UTC)

    補充：IP地區是提交由服務端判斷，而不是在前端處理，所以實際上仍然會提交中國大陸IP，只是不會儲存在伺服器上。--桐生ここ★[討論] 2024年6月7日 (五) 09:13 (UTC)

    檢測IP是否中國大陸或其他受限地區 這個感覺不是長久之計，GFW未來可能會給Unblock-zh上SNI封鎖，使用者會不得不套代理訪問，這樣Unblock-zh獲取到的就不是真實IP--Yuki Rutygr (留言) 2024年7月9日 (二) 13:15 (UTC)

    • 我想過geoip定位這個方案，但是ip定位資料庫需要每個月更新，而且並不完全準確。連維基媒體基金會都放棄了自己的geoip API（否則我就可以利用了）。有一個折衷辦法，那就是查詢封鎖資料庫。如果使用者目前的IP不再封鎖列表中，大概率說明沒有開代理，此時我彈窗提示開代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)

(－)反對，考慮到Unblock-zh未來極有可能受到GFW封鎖。--mije meli carrot_233 -- 討論 2024年7月25日 (四) 11:33 (UTC)

網信辦說的？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年7月25日 (四) 15:07 (UTC)

這種網站大概率被牆。--mije meli carrot_233 -- 討論 2024年7月30日 (二) 07:42 (UTC)

這反對理由太怪了，你維本來就被GFW刀了，有差嗎？--SunAfterRain 2024年7月27日 (六) 04:23 (UTC)

問題在於，如果Unblock-zh被GFW封鎖，則中國大陸無法直連Unblock-zh，故無法獲取真實IP。--mije meli carrot_233 -- 討論 2024年7月30日 (二) 07:41 (UTC)

我們本來就不是為了獲取使用者的國內IP，因為目前郵件列表也只是看到你的查封ID和IP位址就對你進行授權，這被查封的IP位址往往都是VPN、代理地址。如果被牆後，還能解決代理不是全局的問題。因為沒有被牆，有的代理會把沒被牆的網站不走代理，導致我們接收到使用者的沒有被查封的IP位址，反而不是我們想要的。Bluedeck 2024年7月30日 (二) 16:50 (UTC)

罐頭回復

經由路西法人的建議，增加了『罐頭回復』功能。將常用的語句加入罐頭回複列表，就能快速的一鍵回復工單。詳見WP:Unblock-zh.org#罐頭回復功能 Bluedeck 2024年8月12日 (一) 21:51 (UTC)

`ChooseNewName`標籤

這是一個比較新的功能，當請求使用者選擇新的使用者名稱時，加入`ChooseNewName`標籤，同時摘掉`回復關閉`標籤的情況下，工單使用者介面會多出一個小工具，便於使用者確認自己所選擇的使用者名稱是否可以註冊。Bluedeck 2024年8月20日 (二) 08:16 (UTC)

長期維護展望

本站不乏一工具或機制，於原維護者隱遁後即生極大之運行困難。若來日Bluedeck不再活躍，此工具是否有辦法由他人接手維護？有必要提前考慮。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月29日 (四) 10:14 (UTC)

請求社群判斷已經數據過期的使用者是否為傀儡

見相關SPI提報，現時最少有法國飲食文化、如懿傳、冊封體制受到影響（很可能還不止這些），請調查助理、管理員和其TA使用者判斷和徹底清查，謝謝！--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:12 (UTC)

• 外加一些帳號（包括SPA），請檢查是否為冏；

以上。--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:24 (UTC)

這難道不應該直接在傀儡調查頁面處理？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年7月20日 (六) 17:39 (UTC)

這些Stale了的帳號，即使有可疑，放上SPI也查不了，所以只能放此。--MCC214（Sign | Contributions） 2024年7月21日 (日) 05:32 (UTC)

(？)疑問-若數據過期，還能SPI嗎？是否主要以人工來判斷？Wetrace歡迎參與WP人權專題 2024年8月23日 (五) 01:31 (UTC)

不能，遞上去監管員都是說 數據過期的（基於隱私政策，使用者數據會/已在帳號最後一次動作的90天後被自動刪除），所以當然只能靠人工的了（除非帳號又活動了）。--MCC214（Sign | Contributions） 2024年8月25日 (日) 04:27 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

仲裁委員會的選舉

今天看到Wikipedia talk:仲裁委員會#公示RFC結果及仲裁方針草案下早有公示過的仲裁委員會試行方案。在其之後仍有討論關於是否有解任管理員的權力問題，但目前本人認為細節基本商榷的差不多了。目前唯一一個剩下的需要形成共識的事情就是在試行期間仲裁委員會需要多少支持率才能上任。定下這個可以直接開始籌備選舉了。那麼這下面先討論支持率的問題吧？--0xDeadbeef (留言) 2024年8月2日 (五) 04:38 (UTC)

我個人認為支持率只需要50%就夠了。首先考慮到仲裁委員會是一個需要社群高度信任的職務，在考量一人是否符合成為仲裁委員會的標準明顯要比管理員的標準要高，於是反對的比率肯定會比管理員更高。本人希望中維能夠選舉出來第一屆委員會，於是希望50%，這樣既獲取majority的支持（超過一半的人支持）也能給仲裁委員會給一個好的起點。（註：英維是採取60%以上可以任職委員會兩年的機制，但因為這次試行所有人都是一年，故偏向50%。--0xDeadbeef (留言) 2024年8月2日 (五) 04:44 (UTC)

抄錄前一階段討論情況：

• 基本同意授予仲裁委員會委員「已刪除內容」、「非公開過濾器」、「IP資訊」、「啟用雙因素驗證」等權限，
  • 尚未有明確共識決定是否授予「查閱全站未受監視頁面」、「建立短連結」、「檢視當前轉碼活動的資訊」、「檢視標題黑名單日誌」等權限；
• 尚未有明確共識決定是否限制仲裁委員會委員在委員會既有職能外行使職權；
• 基本同意仲裁委員會委員（至少第一任期）選舉採相對多數（百分之五十）當選制；
  • 尚未有明確共識決定是否按支持率多寡區分當選任期（如百分之五十以上為一年、百分之六十以上為兩年）；
• 基本同意仲裁委員會處理管理人員解任案件，係經調查確認存在操守違規事實後，方轉交社群決議是否除權；
  • 尚未有明確共識決定如何區別或取捨仲裁委員會與社群既有解任管道；
• 基本同意仲裁委員會有權拒絕受理案件。

似乎第一屆確實不需要區分任期。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月2日 (五) 05:45 (UTC)

哎，當時的討論有點久遠，所以應該是不需要討論支持率了？那我覺得可以直接開始籌備選舉事宜。RFC先刪掉，之後寫點時間相關的內容。0xDeadbeef (留言) 2024年8月2日 (五) 06:19 (UTC)

但似乎還有若干職權問題必須商榷？要擱置也不是不行（仲裁委員會現有職權不少，也夠行使一整屆了吧？），但似乎想要快速推動仲委會設定提案者，目標都是希望該會介入（調查）管理人員解任，那就又不適合擱置？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月2日 (五) 13:23 (UTC)

我選擇先擱置管理人員解任問題是因為要是先選出來一批人，這一批人可以幫忙推動共識，也就是說在委員會成立之後再對於管理人員解任的事情幫忙推動共識。既然他們都選上了，他們來推動討論、邀請社群成員來發表意見來形成共識個人覺得更合適--0xDeadbeef (留言) 2024年8月2日 (五) 14:12 (UTC)

(！)意見：對於「尚未有明確共識決定如何區別或取捨仲裁委員會與社群既有解任管道」：

1.若使用者未申請仲裁，自然可直接發起罷免解任。

2.若使用者申請仲裁，委員會決議不解任管理員，則社群在一段限制時間內不得以同一事由發起罷免（該段時間可議，比如半年、兩年等）；當該段限制時間過後，社群若以同一事由再次發起罷免，須出具自前次仲裁後出現的新事證（也就是新糾紛事件的時間點或所出具的證明實際發生在前一次仲裁後）。

3.若使用者申請仲裁，社群或相關使用者對委員會的決議不滿，可將委員會的決議，在具備可明確、合理、一般人所具智識即可辨識之理據或事證的前提下，向基金會投訴（也就是仲裁極其離譜，而如何為「極其離譜」，或可討論）。

4.若使用者申請仲裁，社群或相關使用者對委員會的決議不滿，可將委員會的決議發起公投，獲特定支持比率的情況下推翻。公投結果須具備數個條件方可具效力，如：不滿意仲裁結果的當事相關使用者須參與聯署（明言自願放棄表態或投票者除外）；總有效票須佔當時社群具投票資格使用者總數的相當比例（比如至少四分之一）；公投結果出爐起一段限制時間內（該段時間可議，比如半年、兩年等），不得就同一事項再發起公投；有效同意票超過不同意票。諸如此類。

5.若委員會決議遭推翻，社群自可再以同一事由發起罷免。惟為避免仲裁程序遭濫用或社群無謂虛耗空轉，社群在委員會決議正常生效、使用者不得以同一事由發起罷免原限制時段的二分之一期間內不得以同一事由發起罷免（該段時間可議，參見第2點，比如原本是半年或兩年不能再發起罷免，這種情況下須在三個月或一年後才可再發起罷免，但不須額外出具同一罷免事由的新事證）。

6.委員會決議遭推翻後，其仲裁結果之效力即自公投結果確認起解除；委員會決議遭推翻前，其仲裁結果之效力視為有效。

個人路過隨想意見，供參。--Kriz Ju（留言） 2024年8月2日 (五) 21:37 (UTC)

鑑於目前的鬧劇，我不認為社群會信任仲裁委員會。--桐生ここ★[討論] 2024年8月3日 (六) 05:57 (UTC)

同上，強烈反對以此次RFDA為由立即推動仲裁委員會上馬，社群有權就必須商榷的若干職權問題進行更加深入的討論。--🎋竹生🎍 2024年8月3日 (六) 11:50 (UTC)

首先，我並沒有「以此次rfda為由」，而只是有人提到「若已有仲裁委員會，則可能此事處理能夠更加妥當」的想法而選擇推動。選擇推動委員會選舉，並不是代表不討論職權問題，但是，早已為仲裁委員會的職權形成共識（其並不包含對於管理人員除權相關的事宜），則說明社群已有仲裁委員會上任的基礎共識，所以我個人覺得你反對的理由無法站住腳的，歡迎你提出另外的理由。--0xDeadbeef (留言) 2024年8月3日 (六) 12:42 (UTC)

你可以解釋一下這兩者（目前的鬧劇、社群對於仲裁委員會的信任）之間的關係。順便，若是你自己表達不信任無妨，但請不要代替社群說話。--0xDeadbeef (留言) 2024年8月3日 (六) 12:34 (UTC)

一個RFDA案就已經出現某人或某些人（無法確定是不是WMLO）發送拉票（或偽裝成拉票）的郵件，意圖使RFDA通過或不通過。如果為解決RFDA而急於成立的仲裁委員會，難以想像是否會有更多對仲裁委員候選人的拉票（或偽裝成拉票）的郵件試圖讓人當選或不當選。--桐生ここ★[討論] 2024年8月3日 (六) 14:07 (UTC)

是的，所以我覺得先完善仲裁委員會的選舉流程以杜絕不公平情況，然後再在這群人獲得社群各方信任的情況下推動共識，是比較好的做法。至於急不急的問題，看社群可以擱置多久。我覺得久一點並無太大問題，畢竟一套完善的流程建立起來之後很多問題都會迎刃而解。--碟之舞📀💿 2024年8月3日 (六) 14:17 (UTC)

不要稻草人，我在這裡討論籌辦選舉又不是為了解決RFDA而急於成立的。--0xDeadbeef (留言) 2024年8月3日 (六) 14:19 (UTC)

不過這裡要澄清一下就是我確實有在主群說過「在選出仲裁委員會再來調查」這一說法，實際上在我後來想過之後不現實，因為成立仲裁委員會之後估計RFDA案沒有什麼可調查的了。因此此次提出完全就是為了流程上繼續推進而已。--0xDeadbeef (留言) 2024年8月3日 (六) 14:21 (UTC)

同樣支持50%。至於相關權限等問題，個人認為仍須回歸社群如何看待此權限及信任程度，如果目前的確認程度已經不需釐清所有細節，個人現無意見。--Kriz Ju（留言） 2024年8月5日 (一) 13:38 (UTC)

---

七日已過，總結一下上方的討論。目前參與討論的使用者基本同意（至少在第一屆）選舉中採取相對多數當選原則，並就選舉結束後繼續推動仲裁委員會相關共識上基本達成共識。就此，我提議在今年9月份展開管理員選舉的同時舉行第一屆仲裁委員會選舉，七日內若無人反對或反對意見已解決的話就進行公示。--人間百態,獨尊變態(討論) 2024年8月12日 (一) 11:36 (UTC)

在確定仲裁委員會權限及仲裁程序以前，選舉仲裁委員會委員沒有意義。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月12日 (一) 14:49 (UTC)

贊同。我們應該等到委員之權限得到確定之後再選舉。--CuSO₄ · 龍年大吉 2024年8月12日 (一) 18:25 (UTC)

@Ericliu1912: Happy to talk about this off-wiki if you want. 首先在Wikipedia talk:仲裁委員會#公示RFC結果及仲裁方針草案下WP:仲裁/方針已經通過公示，於是以下為已確定（有共識，被社群接受的方針）的仲裁委員會的職權：

中文維基百科社群委託委員會處理以下事務：

1. 在無法通過社群討論及管理程序等常規流程解決的嚴重使用者衝突中擔任最高爭議解決機關，作出具約束力的裁決；
2. 處理管理人員解任請求（自請者除外）及
3. 處理仲裁裁決有關之封鎖及禁制申訴。

至於仲裁程序也在方針下「流程」的section已經定下，不知道有什麼還需要確定的。而基本權限部分也在Wikipedia talk:仲裁委員會#RfC：2024年2月定好。

目前唯一存在爭議的是仲裁委員是否可以經決定直接解任管理員，而這一小細節不應阻止我們選出委員會吧？--0xDeadbeef (留言) 2024年8月13日 (二) 02:51 (UTC)

不，管理員仲裁解任權（暫且這麼叫它吧）關乎「處理管理人員解任請求」的實施形式，是先前討論的焦點之一。在下相信社群對於「誰適合當選沒有管理員仲裁解任權的仲裁委員」和「誰適合當選有管理員仲裁解任權的仲裁委員」這兩個問題的看法是有差異的。管理員仲裁解任權問題未解決就舉行選舉，無異於認為這種差異可以忽略。竊以為，這種差異值得得到關注，如果在解決管理員仲裁解任權問題前就選舉，就操之過急了。--CuSO₄ · 龍年大吉 2024年8月13日 (二) 07:13 (UTC)

@CopperSulfate：我並不覺得屬於操之過急，因為我覺得這是一個循環依賴 (en:circular dependency)。比如說，在討論委員會是否應當有仲裁解任權的時候，便有人以「社群不一定信任委員會而支持其有這樣的權力」來反駁我個人認為應當擁有此權力的觀點。但是呢，如果人已經選出來了，那麼討論委員會到底是否應當有這種權力則可以在以選出的人作為context。比如說如果我個人信任被選出來的人，我個人就會對於委員會有這種權力更放心。如果我個人不信任被選出來的人，我可能就不會希望委員會有這樣的權力。

另外，根據之前的匿名問卷，貌似已有大概共識在「仲裁委員不應有仲裁解任權，而是調查查證報告給社群」這一觀點，所以以「委員會在前期很有可能不會有直接解任管理員的權限」來選舉是合理的。

你覺得這樣的解釋是否合理？--0xDeadbeef (留言) 2024年8月13日 (二) 07:42 (UTC)

可以準備公示了。--0xDeadbeef (留言) 2024年8月19日 (一) 02:15 (UTC)

公示7日，2024年8月26日 (一) 11:54 (UTC)結束--0xDeadbeef (留言) 2024年8月19日 (一) 11:54 (UTC)

想問下不考慮技術原因，你們覺得選舉應該跟管理人員申請錯開還是一起辦？兩者性質畢竟不同，我當初提個「管理人員當然席位」還一直被打槍。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月19日 (一) 14:11 (UTC)

另外連個具體流程都沒有出臺就公示，未免操之過急。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月19日 (一) 20:59 (UTC)

個人認為試運行為方便放在一起。仲裁系統成熟後應錯開。--0xDeadbeef (留言) 2024年8月20日 (二) 03:07 (UTC)

@0xDeadbeef(！)意見：鑑於社群在仲裁解任問題上已有模糊的共識雛形，如果不給予新當選的仲裁委員「管理員仲裁解任權」的話，我不反對儘早開始選舉。--CuSO₄ · 龍年大吉 2024年8月19日 (一) 20:04 (UTC)

(？)異議：應先就選舉具體流程達成共識。另(？)疑問在「不需要考慮當選人有無權限決定管理員罷免」的情況下選出仲裁委員後，要進一步讓社群「信任他們能夠有權決定管理員罷免」豈不是更難？應先確定和細化「仲裁委員不應有仲裁解任權，而是調查查證報告給社群」的初步共識，這樣豈不更快。--🎋竹生🎍 2024年8月20日 (二) 02:48 (UTC)

@Ericliu1912 @Newbamboo，那就與管理員選舉相似，一周預討論（與管理員選舉同時進行），一周提名期（可自己提名也可由他人提名，每個候選人應提供自我介紹），兩周意見期（可提問、討論），兩周投票期如何？--0xDeadbeef (留言) 2024年8月20日 (二) 12:55 (UTC)

公示通過。社群將會根據討論得出的仲裁委員會職權和流程在今年9月舉行第一屆仲裁委員會成員選舉。--人間百態,獨尊變態(討論) 2024年8月26日 (一) 13:15 (UTC)

---

社群目前業已達成舉行選舉的共識，然在部分流程的細節仍未敲定。就此鄙人展開對選舉相關工作的討論。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

仲裁委員會使用者群組

在先前的討論中已經敲定了仲裁委員會成員具有的權限，但對是否設立該使用者群組尚無定論。就此對是否設立仲裁委員會使用者群組展開討論，若無異議或異議已解決，將會建立設立仲裁委員會使用者群組的工單。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

支持設立特定使用者群組，有利於識別委員會成員。不過(？)疑問使用者群組名將會是什麼，「仲裁委員會委員」？——即請秋安 ZhaoFJx_(論•簽) 2024年8月29日 (四) 09:56 (UTC)

使用者群組名為仲裁員，不過仲裁委員會委員也可以。--人間百態,獨尊變態(討論) 2024年8月29日 (四) 10:09 (UTC)

支持成立「仲裁委員會委員」使用者群組，建議在Wikipedia:在編輯記錄中標示使用者權限中顯示為粉紅色的「委」。--維基病夫_{❤️邊緣人小組·簽到·FLC} 2024年8月29日 (四) 10:04 (UTC)

深紫色的「裁」可能較好。「委」一眼看不出來是什麼意思。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月29日 (四) 10:08 (UTC)

同意，Eric的方案比本人更好。個人也支持將使用者群組名稱簡化為「仲裁員」。--維基病夫_{❤️邊緣人小組·簽到·FLC} 2024年8月29日 (四) 10:17 (UTC)

他站已有「仲裁委員會委員」使用者群組，本站可以引進，並自訂權限。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月29日 (四) 10:08 (UTC)

仲裁委員會成員的人數和條件

在先前的討論中已經確立了仲裁委員會成員的人數和條件，但不清楚目前社群對此共識是否有異議。如果沒有異議或異議已解決，將會根據此共識進行選舉工作。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

仲裁委員會選舉的討論場所

目前對仲裁委員會選舉的討論場所尚無定論。鄙人認為可以跟管理人員申請的預討論一樣在Wikipedia:互助客棧/其他討論，但不清是與管理人員申請在同一章節討論更好，還是另開一章節討論更好。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

實際還是預討論，而且開啟的時候肯定挨在一起。個人覺得應該拆分成兩個章節，但是也可以共用一個討論串。--0xDeadbeef (留言) 2024年8月29日 (四) 00:43 (UTC)

我也認為拆成兩個章節可能更好。--人間百態,獨尊變態(討論) 2024年8月29日 (四) 00:48 (UTC)

兩者全然不同，僅是時間巧合，仍宜分為兩話題討論。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月29日 (四) 10:10 (UTC)

參與仲裁委員會選舉使用者的個人選舉頁面

目前參與仲裁委員會選舉使用者的個人選舉頁面尚無定論。鄙人認為可以參考其他的管理人員申請設立一個WP:申請成為仲裁員並將所有參與仲裁委員會選舉使用者的個人選舉頁面置於其子頁面。如果沒有異議或異議已解決，將會根據此方案進行選舉工作。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

關於仲裁委員會選舉是否公布有資格投票人數及名單

目前公布管理人員任免案投票人數及名單的提案正在公示。如果公示通過且沒有異議或異議已解決，將會讓未參與選舉的行政員在安全投票開始前15日內公布具人事任免投票資格的使用者人數及使用者名單。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

仲裁委員會選舉的監票工作

目前方針規定由監督員兼任選舉的監票員，但參與選舉的監督員是否能成為監票員尚未有定論。鄙人認為參與選舉的監督員應秉持避嫌原則不應擔任選舉的監票員。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

仲裁委員會的RFC

目前對於仲裁委員會的職權尚存在一些爭議。鄙人認為在這次選舉後應展開一次關於仲裁委員會的RFC，並在RFC上釐清仲裁委員會的職權以及完善仲裁委員會的相關頁面。如果沒有異議或異議已解決，將會在選舉結束後舉行一場關於仲裁委員會的RFC。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

其他意見

此章節供社群發表雜項意見，若有重要問題提出者，歡迎於上方新置章節。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 04:58 (UTC)

不如連檢討管理人員任免制度一起寄送討論通告。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月29日 (四) 07:59 (UTC)

寫了份模板，沒什麼問題的話三日後走公示程序。--人間百態,獨尊變態(討論) 2024年8月29日 (四) 08:39 (UTC)

我晚點結合管理人員任免制度檢討事寫一份更簡潔的通告吧。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月29日 (四) 10:12 (UTC)

• 現行經手行政員的選舉相關決定，包括不限於延長及宣告無效等決定，是否將由仲裁委員會接手？-某人✉ 2024年8月29日 (四) 10:36 (UTC)

  個人覺得這種事務還是與委員會的事務有區別，所以不一定可以交給委員會。行政員一般是「總結討論共識」的，而委員會則更多是「基於方針、指引、與已有社群共識解決使用者行為問題」。--0xDeadbeef (留言) 2024年8月29日 (四) 10:44 (UTC)

  仲裁委員會起因好像就是因為上兩次任免選舉社群對於行政員的決定有異議吧--某人✉ 2024年8月29日 (四) 13:22 (UTC)

引進CampaignEvents擴充功能

路過看到這一擴充功能，因本站時常舉行編輯松，似乎可以引進來測試一下看看效果，不知諸位覺得如何？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月16日 (五) 02:05 (UTC)

(＋)支持：順便把擴充功能主頁翻譯到中文了 ——即請秋安 ZhaoFJx_{（論•編）} 2024年8月16日 (五) 09:37 (UTC)

個人不反對此等引入。不過，現階段如何運用該功能？就個人理解，本站編輯松的註冊大多利用維基上的頁面（如動員令）或 fountain（如亞洲月），似乎它略簡單的註冊功能（缺乏計分功能）未必適用本站？而它的邀請功能雖明顯有利編輯松的參與度，但現在仍測試中。謝謝。--SCP-0000（留言） 2024年8月18日 (日) 13:12 (UTC)

@SCP-2000：所以正應該引進來試試操作，反正不適合就擱著不用，也無大礙。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月19日 (一) 14:02 (UTC)

---

公示7日，2024年9月2日 (一) 13:20 (UTC)結束：討論使用者就引進CampaignEvents擴充功能一事基本達成共識，進入公示期。--人間百態,獨尊變態(討論) 2024年8月26日 (一) 13:20 (UTC)

問題不當本人想問一下，只有2人也算「達成共識」嗎？雖然7日之內無人加入，但是2人是不是太少了？（我還是新手，不太懂）--WiiUf ——青龍出世，傲視蒼穹 的第1000次編輯！ 2024年8月29日 (四) 04:46 (UTC)

再議設立編者著作權調查

之前的討論見此。

在上次的討論中，討論使用者就設立編者著作權調查一事基本達成一致。根據此共識，鄙人在此提出編者著作權調查的草案。若草案有不足之處還請指出。--人間百態,獨尊變態(討論) 2024年8月17日 (六) 13:00 (UTC)

字句及流程問題：

1. 「多次撰寫」，很多侵權文字不算撰寫。「多次」的斷句有風險。建議「多次上傳侵犯著作權的內容（文字或圖片）的使用者」。
2. 「長期且大量的侵權行為」的長期是否能去掉呢。
3. 「五處及以上侵權行為」改成「至少五例侵權行為」。
4. 「（包括修訂版本和圖片）」的含義模糊，次數計算方式需要摸索和設定常識（如過往已結案案例與承諾；同一條目的多次或連續編輯）。
5. 「已被封鎖則不必通知」的含義，對於近期封鎖、申訴中仍可能需要？儘可能通知仍允許？
6. 「此前未參與該調查申請」的含義，支持提報或提供證據算參與嗎，與「提報人以外」的差別是？
7. 未見拒絕的時間點，拒絕後如何抗議。
8. 建立子頁面及填入數據的流程指南。
9. 「使用者如果批准了一個調查申請，那麼就需」->「批准調查申請的使用者需要」。
10. 已刪除內容的審閱，可能需要藉助站外工具或管理員，而非以?結案？

總體而言支持試行，具體流程慢慢來定，以討論和共識為基準。--YFdyh000（留言） 2024年8月17日 (六) 13:31 (UTC)

已微調第一條的建議。--YFdyh000（留言） 2024年8月17日 (六) 14:37 (UTC)

「沒有證據的調查申請可能會被認定為是擾亂行為」這句中的「擾亂行為」可以考慮連結到Wikipedia:遊戲維基規則。
還有如何判定調查申請的理由是否充足，有沒有相關標準？
另外還有User:YFdyh000提到的兩點：被拒絕申請後如何上訴；建立子頁面及填入數據的流程指南何在。--Benho7599 | Talk 2024年8月17日 (六) 13:57 (UTC)

@Hoben7599、YFdyh000：在這裡統一回復下兩人的問題

YFdyh000：

1. 已修改
2. 已去除
3. 已修改
4. 上次討論中對於如何算一次侵權行為，基本認為如果使用者在一個修訂中有上傳侵權內容行為就算一次侵權。不過含義模糊這點也確實存在，所以這處我已經改成了對侵權行為本身的舉例描述。
5. 已修改
6. 已修改為提報人以外
7. 已添加相關內容
8. 已添加相關內容
9. 已修改
10. 已添加相關語句，但?確有存在的必要。例如擱置以等待管理員查閱，或表示該內容不值得審閱。

Hoben7599：

關於如何判定調查申請的理由是否充足，我已經在草案中給出了標準--看調查申請給出的證據是否能夠證明該使用者是否存在至少五處侵權行為。至於如何判斷為侵權行為，這就不是這個草案該解決的問題了。

--人間百態,獨尊變態(討論) 2024年8月18日 (日) 06:12 (UTC)

中文現階段可能不需要個別案件子頁面（我預計此種專門調查不會如傀儡調查頻繁），全部放在同一請求主頁面即可。這樣也可以加快立案流程，減少技術負擔。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 10:44 (UTC)

設立案件子頁面恰恰是為了分擔主頁面內容。如果將貢獻數據全堆在主頁面的話反而會顯得主頁面有些臃腫，所以在設計時我才沿襲了英維的分頁面處理方案。--人間百態,獨尊變態(討論) 2024年8月18日 (日) 12:29 (UTC)

支持，上次討論就是我發起的（--0xDeadbeef (留言) 2024年8月20日 (二) 12:56 (UTC)

---

距離最後發言已過三日，就該草案 公示7日，2024年8月31日 (六) 06:29 (UTC)結束--人間百態,獨尊變態(討論) 2024年8月24日 (六) 06:29 (UTC)

為管理人員任免制度檢討等事

近期又一管理人員解任投票，甫應用安全投票之新制，技術實務運作尚難稱熟稔；又逢顯著外來干涉及共識形成程序疑慮，遂致前所未有之困窘，亂象叢生、弊端頻出，社群矛盾對峙趨於激烈，此實無庸置疑。與此同時，定期審視更新管理人員任免制度，有助於人才新陳代謝，充實本站進階維護量能。時值仲裁委員會組織籌備停滯之際，「遠水難救近火」，故謹以此話題為首，先行就管理人員任免制度若干既存問題略作檢討，望社群踴躍發表意見。改革路程自不必操之過急，但求氣象有所更新爾。本人謹提出三個大問題，社群可撥冗予以回應，或自行提出其他值得專門討論之問題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)

安全投票問題

目前，本站之管理人員任免案，均採行安全投票制度。安全投票之匿名，優缺點一體兩面，優點在於得脫離現實外力束縛，保障自由表達意見，有助於完整呈現社群意志；缺點則在於幾無制衡極端之手段，如此次投票之若干附言，或因涉及與當事人之私人恩怨，極盡猥瑣下流之能事，對部分群體及特定個人之攻訐、人身攻擊及無理羞辱等暴言（本人不擬重述各種不堪入耳之文字於此，請自行閱讀相關內容），不僅早已背離解任投票本身形成有效共識之意旨，更遠遠超出社群應容忍之文明底限，而顯難以「可受公評」為藉口。此外，安全投票雖號稱得以防堵大規模公然拉票之威脅，惟迄今其效果不僅有待商榷，而社群因該制度高度封閉之特性，反而難以協助查核投票細節；如此次投票雖有嚴重擾亂之指控，但僅有少數電子郵件等書面證據，社群無法對比既有編輯貢獻，或額外確認許多可疑相關內容。又安全投票長期未能由本地社群完整掌握，須受制於全域社群等客觀限制；投票設定程序繁瑣冗長，更屢生不可抗力之技術問題，若與其他因素疊加，結果甚至可能損及管理人員任免案本身之公信力。安全投票本為預防若干外部勢力之現實威脅而設，此種威脅既已有消退跡象（與本站志趣不合之同志，多已分道揚鑣不復歸），加之以前述安全投票之弊端，雖難謂前述惡意影響蕩然無存（此處須特別強調仍不應低估危險），惟兩相權衡下，認為有酌加商榷該制度應用之必要，至少亦應有些許合理討論。謹嘗試提出問題如下：

一、社群過往執行安全投票，就可自行控制之部分（不包含須迎合全域動態之技術安排等），有何應從速改善之處（如事前人事選定等籌備作業、事後點票及公告程序等）？

二、社群應是否繼續於管理人員申請及管理員解任投票採行安全投票？或研議若干指標，持續評估是否沿用，乃至於採取行動，制裁投票過程可能出現違反方針與指引之舉？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)

就管理員解任而言，我個人覺得非常有必要返回公開討論的機制。

1、安全投票所帶來的「隱私」實際弊大於利，共識應當是一個持有不同意見的人互相嘗試說服對方的過程，而無法回復他人意見導致事實查核無法有效反駁（例：Bluedeck原話說不至於不限期封鎖，在解任介面持續被說成第三方管理員不認同可構成查封理由，而Bluedeck實際上會有限期封鎖。）另外，安全投票對於外部影響有混淆的負面效果，如果有人平時沒有編輯的突然在解任案上發表意見，則可能是被拉票。公開投票則讓社群更能夠找出可能影響。

2、安全投票程序複雜，給志願者帶來不必要的工作

3、未發現公開討論有哪些弊端，目前的惡意影響有利用資訊不透明的嫌疑，因此不認為站內投票會加強惡意影響。--0xDeadbeef (留言) 2024年8月19日 (一) 02:35 (UTC)

1、可自行控制之部分之後基金會可能允許直接在本地維基上舉行安全投票，有關要求可以跟基金會提。

2、安全投票可以保證意見不受干擾，雖然WP:暴力威脅風險降低，但也有公開表達意見者遭受WP:騷擾的問題，因此社群應繼續採行安全投票。

3、對於制裁投票過程可能出現違反CIV、PA等投票內容，應該可以宣告辱罵他人等違反方針的投票無效，相信很多人就不會發出違反方針的內容了。必要情況下也可以請求基金會協助，因為技術上還是能找到這個人的。

4、投票前就可以討論並嘗試達成共識，投票中也仍然可以在站內討論，也可以回復他人意見。另外也建議公開投票人名單即可找出可能的影響。

--桐生ここ★[討論] 2024年8月19日 (一) 03:34 (UTC)

有公開表達意見者遭受WP:騷擾的問題 - 如何證明安全投票減少騷擾，或公開投票騷擾現象會更多？ 0xDeadbeef (留言) 2024年8月19日 (一) 11:18 (UTC)

使用安全投票，騷擾者不知道你的態度，所以根本不會騷擾你，因為他根本不知道你的意見和他一致還是相反。使用記名投票，騷擾者知道你的選擇和他不同，自然可以騷擾你。你維現在也有郵件騷擾這種事。--桐生ここ★[討論] 2024年8月19日 (一) 13:07 (UTC)

這個和安全投票防止暴力威脅的原理是差不多的。--桐生ここ★[討論] 2024年8月19日 (一) 13:10 (UTC)

並不覺得這種未經證實的事情（你只是提供了「公開投票可能有更多騷擾行為」的解釋，你並沒有證明這實際上會發生）可以作為以投票代替討論的理由。共識就應該以討論來產生，安全投票只會導致原本願意溝通的人更加兩級分裂（參考此次解任案）而對於對方的合理觀點不予理會。--0xDeadbeef (留言) 2024年8月19日 (一) 13:17 (UTC)

附議。甚至之於管理員選舉等重要議事事項也未嘗不能恢復到公開投票的模式。--SheltonMartin留言|簽名 2024年8月20日 (二) 06:31 (UTC)

@SheltonMartin：可否澄清一下此附議是指哪一個留言--0xDeadbeef (留言) 2024年8月20日 (二) 12:58 (UTC)

您的。--SheltonMartin留言|簽名 2024年8月22日 (四) 02:37 (UTC)

(！)意見 雖然安全投票可以很好地隱藏發言人，並且在結束前無法得知意見，但這也催生了一些可從本次投票窺見的問題。A. 安全投票能保護投票人，可能會有人抱著找不到我的心態投票，導致一些公開投票不會出現的留言；B. 依WP:投票不能代替討論，隱藏意見對共識的取得是致命的，無疑盲人摸象。就好比辯論雙方只能寫意見到白板上，裁判喊321同時亮牌子並直接打分。縱觀RFA/AFD投票，經常會有人被他人說服後改票。

直接取消安全投票也可，但我也想了兩種不成熟的折中方案，供社群參考，拋磚引玉：

先行投票是否啟用SecurePoll

在依方針舉行SecurePoll前，先請各位維基人對是否啟用安全投票進行投票。投票完畢後，則按照結果正常執行程序。補充：也可考慮僅允許投票選擇投票方式的使用者參加正式投票，此舉一可以避免群發討論頁資訊，二可提前篩選使用者。

安全投票之優勢在於避免受他人威脅與保護自我隱私，如果上述二種訴求不強烈，大可採用更便捷的公開投票。缺點則會使過程冗長。

自願隱藏投票者

與舊投票方式無異，但是使用者可自行選擇隱藏投票簽名者。目前能想到的辦法是請求監督隱藏編輯者使用者名稱？

優點是便於劃無效票，並及時知道他人意見以供參考。缺點則會增加監督工作量。——即請秋安 ZhaoFJx_{(論•歡迎簽名)} 2024年8月20日 (二) 15:52 (UTC)

不覺得兩方案可行，第一方案在原本SecurePool之上更加浪費時間，而不一定就解決投票代替討論這一問題。第二方案，首先技術層面上就很難做到，其次也阻止不了「寫下歪曲事實或誹謗的意見就走人」這種情況（因為如果實際匿名，那監督員不應知道是誰留下意見，而如果監督員知道所謂匿名的意義也就消失了，與其把擾亂使用者揪出來的責任交給監督員不如公開讓社群看到是誰）--0xDeadbeef (留言) 2024年8月24日 (六) 07:19 (UTC)

所以直接取消掉安全投票轉公開投票也挺好的，不過還是要看社群共識。對第二個方案我想補充一下，顯然不符合事實的投票質詢回復來來回回，自然可看出誰有理。而且可以考慮允許監督員作為受信任使用者監票並記錄，同時在爭議情況下綜合意見判斷特定投票是否有效。——即請秋安 ZhaoFJx_{(論•歡迎簽名)} 2024年8月24日 (六) 09:09 (UTC)

我有替代方案就是同時進行公開投票和安全投票，擔心有安全風險或遭受暴力威脅騷擾報復的情況下可以登記為安全投票投票人，然後這些人使用安全投票，其他人使用公開投票。--桐生ここ★[討論] 2024年8月24日 (六) 17:37 (UTC)

仍不能避免此制度遭濫用。另一個想法是恢復公開投票，但允許有必要者向第三方行政員（或管理員？）報備後使用未公開分身帳號投票。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月26日 (一) 07:15 (UTC)

若那些留言嚴重到需要處理，社群完全可以請求基金會處理，而無需因噎廢食。想想為什麼基金會選舉使用安全投票？為什麼運動憲章使用安全投票？為什麼UCoC使用安全投票？為什麼en仲裁委員會使用安全投票？如果社群不打算徹底改革管理員任免，停止以投票決定結果，改成就某人是否能擔任管理員一題不設時間限制辯論至得出共識為止，那麼就不應該對投票制度倒行逆施。--桐生ここ★[討論] 2024年8月26日 (一) 07:56 (UTC)

某些純粹是道德低下的行為，如果換成公開投票，當事人不見得就敢如此在自己的簽名前面大放厥詞，就算堅持要發，至少也能公開為自己愚蠢的言論負責。我當然亦不會幻想這樣做能解決所有問題，但肯定能解決不少。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月26日 (一) 15:36 (UTC)

涉及管理權限爭議之過渡仲裁措施

此次投票，一大理據涉及管理權限特定爭議。此種複雜之爭議，本應考慮由具公信及專業之第三方維基人組織仲裁，詳加審核相關操作及證據，並經深入思索提出報告供參為宜。「管理員的離任方針」亦明確強調，解任投票屬最終手段，當有十足充分之考量而行之；若能藉由仲裁措施或處分有效釐清雙方權責過失，並藉由溝通有效緩和爭議、化解雙方分歧，最終往往毋須訴諸解任。惟本地現有制度，尚未提供前述第三方仲裁措施之基礎；如管理員布告板，向來無力處理特別嚴重之爭端，而此次投票縱有若干管理員等社群成員就解任理據獨立從事查證，惟其受時間、人力等客觀限制，亦難稱臻至完善，且未能獲社群正式背書，效力恐有所折扣。近年來本站籌設仲裁委員會，固有就此問題予以釜底抽薪之可能，惟社群現階段仍在討論組織及人事細節，望其短時間內付諸運轉、乃至於樹立適當權威，自是天方夜譚。值此一過渡之際，實有賴社群即時研議臨時仲裁措施，以處理涉及管理權限之爭議。謹嘗試提出問題如下：

一、社群對於現有個別管理員難以處理龐大管理權限爭議之情況（如管理員布告板各子布告板等），有何協助應對之可能方案？

二、社群現階段於嚴重權限爭議及解任投票「決戰」夾縫間，是否可能留有任何緩衝之選擇？如比照相關權限方針，引進停權警惕機制？甚或搭配獨立第三方調查制度，由行政員、管理員或其他有能社群成員聯席組織，以停權當事人之臨時處分，換取些許餘裕，得為有限期而妥當之調查報告，而免於驟然躍進解任投票之地步？

註：有關仲裁委員會之組織細節，請繼續踴躍參與上方相關段落討論。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)

• 「解任投票屬最終手段」這話沒錯，而且社群也遵循了這一規則：反正都不能溝通，當然要使用戰爭手段，而你維的戰爭手段不就是拼人數嗎。說了多少遍了，你們非要從眾而不是從賢。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年8月20日 (二) 09:38 (UTC)

「臨時」管理員任期問題

社群晚近引進「臨時」管理員機制，為尚待爭取社群充分信任者提供有限期權限以為鍛鍊。惟「申請成為管理人員方針」指出：「臨時權限與一般不限期權限無異，但需在任期結束前重新申請，並經社群投票確認，才能繼續保留權限。」對於所謂「投票確認」之細節語焉不詳，尤未有聲明此種「臨時」之有限效期是否得以連續申請無條件延長（形同「任期無限」），此於本年新一輪管理人員申請前當有所解決，方得迴避無謂混亂。謹嘗試提出問題如下：

一、社群是否應保留「臨時」管理員機制？抑或取消之，或再研議其他制度以為替代？

二、社群是否應就「臨時」管理員之任期有所限制？如限定任一期或連任特定次數以後，次輪（下輪）申請累積信任須達到正式通過門檻，否則即應收回「臨時」權限，越次輪（下下輪）始得重行申請？或改為逐步提高次一任期之通過門檻，直至正式通過為止？

註：特副知目前本站唯一「臨時」管理員@ATannedBurger。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)

臨時管理員機制既然是提供給還沒取得社群充分信任的人爭取社群信任，那麼臨時管理員就應該把握時間讓大家認可他，加上臨時管理員權限與一般管理員無異，代表臨時管理員在下一次申請前能充分表現，若是經過一次任期仍無法取得社群足夠的信任，那或許就是暫時還不適任，因此我認為臨時管理員在次輪申請時需至少達到正式通過門檻，若無法達到則應收回臨時權限，下下輪才能再申請。--PC 2024年8月18日 (日) 20:36 (UTC)

我認為臨時管理員機制多少還是有些必要性。不論是因為當前社群對永久管理員門檻的下調程度有限，又或者是在實務上能幫助社群多認識和了解新管理員處理事務的方式，貿然取消當前制度的話很可能導致經常被詬病的管理員難產問題再次重現。

第二個問題的話大致上同PC君的觀點。考量到臨時管理員的當選區間（65% ~ 75%）並沒有很大，逐步提高次一任期之通過門檻究竟是需要離上次當選差多少百分比（換句話說，多少的提升才無法用誤差範圍/臨界值來解釋），為了避免此類爭議，我覺得倒不如選擇較為乾脆的處理方式會比較洽當。--$\int$（☎）dt 2024年8月18日 (日) 20:52 (UTC)

1、若現在取消臨時管理員，那麼這個試驗期太短，無法評判臨時管理員制度效果，因此建議目前保留。

2、大致認同PC意見。--桐生ここ★[討論] 2024年8月19日 (一) 03:40 (UTC)

---

總結一下討論。討論使用者基本就臨時管理員在第二次申請權限時須達到正式管理員標準才可保留權限一事基本達成一致。根據目前共識，個人提議在申請成為管理人員方針條文中修改以下內容：

現行條文 行政員須按投票中有效的支持票佔總有效票的比例（支持率）判定管理人員申請是否獲得通過。支持率達75%者，將獲授予申請之權限（但根據全域使用者查核和監督方針，使用者查核員和監督員需要25票支持才能當選）。而管理員申請支持率達65%、但不足75%者，亦得獲授予為期六個月的「臨時權限」；臨時權限與一般不限期權限無異，但需在任期結束前重新申請，並經社群投票確認，才能繼續保留權限。

提議條文 行政員須按投票中有效的支持票佔總有效票的比例（支持率）判定管理人員申請是否獲得通過。支持率達75%者，將獲授予申請之權限（但根據全域使用者查核和監督方針，使用者查核員和監督員需要25票支持才能當選）。而管理員申請支持率達65%、但不足75%者，亦得獲授予為期六個月的「臨時權限」；臨時權限與一般不限期權限無異，但需在任期結束前重新申請，並在投票中的支持率達75%，才能繼續保留權限。

--人間百態,獨尊變態(討論) 2024年8月26日 (一) 10:27 (UTC)

停止以投票決定結果

具體意見與前次RFC相同。在維基百科的權限得失上用投票得結果不過是拙劣的cosplay。既然這麼喜歡互煮，建議改成就某人是否能擔任管理員一題不設時間限制辯論至得出共識為止。——暁月凜奈 (留言) 2024年8月21日 (三) 08:36 (UTC)

所謂「投票」是有必要的，因為以社群規模永遠不可能純經討論得出共識，最後還是會變成「類似投票」（!vote）。其實管理人員申請及解任投票理論上一直都是「類似投票」；個人反而覺得「解任投票」目前看來很有必要降低純「投票」的成份（儘管社群整體意見仍占有極高比重）。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月22日 (四) 13:53 (UTC)

有何差異，為何RFA如此特別，應該繼續「類似投票」，無需降低「純投票」成分？--桐生ここ★[討論] 2024年8月26日 (一) 07:58 (UTC)

不用投票決定結果，難道以反對罷免的那幾個人決定結果？--日期20220626（留言） 2024年8月25日 (日) 02:15 (UTC)

RFA和RFDA是否要求提供理由

最近有些人認為應該廢除RFDA要求提供理由：

• 要求提供理由如同DYKC要求必須寫廢話
• 判斷理由是否有效造成點票困擾
• 要求提供理由引發很多問題

也有人認為：

• 要求提供理由對共識判斷相當有幫助

提請社群討論，如果要求提供理由沒有意義，而且弊大於利，是否應該廢除。如果要求提供理由利大於弊，對共識判斷相當有幫助，是否應該也要求RFA必須提供理由。--桐生ここ★[討論] 2024年8月24日 (六) 18:05 (UTC)

其他意見

此處供社群發表雜項意見，若有重要問題提出者，歡迎於上方新置章節。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)

除放置公告欄外，是否亦考慮寄送使用者討論頁通告，俾便廣大社群知悉參與？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)

同意應該寄送。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年8月20日 (二) 12:01 (UTC)

簡要模仿管治討論做了一份通告模板供參考。——即請秋安 ZhaoFJx_{(論•歡迎簽名)} 2024年8月21日 (三) 06:44 (UTC)

公示7日，2024年9月5日 (四) 07:29 (UTC)結束：討論使用者基本就寄送通告達成共識，進入公示期。--人間百態,獨尊變態(討論) 2024年8月29日 (四) 07:29 (UTC)

我晚點結合仲裁委員會選舉事寫一份更簡潔的通告吧。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月29日 (四) 10:12 (UTC)

澄清解任過程中發言的不同解讀

關於0xdeadbeef閣下在討論中提到（例：Bluedeck原話說不至於不限期封鎖，在解任介面持續被說成第三方管理員不認同可構成查封理由，而Bluedeck實際上會有限期封鎖。），在下認為是不當解讀， 澄清可見於：澄清解任過程中發言的不同解讀。 --Gluo88（留言） 2024年8月23日 (五) 09:45 (UTC)

您好，因與檢討相關制度並無直接關聯，本人將此議題移至其他意見。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月24日 (六) 08:08 (UTC)

謝謝--Gluo88（留言） 2024年8月24日 (六) 13:05 (UTC)

關於管理員錯誤自查表/封鎖補充的說明

請移步相關頁面繼續討論，勿於此處別生枝節。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月24日 (六) 14:34 (UTC)

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

---

Bluedeck 於2017年4月28日建立這個文檔:Wikipedia:管理員錯誤自查表/封鎖，感覺目的挺好：「在中文維基百科的實踐中，管理員和管理人員有時可能會因為未注意到方針指引的一些細節而出錯。在此總結了一些常見的錯誤，以便管理員在執行封鎖時更加符合方針和指引，同時也便於普通使用者根據方針指引與管理員溝通，針對疑似不當封鎖的類似情況提出質疑。」

有些管理員需要更加熟悉有關方針和指引， 約束自己的行為，避免長期多年做出大量違反方針和指引的封鎖行為， 避免發展到需要社群啟動彈劾程序。為此目的，我系統地閱讀了方針指引，查找了眾多案例，花費了大量時間，進行了較為詳細的補充。

所增加的問題都是在實際過程中所觀察到的。從目前情況來看，許多有多年經驗的管理員對方針指引仍然不夠熟悉。這些總結不僅有助於管理員自查，也能幫助受到不公正待遇的使用者找到相關方針和指引，以分析實際遇到的問題。

更重要的是，我們希望管理員和使用者都能夠按照方針辦事，這些總結是否能幫助管理員和使用者、是否能幫助維基社群營造一個和諧公平的合作環境是我們需要考慮的重點。 希望大家關注如何幫助社群，如何幫助維基營造一個和平公正的合作環境。

有不同意見可以提出，社群可以繼續補充和討論， 有助於建立積極的中維社群環境。社群協作的關鍵在於理解、尊重和包容不同的觀點。即使某些使用者表現不佳，作為管理員，我們應該保持專業和耐心，應該保持客觀、公正和理性，而不是簡單地採取高壓態度。公信力需要建立在合理和公正的行為基礎上。 --Gluo88（留言） 2024年8月24日 (六) 13:13 (UTC)

其實在Wikipedia talk:管理員錯誤自查表/封鎖#有關此頁面新增內容，請大家協助確認及提供意見已有用rfc發起討論，建議在該討論頁討論即可。--Wolfch (留言) 2024年8月24日 (六) 13:28 (UTC)

謝謝您的理解， 社群需要一起合作， 進一步改善。這個補充的目的，和本次解任直接相關，涉及範圍大時間長影響大，更應該在客棧的檢討此次檢驗程序的過程中討論，讓一切改動公開透明，廣泛徵求意見， 有助於避免將來再啟動彈劾程序。

目前我的修改已經被全部徹底的回退。請測評使用者看一看在下的補充，發表您的意見， 包括是否應該恢復在下的編輯。--Gluo88（留言） 2024年8月24日 (六) 13:48 (UTC)

(！)意見，此討論內容已經和頁面發起的rfc討論重複，請求未參與其中的其他使用者協助關閉此段討論，謝謝。--提斯切里（留言） 2024年8月24日 (六) 13:55 (UTC)

---

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

關於新建LTA頁面

如題，本人昨天依據部分經驗以及日文維基百科片段建立了LTA:GNSN頁面，但根據LTA建立指示，只有在破壞易誤會為善意編輯時有需要建立頁面。

然GNSN之破壞行為皆非常明顯，不易誤認，請問各位此頁面是否有存在之必要？--William is Wikipedia! 2024年8月21日 (三) 07:30 (UTC)

我認為沒必要，列入LTA反而讓其目的達成。回退、封鎖、不理會即可。--自由雨日🌧️（留言｜貢獻） 2024年8月21日 (三) 08:09 (UTC)

不過William指出這些破壞者應當提交全域鎖定，不知道這和列入LTA是否有相關性？思考...--自由雨日🌧️（留言｜貢獻） 2024年8月21日 (三) 08:11 (UTC)

(～)補充：據最新資料顯示，中維的原神破壞者似並非LTA:GNSN（我認為該「聲明」可信度較高）。他列出的那些傀儡帳號或IP，行為確實和疑似真正的LTA:GNSN建立的GoogleRitz 2行為有異。--自由雨日🌧️（留言｜貢獻） 2024年8月21日 (三) 08:50 (UTC)

(：)回應，如果聲明沒有騙人，那我們其實也沒什麼需要花太多時間討論這個了...不過我想連ja那邊應該也還不知道這個GNSN是假的。--William is Wikipedia! 2024年8月21日 (三) 09:37 (UTC)

ja那邊有關注到我們中維的這個「假GNSN」嗎？--自由雨日🌧️（留言｜貢獻） 2024年8月21日 (三) 10:51 (UTC)

看起來還沒，不過這可能就要勞煩較為熟知日語及日語維基的人幫忙了。--William is Wikipedia! 2024年8月21日 (三) 12:36 (UTC)

我的意思是，日維那邊「是否知道中維最近兩個月出現了這個假GNSN」，而不是「是否已經知道中維的這個GNSN是假的」，如果是「完全沒有注意到中維的這個人」的話，那應該就什麼也不用做？不過看您的回覆，應該是後者，即他們「已經知道了，但還不知道是假的」這種情況……--自由雨日🌧️（留言｜貢獻） 2024年8月21日 (三) 12:42 (UTC)

抱歉是我沒表達清楚，但我從日語的破壞者紀錄頁面發現他們也有記錄到這幾個假的GNSN（他們在ja也有破壞被封鎖）他們似乎還不知道這些最近才出沒的LTA是假的。--William is Wikipedia! 2024年8月21日 (三) 12:54 (UTC)

同意自由雨日的說法，攻擊太明顯了，大多數情況下長期破壞者並不需要被記錄。--Nostalgiacn（留言） 2024年8月23日 (五) 08:31 (UTC)

LTA:2077、LTA:QCHM、LTA:RF、LTA:WOW等使用者也是純破壞或攻擊。另WP:RBI不是正式方針。--132.234.228.192（留言） 2024年8月23日 (五) 08:58 (UTC)

他們是LTA方針修訂前納入的LTA，不一定適用新案例--—— Matt Zhuang表示有事按「此」留言 2024年8月23日 (五) 09:38 (UTC)

如Matt Zhuang所言，記錄指南這個記錄標準，是2023年2月才通過。很多標準在變，這個不溯及既往的規則，所以舊的不以新標準評判。--Nostalgiacn（留言） 2024年8月23日 (五) 10:06 (UTC)

@WilliamSkyWalk：如果確認是跟新規定，這個LTA可以快速刪除了，免得助長他人氣焰。--Nostalgiacn（留言） 2024年8月24日 (六) 05:54 (UTC)

倒也不必快速刪除，保留占位頁面亦可，祇需要去掉有關破壞內容之記載。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月24日 (六) 07:30 (UTC)

可被不熟悉其編輯模式的管理員簡單判斷為純粹破壞者的案例就沒有列入需要（LTA:WHICH），按目前規範執行行了，目前沒看到有例外的必要。--Nostalgiacn（留言） 2024年8月25日 (日) 05:27 (UTC)

管理操作覆核請求：被提報使用者明顯存在不文明行為時拒絕做出相應處理

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

操作： Special:Diff/83911370

執行者： Manchiu （討論 · 貢獻 · 日誌）

先前討論：Wikipedia:管理員布告板/其他不當行為#Zhenqinli

如題。 --——— 紅渡廚（留言・貢獻） 2024年8月22日 (四) 04:23 (UTC)

首先紅渡廚閣下只對這個版本發出了警告，未見雙向留言溝通。個人認為紅渡廚閣下提出的每個版本裡，能看到紅渡廚閣下的文字，非常地很有個人風格，對比Zhenqinli的文字，兩位都很有自己的直率文字格調。將心比心，在假定善意且為初次提報之下，管理員處置並無不妥，若經過溝通無效加上數次警告後，提報才是最後考慮。（另建議，中文字儘量避免使用斜體。）--提斯切里（留言） 2024年8月22日 (四) 14:25 (UTC)

斜體是AARV模板附帶的，大家熟悉一下，請各位閱讀Wikipedia:管理操作覆核請求，這是本站第一個AARV--桐生ここ★[討論] 2024年8月22日 (四) 14:41 (UTC)

原來是這樣啊、我的誤解、非常抱歉請見諒。--提斯切里（留言） 2024年8月22日 (四) 14:59 (UTC)

我認為您說的是有道理的，我這幾天會找時間與被提報使用者溝通，感謝您的意見。（另外，閣下說的斜體是指的「此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。」嗎？）--——— 紅渡廚（留言・貢獻） 2024年8月22日 (四) 14:42 (UTC)

見桐生君解釋後明白是我的誤解，都是模板不好（?），請見諒。--提斯切里（留言） 2024年8月22日 (四) 15:02 (UTC)

沒事。--——— 紅渡廚（留言・貢獻） 2024年8月22日 (四) 15:09 (UTC)

一般按照以往案例來說，違反CIV而採取封鎖的都是顯而易見帶髒字的辱罵他人。--桐生ここ★[討論] 2024年8月22日 (四) 14:35 (UTC)

我也認同，雖然言論可能有些許不妥，但離CIV還遠了。--William is Wikipedia! 2024年8月22日 (四) 14:47 (UTC)

懂了，在你維可以隨便陰陽怪氣，隨便惡意揣測他人動機。--——— 紅渡廚（留言・貢獻） 2024年8月22日 (四) 14:49 (UTC)

非此意，只是依以往案例，比較像AGF而已，並沒有要贊同這種行為。--William is Wikipedia! 2024年8月22日 (四) 14:55 (UTC)

同WilliamSkyWalk。--桐生ここ★[討論] 2024年8月22日 (四) 14:58 (UTC)

你們是不是此意不重要，關鍵是有管理員覺得可以啊，反正像《Wikipedia:管理員布告板/其他不當行為#Zhenqinli》這樣惡意揣測，只會得到管理員的一句不痛不癢的提醒，那我以後也這麼講話咯。--——— 紅渡廚（留言・貢獻） 2024年8月22日 (四) 15:08 (UTC)

在假定善意之下，個人認為紅渡廚閣下盡量試看看先跟對方溝通，請他避免自我揣測。就像現在，我覺得您直接認為管理員沒有看出對方的「惡意」的發言略帶有「攻擊性結論」。每個人感受到不同，可能也許或者我猜您會說我就是這樣說話，但對方或許也是呢。還是試著聊聊吧。--提斯切里（留言） 2024年8月22日 (四) 15:14 (UTC)

我還是希望大家多溝通為宜。--千村狐兔（留言） 2024年8月23日 (五) 22:51 (UTC)

遇到校園欺凌時，老師對受害人說「如果你不要跟壞孩子接觸，如果你再強壯一點，如果你再聰明一點，如果你成績再好一點，如果你不要激怒他們，如果穿得不是那麽暴露……事情就不會發生。」這是在暗示「你也犯了錯誤」（[2]）。

當然性質可能不同，但是受害人的感覺與旁觀者是不同的。「好警察」也夠多了，也需要有人做「壞警察」。--Nostalgiacn（留言） 2024年8月25日 (日) 05:39 (UTC)

@Nostalgiacn閣下的意思是，紅渡廚閣下確實受到傷害？--提斯切里（留言） 2024年8月25日 (日) 09:23 (UTC)

我又不是他，我怎麼知道。當代政治正確，一個稱呼不當，對方也會被感到被歧視，被冒犯，這是很主觀的。退一步硬要我去猜測的話，基於善意推定，紅渡廚在提報後，不服判決走覆核，那就是對某些言語忿忿不平。--Nostalgiacn（留言） 2024年8月25日 (日) 14:57 (UTC)

你維很多人確實有一種愚蠢的文明觀：只要不帶髒字，怎麼罵人，怎麼冒犯，怎麼誹謗都可以。但是。你要說人家是誹謗，也要說清楚為什麼是誹謗吧？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年8月23日 (五) 08:51 (UTC)

(！)意見我認為有符合CIV中的輕蔑其他編輯（如果要來比較清理廢話跟無事生非，浪費社群資源哪句比較不文明當然也可以討論）。批評肯定是有的，是不是惡意的話...或許在執行層面上Manchiu希望兩位還能保持一定的假定善意就是了。--$\int$（☎）dt 2024年8月26日 (一) 05:51 (UTC)

你維CIV又能這麼用啦？真是充滿了魔法呀。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年8月26日 (一) 08:45 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到覆核請求關閉。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

請求CCI Lki5168

@0xDeadbeef，我和@User:Jonathan5566 審閲最近 @User:Lki5168的草稿發現有大量侵權，現在提請CCI流程。 -Lemonaka 2024年8月27日 (二) 00:39 (UTC)

Can you give examples of the five infringements of User:Lki5168.

可否給出User:Lki5168五處侵權的實例。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 02:10 (UTC)

敝人撰寫之詞條

皆為參考資料後

以自己的方式進行撰文

然 史實 "無法" = 串改

只能依照 "參考資料" 進行 = 潤飾

再依照格式以及各資料予以進行總和撰文

故而 "大量" 的 = 侵權!!!

請再次查明--Lki5168（留言） 2024年8月27日 (二) 02:27 (UTC)

潤飾就是侵權。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年8月27日 (二) 07:13 (UTC)

@Lki5168 這指：不是你僅在單一條目／草稿有侵權行為，而是你涉及多個頁面、多次的侵權行為--Benho7599 ^{堅決擁護以芙寧娜同志為核心的楓丹} 2024年8月27日 (二) 07:34 (UTC)

1. Draft:後社角聖和宮(學甲)軼事段落。
2. Draft:大埔口(學甲)歷史軼事段落
3. Draft:學甲煥昌鎮壽殿建廟沿革。

-Lemonaka 2024年8月27日 (二) 13:50 (UTC)

Can you provide more examples of infringement.You have provided only three instances of infringement, whereas we need a minimum of five.

能否提供更多的侵權實例。您僅提供了三處侵權實例，而我們最少需要五處。--人間百態,獨尊變態(討論) 2024年8月27日 (二) 13:57 (UTC)

4.草稿:宅口(學甲)聞人段落。軼事傳說段落。
5.後厝仔角聞人段落。 -Lemonaka 2024年8月27日 (二) 14:03 (UTC)

Thanks.I accept this CCI request.--人間百態,獨尊變態(討論) 2024年8月27日 (二) 14:16 (UTC)

@人間百態Please create a CCI page, thank you. There's some bug in my JRE. -Lemonaka 2024年8月27日 (二) 15:09 (UTC)

I have created it.If the CCI issue is passed, this page will turn positive.--人間百態,獨尊變態(討論) 2024年8月28日 (三) 01:42 (UTC)

跟這邊大家說聲道歉，我當時審核草稿未臻周延，竟未發現條目內容出現侵權情況。--William is Wikipedia! 2024年8月27日 (二) 15:18 (UTC)

@WilliamSkyWalk Not so obvious, for example, the sentence in article is
"大二時即通過普考，當完兵後又考上高考，七十五年（1986年）再考上甲等特考。服完兵役的第一份工作是到經濟部金屬工業研究所服務"
The origin is
"大二通過普考，當完兵即考上高考，七十五年又考上甲等特考（與馬英九同榜）。服完兵役的第一份工作是到經濟部金屬工業研究所服務，" -Lemonaka 2024年8月27日 (二) 17:46 (UTC)

P.S. This user also used lots of books for reference, I cannot check whether these are copyvio or not. -Lemonaka 2024年8月27日 (二) 18:00 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到基本核實。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

管理操作覆核請求：不對顯然違反雙向交互禁制的行為進行處理

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

操作： Special:Diff/83987281/83987339

執行者： Ericliu1912 （討論 · 貢獻 · 日誌）

先前討論：Wikipedia:管理員布告板/其他不當行為#Chinuan12623_2

不需要更多理由，以最大程度避免我自己違反禁制。 --自由雨日🌧️（留言｜貢獻） 2024年8月27日 (二) 19:24 (UTC)

請注意我不是不管，而是基於夜半時分相關操作時間軸相近及禁制制度運作模式，合理認為有相當可能為誤解。本人據此善意推定，先行詢問當事人是否誤解，我認為這是基於人性的正常操作，而且當事人什麼回答都還沒有，蓋以玩弄技術程序問題執行封鎖，亦難謂道德。另外他在我討論頁的編輯我也已經予以單獨警告，但你可不可以再多等一下啊，連這也要立刻覆核，彷彿一點空間都沒有似的，那我下次就真的不管了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月27日 (二) 19:30 (UTC)

另外，我想除在布告板提報對方違反禁制條件外，向管理員提出禁制申訴本身應該也屬於另一例外，否則要詳細解釋就八成會違反禁制，這就相當於禁止當事人申訴，其實也不合理吧？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月27日 (二) 20:03 (UTC)

雖然現行方針寫「禁制申訴及覆核應於使用者討論頁提出」，但總會有外溢抗議（比方說管理員布告板那個跟現在這邊這個應該都算），這些是否亦應全部禁止？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月27日 (二) 20:06 (UTC)

同意這個觀點，既然提報屬於合規行為，那麼申訴也應該屬於合規行為。--桐生ここ★[討論] 2024年8月27日 (二) 20:09 (UTC)

@桐生ここ：由于禁制所限我無法直接對您這句話展開討論，我只能說您後半句描述的情況並非實際發生的事情。--自由雨日🌧️（留言｜貢獻） 2024年8月27日 (二) 20:14 (UTC)

補充：我還沒仔細看來龍去脈，只是對Eric Liu提出的方針改革方案表示支持。--桐生ここ★[討論] 2024年8月27日 (二) 20:18 (UTC)

已經先調整相關禁制範圍，排除此種情況。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月28日 (三) 16:44 (UTC)

(～)補充：我剛又進行了新的提報，見WP:ANM（本條評論發出時暫未有管理員處理）。--自由雨日🌧️（留言｜貢獻） 2024年8月27日 (二) 20:27 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到覆核請求關閉。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

為何WP:XRV需要在本頁提出？

現在本頁面已有兩個管理操作覆核請求，但不理解為何要在本頁提出。像WP:VIP、WP:ANM、WP:AN3、WP:BN等也有各自的報告頁，為何WP:XRV需要在本頁提出？--132.234.229.167（留言） 2024年8月28日 (三) 00:12 (UTC)

因為此制度並非正式，嚴格來說該頁面只是提供討論用「模板」，相關話題與一般話題性質並無二致。其實這種話題當然也可以在管理員布告板提出，雖然可能不少人覺得那邊冷門，但畢竟還是正兒八經的布告板，應該考慮多加利用。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月28日 (三) 08:11 (UTC)

新設一個頁面就沒人看了唄--0xDeadbeef (留言) 2024年8月28日 (三) 10:23 (UTC)

提議完善MediaWiki:Spamprotectiontext

檢視垃圾連結日誌，幾乎全部的觸發都不是真的因垃圾連結而觸發，因此提議改善提示訊息。

現行條文 垃圾過濾器禁止保存您剛才提交的頁面，這可能是由於您所加入的外部網站連結所產生的問題。 您可以使用此工具測試您加入的連結符合哪條本地或全域垃圾連結黑名單，並請參見外部連結使用指引。如果您確認垃圾過濾器封鎖有誤，請在垃圾連結黑名單討論頁面提交修復請求。如果您只是允許一個特定的連結，而不是要移去黑名單上的整個連結，您可以到垃圾連結白名單的對話頁提出請求。

提議條文 垃圾過濾器檢測到您的編輯中含有新的外部連結，並且該連結與本地連結黑名單或全域連結黑名單匹配，因此您的編輯沒有被保存。提示訊息的最下方列出觸發過濾器的網址，請參見外部連結使用指引。請修正您欲提交的內容後再次嘗試保存。 以下是觸發垃圾連結過濾器的常見情況： 您的連結為短網址，如 bit.ly、reurl.cc、tinyurl.com、youtu.be、t.co、b23.tv 等。請將其替換為該頁面的完整網址。 您的連結形如 google.com/url?... 或 baidu.com/link?...。您直接從搜尋引擎的結果頁面中拷貝了網址，但其並非網頁的真實地址。請實際造訪目標網頁後，使用其網頁的真實網址。 您的連結形如 google.com/amp/... 或 .../gate/big5/...。您使用了為手機瀏覽網頁而設計的快速瀏覽服務或為繁體中文使用者設計的自動簡轉繁服務，並非網站的真實網址。請使用網頁的真實網址。若繁體中文版網站只提供形如上方的簡轉繁網址，請改用簡體中文版網址。 您的連結被明令禁止使用。如 xvideos.com、pornhub.com、discord.gg、ptt.cc 等。請另尋可用的來源連結，或參見下方說明。 您可以使用此工具測試您加入的連結符合哪條黑名單規則。 若您認為此次觸發為錯誤觸發，或者您認為該網站不應該被封鎖，請按這裡遞交申請。 若您認為有必要為您希望添加的單一網頁設定封鎖例外，請按這裡遞交申請。

--MilkyDefer 2024年8月29日 (四) 13:11 (UTC)

(＋)支持 更詳細一些總是好的。不過後面的「按這裡」是否可以替換為頁面名稱？如請在外部連結黑名單遞交申請。——即請秋安 ZhaoFJx_(論•簽) 2024年8月29日 (四) 13:25 (UTC)