維基百科:互助客棧/方針

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書

捷徑

此頁面探討維基百科的方針與指引。


請注重禮儀、遵守方針與指引，一般問題請至互助客棧其他區或知識問答提出，留言後請務必簽名（點擊 ）。


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

議題最後回應時間為4月8日之前（正在公示者除外）或者該議題已經標記為結束達三日，則該議題會存檔至相關討論頁或存檔頁。討論存檔至相關討論頁後，相關討論標題則會於一日後存檔。跳至本頁的：目錄 · 底端

公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 重議刪除方針規定「多餘無用」模板模組提刪條件及確立廢棄模板模組提刪規範 102 17 阿南之人 2024-04-15 18:57
2 提議提高條目評選投票資格門檻 29 16 WiiUf 2024-04-16 22:18
3 享年歲數究竟是需要來源還是可以被視為「簡單計算」的結果？ 4 4 Milkypine 2024-04-11 21:26
4 進一步增修封鎖方針以及建立封鎖申訴的本地共識 23 7 Sanmosa 2024-04-11 23:58
5 建立封鎖申訴的本地共識 57 5 Shwangtianyuan 2024-04-18 13:58
6 我想問下 草稿可以儲存 疑似侵權的內容嗎 5 5 GZWDer 2024-04-17 21:16
7 共識建立的遞進步驟 1 1 LuciferianThomas 2024-04-09 16:11
8 有關社羣討論所需的文明程度的疑問 33 10 桐生ここ 2024-04-15 22:33
9 「徵求意見公示寫入相關方針指引」提案公示通知 3 2 0xDeadbeef 2024-04-18 17:20
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

正在廣泛徵求意見的議題

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

維基百科格式與命名

Module talk:Citation/CS1/Configuration § 編輯請求：更正cite AV media參數顯示

Wikipedia talk:格式手冊/日本動漫遊戲 § 提議將WP:MOSACG跨媒體部分提升為指引

維基百科方針與指引

Module talk:CGroup/Korea § Module:CGroup/Korea

Wikipedia talk:維基百科不是什麼 § 修訂方針維基百科不是維基物種

Wikipedia talk:共識 § 共識建立的遞進步驟

Wikipedia talk:格式手冊/日本動漫遊戲 § 提議將WP:MOSACG跨媒體部分提升為指引

維基百科提議

Wikipedia talk:仲裁委員會 § RfC：2024年2月

Wikipedia talk:回饋請求服務 § 將回饋請求系統用於存廢討論和存廢覆核

Wikipedia talk:字詞轉換處理/公共轉換組 § 思路：條目預儲公共轉換組中匹配的規則，減少載入時間

Template talk:Twitter § Twitter改為X

條目主題
非條目主題
提示
要將某一個討論加入上述列表中：
  • 在討論頁中的對應討論章節頂端加上{{rfc|xxx}}標籤，其中「xxx」為分類縮寫。各類分類縮寫已列於上方項目中，並應將其插入{{rfc}}中。多個分類請使用管道符號分開，如{{rfc|xxx|yyy}}，其中「xxx」為第一個分類，「yyy」為第二個分類。
更多資訊請參閱Wikipedia:徵求意見。請在Wikipedia talk:徵求意見回報有關錯誤。本列表由LuciferianBot於每個小時進行更新。

重議刪除方針規定「多餘無用」模板模組提刪條件及確立廢棄模板模組提刪規範

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:刪除方針。

WP:DP#9規定：

9. 多餘無用，且影響其他模板命名或者百科運作的模板

此規則長期引來爭議，尤其限制了廢棄的模板模組提刪（當G1、G2、G3、G14、G15都不管用的前提之下），甚至有人因為類似原因吃上了禁制，先前也有修訂該方針的討論但無共識作結。以下有三條路可以走：

  1. 禁止廢棄模板模組提刪
    亦即禁止一切因為僅僅是廢棄的模板模組提刪
  2. 有條件才能提刪
  3. 允許一切提刪
    也可以說還原Wikipedia_talk:刪除方針/存檔5#提高無連入模板刪除門檻_2的修訂
    當然管理就要做好DRV增加的可能，畢竟某個被小工具使用的模板就被同一個人提刪了兩次，說不定下次就不小心被刪掉了呢
  4. 擺爛
    如果您們不介意刷編輯數的人的話...

另，若是要允許廢棄模板模組提刪的話，個人建議不妨直接建個集中提報頁處理。

以上。副@Sanmosa、A1Cafel、阿南之人、A2569875：--SunAfterRain 2024年3月14日 (四) 10:37 (UTC)[回覆]

