维基百科

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

< Wikipedia:互助客栈
最新留言：4小时前由Jimmy-bot在话题有关社群讨论所需的文明程度的疑问内发布

快捷方式

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


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


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

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

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 重议删除方针规定“多余无用”模板模块提删条件及确立废弃模板模块提删规范 102 17 阿南之人 2024-04-15 18:57
2 提议提高条目评选投票资格门槛 40 20 HK5201314 2024-04-23 15:37
3 进一步增修封禁方针以及创建封禁申诉的本地共识 1 1 Jimmy-bot 2024-04-23 16:14
4 创建封禁申诉的本地共识 57 5 Shwangtianyuan 2024-04-18 13:58
5 我想问下 草稿可以储存 疑似侵权的内容吗 5 5 GZWDer 2024-04-17 21:16
6 有关社群讨论所需的文明程度的疑问 1 1 Jimmy-bot 2024-04-24 00:14
7 再拟议立国际关系命名常规为方针 17 6 Sanmosa 2024-04-23 23:01
8 修订删除方针明确允许删除没有来源30日以上的条目 7 5 YFdyh000 2024-04-23 14:42
9 Quick CU introduction 4 3 桐生ここ 2024-04-21 19:16
10 提议英维指引en: MOS:TVINTL经本地化后引入中维维基百科:格式手册/电视 9 4 HK5201314 2024-04-23 14:04
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时，
请先检查设置是否有误

正在广泛征求意见的议题

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

维基百科格式与命名

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

维基百科方针与指引

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

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

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

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

Wikipedia:互助客栈/条目探讨 § 盛冈市的导言和宣传的定义

维基百科提议

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于每个小时进行更新。

重议删除方针规定“多余无用”模板模块提删条件及确立废弃模板模块提删规范 编辑

最新留言：8天前102条留言17人参与讨论

本主题或以下段落文字，在讨论结束后应存档至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)回复

提议提高条目评选投票资格门槛 编辑

最新留言：12小时前40条留言20人参与讨论

