維基百科:互助客棧/方針/存檔/2023年5月

刪除方針指引實體和程序規則綜合修訂案

刪除方針指引（PL400系列方針和GD700系列指引）實體和程序規則綜合修訂案
提案人：中文維基百科圖書檔案館 KirkLU

整理性修訂

• 修訂案由：
  1. 刪除方針指引是中文維基百科歷史最悠久的系列方針指引，根據中文維基百科圖書檔案館的編目，除《刪除程序指引(論述)》中新列為試行指引的「重新提交討論」部分，有5個方針（包括依附於《重定向指引(GD201)》的《重定向刪除方針(PL401.1)》）和2個指引；
  2. 上述方針指引中除了《快速刪除方針(PL402)》《修訂版本刪除方針(PL403)》《存廢覆核方針(PL404)》針對性強、內容簡明集中外，其他方針在歷史上不斷「縫縫補補」的過程中，出現了相互交叉重複（甚至齟齬）的情況，這一點在一般性規則和頁面存廢討論有關規則方面尤其嚴重；
  3. 最典型的是《刪除方針(PL401)》、《關閉存廢討論指引(GD702)》和《刪除程序指引(論述)》相互重複（甚至有大段全文重複），既不便於新手閱讀（簡潔性）、不便於修訂（需要交叉修訂），又影響了《刪除程序指引(論述)》存在的必要性（大量內容已經存在，無需再將其中大部分論述內容轉化為指引）。
  4. 圍繞上述問題，提案人提出一系列綜合修訂方案，其精神包括——

     a. 新的《刪除方針》專注於實體規則：著重描述刪除的介紹和主要理念，刪除的規定理由，刪除以外的選擇等；並對刪除的不同類型和流程作總覽性地介紹，並以內鏈溝通各特殊刪除類型和關於程序的介紹；

     b.《關閉存廢討論指引》與《刪除程序指引(論述)》，以前者的內容和後者的框架為基礎整理為新的《刪除程序指引》綜合描述程序性規則，包括——

     • 此前，《刪除方針》對於快速刪除、修訂版本刪除、存廢覆核、侵權處理的程序有導引性介紹，《刪除程序指引》對於快速刪除有導引性介紹，幾部分加以整並列入新的《刪除方針》；
     • 快速刪除作為流程上最先可能出現的流程，首先獲得介紹（僅簡要介紹並提供內鏈，具體程序仍載於《快速刪除方針》不變）；
     • 修訂版本刪除的RD5需要基於快速刪除，故對其介紹緊接在快速刪除流程之後出現（僅簡要介紹並提供內鏈）；
     • 存廢討論部分是《刪除程序指引》的核心，《關閉存廢討論指引》和《刪除程序指引(論述)》中已列入試行的內容進入此處；
     • 侵權處理的程序包含了對快速刪除、修訂版本刪除和作為存廢討論子板塊的侵權處理的使用，故在存廢討論後出現（僅簡要介紹並提供內鏈）；
     • 存廢覆核最後出現（僅簡要介紹並提供內鏈）；
     • 所有內容羅列完成後，引入原先在《刪除方針》使用的列表加以總結。

     c.《快速保留指引(GD701)》以新的《刪除程序指引》中的內鏈，與存廢討論的規則取得聯繫；

     d. 原先孤立存在（僅在《刪除程序指引(論述)》中有內鏈）的《非管理員關閉討論論述》引入新的《刪除程序指引》相應部分作為參考性論述；

  5. 修訂以不對任何刪除相關的程序做實質改變為基礎，文字主要是對各來源原有文字拼接整合而來。
• 下一步可以探討做實質性修訂的內容——整理性修訂過程中發現了很多具有實質性修訂潛力的內容，為便於整理性修訂通過，減少因實質性修訂分歧導致的討論冗長，先僅列於此：
  1. 《刪除方針(PL401)》的14條刪除理由需要整理優化（存在定義不清或相互重複的情況）；
  2. 新的《刪除程序指引》（原《關閉存廢討論指引》）中提前關閉討論的情形需要整理優化（存在相互重複的情況）；
  3. 《快速保留指引(GD701)》的情形需要整理優化（存在相互重複的情況）。