其實本人一直都主張「扔掉」，例如廢橋就該拆、破鐵路就該廢等等。之前只是符合我的觀點才不斷提刪，既然被封了就算了。既然現在改動方針的話，我也不反對。鐵膠壹名 2024年3月14日 (四) 10:52 (UTC)[回覆]
小心屎山，搞不好拔了一個不起眼的東西，某些東西就塌了。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月14日 (四) 12:19 (UTC)[回覆]
那些放在子模板的廢棄模板並不會哪天就把你站炸了 囧rz……--SunAfterRain 2024年3月14日 (四) 17:07 (UTC)[回覆]
站大概不會炸，只是突然發現某個模板調用出問題，結果找了一圈才發現某個以為沒用的模板刪了就樂了。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月15日 (五) 00:55 (UTC)[回覆]
那就有點太過預想錯誤會存在了🙃--SunAfterRain 2024年3月15日 (五) 11:58 (UTC)[回覆]
從沒壞不修和保留歷史貢獻角度，我是傾向不刪慎刪的。如果非要做清理工作，希望參考關注度、草稿化流程，例如，刪除前確定無連入，懸掛告示模板並使模板失效（例如用模板包起，或者註釋、移除代碼），懸掛至少3或6個月，以確認無負面影響，期滿後提刪（類似關注度提刪）。告示模板時是否通知可選（需工具與模板支持），告示期間有爭議、合理理由則流程中止直至解決。--YFdyh000（留言） 2024年3月14日 (四) 11:52 (UTC)[回覆]
比較支持YFdyh000的意見，確定無連入，宣告失效並至少保持幾個月，之後如果認為仍然不會造成問題再提刪。通知方式我認為還可以直接在模板中嵌入失效通知，有頁面使用失效模板的話更容易發現。--百無一用是書生 (☎) 2024年3月15日 (五) 02:58 (UTC)[回覆]
但是如果是小工具以js的mw api使用的話，可能也不會發現……-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月15日 (五) 03:36 (UTC)[回覆]
@A2569875：這個我覺得學Wikipedia:被連鎖保護的項目/嵌入在MediaWiki命名空間處理就好了，小工具也就那幾個手動更新就好了--SunAfterRain 2024年3月15日 (五) 06:21 (UTC)[回覆]
偏向擺爛或者保留，如果沒有確鑿的理由說明模板沒被使用（存在通過條件判斷嵌入的情況，這樣連入檢查是看不出被嵌入的）。同時要注意一些為了令模板能被認為「沒用」刪除而故意移除對其的嵌入的編輯。存廢討論的意義在於此，這個條款很「『指引』，而非實際規則」。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月14日 (四) 12:18 (UTC)[回覆]
畢竟用指引沒有的條款就是IAR，我不認為大量IAR是好事啦，--SunAfterRain 2024年3月14日 (四) 17:05 (UTC)[回覆]
老實説當時的討論根本沒有有效凝聚共識，我傾向於認定當時的通過結果無效（雖説我也不反對重提WT:刪除方針/存檔7#有關模板的刪除理由中我或KirkLU的方案）。Sanmosa Gloire d'Yser 2024年3月14日 (四) 15:39 (UTC)[回覆]
個人傾向Bluedeck之前的意見，刪除歷史模板會讓歷史頁面版本顯示出現問題，除非認為歷史頁面完全沒用（似乎不是），所以既然不影響當前運作，標記為歷史模板不好嗎。Kethyga（留言） 2024年3月14日 (四) 23:28 (UTC)[回覆]
不好，這恐怕只是中文維基百科獨有的清奇想法。Sanmosa Gloire d'Yser 2024年3月15日 (五) 05:38 (UTC)[回覆]
哪裏不好了？另外獨有的清奇想法[來源請求]，我倒覺得您們閒閒沒事幹整天去找廢棄模板模組提刪比較「清奇」...--SunAfterRain 2024年3月15日 (五) 06:27 (UTC)[回覆]
就我看到的情況，其他維基百科對於機能已被取代的模板的處置方式就是刪除。Sanmosa Gloire d'Yser 2024年3月15日 (五) 06:55 (UTC)[回覆]
其實很多已刪除的模板並未直接引用在條目里，而是被其他模板調用（例如Module:MTR），刪除後不會影響歷史版本的。鐵膠壹名 2024年3月15日 (五) 13:46 (UTC)[回覆]
對於使用有一段時間的模板，大可停用，能不刪則不刪。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年3月15日 (五) 04:46 (UTC)[回覆]
我之前好像有提及過如果不直接刪掉模板的話，總有用戶會誤用已「停用」的模板。中文維基百科的「停用」並無約束力。Sanmosa Gloire d'Yser 2024年3月15日 (五) 05:40 (UTC)[回覆]
所以這跟刪除被lua取代的模板有關嗎？這類子模板你誤用給我看--SunAfterRain 2024年3月15日 (五) 06:24 (UTC)[回覆]
還有依照這種邏輯的話你維一堆histroical都可以刪掉了（要我舉例我再找來），因為會有人誤用嘛--SunAfterRain 2024年3月15日 (五) 06:29 (UTC)[回覆]
我個人確實是支持刪掉所有或大部分historical的。除非是極為特殊的情況，不然掛historical本質上就是懶政。Sanmosa Gloire d'Yser 2024年3月15日 (五) 06:54 (UTC)[回覆]
翻歷史垃圾堆的時候還是有點用的，雖然用處不大----Cat on Mars 2024年3月15日 (五) 10:21 (UTC)[回覆]
既然用處不大，那你確定這樣的「用處」真的有實際價值嗎？Sanmosa Gloire d'Yser 2024年3月15日 (五) 15:31 (UTC)[回覆]
那我說，我看到頁面歷史裏一堆因刪除而壞掉的模板會很煩躁，產生負面情緒，甚至引發精神疾病，如需醫師證明，我可以請我的精神科主治醫師寫，進而影響我的正常貢獻，你接受嗎？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月15日 (五) 15:36 (UTC)[回覆]
我認為這不是合理的理由，難不成這裏的任何人能因為在這裏跟大家討論會很煩躁而拒絕討論嗎？大家不也還是要在這裏討論？畢竟這裏應該沒有人是Jimbo吧？Sanmosa Gloire d'Yser 2024年3月15日 (五) 15:38 (UTC)[回覆]
作為貢獻存在的證明，只要曾經是有益的，我都傾向保留（指可檢索）。雖然目前實際做不到，包括速刪請求、存廢刪除、版本刪除等等都會使貢獻不可見，僅已刪百科之類的東西部分彌補。--YFdyh000（留言） 2024年3月15日 (五) 16:01 (UTC)[回覆]
「停用並無約束力」？那請示範一下您可以在哪個頁面上使用{{Cat also}}？然後再看看Template:Deleted template#實際範例的說明。--Xiplus#Talk 2024年3月15日 (五) 13:17 (UTC)[回覆]
啊？我説的是{{Deprecated template}}。Sanmosa Gloire d'Yser 2024年3月15日 (五) 15:30 (UTC)[回覆]
既然軟停用（{{Deprecated template}}）沒約束力，那改用強制停用（en:Template:Deleted_template/{{Deleted template}}）不就有約束力了？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月15日 (五) 15:33 (UTC)[回覆]
不是所有情況都適合使用{{Deleted template}}，而且也不是所有情況都適合使用{{Deprecated template}}。Sanmosa Gloire d'Yser 2024年3月15日 (五) 15:36 (UTC)[回覆]
建議您再讀一次您的發言看看您是不是打錯了，讀起來好怪...--SunAfterRain 2024年3月15日 (五) 16:54 (UTC)[回覆]
調整了。Sanmosa Gloire d'Yser 2024年3月17日 (日) 07:56 (UTC)[回覆]
支持刪除廢棄模板、模組，理由同Sanmosa。--紺野夢人 2024年3月15日 (五) 07:03 (UTC)[回覆]
User:MilkyDefer對評級系統修改開出的第一槍就是對{{WPBS}}維持原生Wikitext架構下來改，因此為了同步至{{WPBM}}同時也維持User:MilkyDefer原生Wikitext架構下來改，因此產生了此輔助模組：Module:PJBSClass/page，功能為將WP:通用評級讀給純wikitext模板使用完成實現。那麼假如未來評級模板徹底實現全面Lua化，將不需要「專門讀資料給純wikitext模板的模組」，屆時肯定會出現類似：
然後就刪掉沒人看得到我曾經寫過這個？那我今年年初是寫了個寂寞？？[1]你們訂立這個根本變相在抹滅他人的編輯歷史紀錄，讓他人曾經做過的貢獻永久消失永久不為人知，連檢閱都不給，這是甚麼鬼。這跟條目更新後把以前所有版本「歷史版本消除掉」讓別人看不到某人某時某刻曾做出某貢獻有甚麼差別？要不要條目永遠都只留一個版本，除了最新版本外所有歷史版本刪除？反本你們覺得「歷史紀錄」很「沒用」嘛。再來，維基百科是創用共享創意署名-相同方式共享4.0協議授權，那你們透過訂立該指引技術性地在未來某一刻抹滅我曾經為評級系統做出的貢獻，因為「刪除」了，所以「署名」不見了，但評級系統只是改版而已，但我的署名「被消失」了，是否違反共享創意署名-相同方式共享4.0版權？因為這就跟條目全文重寫後，你把條目全文重寫前的歷史全部WP:RRD掉沒兩樣嘛。留着到底哪裏礙到你們了？當這個議案通過之後，Module:PJBSClass/page就等於被你們宣告死刑了，幾年後我的貢獻就要被你們的「惡法」而「被消失」了，比阿卡林更可怕，是真的消失了，永遠不復存在。所以我要(！)抗議，就這樣。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月16日 (六) 02:53 (UTC)[回覆]
你不是引了討論連結嗎？單是這一點，「讓他人曾經做過的貢獻永久消失永久不為人知」這個説法就顯得過分誇張了。Sanmosa Gloire d'Yser 2024年3月17日 (日) 08:59 (UTC)[回覆]
只讓人看得到討論，卻封殺具體內容（刪除模板/模組使其具體內容只剩管理員看得到，其他所有人都看不到，不叫做封殺叫做甚麼）？這是什麼？新式變相言論封鎖？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月17日 (日) 09:37 (UTC)[回覆]
而且討論中，沒有提到技術實現細節採用Module:PJBSClass/page，只說了「詳細實現請參考沙盒，以沙盒內容為主公示」，那麼被刪除後，鬼才知道有人貢獻過Module:PJBSClass/page。既然「鬼才知道」，那「讓他人曾經做過的貢獻永久消失永久不為人知」哪裏過分？鬼嗎？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月17日 (日) 09:42 (UTC)[回覆]
最好還是少殺慎殺，不影響別人那留着沒害。--素菓霖（留言） 2024年3月28日 (四) 16:03 (UTC)[回覆]

修訂案

鑒於上方似乎沒有辦法再提出更多有價值的意見了，參考上方內容提出一版修訂案： Wikipedia:刪除方針

現行條文

9. 多餘無用，且影響其他模板命名或者百科運作的模板

提議條文

9. 多餘無用且影響其他模板命名，或者影響百科運作的模板

註：看起來只是逗號換位置了，實際上是將原來的條文刪了並重新寫了一條適合直接提交到頁面存廢討論的條文上去

Wikipedia:頁面存廢討論/廢棄模板模組Wikipedia:廢棄模板模組處理指引 請參考User:SunAfterRain/sandbox/DeprecatedTemplate 註：先聲明，以上條文並沒有嘗試整合上方意見，覺得不妥請直接講或是合理範圍內直接修訂頁面，謝謝

Template:ProposalDeprecated 請參考User:SunAfterRain/sandbox/DeprecatedTemplate/Template:ProposalDeprecated

以上。@Sanmosa、A1Cafel、阿南之人、A2569875、Ericliu1912、MilkyDefer、YFdyh000--SunAfterRain 2024年3月24日 (日) 14:35 (UTC)[回覆]