本主题或以下段落文字，在讨论结束后应存档至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)回复
我下面也说过类似的，但我觉得所谓水票是投票制下的自然成果。如果说不仔细检查条目是老手都能犯的错误，那这必然是系统的问题。提高投票门槛只能是治标不治本。
当你维真正投入共识讨论制，大家都要关于为何自己认为条目符合标准写下意见的时候，自然不会有那种没有意见的、只读了条目的一部分投水票这种事情。--0xDeadbeef (留言) 2024年4月20日 (六) 04:45 (UTC)回复
共识制也好, 投票也好，本质都是如何让更多有能之士参与条目评审的问题。首先是要有编辑愿意来审条目，其次是怎样回报鼓励他们，并防止他们被报复。--Temp3600（留言） 2024年4月21日 (日) 18:19 (UTC)回复
关键就是FA和GA有标准，而DYK没有标准，甚至连WP:WIACCA这样模糊的标准都没有。既然DYK没有标准，那条目只要过提名门槛，大家想怎么投就怎么投；我不同意你的票，就用一张相反的票（而不是针锋相对的理由）抵消。然后DYK坏习惯传到FAC和GAN那边，最后搞成现在没有任何地方是来根据标准提意见的。DYK就是一个选首页内容的地方，怎么搞成条目品质评审主阵地了？我真想说DYKN是中文维基毒瘤。--For Each element In group Next（留言） 2024年4月22日 (一) 14:21 (UTC)回复
DYK和FA/GA还得两说。DYK是选首页展示条目，FA和GA才评估条目品质。很短但格式整洁的初级条目合适上首页展示，而内容丰富但格式粗糙的乙级条目则难登大雅之堂；但从完整度来看，后者远胜于前者。像英文维基编者那样，谈品质就不要谈DYK，FA和GA才有出路。至于DYK，就看社群希望怎样的条目上首页了。--For Each element In group Next（留言） 2024年4月22日 (一) 14:44 (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&#123;&#123;colour&#61;green&#166;&#125;]]（留言） 2024年4月16日 (二) 14:18 (UTC)回复
任何条目质量评选（DYK、GA、FA）使用投票制都是属于败笔。拿英维的存废讨论举例子：因为不是投票而是讨论，所以不用方针支持的删除/保留理由本来就弱。与此同时 若是新用户则会有使用{{spa|Example}}— Example（讨论）在本主题以外只有很少或没有编辑。方便让关闭讨论的人做决定。
娜娜奇鲜果茶上面说的问题本来就是DYK投票制本身存在的问题。--0xDeadbeef (留言) 2024年4月20日 (六) 04:40 (UTC)回复
不知道是哪个大聪明曾经提议支持票不用理由，而该提案又真的通过了。--唔好阻住我爱国（留言） 2024年4月23日 (二) 07:37 (UTC)回复


要先讨论清楚问题，才能对症下药:

  • 问题是"傀儡刷票": 提高门槛以阻止养傀儡，重罚刷票者
  • 问题是"新人/老的"新人"滥投支持票":提高反对票的票效，令支持票再投也没意思，并最终过渡到评审制
  • 问题是"没人愿意投反对票，害怕开罪其他编辑":这个是最难解决的问题，即所谓"人情票"。我觉得只有引入匿名发言制度才有解。
  • 以上。--Temp3600（留言） 2024年4月13日 (六) 18:19 (UTC)回复
疯狂一点，干脆DYK手游体力化。 --窝法乙烷 儿法梦碎 2024年4月22日 (一) 15:16 (UTC)回复
  1. 每位维基人一天（24小时）内拥有7次提名体力和7次支持票体力
  2. 反对票或不合要求不设置体力
  3. 体力于午夜（太平洋标准时间）补充，上限为7次
  4. 先前未使用完的体力并不会保留，因此不会有昨天胜3次过了午夜变成10次的情况发生
  5. 活动期间如动员令可解除体力限制或增加次数
  6. 如果维基人的提名、投票被指出不合要求，将受到体力减少惩罚，每次减少1次体力，最多减少7次体力
  7. 受到惩罚减少的体力于每周日午夜（太平洋标准时间）补充，每周补充1次体力，上限为7次体力

进一步增修封禁方针以及创建封禁申诉的本地共识 编辑

最新留言：12小时前1条留言1人参与讨论

本主题全部或部分段落文字，已移动至Wikipedia talk:封禁方针。执行人：Jimmy-bot（留言） 2024年4月23日 (二) 08:14 (UTC)。回复

创建封禁申诉的本地共识 编辑

最新留言：5天前57条留言5人参与讨论

本主题或以下段落文字，在讨论结束后应存档至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)回复

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

最新留言：6天前5条留言5人参与讨论

个人主页的草稿 或者条目的草稿--此条未正确签名的留言由阿俊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)回复

有关社群讨论所需的文明程度的疑问 编辑

最新留言：4小时前1条留言1人参与讨论

本主题全部或部分段落文字，已移动至Wikipedia talk:文明。执行人：Jimmy-bot（留言） 2024年4月23日 (二) 16:14 (UTC)。回复

再拟议立国际关系命名常规为方针 编辑

最新留言：5小时前17条留言6人参与讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名常规 (国际关系)。

有鉴于前次讨论中提及的所有合理异议已获解决，这里再一次重新提议将国际关系命名常规立为方针。Sanmosa Szégyen a futás, de hasznos 2024年4月20日 (六) 02:20 (UTC)回复

这里对于（部分）可能会被认定为未获解决，但个人认为不甚合理的异议进行回应：
  • 捍粤者在被永久封禁前多度发表中华极端主义言行，在前次讨论中已有一次且因而被警告，前次讨论中的其他用户亦普遍不认可其见解，因此基于社群的主流意向不接纳其意见。
  • 有关页面分类排序的部分，由于提案只是为中文维基百科现行的排列习惯进行归纳，因此“排序毫无章法”一说并非实情。再者，将既有的排列习惯成文化并不会干扰现有的条目命名习惯，这算不上什么“向前冲”，而这也与WT:共识#共识创建的递进步骤的提议会干扰社群成员参与讨论的习惯有本质上的不同。
  • “一堆难以下咽的文字”之说需要额外的客观举证，否则无异于单纯的谩骂。“能使用最简称呼就使用最简称呼”有机会违背易于识别的要求，比如该意见举出的“爱爱关系”例子虽然语义上确实仅可能指爱沙尼亚与爱尔兰两国之间的关系，但一般读者不太可能在第一时间判断到“爱爱关系”一词中提到的两个国家名称的缩写分别指爱沙尼亚与爱尔兰。
