维基百科:互助客栈/方针/存档/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)