@SunAfterRain 我有個問題，像這種已失效的模板能不能直接以DP12刪除？鐵膠壹名 2024年3月25日 (一) 04:13 (UTC)[回覆]
@阿南之人：個人傾向失效不代表不符合使用目的，而且如果沒有影響到新模板命名的話放一下感覺比較安全。（反正如果影響到你的新模板命名的話可以用新的DP9刪掉）--SunAfterRain 2024年3月25日 (一) 10:50 (UTC)[回覆]
上述關於廢棄模板模組的條文更正成指引--SunAfterRain 2024年3月26日 (二) 09:45 (UTC)[回覆]
我覺得不需要特別為這個東西弄一大堆指引⋯⋯ —— Eric Liu 創造は生命（留言・留名・學生會） 2024年3月26日 (二) 12:04 (UTC)[回覆]
我覺得曾發生過的爭議級別達到有人被WP:BAN過的情況，宜立指引確立共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月26日 (二) 12:09 (UTC)[回覆]
@Mys 721tx 請閣下解釋一下對本人的禁制，以及回應對廢棄模板爭議的立場。鐵膠壹名 2024年3月26日 (二) 12:40 (UTC)[回覆]
User:阿南之人在受到質疑後仍然不尋求共識自行大量提刪，是為擾亂。阻止擾亂行為不需要在相關爭議中有任何立場。--Mys_721tx（留言） 2024年3月27日 (三) 04:12 (UTC)[回覆]
@Mys 721tx 前兩次被封是因為把有用的模板清理連結，然後以廢棄模板為由提刪。第三次純粹是提刪了真正的廢棄模板，但還是被人檢舉。後者不構成擾亂行為。--鐵膠壹名 2024年3月27日 (三) 04:24 (UTC)[回覆]
換句話說，前兩次因為亂刪有用的模板然後被封了。好了，我不亂刪了。第三次卻因為持續提刪未實際影響維護的已停用模板而被封了。這兩個原因分別很大。還有，明明你覺得我錯誤提刪，設定禁止提刪模板的禁制就可以了嗎，幹嘛不准我編輯模板？鐵膠壹名 2024年3月27日 (三) 04:31 (UTC)[回覆]
@Ericliu1912：如果是指不要再多一個「指引」出來或特許以做為刪除方針的子集處理但有沒有先例這個還得研究；如果是指新訂規則的話，廢棄模板真的不適合去存廢討論混（沒有什麼好討論的，又不會突然就變有用了二哈二哈），加上現在的方針明顯是排斥廢棄模板的，不如直接一次處理掉這兩個問題--SunAfterRain 2024年3月26日 (二) 12:21 (UTC)[回覆]
其實完全可以寫成論述，然後在相關方針與指引中提及，推薦參照這一流程。不需要鉅細靡遺的把這些東西全部寫到政策裏面去。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年3月26日 (二) 13:27 (UTC)[回覆]
@Ericliu1912：如果當論述處理，那這個提案就完全沒有意義了，您真的知道自己在說什麼嗎 囧rz……--SunAfterRain 2024年3月26日 (二) 18:17 (UTC)[回覆]
（已在站外提請對方提出他認為能符合需求的草案）--SunAfterRain 2024年3月27日 (三) 02:48 (UTC)[回覆]
不反對把較繁瑣的定義及程序性內容寫成論述或參考流程（實際上英文維基百科存廢討論就有很多），所以不知道是要額外提出什麼草案。我甚至認為刪除方針原條文也不用修正，只需要在刪除指南中提及相關流程即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年3月28日 (四) 02:48 (UTC)[回覆]
重新看了一遍流程草案，單獨為此類提刪建立頁面實屬多餘；要不然就正好比照英文維基百科，把整個模板（模組）存廢討論切出來，倒是意外可行的辦法。另外，三個月審核期顯然太久，維持一般存廢討論程序即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年3月28日 (四) 02:48 (UTC)[回覆]
@Ericliu1912：三個月與其說是審核期倒不如說是讓不是真棄用的還有挽救的時間（總比刪掉再來覆核好），而且放在那裏三個月也不礙事，礙事的話直接AFD處理就好。如果說要直接切出來倒也行，其他人覺得合適的話再來擬TFD獨立的改法，一開始只拆分棄用模板模組是想說如果把TFD直接拆分了可能會導致更加嚴重的relist現象。--SunAfterRain 2024年3月28日 (四) 09:18 (UTC)[回覆]
我認為直接分出TFD比較可行，但感覺不完全拆分也不是不可以。Sanmosa Gloire d'Yser 2024年4月1日 (一) 02:21 (UTC)[回覆]
個人仍然(×)傾向刪除所有廢棄的模板。簡單說一下為什麼個人認為保持歷史版本的理由不成立：維基的歷史版本預覽既不會使用共時的模板歷史版本渲染，內部連結也不會連結到共時的歷史版本，這樣渲染出來的上古版本毫無意義，而刪除又不太影響近期版本。真·歷史版本出門左轉 Archive.--DvXg 📬 2024年4月2日 (二) 15:21 (UTC)[回覆]
(！)抗議User:David Xuang「完全不把我和User:MilkyDefer」看在眼裏。我們的貢獻全部都被您弄成白工了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月2日 (二) 15:27 (UTC)[回覆]
Cry me a river and get yourself a wambulance. 有建議提意見建議，不要搞稻草人謬誤給我植入我沒說過的話、還沒罵起來就自己加戲表演受害者，在接下來是不是還要接着非暴力不合作啊。我從來就只說過支持刪棄用模板，又沒有要迫害你不准你在新模板里留reference和credits。替代方案被你搞得像什麼重大讓步，但棄用模板既然是零連入哪裏會有人看，署名轉到活躍模板訪客才看得見。
維基百科的結構是一個有向圖，和GC管理的內存模型類似，懸吊節點當然要刪掉，不然時間一長搞得模板空間比條目空間還大。替代模板給原作者署名本來就是應有之義，CC-BY本來就要求這個，舊模板沒刪的時候可以用內部連結替代，刪了那自然是要把署名手動掛上。怎麼這個都想不明白了，這一點為什麼還需要作為一個觀點被提出來討論，這篇論述/指引不存在的話，願意寫的人現在就可以開始準備了。--DvXg 📬 2024年4月2日 (二) 16:20 (UTC)[回覆]
參考開源軟件社區的實踐：重寫只有給原作者留署名的義務，沒有把原專案的commit history存下來的義務。如果重寫是淨室的，連署名義務都沒有。--DvXg 📬 2024年4月2日 (二) 16:26 (UTC)[回覆]
藍桌說了「維基百科的刪除又沒有任何技術上的好處比如節省磁碟」，所謂刪除根本沒有從「儲存設備」中移除，反而還要加上一個「已刪除」標記，並沒有省空間，所以我認為你所指「GC管理的內存模型類似，懸吊節點當然要刪掉」完全站不住腳，除非你直接從後台資料庫DELETE，否則沒有實際意義上的「刪除」。既然你要硬舉GC，好，那我告訴你，我研究過維基百科後台php代碼，維基所謂刪除只是變更一個標記的值，設定成只能讓管理員能看到有關內容，其他人看不到，代表儲存空間仍然佔據，但其他人看到是紅色連結接，（對非管理員而言）就像是遺失了內容，[但還佔據記憶體空間，豈不是一種類似memory leak的概念？][比喻]未必比較好。（2024/4/3 13:05 UTC+8註：我這樣說並不意味着他真的memory leak，事實上資料庫資料都還在，紀錄還在，可查、可控，並未流失。我想講的是，對一般非管理人員來說，他可能記得曾有甚麼東西在維基，但現在卻找不到了，出現認知落差；有時要追查上古技術債或其他的西要拿相關連結附上來，參與特定討論，討論某東西時也不好處理，因為你看不到了。相關存檔中的diff連結失效，徒增未來查閱討論者的困擾。）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月2日 (二) 16:54 (UTC)[回覆]
一個標記位從假翻轉成真，為什麼會佔用額外空間？
數據庫里沒有真正的刪除，所以呢？學過電腦的多級緩存結構嗎？不標記為刪除，會不會不必要地佔用站內和站外的緩存？是不是會污染站內外搜尋結果和編輯聯想？主數據庫本身是沒有瘦身，但頁面刪除（公開不可見）當然會從各方面減少開銷，包括硬件資源和人的注意力。
「攔截」後台數據庫？「內存泄漏」？請你不要再討論你完全不熟悉的領域了，徒增笑耳。--DvXg 📬 2024年4月2日 (二) 17:08 (UTC)[回覆]
就數據庫而言，數據是放在磁盤上的。非公開可見之後，一個頁面就不太會被訪問了，就不會有無聊的爬蟲導致這條數據被數據庫引擎讀進內存，再返回給反向代理伺服器，然後再被CDN緩存下來。基金會就是再有錢，也不會把整個數據庫放內存里，而內存比冷數據磁盤的成本高若干個數量級。這樣，一個沒有被刪除的頁面，當然會有額外的開銷。
閣下的發言印證了閣下並不具備泛電腦科學專業本科的水平。比如對數據庫的見解暴露了閣下對「電腦組織與結構」和「數據庫」這兩大專業課並不熟悉；對「內存泄漏」的見解和胡亂類比提示閣下可能不熟悉手動內存管理、RAII以及JVM/CLR這樣的託管運行時。建議閣下在技術上謹言慎行。--DvXg 📬 2024年4月2日 (二) 17:41 (UTC)[回覆]
WP:PERF。「不然時間一長搞得模板空間比條目空間還大」，那是否能說條目歷史比條目大得多（並且維基百科存儲每個版本的完整內容而非差異），署名並刪除舊版本豈不是更優化性能。我認為您的要求才不合情理。--YFdyh000（留言） 2024年4月2日 (二) 17:55 (UTC)[回覆]
我提的性能理由不是在為刪除背書，而是先前某人對Mediawiki和電腦的解讀實在是太離譜，我對GC的提及是類比而不是討論性能，性能不是我主動提出的話題。
對於這裏的提案，刪除條目包括兩個操作：
  • 刪除entry，不再可被內部連結、嵌入；
  • 刪除history，不再可被查閱。
我之前提到的污染結果很顯然主要是前者。Mediawiki做不到只刪entry不刪history，那就是mw的副作用。刪除不再有用的entry天經地義，不可能說沒有連入的條目可刪、沒有連入的模板反而不能刪了。副作用能不能緩解、需要緩解到什麼程度是需要討論的。不同程度的緩解措施可以包括：
  • 刪除時手動轉移署名
  • 開發小工具導出署名
  • 魔改mw，提供帶完整歷史dump的特殊刪除功能
--DvXg 📬 2024年4月3日 (三) 03:29 (UTC)[回覆]
@David Xuang：Wikipedia:不要擔心性能，如果不刪除這些廢棄模板性能能有多顯著下降請你去找基金會討數據來並且由他們證實影響很大必須處理，不要用理論論事，人家基金會都不在乎了你在乎幹嘛？--SunAfterRain 2024年4月3日 (三) 02:13 (UTC)[回覆]
  • 我沒有說這些對性能影響很大，但先前對維基後台的描述存在事實錯誤；
  • 我提到的不僅僅是性能，污染結果、造成誤用、干擾注意力的影響是很重要的。
--DvXg 📬 2024年4月3日 (三) 02:59 (UTC)[回覆]
@David Xuang：那請你四個都舉證。--SunAfterRain 2024年4月3日 (三) 03:24 (UTC)[回覆]
  • 我為什麼要舉證性能？性能不是我主動提及的話題，我提及GC是在類比抽象結構，是某人堅持沒有性能問題並作出了一篇不夠專業的論述；
  • 干擾結果這個方面是要舉出什麼樣的證據呢？模板名總該是要搜尋和聯想的罷。平行或者承繼關係的模板（組）可以相互干擾搜尋的例子是有的，比如大陸軌道交通的車站結構模板有好幾個家族，名字也有相似之處。