以上。Sanmosa Szégyen a futás, de hasznos 2024年4月20日 (六) 02:41 (UTC)回复
(＋)支持。--CaryCheng（留言） 2024年4月20日 (六) 14:46 (UTC)回复
(＋)支持：我一向反对国际关系条目名用“单字简称式”。--Tp0910（留言） 2024年4月20日 (六) 20:41 (UTC)回复
不知何时能进到“深水区”，例如中英关系、中美关系，目前部分已更改，例如中日关系→中国—日本关系、中俄关系→中华人民共和国—俄罗斯联邦关系。另外在Wikipedia:命名常规#易于识别中提到：“条目标题应该易于识别，尤其是对于条目主题有一定认识者应该能够识别条目主题为何。”对于国际关系有一定认识者都应该能够识别了，更何况对于没有一定认识者，所以才更不能用“单字简称式”。--Tp0910（留言） 2024年4月20日 (六) 22:29 (UTC)回复
但是传统的这几个国家（英、美、德、日、俄…）确实单字常用，如果检索Google Scholar的话，scholar:中英关系有相当数量的结果，还有日语维基百科也用的ja:日英関系，如此限制单字使用可能违反Wikipedia:命名常规#使用常用名称，可能也原创研究，真的会有人写书命名《中国—日本关系史》吗，可能除了中文维基百科之外很少有人用。--Kethyga（留言） 2024年4月20日 (六) 23:48 (UTC)回复
所以有个Wikipedia:命名常规 (国际关系) #特殊情况。但对于已经更名的条目而言，又存在着不一致了。或许双边关系史的命名可以例外。--Tp0910（留言） 2024年4月21日 (日) 02:42 (UTC)回复
双边关系同样，不只是历史。个人反对已经有可靠来源、且常用的情况下去原创。即使对于美日关系美国国务院都直接用美日外交关系大事记（日维用ja:日米関系）。本来单字也是中文（汉字文化圈）的习惯。类似的甲午中日战争中文会有人说甲午中国—日本战争吗？--Kethyga（留言） 2024年4月21日 (日) 11:51 (UTC)回复
实体与实体之间的关系是全面的、广泛的，与纯粹的历史还是有所不同，所以我说“或许双边关系史的命名可以例外”，例如甲午战争、国共内战……，当然不会傻到改为甲午中国—日本战争、中国国民党—中国共产党内战，而且这些也不是目前命名常规 (国际关系)中所明确定义的实体（地方、国家、多国集团、国际组织）。日美关系于日前已改为日本—美国关系。--Tp0910（留言） 2024年4月21日 (日) 13:01 (UTC)回复
@Kethyga：我们可以规定仅在此类条目之标题命名上使用此种格式，但内文大可照用简称，其余衍生条目亦不必更易，我认为这并不妨碍全局。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月21日 (日) 14:33 (UTC)回复
@Ericliu1912：还是想提一下我这里提议定为方针的是命名常规，命名常规本即不管束内文用词。Sanmosa Szégyen a futás, de hasznos 2024年4月21日 (日) 23:51 (UTC)回复
这样会背离命名一致性的要求，子命名常规本来就是为（在专题下）达致命名一致性而设的。Sanmosa Szégyen a futás, de hasznos 2024年4月21日 (日) 23:55 (UTC)回复
一致性弱于Wikipedia:命名常规#使用常用名称。个人反对在已有常用词的情况下原创和使用不常用的规定。真有中文读者看不懂中日关系指的是什么，“可识别性及避免产生歧义”哪里有问题，台湾学者蒋永敬《近百年中日关系论文集》，个人检索台湾的华艺学术“中日关系”1700多条，“中国日本关系”4条，可以说“中日关系”绝对常用，“中国日本关系”几乎没人用。
此外，个人想提醒下之前订立的Wikipedia:格式手册/朝鲜半岛用语（必然会涉及到条目命名问题），其中新加坡、马来西亚不用或少用“朝鲜”、-“南韩”， Sanmosa基于港台常用"南韩"将韩国改为南韩，不知道是否违反Wikipedia:避免地域中心，本来“南韩”就已经是基于地域中心的用词，虽然可能是地区常用词。
不要制定一个没人用的规则，回来还得修复。--Kethyga（留言） 2024年4月22日 (一) 09:12 (UTC)回复
@Kethyga：（1）然而子命名常规在执行上优先性高于母命名常规，而且“子命名常规本来就是为（在专题下）达致命名一致性而设的”这点依然成立。（2）上一个指控（注意我的用词是“指控”而非“提出忧虑”）地区词地域中心的人是钉钉，社群当时已经驳斥过不只一次了，我想我应该用不着在这里重新抄送当时的驳斥。Sanmosa Szégyen a futás, de hasznos 2024年4月22日 (一) 23:54 (UTC)回复
子命名优先的前提是该规定合理，维基百科还有Wikipedia:非原创研究要求，使用实际不用或很少使用的名称显然不合理，个人简单看了中英几个方针还没有哪些方针命名明显去违反常用名称原则的。本来使用常用名称，如果读者（不管什么程度的）去搜索能找到很多结果，现在很少的结果，是说中文世界对于该项议题没有研究吗？
朝韩的命名问题即使是现实世界的地域中心，依然是基于地域中心的，可能和编辑无关，另外还没解决新加坡、马来西亚的问题。--Kethyga（留言） 2024年4月23日 (二) 05:56 (UTC)回复
依我看，钉钉所提出来的问题和Kethyga提出来的问题完全是两回事。可能您需要重新看一看他的留言。--Ghren🐦🕑 2024年4月23日 (二) 06:10 (UTC)回复
就算如此，这个问题也与国际关系命名常规无关，这顶多只能算是转换组设置的问题，这问题已经在走RFC流程了，如果继续在这里讨论这个问题的话就属于FORUMSHOPPING了。Sanmosa Szégyen a futás, de hasznos 2024年4月23日 (二) 15:01 (UTC)回复