• 修訂案草案以及修訂路徑：
  1. 《刪除方針》修訂案草案
  2. 《刪除程序指引》草案（該案成立後寫入當前標題，《關閉存廢討論指引》因內容已被吸納而重定向到《刪除程序指引》，《刪除程序指引(論述)》作為歷史版本）
• 優勢：
  1. 大幅提高了可讀性：《刪除方針》的篇幅一定程度縮短，內容集中，《刪除程序指引》也集中了所有之前分布各處的程序規則，各方針指引篇幅上更加友好、邏輯上更加清楚；
  2. 消除重複和齟齬，也方便日後修改：刪除重複部分，並利用內鏈相互勾連，使得實體、程序規定能各自集中一處，日後修正也只需修正一處即可在各方針指引間關聯落實。

以上。--KirkLU (A) 2023年4月17日 (一) 11:57 (UTC)

修正案的「一句話概要」：《刪除方針》對各種刪除程序的詳細規定，與《關閉存廢討論指引》以及列為試行指引的「重新提交討論制度」合併，整合為《刪除程序指引》。--KirkLU (A) 2023年5月4日 (四) 16:32 (UTC)

@KirkLU：建議提供一下草案與現行條文的版本差異。Sanmosa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年4月18日 (二) 15:59 (UTC)

這個好像難度實在太高，小修正個別字句還行，大修訂如果要比較條文可能全文都要發在這裡了，而且到處紅綠。還是直接審閱草案較好，如果覺得哪裡的修改會帶來實質性變動，我們可以優化對應部分以保持制度不變。--KirkLU (A) 2023年4月18日 (二) 18:47 (UTC)

我沒記錯的話，你應該可以用diff連結，「Special:diff/（草案版本編號）/（現行條文版本編號）」就可以。Sanmosa _{In the long run we are all dead} 2023年4月19日 (三) 10:09 (UTC)

我嘗試一下，我自己感覺意義不大，因為《刪除程序指引》實際上是整並而成：新舊《刪除方針》（Special:diff/76855600/74656314）、新《刪除程序指引》與《關閉存廢討論指引》（Special:diff/76875671/71500235），現有《刪除程序指引(論述)》不納入比較是因為其內容僅有一個章節（即列入試行指引的第2.6〔重新提交討論〕章節）與本次整合修訂有關。--KirkLU (A) 2023年5月4日 (四) 16:24 (UTC)

啊，不過感謝您能三番五次關心本案。本案屬於審閱工作量較大，但是卻不修改實質性制度，只是消除齟齬並增強可讀性，提案受關注度可能相對較低一些。--KirkLU (A) 2023年5月4日 (四) 16:27 (UTC)

另已加粗草案內鏈，使其顯眼。--KirkLU (A) 2023年4月18日 (二) 19:54 (UTC)

@KirkLU：想問一下此修訂案一共涉及哪一些方針、指引或論述？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年5月4日 (四) 09:31 (UTC)

修正案不涉及實質性合併論述，只涉及三個（或者說兩個半，因一個是將論述的一個章節接納為指引，即Wikipedia:刪除程序#重新提交討論）方針指引。也即只將《刪除方針》中與《關閉存廢討論指引》、《刪除程序指引(論述)》中已列為試行指引 （即重新提交討論制度）重複內容剝離後，統一整合為新的《刪除程序指引》，改變程序性規定分列三處且互有齟齬的情況。--KirkLU (A) 2023年5月4日 (四) 16:16 (UTC)

存廢討論「五周無共識」制度的修改

話說最近一直採用relist方式處理積壓討論，而且已經把積壓減到了很低，但同時也發現了一些實操上的問題，正好藉此說一下。主要就是積壓存廢中的「存廢討論持續五周或最後留言已過一周」的規定，最近一直讓我非常疑惑。其實在積壓很多的時候並不覺得這個條件有什麼問題，但是當積壓已經清理得差不多之後，這個條件造成的問題就浮現出來了，特別是啟用了relist之後就更明顯了。