--DvXg 📬 2024年4月3日 (三) 03:42 (UTC)[回覆]
如果只是存檔陳舊頁面，這些都有非刪除手段緩解。模板可以更名、放入子頁面，模板文件可以標註過時、歷史性、最新替代品，站外索引可以禁止爬蟲，哪怕全文搜尋被認為干擾，也可清空頁面但保留歷史記錄、連結（如索引頁）。除非您在意的是歷史記錄爬蟲或者數據庫轉儲的增長。--YFdyh000（留言） 2024年4月3日 (三) 11:42 (UTC)[回覆]
沒有刪除commit history的必要。大量編輯（翻譯頁面、移植代碼等等）未能履行署名義務，我贊成儘量留存原始歷史。--YFdyh000（留言） 2024年4月2日 (二) 16:41 (UTC)[回覆]
我不覺得這個情境下實然可以超越應然。就翻譯而言，確實管不了。但刪除棄用模板這個情景，管理員是必然顯式地參與到這個過程中的，這裏都不能enforce先署名後刪除的政策，那等於說維基站務就是什麼都幹不了，討論出來的方針什麼用都沒有。那還開這個討論做什麼。--DvXg 📬 2024年4月2日 (二) 17:15 (UTC)[回覆]

目前這個版本的DP9的始作俑者是我，我就出來說明一下為什麼當初要改成這樣。1、有些模板只subst使用；2、有些模板只通過腳本、api等外部方式調用；3、有些模板對大量歷史頁面的歷史完整性起到正面作用。原來的條款是「多餘無用的模板即可刪除」，但是其實上述三種情況不應該屬於多餘無用，所以即使按照原來的刪除守則，也不應該刪除。在實際操作中，有的模板單純因為沒有連入就被提刪人和管理員共同認定為多餘無用，這是不對的。改成這樣就等於強調了一下請不要這麼做。其實呢，如果你能保證上述三種情況都不發生，也就是「真·多餘無用」的模板，那麼我為什麼要關心他刪不刪除呢🐶？我不關心。但是我認為你永遠無法做到證明一個模板的「真·多餘無用」性，維基百科的刪除又沒有任何技術上的好處比如節省磁碟，所以不珊少刪我認為是最合理的，就改成了現在的樣子。當然我現在的看法其實也沒有改變，我希望維持目前的條款。Bluedeck 2024年3月31日 (日) 08:09 (UTC)[回覆]

其實我在相關的AFD也有提到過當時把DP-9改成現版本並沒有有效的討論共識支持，而且現版本的寫法也顯然超出了Bluedeck上方提到的設想（雖説我自己不認同他的第三個設想是保留模板的理由），我質疑現版本的寫法的正當性。Sanmosa Gloire d'Yser 2024年4月1日 (一) 02:19 (UTC)[回覆]
說得基本有道理。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月10日 (三) 03:10 (UTC)[回覆]

參考資料

  1. ^ 我並不是要說我寫這個很辛苦，評級案因為最辛苦的環節不在這（如編程Module:PJBSClass/page等），而是在手工移動上千個分類的那個步驟。舉這粒只是借題發揮，認為不該所有廢棄模板/模組/程式腳本都該刪除，而是有些應可作歷史保留，尤其是檢視歷史後還會看到的那一種

更新版修訂案

TFD的具體細節似乎還存在着一定的爭議，因此這裏僅保留上方修訂案中修改Wikipedia:刪除方針的部分，並作為獨立提案：

現行條文

9. 多餘無用，且影響其他模板命名或者百科運作的模板

提議條文

9. 多餘無用且影響其他模板命名，或影響百科運作的模板

以上。Sanmosa Szégyen a futás, de hasznos 2024年4月11日 (四) 16:04 (UTC)[回覆]

@A2569875 @SunAfterRain @Sanmosa @A1Cafel 本人突發奇想，想到了一個讓雙方都能容易接受的方案：
  • 廢棄，而且沒有任何價值的模板/模組可以進行刪除。
  • 廢棄，但有價值的模板/模組可以考慮不留重新導向移動至某頁（Wikipedia:已刪除的模板存檔？）的子頁面，以進行存檔。
  • 廢棄，但有價值，而且有需要完善歷史修訂的模板/模組可以進行存檔，但保留Template->Wikipedia的跨命名空間重新導向。
以上方案不但保留了用戶應有的勞動成果，也可以儘量避免廢棄模板誤用的問題（至少我不會覺得礙眼的），一舉兩得。鐵膠壹名 2024年4月15日 (一) 10:57 (UTC)[回覆]

提議提高條目評選投票資格門檻

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:新條目推薦/候選。

如題，本站以前曾有過不黯規則的新手未有詳細檢查條目（雖然是說這樣的老手也好幾個，嗚呼哀哉）即在GAC、FAC投下符合標準（Special:Diff/81702620），敝人認為應該將GAC、FAC、FLC投票資格統一由原先的「編輯註冊7日且編輯次數達50次的用戶／自動確認用戶」改為延伸確認用戶。畢竟即使很多老手都沒有能力評選條目（就不點名了），相較之下認為「編輯註冊7日且編輯次數達50次的用戶」顯然不可能有評選能力，只有這樣的經驗顯然不適合評選放在維基百科門面的條目。--Sean0115 2024年3月31日 (日) 04:58 (UTC)[回覆]

支持提升GAC、FAC、FLC三者的投票者標準。不過可以的話是否也能提升下DYK投票者的標準，目前僅需自動確認用戶的標準未免有些過低。--人間百態,獨尊變態(討論) 2024年3月31日 (日) 05:33 (UTC)[回覆]
DYK個人覺得可以提升至XCON。近期有不少傀儡案件都是透過發現DYK的大量灌票而提報（見Wikipedia:傀儡調查/案件/Maccomcre/存檔、Wikipedia:傀儡調查/案件/Cq521/存檔、Wikipedia:傀儡調查/案件/PoisonHK/存檔）。GAC、FAC、FLC我認為雖然這三類評選還沒到「壞掉」的程度，但確實有許多評選上可以改善的地方，或特許以從其他方面着手而不是單純提高門檻。
不過在DYK個人覺得急需提升至XCON的情況下，把GAC等較高級的評選維持AUTOCONFIRM確實有些反直覺。這方面（GAC、FAC、FLC三類）或許需要更多討論。--（☎）dt 2024年3月31日 (日) 07:49 (UTC)[回覆]
話音剛落就有人來DYKC搗亂了，望社群能正視這個問題--Sean0115 2024年3月31日 (日) 14:58 (UTC)[回覆]
感覺意義有限。未必沒有評選能力，要看理解程度和花費時間，完全的維基新人如果了解條目主題，也可能給出有價值意見。或者格式、內容、來源等分開評審和發表意見（以及最終公示期？），或者某些短意見或者較新用戶算半票。以上只是想法，不構成建議。--YFdyh000（留言） 2024年3月31日 (日) 06:23 (UTC)[回覆]
抑或者只能投反對而不能支持？只是個概念，畢竟主要是希望避免亂支持造成不合格條目通過。—Sean0115 2024年3月31日 (日) 11:03 (UTC)[回覆]
不能完全排除新用戶故意或在不明就裏的情況下投反對票的情形（比如上面提到的Maccomcre）。Sanmosa Gloire d'Yser 2024年3月31日 (日) 15:56 (UTC)[回覆]
您提議的內容是不是就是我屢次提議但是社群不肯接受的評審制？--a'4 d8 e8 a'4 g'4 a'4 g'8 e'8 a'2 2024年3月31日 (日) 21:43 (UTC)[回覆]
「抑或者只能投反對而不能支持」——其實就類似於DYKC最早期用過的規則：「如果有人提出異議且其異議受到其他人的認同覺得推薦有點不妥時，5天以後如果反對意見佔多數，則應該撤下這個條目」，當年的DYKC基本上是不用支持票的。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年4月1日 (一) 07:11 (UTC)[回覆]
您要找的是不是，五分之三妥協或者OpenReview？--MilkyDefer 2024年3月31日 (日) 11:56 (UTC)[回覆]
提高投票資格能治到幾多水票先不談，畢竟都說了很多老手也是亂投的；不過能夠令傀儡偽造投票的成本和難度大幅增加（時間和次數都增加了至少十倍），即使仍是治標不治本，但還是樂見的。至於老手亂投支持的問題，我以前提過了這麼的一個設想：「有一種情況倒是可以明顯揪出來：見Talk:全國土地日，裏面投支持票的明顯連歷史也沒有看（別說這還可以假定有看，有看的話無可能連條目不夠長也不知道；也別告訴我評選不用看歷史，基本推薦資格部份規則與條目歷史有關，所以投票人有責任看歷史），也特許以從這方面入手——諸如當被宣告取消資格時，投了支持票的人會被視為亂投票，當亂投票達到若干次後須在某一期限內被暫停投票權」，就看這個設想這次能不能拋磚引玉了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年4月1日 (一) 07:22 (UTC)[回覆]
我對於「暫停投票權」的設想有些抵觸，這讓我想起了「剝奪政治權利（終身）」。Sanmosa Szégyen a futás, de hasznos 2024年4月1日 (一) 09:55 (UTC)[回覆]
新人來的時候是一張白紙，根本不知道評選是何物。老手按en:WP:FAC的程度來提意見，新人模仿不出來，那自然不會隨便發言。但現在評審頁是清一色的* {{yesFA}}--~~~~，那新人可不有樣學樣？--For Each element In group Next（留言） 2024年4月4日 (四) 12:40 (UTC)[回覆]

分段：DYK

由於前段提到的近期DYK遭遇大量傀儡投票問題，個人認定提升DYK投票門檻具有較高急迫性，故拆出此段以促盡速商議。

現行條文

