维基百科:互助客栈/方针

本页使用了标题或全文手工转换
维基百科，自由的百科全书

快捷方式

此页面探讨维基百科的方针与指引。


请注重礼仪、遵守方针与指引，一般问题请至互助客栈其他区或知识问答提出，留言后请务必签名（点击 ）。


发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。

议题最后回应时间为4月7日之前（正在公示者除外）或者该议题已经标记为结束达三日，则该议题会存档至相关讨论页或存档页。讨论存档至相关讨论页后，相关讨论标题则会于一日后存档。跳至本页的：目录 · 底端

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (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 创建封禁申诉的本地共识 55 5 Shwangtianyuan 2024-04-17 21:04
6 我想问下 草稿可以储存 疑似侵权的内容吗 5 5 GZWDer 2024-04-17 21:16
7 条目创意私房提供网址，是否违反Wikipedia:儿童保护？ 1 1 Jimmy-bot 2024-04-17 16:14
8 共识创建的递进步骤 1 1 LuciferianThomas 2024-04-09 16:11
9 有关社群讨论所需的文明程度的疑问 33 10 桐生ここ 2024-04-15 22:33
10 “征求意见公示写入相关方针指引”提案公示通知 1 1 0xDeadbeef 2024-04-10 23:59
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时，
请先检查设置是否有误

正在广泛征求意见的议题

以下讨论需要社群广泛关注：（重新整理）

维基百科格式与命名

Module talk:Citation/CS1/Configuration § 编辑请求：更正cite AV media参数显示

Wikipedia talk:格式手册/日本动漫游戏 § 提议将WP:MOSACG跨媒体部分提升为指引

维基百科方针与指引

Wikipedia talk:征求意见 § 征求意见公示写入相关方针指引

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

Wikipedia talk:维基百科不是什么 § 修订方针维基百科不是维基物种

Wikipedia talk:共识 § 共识创建的递进步骤

Wikipedia talk:格式手册/日本动漫游戏 § 提议将WP:MOSACG跨媒体部分提升为指引

维基百科提议

Wikipedia talk:仲裁委员会 § RfC：2024年2月

Wikipedia talk:回馈请求服务 § 将回馈请求系统用于存废讨论和存废复核

Wikipedia talk:字词转换处理/公共转换组 § 思路：条目预储公共转换组中匹配的规则，减少载入时间

条目主题
非条目主题
提示
要将某一个讨论加入上述列表中：
  • 在讨论页中的对应讨论章节顶端加上{{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)[回复]

我想问下 草稿可以储存 疑似侵权的内容吗

个人主页的草稿 或者条目的草稿--此条未正确签名的留言由阿俊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:儿童保护？

本主题全部或部分段落文字，已移动至Wikipedia talk:儿童保护。执行人：Jimmy-bot（留言） 2024年4月17日 (三) 08:14 (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)[回复]

取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/方针&oldid=82301653”