主要是這幾方面：

1. 存廢討論規定提交存廢后7日結案，比如4月11日的提案今天可以處理了，但是如果管理員因各種原因（比如極端情況，伺服器維護導致資料庫只讀了兩天，當然常見情況是管理員沒空或者懶）過了兩天才處理，那麼4月11日的提案就進入了積壓，此時是否就要遵循「存廢討論持續五周或最後留言已過一周」的規定，還是提案7日後結案的規定？畢竟這種情況本質上不是因為討論持續暫時無法達成共識而造成的積壓，只是暫時沒人處理而已，甚至如果只嚴格遵循「存廢討論持續五周或最後留言已過一周」的規定，還會導致更多的積壓產生。而且，此時這兩個規定是互相矛盾的，不可能同時遵守。
2. 根據我最近幾個月來處理存廢積壓的經驗，討論持續超過一周的大概也就是5%左右，達到5周的百無其一，因此為了這麼少的情況，設定「存廢討論持續五周或最後留言已過一周」的條件是否有必要？尤其是採用relist後，感覺上就更無必要了
3. 設定「存廢討論持續五周或最後留言已過一周」的條件，在實操上其實就是關注兩個時間點，以今天為例，需要關注3月14日（存廢討論持續五周）和4月11日（最後留言已過一周）這兩個日期，在處理積壓的時候要時刻注意討論串中的提案日期和留言日期不要晚於這兩個日期。但現實情況是（至少對我而言），既要仔細分析大家的討論、查看頁面的內容，判斷討論是否形成共識，基本上注意力全部都集中在了討論上，很容易忽略時間，即使一直提醒自己要注意時間，但往往仔細看一會討論後就忘了時間問題，因此嚴格遵守這個規定在實際中因人類注意力機制的問題其實非常難以做到

綜上，我建議在啟用relist的情況下，全面取消「存廢討論持續五周或最後留言已過一周」的規定，relist的模式也能夠保證存廢討論最長持續21-30天，而且取消這個規定，實操上也更方便（管理員更不容易犯錯，目前的規定說不好聽點就是個管理員陷阱）。在使用relist之後，我才更明白英文版採用這種制度的好處：只要管理員稍微處理積極一點，存廢積壓根本不是一個問題--百無一用是書生 (☎) 2023年4月18日 (二) 03:17 (UTC)

我覺得這個提議非常有意義，唯一我比較害怕的點在於，整理性修訂不實質改變制度比較容易取得共識，引入了實質性變動後有可能會讓討論冗長。如果您不介意的話，我緊接著本子章節，新開一個章節，然後「五周無共識」這方面的變動，與上面的整理性修訂分離討論，妥否？--KirkLU (A) 2023年4月18日 (二) 06:08 (UTC)

好啊，我本來就是想開個新討論的，看到你的這個我就順道了--百無一用是書生 (☎) 2023年4月18日 (二) 07:04 (UTC)

已分割為新章節。--KirkLU (A) 2023年4月18日 (二) 09:14 (UTC)

那句是安亭改的。原本是「無共識保留的頁面可能列入Wikipedia:刪除投票和請求/積壓投票與Wikipedia:檔案存廢討論/積壓投票討論繼續，並在下列日期最早者，並仍無共識時，予以關閉並保留：刪除投票討論已開始足5週；最後意見發表已逾1週。」，這樣的話句子就相當明白了。那是沒有共識的話，要符合以下這些條件，方可以無共識保留，而不是合乎這些條件就必須要無共識保留。所以根本不存在矛盾。--Ghren🐦🕓 2023年4月19日 (三) 09:37 (UTC)

「無共識保留的頁面可能列入Wikipedia:刪除投票和請求/積壓投票與Wikipedia:檔案存廢討論/積壓投票討論繼續」這句話無法理解，既然無共識保留了，那麼怎麼還會在積壓里出現？而且即使這個言之成理，我提出的理由中的2、3點也仍然存在--百無一用是書生 (☎) 2023年4月27日 (四) 02:12 (UTC)