投票須知

  • 投票者須於投票發起時已為自動確認用戶。不可投票予自己主編之條目。
  • 投票者請使用**號，而不要使用*號或#號，以保持版面清晰美觀。
  • 投票者只可用{{支持}}、{{反對}}（或{{support}}、{{oppose}}）進行投票，動用到自訂參數修改預設顯示文字的模板不計票。可用其他模板作為引子來表述觀點。
  • 若在投票結果確認後投票或發表意見，請同時清空DYKEntry模板的result參數，以免影響自動更新。
  • 關於投票的有效性，請參考上方「獲選標準」中，「關於投票的有效性，採取下列規定」的文字。
提議條文

投票須知

  • 投票者須於投票發起時已為延伸確認用戶。不可投票予自己主編之條目。
  • 投票者請使用**號，而不要使用*號或#號，以保持版面清晰美觀。
  • 投票者只可用{{支持}}、{{反對}}（或{{support}}、{{oppose}}）進行投票，動用到自訂參數修改預設顯示文字的模板不計票。可用其他模板作為引子來表述觀點。
  • 若在投票結果確認後投票或發表意見，請同時清空DYKEntry模板的result參數，以免影響自動更新。
  • 關於投票的有效性，請參考上方「獲選標準」中，「關於投票的有效性，採取下列規定」的文字。

--（☎）dt 2024年4月1日 (一) 03:45 (UTC)[回覆]

如果只就Wikipedia:傀儡調查/案件/Cq521類似的案例的話，這幾乎沒啥作用，例如舉例的三個帳號都有延伸確認的，然並卵（也就是預謀已久的傀儡是很難擋住的）。我認為還是針對支持者是否有仔細核對條目來判斷或者指正可能有所效用。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月1日 (一) 08:44 (UTC)[回覆]
目前比較容易發現的是在已經有人提出合理且明確的反對意見，卻仍然莫名其妙投支持的人（還不少呢）。這種人不應該有資格投票，但實行什麼又怕會有寒蟬效應。--Sean0115 2024年4月1日 (一) 10:38 (UTC)[回覆]
本來任何硬性措施就是沒有辦法避免預謀已久的傀儡。雖然可能有個別案例是農到了延確，不過（起碼另外兩個列出的case）就大多數狀況來說把投票資格提升至延確還是有一定的效果。
當然之後也可以再討論要不要把延確標準再往上拉，不過那大概又要再開一個串了。--（☎）dt 2024年4月1日 (一) 17:28 (UTC)[回覆]
這個方案不一定有實際效果，一是你維在DYK灌水票中有不少是延伸確認用戶，二是那些濫用傀儡的人（比如Elmond、CQ521）很多都把自己的傀儡養到滿足延伸確認用戶。——Aggie Dewadipper 2024年4月2日 (二) 03:15 (UTC)[回覆]
我持(－)反對意見，自動確認的門檻很低了，如果是「延伸確認」，門檻更高，不能說提高門檻就能解決問題了。關鍵是看用戶素質怎麼樣了。--Shwangtianyuan 不忘初心 牢記使命 2024年4月2日 (二) 16:13 (UTC)[回覆]
重點是就算某用戶素質不怎麼樣還是可以投票，即是說就算知道他的素質也不能改變什麼。--Sean0115 2024年4月3日 (三) 00:32 (UTC)[回覆]
只能說水支持票是DYK的一部分，或者自認為覺得條目不好不想讓它上卻被其他編輯抬了上去而感到不滿，不服別玩。應該考慮的是：如何避免類似這個案例的長久準備作案傀儡問題、還有如何正確地提出自己的條目質量評價意見來說服別人「這個條目不值得上DYK」。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月3日 (三) 00:37 (UTC)[回覆]
對於此類提案是否能有效處理提案欲處理的問題持悲觀態度。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 07:55 (UTC)[回覆]
可以考慮提升部分評選至延伸確認用戶。新條目推薦候選的話，門檻或維持較好。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月11日 (四) 16:32 (UTC)[回覆]
支持該次修訂。本來這次修訂的目的就不是為了根治評選中出現的濫用投票問題，而是為了讓那些大部分情況下根本不懂如何審評條目的用戶無法進行投票。我們不排除會有自動確認用戶給出有價值的意見，但就目前而言這樣的用戶十分少見，也不能因為可能有給出有價值意見的自動確認用戶，而去忽視目前評審中出現的大量來自自動確認用戶的「水票」--人間百態,獨尊變態(討論) 2024年4月12日 (五) 14:28 (UTC)[回覆]
  • 建議提出有效的反對意見並掛模版。如果這樣依然不夠，可考慮修改DYK規則，進一步增強合理反對票的力量。--Temp3600（留言） 2024年4月12日 (五) 19:21 (UTC)[回覆]
    • @Temp3600：那就會有人在投票結束前的十幾分鐘前來投「強化反對票」，不但讓編者根本沒時間反應，沒時間改，還害整個評選失敗被要整個重來，甚至還會因為討論被關閉了，無法進一步地與反對者商討有關意見的條目改善方案（因為評選討論會馬上變成「這個投票已經結束，請不要對這個提名做任何編輯。」）。我就被這樣噁心到了Talk:大小#未通過的新條目推薦討論、User_talk:A2569875#大小（由User:FradonStar留言，「被噁心到了」這一詞是我從這裏學來的，之前不知道有此詞彙用法）。我擔心「進一步增強合理反對票的力量」會出現大量的這種擦邊球，讓人被噁心到了，情緒上來，完全無助於改善條目。故認為「強化反對票」可能對「有效地改進條目」可能有負面效果。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月12日 (五) 22:47 (UTC)[回覆]
      的確有這個可能，但理論上應該不多。因為DYK規則是"基本投票期為4天。待至基本投票期屆滿時，如獲得中選所需的最低票數或以上，投票即會結束並獲通過；否則，投票期將自動延長3天，並待至延長投票期屆滿時方為結束投票"，所以如果是首4天內被投下反對票，投票期會自動延長。如果想解決7天評選期結束前吃反對的問題，可以改規則，容許在6-7天被反對的條目可以再獲得幾日的修改期。DC實際上就採用了這種"截止報名但容許修正"的方法。--Temp3600（留言） 2024年4月13日 (六) 18:12 (UTC)[回覆]
