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