答曰：不知道。得請教一下@antigng是怎樣一回事。而您所提的第2點建基於relist，得真的推行才成立；第3段也不成立了，因為當管理員認為有共識了，就不需需考慮「存廢討論持續五周或最後留言已過一周」的問題，直接保留/刪除就行。--Ghren🐦🕛 2023年4月27日 (四) 04:20 (UTC)

同意這個提案，並建議Wikipedia:刪除程序#重新提交討論直接轉正。Sanmosa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年4月18日 (二) 15:48 (UTC)

《刪除方針》14條刪除理由綜合修訂

（預留）

提前關閉討論條件綜合修訂

（預留）

快速保留條件綜合修訂

（預留）

有關m:IP masking啟用後未註冊用戶的用戶討論頁

現時IP位址的用戶討論頁在該IP停止編輯30日後由機器人存檔，避免給使用同一IP位址的用戶帶來混淆（即WP:O3）。但是當m:IP masking啟用後未註冊用戶是以Cookie分配。請問在m:IP masking啟用後是否需要維持未註冊用戶停止編輯一段時間後對其用戶討論頁存檔嗎？--211.30.8.164（留言） 2023年5月6日 (六) 08:26 (UTC)

到時再說，我個人覺得不用。 ——魔琴 [ 萬戶涕淚 ] 2023年5月6日 (六) 09:55 (UTC)

同上，現在討論意義不大。--SCP-0000（留言） 2023年5月7日 (日) 02:42 (UTC)

其實IP masking最快今年實施，所以現在開始討論也不是太早。--132.234.228.224（留言） 2023年5月7日 (日) 23:30 (UTC)

那頁面不是寫臨時帳號有效期是90天嗎，然後就會註銷嗎？那就看看註銷後是否有標示，又是否會重用再說。--路西法人 2023年5月7日 (日) 02:30 (UTC)

臨時帳號有效期是1年，不是90日。--132.234.228.224（留言） 2023年5月7日 (日) 23:25 (UTC)

啊，被File:IP Masking - Temp account - Design mocks.png左下角的圖片誤導了（（--路西法人 2023年5月7日 (日) 23:48 (UTC)

一些前置性工作——關於IP Masking的啟用與規則上的適配

2023年19期技術新聞提到IP Masking機制大概於2024年啟用，詳情看元維基的介紹，不過這裡可能需要一些前置性工作：

• 原來針對「IP用戶」允許與不允許的操作的規則可能需要修改字眼來適應，可能需要一份共識，方便對現有的方針指引中的用詞進行適應修改，而不需要花時間逐個討論。
• 可能或是否需要將完整IP信息顯示的權限（「ipinfo-view-full」）也給其他需要處理破壞等的管理型組別了（例如新頁面巡查），可能在應對匿名用戶（包括跳IP，跳臨時帳戶）的破壞還是有作用。
• 會有一個用戶組（Special:用戶列表/no-ipinfo）用於拔除相應ipinfo的權限，怎樣用到？是不是需要制定規則來使用？
• 現實IP用戶的討論頁會轉移版本到對應存檔頁，以後匿名臨時用戶的討論頁是否延續這套機制？

大概。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年5月9日 (二) 07:03 (UTC)

應該不需要強制的存檔了。臨時用戶只是相對註冊的用戶而言的，使用上並不會像IP一樣多人共用。——暁月凜奈 (留言) 2023年5月9日 (二) 07:12 (UTC)

第四點我認為的確可以不用，臨時用戶名是跟Cookies的，某個自然人如果會搬Cookies的話，那這些對應的討論頁（和討論內容）就對應延續。如果會清空Cookies的話，那就是他根本不在乎上面的留言。原有IP討論頁存檔觀點是後面的自然人可能會不同，所以不要交叉打擾。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年5月9日 (二) 08:03 (UTC)

IP用戶→未註冊用戶（？） ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年5月9日 (二) 07:30 (UTC)

匿名用戶。--路西法人 2023年5月9日 (二) 07:54 (UTC)