修订删除方针明确允许删除没有来源30日以上的条目 编辑

最新留言：13小时前7条留言5人参与讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:删除方针。

修改WP:DP#REASON当前的7：

现行条文

彻底尝试后仍无法由可靠来源查证的条目，尤其是不符合任何关注度指引（《通用关注度指引》或者其它专题关注度指引），且已经挂相应模板30天的条目

提议条文

所有版本均没有可靠来源查证的条目，尤其是不符合任何关注度指引（《通用关注度指引》或者其它专题关注度指引），或已经挂相应模板30天的条目。

删除方针中的“务必先考虑改善页面”和“彻底尝试后”在实践中导致了某些页面“现在没有来源，但是仅仅因为可能有来源”而保留。其指导的行为导致了读者得到不可靠的信息，影响了维基百科的质量。

现在的cat:缺少可靠来源的条目和cat:缺少来源的条目的统计数和约为4.5万，足以证明可供查证方针并没有得到完全的执行。--落花有意12138 2024年4月20日 (六) 14:52 (UTC)回复

虽然这能增加存废提出和倒逼质量提升，但这与过往实践有很大不同。“或已经”似乎意味着没有来源的条目能直接提删。怀疑社群无力妥善处理众多条目，同时，有来源但不够或不准的条目也有很多，只删除无任何来源的条目可能留下漏洞，且某些可能明显有来源。对于“不可靠的信息”而未做查证，倾向更显著和充分的标注。--YFdyh000（留言） 2024年4月20日 (六) 23:17 (UTC)回复
“且”改“或”意味着只要挂著模板，就算实际上已经不再需要挂模板也依旧需要提删，我不认可。Sanmosa Szégyen a futás, de hasznos 2024年4月22日 (一) 01:31 (UTC)回复
"彻底尝试后仍无法由可靠来源查证的条目"和“尤其是不符合任何关注度指引，且已经挂相应模板30天的条目”才是两类不同的条目，这样改法会过度扩大删除范围，甚至还会波及部分老旧且本来就没有脚注来源的条目，即使这些条目并没有标注。还是认为没来源的情况，挂标识作为留意，而不是做删除派。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月23日 (二) 01:14 (UTC)回复
对，原本方针讲的是提删无关注度条目，现在被落花有意扩大成提删无来源条目。--日期20220626（留言） 2024年4月23日 (二) 03:38 (UTC)回复
原本的方针挺好的，不必修改。有来源也不代表什么，理论上可以学折毛，乱塞来源；维基百科本身就是不可靠信息，加不加来源都不改变这个性质；删除方针第二段明确写有“我们应该尽量保留所有合乎百科全书目标的页面，删除应该是最后的选择”，提案与这句话精神不符，应该尝试去找来源，而不是想着去提删，实在找不到来源可以挂关注度模板，而且中维要是一堆条目缺失，也让中维失去存在的意义。--日期20220626（留言） 2024年4月23日 (二) 03:21 (UTC)回复
我有个想法，对于长期无来源或明显不足的，使维护模板更显著一些，如更大横幅，黄色警告标志（黄底，而非当前{{无来源}}较温和的橘红色）等，以督促解决和提高警惕。甚至整个条目加底纹。至少，这比删除要温和一些。如果time参数控制让人担心，可以用单独模板或参数控制。--YFdyh000（留言） 2024年4月23日 (二) 06:42 (UTC)回复