(－)反對，中文維基百科僅有不足5000名延伸確認用戶，為傀儡一事而影響其他（可能有上萬名）用戶的自由是不應該的。而且，正如其他用戶所說，這樣並不能從本質上解決問題。
[[User:WiiUf|WiiUf{{colour=green¦}]]（留言） 2024年4月16日 (二) 14:18 (UTC)[回覆]


要先討論清楚問題，才能對症下藥:

  • 問題是"傀儡刷票": 提高門檻以阻止養傀儡，重罰刷票者
  • 問題是"新人/老的"新人"濫投支持票":提高反對票的票效，令支持票再投也沒意思，並最終過渡到評審制
  • 問題是"沒人願意投反對票，害怕開罪其他編輯":這個是最難解決的問題，即所謂"人情票"。我覺得只有引入匿名發言制度才有解。
  • 以上。--Temp3600（留言） 2024年4月13日 (六) 18:19 (UTC)[回覆]

享年歲數究竟是需要來源還是可以被視為「簡單計算」的結果？

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:非原創研究、WikiProject talk:傳記。

享年，即一個人到底活了多少歲（多少年），目前社會上有很多不同的計算方式，有嚴格把不足年的部分全部捨棄掉的；有不過半年舍掉過半年進位的；有一律進一歲的；甚至有生活在一個紀年過就一律算一歲的（這樣可以頭尾各多算一歲，對於有些人來說比第一種計算法多了兩歲）。 目前維基百科自己的模板自動計算的享年歲優先使用第一種去尾法，對於生卒具體日期不全只有年份的才使用第三種，但是很多社會人士死亡後媒體會大量採用二至四的計算方法。 我個人編輯習慣是碰到上面這種人，如果有生卒年月，一律按第一種方法自行計算，而不在乎來源，但是有人對我提出過異議，認為如果媒體的報道採用了別的計算方法的歲數，應該尊重來源。 但是，享年似乎也可以被視為是對基本數學事實的簡單計算，而現行方針簡單計算內容一律不需要來源。 那麼，在中文維基百科，我們究竟是應該把享年一律統一為簡單計算退一法，還是尊重來源報道，還是什麼別的呢？--a'4 d8 e8 a'4 g'4 a'4 g'8 e'8 a'2 2024年3月31日 (日) 21:40 (UTC)[回覆]

為什麼會出現一個一定程度上有名的人，只知道生卒年但不知道時期的情況？可否勞煩舉幾個例子？ --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月2日 (二) 15:40 (UTC)[回覆]
如果我沒理解錯，魔女是指某些注重私隱、僅讓公眾知曉自己幾歲而沒告知準確出生日期，從而站內只有推算出來的出生年的情況。另外歷史人物有些也有這個問題，只知道生卒年，不知道何月何日生、何月何日死。
推算出生年尚算是簡單計算，比如2024年初說自己23歲的人可以是2001年或2000年生，寫「2000–2001年生」是合理的（並應附註來源）；但計算享年歲時，不知道何年生，只知道何年何月何日死，內文就僅標註「可能的出生年」和死亡日期，只在資訊框寫如「79–80歲」等字樣。
如果本身已經有存在來源佐證的生卒日期，那麼享年歲應以簡單計算為準，不應參照來源；若本身無出生年，則應按來源寫享年歲多少，但不能用「簡單計算」去推算出生年（華人很愛過世時多加一兩三歲）。--路西法人 2024年4月3日 (三) 09:24 (UTC)[回覆]
我腦中能立刻想到的人只有卡爾·拉格斐，雖然最後還是公開，但好歹曾是。　--窩法乙烷 兒法夢碎 2024年4月11日 (四) 13:26 (UTC)[回覆]

進一步增修封鎖方針以及建立封鎖申訴的本地共識

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:封鎖方針。

User:LuciferianThomas（路西法人，或稱路君）於2023年3月提出了封鎖方針的重大修訂，儘管方針大部分內容引自英文版方針。

在2024年2月我因不當行為被不限期封鎖之後（不到兩天被解封），有用戶在我討論頁評論的時候仍把「不限期封鎖」稱為「永久封鎖」，這明顯違背了「不限期封鎖」方針所制定的目標「不代表該封鎖永恆不可變」。而我被封的時候也看到了路君的回覆，也是自此時開始即對封鎖方針進行了重新翻閱，又看了英維里的方針，發現有部分方針內容是需要改進的，尤其是「不限期封鎖」方針需要進一步修訂，畢竟「永久封鎖」的說法在英維里早就被「否定」了。

結合當前情況考慮，我提議對封鎖方針的部分內容作出增修，重點修訂「不限期封鎖」方針，同時新增「請求封鎖」方針以及修訂「解除封鎖」方針（小修改）。另外我提議建立封鎖申訴的本地共識。以上工作的目的是，填補過去中維在封鎖方針指引上的漏洞，讓相關方針指引如同英維一樣健全，將封鎖方針指引更加程序化、系統化。提議共四條（章節），請大家分章節討論，謝謝。

還有必要稱呼「永久封鎖」嗎？

現行條文

不限期封鎖（或稱永久封鎖）是指無失效時限的封鎖，通常用於防止嚴重擾亂維基百科正常運作的行為或嚴重違反維基百科方針指引的行為。不限期封鎖或適合用以阻止持續的不當行為，但仍需注意同樣不是作懲罰之用。不限期封鎖並不代表永恆不可變，而僅代表未有訂立封鎖時長，封鎖不會自動過期解除。被不限期封鎖的用戶在合適的情況下可獲解除封鎖，並在讓其被觀察的情況下繼續編輯，以確保該用戶未來不再違反維基百科的不同規範。

提議條文

不限期封鎖是指無失效時限的封鎖[1]，通常用於防止嚴重擾亂維基百科正常運作的行為或嚴重違反維基百科方針指引的行為。不限期封鎖或適合用以阻止持續的不當行為，但仍需注意同樣不是作懲罰之用。

另需注意「不限期」不應理解為「永久」，即不代表該封鎖永恆不可變，而僅代表未有訂立封鎖時長，封鎖不會自動過期解除。被不限期封鎖的用戶在合適的情況下可獲解除封鎖，並在讓其被觀察的情況下繼續編輯，以確保該用戶未來不再違反維基百科的不同規範。但在特別嚴重的情況下，如無管理員願意解除封鎖，該用戶實際上已被社群禁止編輯。

參考資料

  1. ^ 無失效時限的封鎖曾稱為「永久封鎖」；因與實際意義不相符而在2023年3月修訂方針後改為現稱。過往稱「永久封鎖」者應理解為「不限期封鎖」，相關封鎖同樣非「永久不可變」。詳見§ 不限期封鎖一節的第二段。

在路君修訂「不限期封鎖」方針之前，封鎖方針關於「永久封鎖」的方針內容如下：

永久封鎖是一個永不失效的封鎖。永久封鎖通常用於防止嚴重干擾或威脅維基百科正常運作的行為，或嚴重侵犯維基百科政策的行為。這能避免該用戶的行為產生更多的問題。 對於社群來說，永久封鎖一個用戶可被理解為完全禁止該用戶進行編輯（如無管理員解封的話）。但在一般情況下，我們建議給該用戶一個最後機會——在某段時間暫時解封該用戶，並在被觀察的情況下繼續編輯，以確保該用戶未來不再違反維基百科的政策。

雖然修訂後已將其更名為「不限期封鎖」，但條文中仍提到「或稱永久封鎖」。2024年2月我被無限期封的時候，也一直以為就是永久封鎖，永遠不給解封了。按照方針所述「不限期封鎖並不代表永恆不可變，而僅代表未有訂立封鎖時長，封鎖不會自動過期解除」，另外用戶確有反省不再違規的話是可以解封的。因此，嚴格來說「永久封鎖」這個說法不妥當，這會對用戶造成誤解，而且這是前後矛盾，模稜兩可。而且「永久」和「不限期」本身意思和真實語景應用中有很大區別（大家可以上網搜尋）。在英文版方針中有一句話直接「否定」其為「永久封鎖」：

Indefinite does not mean "infinite" or "permanent"

意思就是，「不限期」不應理解為「無限」或「永久」。但基於中文語境情況，我提議修訂的條文改為「不應理解為『永久』或『終身』」。

同樣，我在英文版的封鎖申訴指引也找到了這一句話：

"Indefinite" does not necessarily mean "forever" or "infinite". It means "however long is needed for the user to address the issue". This can be minutes, hours – or indeed the user may never do so.

意思是，「不限期」不一定是「永久」或「無限」。其意思是「用戶需要多長時間來解決問題」。這可能是幾分鐘、幾小時——或者實際上用戶可能永遠不會這樣做。

為了避免對其他用戶造成進一步的誤解，我提出修訂建議，參照英維的方針作進一步修訂，具體提議內容見上。--Shwangtianyuan 不忘初心 牢記使命 2024年4月2日 (二) 16:08 (UTC)[回覆]

支持修訂。不贊成「終身」，非「無限」就足夠了。--YFdyh000（留言） 2024年4月2日 (二) 16:34 (UTC)[回覆]
不反對如此修訂。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 07:48 (UTC)[回覆]
我在文內保留括號（或稱永久封鎖）是基於讓後來的人能再檢視前人所說「永久封鎖」是什麼意思，如果連括號都容易造成誤會，那麼也請改成註釋，寫例如無失效時限的封鎖曾稱為「永久封鎖」；因與實際意義不相符而在2023年3月[[Special:Diff/XXXXXX|修訂方針]]後改為現稱。過往稱「永久封鎖」的意思應視同「不限期封鎖」之意，同樣非「永久不可變」；詳見§ 不限期封鎖一節的第二段。這樣。
另外我記得當初我決定寫「不限期」而不是「無限期」是因為後者中的「無限」容易誤導他人以為是「infinite」的意思。我不清楚YF的意思是怎樣，但提案人所列出「不應理解為終身」我認為是相當合理的。--路西法人 2024年4月3日 (三) 09:36 (UTC)[回覆]
個人不反對註釋化處理，@Shwangtianyuan、YFdyh000。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 10:25 (UTC)[回覆]
可以。只是不贊成引入「終身」用詞，封鎖是針對帳號而非訴諸人身的，雖然禁止繞過封鎖。--YFdyh000（留言） 2024年4月3日 (三) 11:10 (UTC)[回覆]
文內正是說「不應理解為終身」，本來就是說「不是」，不知道你是在反對什麼……？--路西法人 2024年4月3日 (三) 15:03 (UTC)[回覆]
有時封鎖的是帳號（對於用戶名違規），身更接近實體，不想將此概念混入。如「不應理解為終身」可能理解為有期限的封鎖身。--YFdyh000（留言） 2024年4月3日 (三) 16:06 (UTC)[回覆]
「不應理解」ABC不等於「可以理解為」DEF。「不應理解為終身」本來就只有「不應理解為終身」的意思，任何其他理解都是超譯，不需考慮。--路西法人 2024年4月4日 (四) 12:40 (UTC)[回覆]
標註註釋的話應該沒什麼問題，雖然它並不一定是永久性的。--Shwangtianyuan 不忘初心 牢記使命 2024年4月3日 (三) 14:58 (UTC)[回覆]
根據上述意見於2024年4月4日 (四) 05:43 (UTC)代為調整提案。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 05:43 (UTC)[回覆]
基本上認可修訂後的提案。--Shwangtianyuan 不忘初心 牢記使命 2024年4月4日 (四) 14:04 (UTC)[回覆]

新增「請求封鎖」方針

參照其他專案及其他語言版本的封鎖方針，提議新增「請求封鎖」方針，內容在「不適用封鎖的情況」之後，「封鎖指導」之前，以此將封鎖方針更為程序化。具體如下：

用戶可以在當前的破壞頁面或者在管理員佈告板/其他不當行為頁面請求封鎖，請求的同時亦應提供充分的證據，但管理員有權拒絕執行被請求的封鎖，並可以進行獨立的調查。在實施封鎖之前，管理員應當充分熟悉具體情況。參見解釋封鎖原因。

待方針通過後，建立快捷方式WP:BLOCKREQUESTS和WP:BLOCKREQ。--Shwangtianyuan 不忘初心 牢記使命 2024年4月2日 (二) 16:08 (UTC)[回覆]

原則上支持。提供充分的依據是否更好，證據不能覆蓋方針，理據不能覆蓋證據。「被請求的封鎖」稱「封鎖請求」就好。未理解「並可以進行獨立的調查」的強調原因，何為獨立的調查，是獨自調查還是能發起單獨調查、詢問或徵詢，有無具體要求。--YFdyh000（留言） 2024年4月2日 (二) 16:34 (UTC)[回覆]
同YFdyh000。除此以外，我覺得AN3是否屬於潛在可請求封鎖的場所也值得探討。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 07:53 (UTC)[回覆]
贊同，但應避免直接列出對應頁面，始終理論上什麼地方都可以用來請求封鎖：例如社群在客棧達成封鎖某名用戶的共識，也是一個非常邊緣但完全合理合規的請求封鎖模式。提案人可考慮將擬新增條文中列出頁面的位置改成「用戶可於適當的佈告板上提出封鎖請求」。
YF所指也是應當參考，可以考慮改成「須附上清晰理據，例如用戶違反了什麼方針指引、如何構成不當行為等。」（後面不需要「但」管理員了，這個轉折似乎沒太大必要。）
我建議可以改成這樣：
用戶可於適當的佈告板提報不當行為，並必須附上清晰理據，例如用戶違反了什麼方針指引、如何構成不當行為等。管理員在接獲提報時應自行複檢提報所列理據是否有效，並在符合本（封鎖）方針規定下執行封鎖。若管理員認為提報有問題（如不符合實際情況、不符合方針賦予管理員封鎖的情況），則有權拒絕提報。--路西法人 2024年4月3日 (三) 09:46 (UTC)[回覆]
基本接受閣下的方案，沒什麼問題。反正，報告請求就是需要提供有效、足以證明的證據，證據不足或者不符合的都應予拒絕。--Shwangtianyuan 不忘初心 牢記使命 2024年4月3日 (三) 15:00 (UTC)[回覆]

修訂「解除封鎖」方針

模板第二次機會是重新贏得社群信任的一種手段，主要針對過往有破壞、擾亂性編輯的用戶。但中維因為方針沒有提及，導致此模板一次都沒用上。我在這裏也是提議引入英維的方針，將「第二次機會」成為本地方針。具體內容如下：

如果用戶聲稱希望做出建設性貢獻，但管理員對其承諾存在疑問，則可以使用{{第二次機會}}模板作為解除封鎖的條件，來展示用戶將如何為百科全書做出貢獻，以此相信用戶提出的修改能夠幫助維基百科。

擬引入的方針待通過後，提議加入於「封鎖申訴」一節，在「任何用戶均可參與……」之前。--Shwangtianyuan 不忘初心 牢記使命 2024年4月2日 (二) 16:08 (UTC)[回覆]

這個想法很好。雖然我對被封鎖者重新寫的條目的質量很不樂觀，但至少讓他們審視一下自己寫的條目也是好的。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 03:52 (UTC)[回覆]
不反對如此修訂，我不清楚PoisonHK算不算一個例子。另外，建議將「聲稱」改為「聲明」，中文裏「聲稱」通常伴隨着負面的用法，在中性的行文裏用可能不太合適。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 07:49 (UTC)[回覆]
這不錯啊。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月4日 (四) 15:45 (UTC)[回覆]
(＋)支持。--冥王歐西里斯（留言） 2024年4月11日 (四) 09:58 (UTC)[回覆]

公示

依照WP:共識#提案討論及公示時間，互助客棧中的提案僅在7日內無新留言時或已討論達30日後，方可在已取得共識的前提下公示，其中「新留言」不包含不對提案進行實則性點評的意見。有鑒於此討論串中最近一個對提案進行實則性點評的意見在2024年4月4日 (四) 14:04 (UTC)發表，此處已滿足公示的條件，故現公示上述3個提案7日。Sanmosa Szégyen a futás, de hasznos 2024年4月11日 (四) 15:58 (UTC)[回覆]

建立封鎖申訴的本地共識

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:封鎖申訴。

早在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)[回覆]