不知道「ipinfo-view-full」會不會給其他用戶組，現時給了CU和admin，元維基的介紹還說給Stewards和T&S，不知道還能不能開放給其他組，至少巡查組應該可以需要。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年5月9日 (二) 08:06 (UTC)

現階段 IP Masking 的機制仍在草案階段（甚至英維社群似乎仍未有相關 RFC）。個人認為社群與其討論本站如何配合機制，反倒過來應討論如何讓機制配合本站的環境，提案如何改進機制。謝謝。--SCP-0000（留言） 2023年5月10日 (三) 03:30 (UTC)

大致能確定的：IP作為匿名用戶現階段的記錄用戶名一定遮蔽，ipinfo的機制已經上線並用了很久。現階段大致確定的是：通過Cookies記錄特定IP特定一次用戶的標識token，可以跨維基項目操作，這個臨時用戶名的前綴正在討論確定。如果是要我們給機制意見的話，我的意見是：「放下助人情結，尊重他人命運」，愛用IP編輯顯IP的將讓他顯，沒必要給遮醜布。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年5月10日 (三) 04:13 (UTC)

IP Masking 推行的主因是不可抗力的法律因素。我們無法決定是否推行，但至少有如何推行的討論空間。謝謝。--SCP-0000（留言） 2023年5月10日 (三) 05:09 (UTC)

還是那句話「放下助人情結，尊重他人命運」。建一個次拋型帳戶比這樣套一層M:N關係還靠譜，只要不涉及破壞，編輯關聯度低，CU也不能查哪裡來的人。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年5月10日 (三) 05:57 (UTC)

不是很理解你的想法。臨時帳號和背後的自然人應該是N:1的關係。CU資料保存三個月應該是適用於臨時帳號的。--MilkyDefer 2023年5月11日 (四) 04:33 (UTC)

可能比CU差，CU大部分普通用戶沒得查，IP Masking用戶有詳細IP查詢的話，似乎能直接查到（至少當前的）IP。如果考慮追蹤編輯的話，同帳戶有沒不同IP或者同IP有沒不同帳戶都應該能查到。而且用戶願意的話，可以憑著這個Cookies的token一直編輯下去（理論上能做到不過期），有詳細IP查詢權的結合前面提到的工具，也可以一直跟蹤下去。詳細IP查詢權至少對於反破壞有用，授權可能比CU會松。所以想要隱藏身份，一個次拋型帳戶比IP編輯更有效，而基金會如此不尊重別人的選擇來給面紗，只不過畫蛇添足沒事幹，還增加普通用戶（沒詳細查詢權的）參與反破壞的麻煩。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年5月11日 (四) 12:27 (UTC)

閣下的意思是，未來計劃的 Cookies + IP 方案，因為「臨時帳號」只指代同一人的性質以及可追尋「臨時帳號」所有使用過的 IP，加上「詳細IP查詢權」取得條件寬鬆及更容易取得詳細 IP 資訊。相比現在的暴露 IP 的做法，反而難以隱藏個人身份及增加隱私風險，倒不如建立一次性帳號？謝謝。--SCP-0000（留言） 2023年5月11日 (四) 13:49 (UTC)

差不多意思。基金會這種假惺惺的隱私保護，給想搞巡查的增加麻煩，真正想隱藏身份的，還不如一次性帳戶靠譜。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年5月12日 (五) 06:02 (UTC)

確實這是一個大問題，個人已在元維基發起相關討論。如果閣下有空，也期望發表意見。謝謝。--SCP-0000（留言） 2023年5月12日 (五) 07:51 (UTC)

這個翻譯好，就叫「IP面紗」吧（匿名面紗怎麼樣 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年5月11日 (四) 16:02 (UTC)