Quick CU introduction 编辑

最新留言：2天前4条留言3人参与讨论

Hello, since 维基百科:IP封禁豁免权授予者 was settled on this project. Shall we introduce another process called QCU related to that?

As the description from English Wikipedia

Use this section to request checkuser information relating to a situation that does not involve sock puppetry. You could use this section to request, for example:

  • Underlying IPs of an account, where the autoblock has expired or been ineffective.
  • Collateral damage checks for the informed hardblocking of IPs or ranges.
  • IP block exemption checks before granting IPBE (or to verify it is being used constructively).

-Lemonaka 2024年4月21日 (日) 10:21 (UTC)回复

Google.
您好，自从维基百科：IP封锁夺权者落户这个项目以来。 我们是否应该介绍与此相关的另一个称为 QCU 的流程？
正如英文维基百科的描述
使用此部分请求检查与不涉及袜子木偶的情况相关的用户信息。 您可以使用此部分来请求，例如：
自动封锁已过期或无效的账号底层IP。
针对 IP 或范围的知情硬阻止进行附带损害检查。
在授予 IPBE 之前进行 IP 封锁豁免检查（或验证其是否被建设性地使用）。 -Lemonaka 2024年4月21日 (日) 10:23 (UTC)回复
重新翻译。
您好，自从WP:IP封禁豁免权授予者在本项目落地后，我们是否应当引入快速用户查核机制？
以下内容翻译自英维。（应该是取自查核请求页面）
如欲进行与操纵傀儡无关的查核请求，请在本小节下留言。例如：
  • 查核账号背后的IP，仅限自动封锁已过期或未能生效；
  • 在有意硬封锁IP或IP段时检查误伤；
  • 在授予IPBE权限前检查IP封锁情况，或确认用户是否正确使用该权限。
--MilkyDefer 2024年4月21日 (日) 10:49 (UTC)回复
WP:CUP#1、WP:CUP#2、WP:CUP#3。由于元维基政策，中文维基百科没有本地用户查核员的情况下此方针无法执行。--桐生ここ★[讨论] 2024年4月21日 (日) 11:16 (UTC)回复

提议英维指引en: MOS:TVINTL经本地化后引入中维维基百科:格式手册/电视 编辑

最新留言：14小时前9条留言4人参与讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:格式手册/电视。

目前，英维en: MOS:TVINTL有限制维基百科应收集怎样的播放信息，但中维没有相关限制，导致各电视节目（包括剧集及日本动漫）均记录了世界各地每一地区的播放信息或重播信息，本人认为条目内记录每一地区的播放信息或重播信息是非常冗长而没经筛选，更甚有条目的播放信息比例占整个条目一半或更多，有机会违反WP:SOAP及WP:NOTTVGUIDE。对此，引入en: MOS:TVINTL也许可解决问题。
en: MOS:TVINTL： Broadcast
This subsection should cover broadcast and release information about the series or season. This can include: the original network or streaming service of release in the country of production (e.g. the British network for a British series such as Doctor Who); a change in network throughout the run, such as with Futurama; start and end dates; and discussion of technical data such as picture and audio format, accompanied by critical commentary. Days or timeslots are not inherently notable, but if covering a series that switches these during its run, it may be helpful to note them for each season. If episodes are released all at once on a streaming service, it may be more appropriate to title this section "Release" rather than "Broadcast". Any syndication deals can also be noted.