我想問下 草稿可以儲存 疑似侵權的內容嗎

個人主頁的草稿 或者條目的草稿--此條未正確簽名的留言由阿俊2018（討論｜貢獻）於2024年4月4日 (四) 12:07 (UTC)加入。[回覆]

不可以。--MilkyDefer 2024年4月4日 (四) 13:46 (UTC)[回覆]
不可以的。根據方針，只有「該條目沒有侵犯版權的內容」的情況下才可以放在草稿。如果有侵權內容最好還是移除。--FK8438（留言） 2024年4月7日 (日) 07:03 (UTC)[回覆]
複製有版權的內容無論存到哪裏都是侵權行為，即便只是存到自己的電腦上。--桐生ここ★[討論] 2024年4月7日 (日) 11:08 (UTC)[回覆]
「複製有版權的內容無論存到哪裏都是侵權行為」——大部分內容都允許個人目的使用（例如），但是維基百科要求內容必須可以無償商業使用。--GZWDer（留言） 2024年4月17日 (三) 13:16 (UTC)[回覆]

共識建立的遞進步驟

本主題全部或部分段落文字，已移動至Wikipedia talk:共識。執行人：路西法人 2024年4月9日 (二) 08:11 (UTC)。[回覆]

有關社羣討論所需的文明程度的疑問

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:文明。

雖説WP:文明#杜絕不文明行為所列舉的那些不文明行為我自己是能完全不碰的，但我還是想知道社羣對於社羣討論中所需的文明程度的最低限度到底在哪裏。這個問題不針對任何單一事件，因為能被我問這個問題的人不止一個。Sanmosa Szégyen a futás, de hasznos 2024年4月9日 (二) 15:01 (UTC)[回覆]