(！)意見：個人支持保護用戶隱私的機制，只是就目前的機制概念而言看起來尚有一些疑慮存在（主要包括上方站友已討論的部分），而此機制避免人身安全或法律風險的措施和部分反破壞站務（比如藉由IP彙整識別LTA）某種程度相悖，也的確成為兩難情境。尤其不同國家或地區面臨的風險程度不一，以目前規劃的查看IP獲權通用門檻而言，其實相當容易達成。不過隨著某些事、時、地和對象所面臨的言論環境逐漸惡化，如果非得二選一，個人會選擇保護人身安全和避免法律風險為優先考量，若要兼顧內容維護和站務，其實最直接的方式的確是鼓勵甚至半強迫用戶直接註冊帳號，這也避免更多規劃或思慮不周，以及各種現實條件限制，所造成用戶需求、編輯實務和站務管理上的困擾。最直接的方式，就是禁止或適當限制IP用戶編輯，然而此種作法亦頗具爭議，雖然目前似乎已在葡語版百科得到部分觀察結論；退而求其次就是不斷提醒匿名用戶註冊帳號，而這或許可以透過進一步限制其編輯或活動空間嘗試達成，比如進一步直接限制匿名臨時帳號的壽命（如：可用時間、編輯次數、轉換帳號次數之類）。無論如何，由於一般不知道技術知識的用戶很可能一開始未必會注意到相關風險，個人強烈建議除了一開始就該對用戶提供明確的相關說明，如果此機制施行，當匿名用戶開始編輯後，至少每隔一定的「編輯次數」（比如每隔10筆或20筆編輯之類）或其他可量化的用戶使用指標，平台應對匿名用戶再次顯示臨時帳號運作機制的說明以及建議註冊帳號的提示相關頁面連結或提示訊息；理想上應該在用戶開始編輯不久後，就能知道相關機制和現有的可行選項，以供自行揀選決定。至於若真的推行此機制，個人認為可以採「年份 - User:2023-12345」的流水號形式。--Kriz Ju（留言） 2023年5月16日 (二) 17:13 (UTC)

限制壽命只會更快更換臨時帳戶，更難追蹤。多次提示似乎有騷擾之嫌（也差不了多少）。用戶名如何定請去m:Talk:IP Editing: Privacy Enhancement and Abuse Mitigation#What_should_it_look_like?. ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年5月17日 (三) 00:37 (UTC)

(！)意見可以在Meta寫一篇IP用戶（或也包括臨時用戶）可能面臨的風險的文章，加到面向匿名用戶的中央通告裡，向中文俄文等版本站點投放。——暁月凜奈 (留言) 2023年5月17日 (三) 00:50 (UTC)

要否將孫中山是男性毋須引用提升為正式方針以輔助WP:可供查證方針？

——勿用「進行」污染中文，要言簡意賅。　捍粵者 2023年5月3日 (三) 15:58 (UTC)

沒有必要。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年5月3日 (三) 17:37 (UTC)

我甚至會給一個反對。因為在某些情況下不同人眼中的事實甚至也不一樣。--ときさき くるみ 2023年5月3日 (三) 21:11 (UTC)

雖然我贊成您的提案，但是通過的機率很低，標題就被堵住了；論述裏的內容，可以考慮加入在當前的方針或指引。 -- 月都 ※ 2023年5月3日 (三) 22:51 (UTC)

沒有這個必要。這頁面已經是共識頁，就算沒有方針指引的地位也同樣是有效的規則。Sanmosa _{In the long run we are all dead} 2023年5月4日 (四) 03:32 (UTC)

問題可能是常識而言，究竟有無有效地約束到，週所周知之，無視如此共識者或事——或者需要論述一般共識效力，可以如何在特殊情境內持續而不至於需要不斷普及常識。--約克客（留言） 2023年5月4日 (四) 03:39 (UTC)

這種情況下直接把相關情況貼到客棧這裏就行了，至少他們沒辦法無視相關討論。Sanmosa _{In the long run we are all dead} 2023年5月14日 (日) 04:07 (UTC)

有什麼好處？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2023年5月9日 (二) 06:28 (UTC)

就怕到時候又要對何為常識進行一場大辯論。。。--newerdrawn（留言） 2023年5月14日 (日) 05:20 (UTC)

我同意您的看法，一般來說冷門就不是常識，除此以外還有邏輯。 -- 月都 ※ 2023年5月17日 (三) 16:29 (UTC)