As Wikipedia is not a television guide, do not include an indiscriminate list of every network that carried a series outside the country of production. Editors are encouraged instead to add noteworthy foreign broadcasts, if reliably sourced. These can include: broadcasts in primarily English-speaking nations such as the United States, Canada, United Kingdom, Australia and New Zealand; special cases such as an American series airing its finale first in France; or a mass international distribution deal, such as Netflix acquiring the international rights for Riverdale and Designated Survivor. If reliable sources exist for English broadcasts in other countries, a talk page discussion should decide whether these are notable.

可以这样本地化：

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外播放系列的每个播放平台。 相反，如果来源可靠，鼓励编辑新增值得注意的非生产地区的广播或串流信息。 这些可能包括：在中国、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的广播或串流资料；其余地区除了特殊情况外，包括如相关地区的通用语言不是中文，但首次播放以中文制作节目的播放信息；或大规模国际发行协议，否则不应被记录。

下列资料不应记录：

  • 播放时间（不包括播放日期）
  • 电视重播信息
  • 电视延后播放信息（只记录该地区最先出现的信息）
  • 马拉松式播放信息（例如在一天内连续播放5集电视节目）
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台
  • 相关串流平台官网、其他可靠来源均没有记录相关节目的准确播放地区且相关播放平台设置了IP限制 (特别注意：Disney+、Netflix、Amazon Prime Video、TVB Anywhere、Viu OTT)
  • 如相关节目于中文地区有“代理发行”信息，则只可记录可在该播放平台清淅辨认相关代理资料的网络播放平台。(特别注意：日本电视动漫)

由于此条文适用于所有曾于电视广播的节目，故在此提案。部分字眼可改，只求尽快通过。--唔好阻住我爱国（留言） 2024年4月22日 (一) 07:16 (UTC)回复

个人感觉：“值得注意的”是重点，但不十分明确。短期内或频繁的重播可能琐碎，得到有效来源介绍的则可考虑。“除了特殊情况外”后面的语句可能仍需润色，不好懂。“播放时间”如果有来源我觉得可以，但可能很多是查证不足。“下列资料不应记录”第三条及之后的含义和用法我不太明白，或许应补充例子。建议邀请活跃编者，可预期存在反对声音，另外它是指引，强制力在短期内可能不会很高，只能作为理由依据。--YFdyh000（留言） 2024年4月22日 (一) 07:56 (UTC)回复
  • “值得注意的”段落可以extend，但应如何extend则交由社群决定。
  • “频繁的重播”当然是琐碎，难道要准确收录何时重播？
  • “播放时间”见下方解答
  • “第三条及之后的含义和用法”，不是电视节目条目编辑者不明白是正常的。
最后那点，请参阅在Wikipedia talk:格式手册/日本动漫游戏 § 提议将WP:MOSACG跨媒体部分提升为指引的讨论。--唔好阻住我爱国（留言） 2024年4月22日 (一) 09:26 (UTC)回复
那之前疫情的时候部分作品由于制作原因推迟播出，算不算电视延后播放信息？而且这一段(如相关节目于中文地区有“代理发行”信息，则只可记录可在该播放平台清淅辨认相关代理资料的网络播放平台。(特别注意：日本电视动漫))应该要加上特摄作品的信息。(有部分特摄作品也会标注其代理信息)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 07:58 (UTC)回复
第一点：想法是只记录该集数最先出现的播放平台，例如“A节目在B平台的播放时间是0900，在C平台的播放时间是0930，在D平台的播放时间是1200…”，这样写实在太冗长及无谓。想法是“A节目于B、C、D平台上架。”
第二点括号内的是我个人想法，当然是不会加入条文之中。--唔好阻住我爱国（留言） 2024年4月22日 (一) 09:04 (UTC)回复
第一个的话这个不反对(反正超级战队系列特摄作品条话一般都是按散文方式写在哪一个平台上架不大受会受影响，但是假面骑士和奥特曼系列的话有可能会受到影响删内容。)第二点的话就是说所有电视类条目都得遵守该规范吗？--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 11:22 (UTC)回复
总之曾在电视广播的节目条目也适用。--唔好阻住我爱国（留言） 2024年4月23日 (二) 06:04 (UTC)回复
依MOS:CHINA，修改为“这些可能包括：在中国大陆、台湾、”。--CaryCheng（留言） 2024年4月22日 (一) 18:21 (UTC)回复
下一版本会更正。--唔好阻住我爱国（留言） 2024年4月23日 (二) 06:03 (UTC)回复
添加话题
取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/方针&oldid=82373556”