（我知道這個問題不針對任何單一事件，但以下是我根據最近的一些討論存在的一些想法）
如討論串中沒有人來擾亂討論，或者管理員願意處理擾亂討論的人的情況下，又或者社群健全能夠實行社群禁制自行踢出擾亂討論的用戶時，則應當遵循文明準則。（注意這句話並沒有說明什麼時候不遵循文明準則是合適的）
然而目前的情況是管理員不願意插手管理擾亂討論的人，也不願意去管有不文明行為的人。沒有社群禁制也間接導致社群在這方面沒有話語權。也許管理員插手操作了一些社群不覺得需要被操作的人，社群可以抗議然後RFDA然後怎麼怎麼，但是如果管理員不願意插手操作一些社群覺得需要被操作的人，社群有辦法逼管理員來管嗎？很顯然是沒有的。
當有人長期擾亂討論而沒有人願意管這些人的時候，只去追究相對而言造成的損傷很小的不文明行為是對社群沒有幫助的。
回到我第一段的說法。為什麼我要給遵循文明準則加上前提呢？當有人不尊重規矩，而又沒有辦法使這個不尊重規矩的人得到應得的後果的話，這是系統的無能。若有人殺了人，而不受到懲罰，這是司法系統的無能。而在司法系統無能的情況下，個人或者小團體所執行的「正義」則在一定程度上更被人接受。某人很喜歡用殺人來做比喻，那麼我也來比喻一下：若一個在逃殺人犯被你碰見，那麼你會選擇殺了他嗎？這個社群的大多數人見到這種「在逃殺人犯」估計都會先逃跑自保吧。又或者說，如果你真的殺了這個在逃殺人犯了之後，難道大家應當就把你完完全全也當作一個殺人犯來看待嗎？你也應當同樣面對殺人的罪行嗎？我不是律師，我不懂。
換一個比喻吧。當你知道有一個人在考試上多次作弊，而每次檢舉他作弊卻沒用。而你正巧和他分配到一個團隊專案。也許你會因為對他的看法，在專案的一些地方故意讓他難堪。那麼這是好的團隊精神嗎？這明顯不是的。而老師應當先懲罰你，繼續無視考試作弊的學生嗎？這就不對了。所以我的想法是，我們在這裏更應該討論的是如何處理作弊的人，而不是問大家團隊精神應當是什麼樣子的。
最後的最後，我的這些想法絕對不是在為不文明行為找藉口，如果有人讀到現在還沒能理解這一點的話，那麼要麼是我語文不好，要麼是讀者語文不好。--0xDeadbeef (留言) 2024年4月9日 (二) 15:49 (UTC)[回覆]
@0xDeadbeef：容我追問（有可能不是唯一一次追問）：「輕率魯莽地指控他人行為不當」、「輕蔑其他編輯」與「譏諷他人或誘使他人作出不文明行為」這三種不文明行為在甚麽時候同時屬於擾亂討論的行為？結合傾向性編輯或WP:FORUMSHOP的情況算嗎？Sanmosa Szégyen a futás, de hasznos 2024年4月9日 (二) 16:07 (UTC)[回覆]
這個我需要上下文。我無法沒有看到實際情況下分辨哪些屬於擾亂哪些不屬於擾亂。但是我覺得更重要的是哪些行為對社群的危害更大，擾亂影響更具有傷害力，哪些人浪費其他編者時間最多，這些才是我們應該注意的。（請隨意追問，沒問題）--0xDeadbeef (留言) 2024年4月9日 (二) 16:13 (UTC)[回覆]
@0xDeadbeef：那我用email和你説吧，就我給的事例你用email回應即可。Sanmosa Szégyen a futás, de hasznos 2024年4月9日 (二) 16:31 (UTC)[回覆]
「輕率魯莽地指控他人行為不當」、「輕蔑其他編輯」與「譏諷他人或誘使他人作出不文明行為」至少這些罪行還是比較具體的，反而「擾亂」這個罪行過於模糊，從提問裏面看出你自己也是不太吃的准。--日期20220626（留言） 2024年4月10日 (三) 01:44 (UTC)[回覆]
「擾亂」本身是一種「口袋罪」，在用以指控他人時一般來說應有非常具體定義（如上面指出幾種細分方法）。我想單純用「擾亂」當理由決定一大堆事情很難說得過去。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月10日 (三) 03:09 (UTC)[回覆]
不知道你從哪裏看出有人要單純用「擾亂」當理由來決定一大堆事情的。--0xDeadbeef (留言) 2024年4月10日 (三) 03:45 (UTC)[回覆]
這裏祇是假設一種不甚好的情況（或許應該加個「若」），不涉及具體案例。實際上其他管理員過往也偶有運用「擾亂」作為制裁的兜底手段，但一般來說都會提供額外理據，就如您下面所言者。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月10日 (三) 08:14 (UTC)[回覆]
抱歉，作為英維管理員，我自認在分辨什麼是擾亂上還是吃得準的。當然，要是我在描寫封鎖理由的時候，當然不會只填「擾亂」。--0xDeadbeef (留言) 2024年4月10日 (三) 03:44 (UTC)[回覆]
如果你真的殺了這個在逃殺人犯了之後，你自然也是殺人犯，你也應當同樣面對殺人的罪行，你不是法官也不是執法人員，殺人犯應經審判而非私刑。法律上你遇見殺人犯可以做的事情就是：1、報警。2、為防止他逃跑而限制他的自由，然後報警，但你不能殺他。3、對方要殺你或攻擊的情況下才屬於正當防衛，但你也只能以阻攔或自保為目的而攻擊他，不能殺他，也不能對方停止攻擊後你還手，否則是防衛過當或不屬於正當防衛。--桐生ここ★[討論] 2024年4月10日 (三) 11:14 (UTC)[回覆]
應該說，別人犯罪不是你跟着犯罪的藉口，WP:別跟着闖紅燈，法律上就是要你報警而不是自己行動。更何況其實辱罵、侮辱在現實世界真的也屬於違法或犯罪，不論在中國大陸、澳門、台灣等都有此規定。--桐生ここ★[討論] 2024年4月10日 (三) 11:33 (UTC)[回覆]
我覺得你沒看懂我的意思。若需要面對殺人的罪行是殺了殺人犯的你，這其實體現了司法系統的無能。按理來說，遇上在逃殺人犯的概率是非常小的，因為在這裏討論的大多數人都居住於有健全司法系統的地方。你所說的防止他逃跑而限制他的自由，然後報警仍然是建立在司法系統是健全的這個前提上的。你必須先接受「報警有用」這個假設。若報警無用呢？--0xDeadbeef (留言) 2024年4月10日 (三) 14:16 (UTC)[回覆]
我懂了，那這還真是問題。不僅要容許一定的「自救行為」（不文明），也需要解決司法系統無能的問題，不知道仲裁委員會能否解決。--桐生ここ★[討論] 2024年4月10日 (三) 15:30 (UTC)[回覆]
但願如此。--0xDeadbeef (留言) 2024年4月10日 (三) 15:35 (UTC)[回覆]
但也有人自己去攻擊意見不和的人，然後就找各種藉口為自己的不文明行為開脫，但找的藉口和他的不文明行為都沒什麼關係。--日期20220626（留言） 2024年4月10日 (三) 22:59 (UTC)[回覆]
我很期待你能舉出一個具體的例子出來。--0xDeadbeef (留言) 2024年4月11日 (四) 01:42 (UTC)[回覆]
規則永遠無法防範善於研究規則漏洞，然後繞過規則的人，即使規則做得再細緻也是一樣，對付這類人的唯一方法就是由勇敢的管理員實施WP:IAR式的封鎖。--高文海（留言） 2024年4月10日 (三) 08:47 (UTC)[回覆]
我實際上是真的想問社群到底能忍讓多大程度的「不文明」，而不是想要藉這個問題來「堵漏洞」。Sanmosa Szégyen a futás, de hasznos 2024年4月10日 (三) 09:17 (UTC)[回覆]
「自我中心的混帳」算不算不文明？拿掉混帳會比較文明嗎？又或者是說對方的「行為宛如自我中心的混帳」（我記得我這麼說過某位維基人） --窩法乙烷 兒法夢碎 2024年4月11日 (四) 13:28 (UTC)[回覆]
我不清楚，甚至説這也是我想問的東西。Sanmosa Szégyen a futás, de hasznos 2024年4月11日 (四) 15:51 (UTC)[回覆]
就「自我中心的混賬」這一例子而言，我是否認為其不夠文明取決於語境。如果這個短語出現的語境比較平和或者有點帶翻譯腔，我不會認為其不夠文明。反之，如果它出現在尖銳的衝突中，我會認為其不夠文明。--CuSO4 · 龍年大吉 2024年4月13日 (六) 16:41 (UTC)[回覆]
  • 這類問題恐怕見仁見智。我自己的觀點是，如果其他討論者都在積極解決問題，那麼罵人者(不管有沒有道理)都不對; 如果有些用戶屢勸不聽，那麼當然還是應該以有禮的態度，按程序處理問題; 但畢竟人的耐心有限，有一些編輯忍不住發脾氣了，其他人可以盡量包容，不要因語氣問題而阻礙了正事。--Temp3600（留言） 2024年4月13日 (六) 18:26 (UTC)[回覆]
    現在UUM以身作則，紅渡廚效仿（[1]），我看社群是越來越文明了。但願參加這個討論的人要是以後被人說「愚蠢」 、「腦子有問題」不要生氣。--日期20220626（留言） 2024年4月15日 (一) 03:25 (UTC)[回覆]
    如三個編者都能夠在和你互動後得到一樣的結論，你是不是該考慮一下也許這不是對你的人身攻擊，而是真正在評論你討論事情、給維基百科貢獻的能力？順帶一提，我可沒說你腦子有問題，我只是對你提出腦子是否有問題的疑問。--0xDeadbeef (留言) 2024年4月15日 (一) 09:11 (UTC)[回覆]
    原來罵人愚蠢是討論事情，以後要不你們見人就開罵好了，也不要討論什麼事情了。--日期20220626（留言） 2024年4月15日 (一) 10:24 (UTC)[回覆]
    哇靠所以現在「你的腦子是否有問題」已經不是人身攻擊了？你攻擊其他人對維基百科貢獻的能力，那麼你的編輯中有一半都是在Wikipedia空間中煮，條目編輯兩百也沒有的又對維基百科做出了什麼貢獻？--某人✉ 2024年4月15日 (一) 10:47 (UTC)[回覆]
    冒犯到維基精英了嗎，那真是實在抱歉。我只是不知道，你僅僅讀了我最後一個評論，然後就開始說我編輯數了，你這樣給討論帶來了什麼呢？上方進行正常討論的時候你不加入，到這裏了你開始攻擊我了。那當然你要覺得是我先開始攻擊別人的，因為畢竟我說別人腦子有病了對嗎。我有些好奇的是，你對於我問他腦子是否有病的討論串上下文究竟了解多少呢？你知道我在什麼樣的情況下發出了那樣的留言嗎？
    你維能不能少點這種連具體事情都不去了解就開始顧左右而言他，扯什麼有的沒的。--0xDeadbeef (留言) 2024年4月15日 (一) 12:25 (UTC)[回覆]
    真的要去了解當時的上下文，更顯得你那句話不合適，我問你要點例子，你就懷疑我腦子有問題。--日期20220626（留言） 2024年4月15日 (一) 12:30 (UTC)[回覆]
    我當時的評論是在表明我所感受到的general vibe，而且我當時很忙，沒時間。有人藉由我提名的人選間接攻擊我，說什麼你提名一個長期違反且不認同站內文明準則的人是想幹什麼？、你讓一個不遵守站內方針的人去當管理員，這算什麼？也許我應該跟他笑臉相迎咯？我是不是禮貌地表達了我不歡迎你的意見呢？那你為啥還要騷擾我？對我有意見，並且還要到處說我的不是，到現在還在說什麼反正社群裏面支持他的人，也就那樣。 甚至前幾回還把這一件事帶到meta上。
    我說過，我是算和善的人了。也許和你說這些沒用，那我就寫給別人看好了。說我在你維待的時間短來批評我已經不是第一次了，但是我總是說，要是有人看我不爽可以直接罵我，可是沒有人願意這樣干。也許是別人不屑與我討論吧。兩個月前就有類似的，今天更是見識到你的編輯中有一半都是在Wikipedia空間中煮，條目編輯兩百也沒有的又對維基百科做出了什麼貢獻這種說法。ATannedBurger之前和我有這樣的分歧，為啥我現在要支持他當選管理員呢？也許他願意溝通，願意聽一下我這個人要說什麼吧。
    也許我說「維基百科沒有很歡迎我表達我的想法」的時候沒哪些特別具體的例子，但沒有例子便去創造例子，不是嗎？AINH上面不就提供了一個完美的例子。--0xDeadbeef (留言) 2024年4月15日 (一) 13:03 (UTC)[回覆]
    我是反對你的提名，理由也闡述多次。當然你可以講話語氣嚴厲一些，可以不那麼禮貌，但直接懷疑別人腦子有問題，顯然就情緒化了。
    那一串討論你本來就已參與，不認為回應你的言論屬於騷擾，而且我也沒有特地@你。
    一個支持他的人還用他罵人的話來罵我，而且理由都站不住腳，這句話重點說的是他，當然你硬要說這句話在說你也沒問題，畢竟你提名他當管理員，也算是支持者的一員。
    meta上留言是因為我覺得你的言行不適合去當委員。--日期20220626（留言） 2024年4月15日 (一) 13:12 (UTC)[回覆]
    你不覺得屬於騷擾就不是騷擾，那隨便你咯。--0xDeadbeef (留言) 2024年4月15日 (一) 13:35 (UTC)[回覆]
    這個討論串真是令人遺憾。--桐生ここ★[討論] 2024年4月15日 (一) 14:33 (UTC)[回覆]

「徵求意見公示寫入相關方針指引」提案公示通知

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

徵求意見公示寫入相關方針指引 已通過徵求意見系統在方針討論頁取得共識，現於公示中，2024年4月17日 (三) 15:52 (UTC) 結束，由於方針修正前規定公示只能在客棧頁面下，則在此通知相當於在客棧下公示。如有意見請在連結中討論頁提出。--0xDeadbeef (留言) 2024年4月10日 (三) 15:59 (UTC)[回覆]

@0xDeadbeef：公示期似已結束。Sanmosa Szégyen a futás, de hasznos 2024年4月18日 (四) 05:43 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
取自 "https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/方针&oldid=82309690"