维基百科讨论:互助客栈/存档3

编辑请求 2021-03-18

请求已处理

将“投诉管理员不当处理站务”的标题改回原本的“投诉虫虫飞不当处理站务”。是虫虫飞把标题上的“虫虫飞”抹去，改成“管理员”--温大善人（留言） 2021年3月18日 (四) 00:27 (UTC)

已改回[1]。—-Outlookxp（留言） 2021年3月18日 (四) 01:54 (UTC)

编辑请求 2021-05-04

请求已拒绝

请协助建立页面：「Wikipedia:长期小作品」，将之与 en 的“Wikipedia:Permastub”链接在一起（跨语言链接），并将“Template:Wikipedia essays”中的「* {{Link-en|Wikipedia:元素小作品|Wikipedia:Permastub|元素小作品}}」一行改为「* {{Link-en|Wikipedia:长期小作品|Wikipedia:Permastub|长期小作品}}」，谢谢。

我是非确认用户，没有权限做这些编辑，本想试试那个内容翻译功能，结果它告诉我服务器连接不上（

WuzgXY（留言） 2021年5月3日 (一) 16:18 (UTC)

*更正：最后一项改为「* [[Wikipedia:长期小作品|长期小作品]]」。

我受自动登出漏洞影响不能编辑原文本，只能在手机版视图再加一条评论了（

WuzgXY（留言） 2021年5月3日 (一) 16:18 (UTC) WuzgXY（留言） 2021年5月4日 (二) 00:21 (UTC)

未见建立的必要。SANMOSA _Σουέζ 2021年5月9日 (日) 01:16 (UTC)

我认为有建立的必要。原文的 perma 显然不是“元素”的含义，这是一点需修正的错误；另外我作为非确认用户想对原文作翻译，不得不请求确认用户建立此页面，还希望能再考虑一下。WuzgXY（留言） 2021年5月9日 (日) 07:09 (UTC)

你可以直接在Template:Wikipedia essays更改译名，而且你理论上也可以直接建立Draft:长期小作品页面并翻译完成后后请求移动。SANMOSA _Σουέζ 2021年5月10日 (一) 03:10 (UTC)

好的，感谢回复。但前者由于 https://zh.wikipedia.org/wiki/User:SteepPeak/Guide/Autologout 无法实现，后者涉及到创建页面，我个人尚未找到 2017 版编辑器创建页面的方法，因此也受此漏洞限制，我个人不能完成此项编辑。我已经将翻译后的文本上传至 https://paste.ubuntu.com/p/7y54Yk6DJX （文中的带协议外［内？］链可能格式有误），如能帮忙建立，感激不尽。WuzgXY（留言） 2021年5月12日 (三) 15:11 (UTC)

@WuzgXY：你能不能先尝试用流动版编辑器（在手提电话上的browser编辑）？SANMOSA _Σουέζ 2021年5月18日 (二) 02:43 (UTC)

已添加Draft:长期小作品，并已修改好 [[Template:Wikipedia essays]]，正等待草稿审核。很抱歉添麻烦了，本来能自己解决的WuzgXY（留言） 2021年5月19日 (三) 11:06 (UTC)

提请人已自行解决。SANMOSA _Σουέζ 2021年5月22日 (六) 03:13 (UTC)

方针区的存档问题

现在方针区已经太大了，我已经多次遇见不能在移动设备上查阅方针区的事情，是否有一些已经讨论完的事项能及时存档，或者移至其他的名字空间进行进一步讨论？--Lightyears_{Talk·Sign#维猫报} 2021年5月15日 (六) 10:08 (UTC)

建议多弄点儿→“方针一区”、“方针二区”、“方针三区”。^{[开玩笑的]}--安忆^Talk 2021年5月15日 (六) 10:12 (UTC)

未尝不可^{[开玩笑的]}--Lightyears_{Talk·Sign#维猫报} 2021年5月15日 (六) 13:12 (UTC)

方针核心；方针热门，入方针必刷，方针动画，方针番剧，方针音乐……方针小黑屋...^{[开玩笑的]}--ClayM300(留言讨论🧐) 2021年5月15日 (六) 13:16 (UTC)

也不要给到B站的连结，，，-- Sunny00217  2021年5月23日 (日) 14:24 (UTC)

之前谁好像说过可以启用集中讨论制度啥的。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年5月15日 (六) 15:10 (UTC)

(？)疑问:现在方针区还好，我也用手机，没发现什么问题，怎么不能查阅？--虫虫飞♡♡→♡℃※留言 2021年5月15日 (六) 15:20 (UTC)

@虫虫飞：我不是很清楚，不过您在香港我在深圳，我需要跨越虚拟混凝土或者用镜像站，这或许是区别之一。--Lightyears_{Talk·Sign#维猫报} 2021年5月15日 (六) 15:22 (UTC)

建议试一下用手机时点选桌面电脑模式，手机的模式，有很多功能都不支援。--虫虫飞♡♡→♡℃※留言 2021年5月15日 (六) 15:31 (UTC)

是桌面电脑模式，不排除是我的手机问题，但方针区的及时存档和分流也应提上日程了。--Lightyears_{Talk·Sign#维猫报} 2021年5月16日 (日) 07:37 (UTC)

就是单纯的大，页面内容多到浏览器渲染起来很慢。当然和链路也有关，VPN会有一个中转的过程，会比在香港直连新加坡服务器慢一点，反代站的话还要有解包处理再打包的过程，还要比VPN慢得多。--安忆^Talk 2021年5月16日 (日) 08:00 (UTC)

(？)疑问:能否使用类似Wikipedia:互助客栈/方针/Example的页面来储存每个讨论，然后只在Wikipedia:互助客栈/方针上使用{{Wikipedia:互助客栈/方针/Example}}这样的语句来显示讨论？或者只在主页面上保留一个前往讨论的链接，而讨论本身放在子页面进行？--Yining Chen（留言|签名） 2021年5月17日 (一) 13:13 (UTC)

方针区的问题严重吗？还是个别型号手机的问题？因为最近维基也有各种形式的问题，像我自己输入“:”“{}”经常有乱码，要复制黏贴才可以，其他人好像都没有这个问题。前些时候，vip的小工具，也只有我不能用，但最近突然又没事了。--虫虫飞♡♡→♡℃※留言 2021年5月17日 (一) 13:55 (UTC)

这样感觉和现有的存档机制不太协调。有一部分是设备和网络的原因，但最主要的原因其实还是页面太大了。现在就进行着很多个大型提案，完全可以分离一下。--安忆^Talk 2021年5月17日 (一) 14:11 (UTC)

我觉得可以利用WP:RFC或WP:CD之类的方式处理。比如将讨论时间过长的讨论转移到相应的对话页或者建立单独的RFC页面继续讨论，减小单个页面的压力。有时候页面那么大，讨论内容各种各样，阅读的心情都没有了，更别说积极讨论了--百無一用是書生 (☎) 2021年5月18日 (二) 01:38 (UTC)

我用PC，在方针版用回复功能经常显示 服务器未在预期时间内相应，但其实我的回复已经发布出去了，我觉得和页面大也有关系。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月17日 (一) 15:28 (UTC)

我这边没这个问题，其他大陆用户也遇到相同问题吗？如果用“quickedit”会否改善?--虫虫飞♡♡→♡℃※留言 2021年5月17日 (一) 22:36 (UTC)

+1，大的页面经常出“编辑冲突”的错误，有的可能自动解决，有的不会。--ClayM300(留言讨论🧐) 2021年5月18日 (二) 08:41 (UTC)

+1，遇到过。回复功能不会有编辑冲突，可视化也比较方便。--安忆^Talk 2021年5月17日 (一) 23:55 (UTC)

前两天我用回复功能编辑冲突好几次....--百無一用是書生 (☎) 2021年5月18日 (二) 01:32 (UTC)

回复功能会通过API回传整个页面内容，时常编辑有保存，但显示连线逾时。--Xiplus#Talk 2021年5月20日 (四) 08:40 (UTC)

半开玩笑的说，不妨在讨论部分引入Discuz，或者其他的BBS系统。虽然编辑冲突仍然存在，但是这样至少可以缓解讨论页的问题。——ClayM300(留言讨论🧐) 2021年5月18日 (二) 08:44 (UTC)

或者默认折叠所有的讨论，只有在主动点击查看的时候再加载内容。——ClayM300(留言讨论🧐) 2021年5月18日 (二) 08:44 (UTC)

电脑端加载缓慢的内容不见得手机端会更容易加载，有一次因为打开的标签页太多，Chrome直接崩溃了。我上一次遇到因为内存不足导致PC端浏览器崩溃的事情是还是在10年前。——ClayM300(留言讨论🧐) 2021年5月18日 (二) 08:48 (UTC)

好像没这功能（指Ajax请求段落文字），就算是用Minerva，也只有图片是懒加载…MediaWiki正常的“折叠”只是视觉上的，实际还是得把全文拉回来才行。--安忆^Talk 2021年5月18日 (二) 09:00 (UTC)

@AnYiLin：参考Wikipedia_talk:模板限制#模板限制后半讨论，认为可以从minecraft wiki引入{{LoadBox}}与{{LoadPage}}模板过来。（mcwiki:MediaWiki:Gadget-site.js、另见mcwiki:Category:Ajax载入页面）。参与者只要在有兴趣的议题按下 [阅读更多..] 之类的按钮或连结即可（像Facebook那样，显示个贴文摘要）。-- 五岁抬头雪菲（☎️·☘️） 2021年5月18日 (二) 09:25 (UTC)

但无论哪种做法，势必都会需要重新调整目前的客栈源代码结构。-- 五岁抬头雪菲（☎️·☘️） 2021年5月18日 (二) 09:29 (UTC)

赶快将无法通过的讨论存档掉就行。--Temp3600（留言） 2021年5月18日 (二) 14:43 (UTC)

同意Temp3600的建议，“赶快将无法通过的讨论存档掉就行。”现在就是太多一望而知无法通过的提案，这些提案提早存档，不但方便阅读，而且避免大家浪费时间在无法通过的提案上，例如有些新手方针还没看，就走来改方针，这类提案都可以提早存档。--虫虫飞♡♡→♡℃※留言 2021年5月19日 (三) 02:39 (UTC)

我一台能跑GPU实时光线追踪的Mac，开方针区网页滚动页面都要白上半秒钟才有内容渲染出来，方针区真的太大了。短时间内涌现大量议题讨论也是可能的事情，我建议尽快分流一些大的话题到集中讨论那里去。 --Milky·Defer 2021年5月18日 (二) 16:35 (UTC)

你确认是你的电脑垃圾吗？我的，使用桌面网页版，Chrome，系统锁定显卡为mx150，都没有这种情况。如果你说在手机上使用手机网页版或者桌面网页版显示加载有延迟，这我倒见过。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年5月19日 (三) 03:11 (UTC)

@cwek：我认为是方针区成千上万个DOM节点造成的。 请注意DOM节点的运算，预设是在CPU，算完才会开始渲染。-- 五岁抬头雪菲（☎️·☘️） 2021年5月20日 (四) 08:37 (UTC)

有本地缓存（例如图片、脚本），重新加载也就是6秒左右。也没有滚动时有明显色块撕裂的情况。可能和机器渲染效率有关，但方针现在的规模还没有达到加载缓慢的问题（像是模板扩展溢出的基本上十几秒）。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年5月20日 (四) 09:27 (UTC)

DOM处理是在CPU，当DOM节点过多时，很难保证CPU能在Frame update前完整更新DOM节点资料给GPU。-- 五岁抬头雪菲（☎️·☘️） 2021年5月20日 (四) 10:05 (UTC)

和显卡有什么关系吗…网页里也没有WebGL、CSS动画等“图形内容”。即使浏览器开硬件加速也不会用GPU算document啊（解析DOM、执行JS等），要是单纯的DOM节点巨多也没关系，主要是还有很多JS在增改它（在DOMContentLoaded的前后，这堆脚本还是各管各的，没多少协调性可言），整体就慢下来了。onload的时间会变得很长。--安忆^Talk 2021年5月20日 (四) 10:11 (UTC)

但长度过长造成困扰也是事实。其他条目照样有JS在增改它，但大部分的条目没有客栈方针区这样的LAG状况，就说明客栈方针区真的太长。建议拆分，可用子页面模式+嵌入包含时用Lua脚本让他只显示摘要或有限内容，展开完整内容则从minecraft wiki引入{{LoadBox}}与{{LoadPage}}模板（见留言#A2569875 2021年5月18日 (二) 09:25 (UTC)）。-- 五岁抬头雪菲（☎️·☘️） 2021年5月21日 (五) 04:59 (UTC)

我的意思是想说“DOM巨多的同时，又被长时间计算和增改，所以才更慢（相比单纯DOM巨多）”…--安忆^Talk 2021年5月21日 (五) 05:16 (UTC)

• 把讨论内容分流到其他页面，很影响社群阅读讨论，而且现在的问题不是很严重，我这边就完全没有问题。如果是个别用户的装置问题，不认为把讨论切割和搬到另一页面就能解决问题。现在方针区的主要问题是太多没意义的提案，很多都是“为改而改”，甚至有新手没看方针，就走来改方针，只要订立一些规则，约束一下不合理的提案，已经可以把方针区的提案大大减少。--虫虫飞♡♡→♡℃※留言 2021年5月21日 (五) 10:24 (UTC)

  因为您离服务器很近…不受传输速率（浪费在跨境中转上）所影响。现在方针区不算脚本、样式表、媒体资源等，一个网页（即/）就将近300K（别看数字比较小，但这和下载文件不一样，浏览器还要并发一些其他的资源，同时解析处理它们，上面说过了），换算起来就是十五六万字，大到能出书。--安忆^Talk 2021年5月21日 (五) 10:36 (UTC)

• 大家喜欢同一件事不断写千字文讨论，研究各种议事程序，讨论得不出自己希望的结果就不愿意存档，这样子愈来愈长也不是什么难以理解的事情啦。--Temp3600（留言） 2021年5月21日 (五) 13:25 (UTC)
• 说一个技术上可能有帮助的方向: 弄一个一键手工存档的小工具。--Temp3600（留言）2021年5月21日 (五) 13:25 (UTC)

User:Temp3600的建议很好，其实不用太复杂，像用户讨论页那样，弄一个存档小工具，方便大家把一些显然没共识的提案尽快存档，不但可以解决提案所提及的问题，而且可以避免浪费社群时间在讨论没意义的提案上。--虫虫飞♡♡→♡℃※留言 2021年5月21日 (五) 13:35 (UTC)

理论上Bluedeck的Easy Archive已经足够了，问题是这岂不是谁想存档点一下就好，打编辑战从未如此方便。--痛心疾首 2021年5月22日 (六) 09:23 (UTC)

建议订立一些存档规则，违规回退存档的可以举报。--虫虫飞♡♡→♡℃※留言 2021年5月23日 (日) 05:04 (UTC)

直接POINT处理就好何必定新方针-- Sunny00217  2021年5月23日 (日) 14:29 (UTC)

我看了下方针区发现有一些提案似乎正处于等待处理的状况，例如专题命名空间和有关新增伪命名空间的提议似乎在等人写机器人，设计一个制度解决部分速删模板挂不上去的页面的删除问题在等着更新Twinkle。像这种与其说在讨论不如说更像是等待性质的提案，是不是可以另外增设类似Wikipedia:互助客栈/方针/等待区将这些等待处理的提案放进去，这应该可以减少一定程度的内容。另外我对于虫虫飞说的“没共识没必要浪费时间讨论的提案”感到疑惑，目前方针区有哪些提案是属于这种性质，能不能提供几个实例？假设将这些没必要浪费时间讨论的提案进行存档后，能不能改善目前方针区内容过大导致有些手机无法查阅的问题？--Poontele（留言） 2021年5月26日 (三) 01:33 (UTC)

可以根据常识判断，如果提案出现大量反对票，那提案人就不好强行通过，要么就撤回提案，要么就根据反对意见弄一个新的修订案。如果还是出现大量反对，提案人坚持下去也没意义。--虫虫飞♡♡→♡℃※留言 2021年5月26日 (三) 02:35 (UTC)

编辑请求 2021-06-13

请求已处理上扬斯克的雪 2021年6月13日 (日) 09:05 (UTC)

hi，各位，我想要翻译条目，然后发现了Wikipedia:翻译请求，但是，我想“为了保持鸡巴整洁，请勿在此填写完成度。”应该并不合适，我不知道维基百科对这个内容的态度是什么，然后我注意到WP:联络我们，然后我到这里来了。--JohnFrankStar（留言） 2021年6月13日 (日) 04:14 (UTC) 还有，请问为什么“WP”也可以链接到Wikipedia？

• @JohnFrankStar：已处理相关破坏。“WP”是Wikipedia名字空间的捷径，您可以通过链接了解更多。—上扬斯克的雪 2021年6月13日 (日) 09:04 (UTC)
• @Kalicine730：好的，谢谢您。:) --JohnFrankStar（留言） 2021年6月19日 (六) 08:33 (UTC)

编辑请求 2021-06-28

请求已拒绝-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

您好，我已在“中华民国中古车出口建设研究协会”编辑"英文"板本:

https://zh.wikipedia.org/w/index.php?title=Special:%E5%86%85%E5%AE%B9%E7%BF%BB%E8%AF%91&page=%E4%B8%AD%E8%8F%AF%E6%B0%91%E5%9C%8B%E4%B8%AD%E5%8F%A4%E8%BB%8A%E5%87%BA%E5%8F%A3%E5%BB%BA%E8%A8%AD%E7%A0%94%E7%A9%B6%E5%8D%94%E6%9C%83&from=zh&to=en#suggestions

请求协助后续发布，谢谢~--ucc（留言） 2021年6月28日 (一) 02:49 (UTC)

invalid-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

有三个网址希望补充一下一些重要资讯

https://zh.m.wikipedia.org/wiki/B.1.617譜系 https://zh.m.wikipedia.org/wiki/B.1.1.7譜系 https://zh.m.wikipedia.org/wiki/B.1.351谱系 希望补充项目： 主要症状 重症率 致死率

如果知道主要症状或许就能够提高染疫者的警觉 Geni0809048212（留言） 2021年6月30日 (三) 07:29 (UTC)

编辑请求 2021-07-08

请求已拒绝-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

请求开放建立振宇五金股份有限公司条目。--Sam2468083（留言） 2021年7月8日 (四) 03:55 (UTC)

invalid-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

编辑请求 2021-07-12

请求已拒绝-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

请管理员协助将以下意见移至“有关台铁EMU500型电联车与台铁EMU600型电联车改造中的资讯有必要留吗？”一节，感谢。

• 改造中的资讯过于琐碎，并不是维基百科所需要的，而且这些资讯只有短时间内才有效的资讯，并不是长期有效的。依照WP:NOTIINFO不应保留此资讯。--111.243.16.179（留言） 2021年7月12日 (一) 16:47 (UTC)

invalid-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

编辑请求 2021-07-22

请求已拒绝：无内容。--东风（留言） 2021年7月26日 (一) 16:13 (UTC)

修改部分页面内容--Villager8787（留言） 2021年7月22日 (四) 07:10 (UTC)villager

编辑请求 2021-07-23

请求已拒绝。--东风（留言） 2021年7月26日 (一) 16:15 (UTC)

您好。 因为我原来的条目“儿童文学作家张友渔”被删除，我不晓得为何被删除。 删除后，张友渔的网页搜寻结果，本人也就是张友渔是女性，照片却被置换成大陆同名同姓已故男性张友渔作家。 请问，我该如何将张友渔（作家）这条目，修改成儿童文学作家张友渔， 以便与大陆已故作家张友渔做出区别。 照片被误植、错置，让人非常忧郁。 恳求这里的高手帮忙，谢谢。--Jeeptaiwan（留言） 2021年7月23日 (五) 07:28 (UTC)jeeptaiwan张友渔

@Jeeptaiwan：您可前往WP:DRV申请复核，此处并非恰当的求助位置。--东风（留言） 2021年7月26日 (一) 16:15 (UTC)

（节删）

注：此处原有文字，因为和互助客栈关系不明确的留言，已由Wolfch (留言)于2021年8月4日 (三) 22:27 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。

关于Wikipedia talk:互助客栈

建议将Wikipedia_talk:互助客栈（或是包含其子页面）以标题黑名单半保护，并自订提示导到WP:VPH。看起来是有新手搞不懂（可能还不是少数）要去哪里求助，造成困扰。-- Sunny00217  2021年7月15日 (四) 03:15 (UTC)

可是客栈各页面都被那群（节删）LTA搞臭到半保护n个月(条目探讨14天而且我发言不久即将到期(LTA一定不死心然后该页被大概率补上3个月)，方针1个月到8月6日，求助57天到8月18日，消息、技术和本页直接到十月)(至于跟维基百科无关问题的WP:ASK则是一周到本月19日)，把新手都挡之门外，那些不友善的页面对新手来说就跟不存在无异，还是要让他们去IRC还是找管理员还比较有可行性。-- Matt Zhuang表示有事按“此”留言 2021年7月15日 (四) 03:51 (UTC)

更新：不出所料，条目探讨保护一结束又有LTA用Open Proxy破坏而再度被半保护到十月。-- Matt Zhuang表示有事按“此”留言 2021年7月16日 (五) 08:48 (UTC)

或者临时将在Wikipedia:互助客栈编辑提醒，加上其他渠道的联系方式，例如IRC、telegram等，方便转走沟通。不过某位虫虫飞黑的孜孜不倦确实令人“叹为观止”。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年7月16日 (五) 02:22 (UTC)

@Cwek：完成。--Txkk（留言） 2021年7月24日 (六) 06:51 (UTC)

求助版不该被保护的！-- Sunny00217  2021年7月16日 (五) 13:35 (UTC)

或者你去说服虫飞飞辞职或者说服那位整天喊虫飞飞辞职的那位收手呗。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年7月24日 (六) 07:00 (UTC)

在求助版发“求助，为什么我编辑不了求助版” 囧rz…… --Yining Chen（留言|签名） 2021年7月25日 (日) 02:44 (UTC)

求助，因为无法求助。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年7月25日 (日) 05:04 (UTC)

Wikipedia:回退、封禁、不理会，不是保护吧 囧rz……-- Sunny00217  2021年7月27日 (二) 02:37 (UTC)

如果不保护的话，就会变成猫捉猫鼠的游戏吧。干脆保护长久一些，他愿意“等待只因渴求”那就无计了。（摊手）——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年7月27日 (二) 02:54 (UTC)

LTA:QCHM

受制于千村狐免及其傀儡实施的长期破坏，使得互助客栈和知识问答的讨论受到严重影响。永无止境的半保护抹杀了IP用户的言论自由。所以，如何在不半保护客栈和知识问答的情况下防止千村狐免继续扰乱或人身攻击？过滤器还是标题黑名单？

以下是千村狐免的常用内容：

• 虫飞到鼻孔里怎么办？
• 虫子和车子什么关系？
• 所谓《讣告》（节删）

--爬行数码1903 2021年8月2日 (一) 05:20 (UTC)

过滤器一直都有，但效果逐步不太好。（LTA也说过这个用户有一定的技术基础）——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年8月2日 (一) 05:40 (UTC)

最佳解决方案：在方针里写明禁止非自动确认用户编辑WP:VP及WP:RD。^{[开玩笑的]}--Yining Chen（留言|签名） 2021年8月7日 (六) 04:29 (UTC)

• 这些东西LTA用字符值（代码）来写，所以可以解释到为何挡不了。--MCC214（Sign | Contributions） 2021年8月23日 (一) 11:00 (UTC)

延长互助客栈的存档时间

希望将互助客栈，只少是方针的存档时间改为10天。因为WP:7days要求7天无发言但又8天存档，结果经常要人打捞，不然很容易错过议题，被存档，不利讨论。ghren🐦吱吱吱...🔊 2021年11月8日 (一) 16:07 (UTC)

现在不就是 10 天存档吗？T: Village pump page header：“10月29日之后没有新回应的议题会移动至相应的讨论页或存档。”

7 日无发言。公示 7 日。公示开始，编辑一次，说一声。公示结束，再编辑一次，总结。然后 10 日后存档。所以最快也是 24 日后才存档。 — 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2021年11月8日 (一) 16:32 (UTC)

• 我更希望vip延伸到7日存档。现在3日存档很容易漏过lta的傀儡。Itcfangye（留言） 2021年11月9日 (二) 00:24 (UTC)

公示7日，将WP:VPP的存档时间延至10天。ghren🐦吱吱吱...🔊 2021年11月17日 (三) 11:08 (UTC)

十日了。--路西法人⛧ 2021年11月25日 (四) 18:16 (UTC)

我去请求更改了。--ghren🐦吱吱吱...🔊 2021年11月26日 (五) 08:47 (UTC)

为什么WP:VPA重定向至此？

总感觉A和“求助”不怎么搭调啊？总感觉A对应article，即条目，照理来说应该重定向到Wikipedia:互助客栈/条目探讨才对啊？--Liuxinyu970226（留言） 2021年12月10日 (五) 01:12 (UTC)

ask？桐生ここ★[讨论] 2021年12月10日 (五) 01:23 (UTC)

如果这样，那岂不是Wikipedia:知识问答更沾边？！--Liuxinyu970226（留言） 2021年12月10日 (五) 04:41 (UTC)

Village pump，VP。--安忆^Talk 2021年12月10日 (五) 07:09 (UTC)

Assistance. -Mys_721tx（留言） 2021年12月10日 (五) 07:12 (UTC)

请求协助存档

我打算帮助这里存档一年前（更近期也可以）的存档（我有开小工具），不知道各位有意见吗？如果没有请@我。另外如果有其他页面积存需要存档也可以一并向我说明。--Evesiesta 2022年8月21日 (日) 14:32 (UTC)

Wen WanYi

Wikit2022（留言） 2022年9月25日 (日) 03:12 (UTC)于文晚一，我尝试编辑，它有显着的参考 qnd 做中文翻译，但 contect 说上个月翻译不好，我不知道该怎么办。我需要帮助做中文翻译Wikit2022（留言） 2022年9月25日 (日) 03:12 (UTC)

WP:共识与WP:移动请求协调等

由于有人认为在页面及其讨论页发起的移动请求，在被转入互助客栈后属于提案，按Wikipedia:共识#互助客栈的公示／免除公示程序及公告等步骤处理，不适用Wikipedia:移动请求：“一般来说，移动请求将在提出请求七天后依据其讨论页之讨论结果处理”，因此提出以下问题：

• 1. 被转入客栈的移动请求经逾七日讨论并达成共识，可否据此共识移动？应否遵循客栈提案的公示／免除公示及公告等步骤？

如以上问题一否一应，衍生以下问题：

• 2. 被转入客栈的移动请求经逾七日讨论并达成共识，处理此请求的管理人员是否有权不经公示／免除公示及公告等步骤，据此共识直接移动？
• 3. 经客栈逾七日讨论、达成共识但未经公示／免除公示等步骤的移动请求，经机器人自动存档转出客栈后，可否免于客栈提案通过程序，据移动共识直接移动？
• 4. 经客栈逾七日讨论、达成共识但未经公示／免除公示等步骤的移动请求，经请求者、管理人员或其他人手动存档转出客栈后，三者分别可否免于客栈提案通过程序，据移动共识直接移动？
• 5. 若不转移移动请求的讨论，仅在客栈设置链接以导向相关移动请求的讨论，其他情形不变，第1、2问答案为何？会否改变？

无关移动请求，亦有客栈提案通过相关问题：

• 6. “提案”为何？
• 7. 如在客栈中有条目等页面编辑提议，提议者或其他人可否在此提议停留在客栈期间，不经公示／免除公示等步骤，实施与此提议一致或近似的编辑？如否，此提议自动或手动存档转出客栈后，又可否如此为之？
• 8. 如在客栈中有条目等页面编辑提议经多日讨论后达成共识，提议者或其他人可否在此提议停留在客栈期间，不经公示／免除公示等步骤，实施与此提议一致或近似的编辑？如否，此提议自动或手动存档转出客栈后，又可否如此为之？
• 9. 如在客栈中有求助性请求，可否不经公示／免除公示等步骤，满足其请求？如否，达成共识后，又可否如此为之？

此外，Wikipedia:共识#互助客栈有极重大漏洞：

• 10. 只规定客栈提案的公示通过、免去公示通过、微小修订通过的条件；未规定无定语或状语的“通过”本身的条件，或前述三者是客栈提案通过的唯三管道。即法理上任何人可不经公示／免除公示／微小修订规定在客栈宣布通过任何提案，包括方针指引修订。（也许有人说确实如此，以上问题全部白问了；或许也有人说前者说法游戏维基规则，该方针实质上暗示“若要通过，理应公示，除非例外”。）

--Gohan 2023年1月20日 (五) 09:03 (UTC)

这是为什么我在一个月前提出修订WP:共识，涉及共识的必须明确表达意见，当进入公示程序时，管理员需插手确认有没有问题，这样的做法可以解决上述问题。--唔好阻住我爱国（留言） 2023年1月20日 (五) 17:16 (UTC)

先决问题是上述请求需不需要公示，此前又有多大比例确实公示。--Gohan 2023年1月21日 (六) 01:40 (UTC)

互助客栈的编辑提示

目前，互助客栈所有子页均使用相同的编辑提示，其中包含一个推荐的讨论格式。但这个讨论格式不适用所有子页，也有新手向我表示在求助版提问时对编辑提示感到困惑。很明显，“问题背景、我的观点、我的解决方案、比较条文”完全不适用于消息、求助版，在条目探讨和其他版也只有部分话题适用。考虑到互助客栈属于高流量页面，且目前使用组提示套用至所有子页，若要一页一提示会需要大改引用关系，所以在这里发起讨论。最基础地，至少应该要在消息和求助版移除这个讨论格式，条目探讨和其他版也应该考虑移除掉。希望得到大家的意见。--Tiger（留言） 2023年1月23日 (一) 15:14 (UTC)

本来就只有方针版有这个提示，是有人自作聪明改的。--Xiplus#Talk 2023年1月24日 (二) 03:14 (UTC)

都几年前的事了 囧rz……--SunAfterRain 2023年1月25日 (三) 05:45 (UTC)

支持，又有多少人在方针版用这个格式呢 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月24日 (二) 13:45 (UTC)

咱觉得直接把那段限定在方针版才能看到就好了吧--SunAfterRain 2023年1月25日 (三) 05:45 (UTC)

• 应改回去。--Temp3600（留言） 2023年1月28日 (六) 16:20 (UTC)

现在编辑提示没有存档提示了。--Gohan 2023年1月31日 (二) 06:07 (UTC)

大幅增添[石油峰值]的内容

{{翻譯自|en|Peak oil}}--ThomasYehYeh（留言） 2023年4月19日 (三) 04:10 (UTC)

只展示模板名称及所调用的参数而非模板本身。--Evesiesta_{Die Gedanken sind frei!} 2023年5月13日 (六) 10:47 (UTC)

本页面格式问题

本页格式自“Wikipedia:互助客栈/技术#吾改Module:High-use前欲论之”开始有不正确的缩进，个人猜测有Lint错误导致未闭合的标签影响到后方的其他章节，烦请各位技术帝协助查看更正，多谢！--Evesiesta_{Die Gedanken sind frei!} 2023年5月13日 (六) 10:40 (UTC)

Wikipedia:互助客栈/方针有办法先存档吗？

快爆了。--窝法乙烷 儿法梦碎 2023年7月26日 (三) 14:25 (UTC)

@Milkypine：最近应该有一批讨论会存档。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年7月28日 (五) 05:37 (UTC)

引入WP:请求评论取代互助客栈方针板及条目探讨板功能

续上个月存在初步共识的讨论（Wikipedia_talk:请求评论#引入WP:回馈请求服务与WP:请求评论），再次提出引入WP:请求评论机制。目前，我经已开始开发负责运行请求评论的机器人（Wikipedia:机器人/申请/LuciferianBot/5），并有初步成功的测试结果。WP:回馈请求服务尚未引入，英维也暂时没了这个服务，似乎也并不至于必须即时引入。@参与上次讨论的用户@0xDeadbeef、Ghren、Ericliu1912、94rain、Hehua、S8321414、魔琴、Taeas：--路西法人 2024年2月5日 (一) 16:35 (UTC)

提案内容

中文维基百科目前使用互助客栈作方针指引修订及条目探讨，运作多年算是运行得不错，但有重大的缺陷需要正视：

1. 互助客栈方针及条目探讨二板块常年存在过长问题（大于100KB），常有载入缓慢或留言储存缓慢的问题；
2. 用户无法长期追踪特定方针指引／特定页面的修订讨论，因为无法自动选择性订阅特定讨论主题；
3. 条目探讨板的讨论往往是条目讨论页迁移过来，难以追踪。

以上两个问题均能通过RFC系统解决：

1. 将讨论回归至各条目及方针指引页面讨论页，不再会轻易造成过长讨论页面。
2. 回归讨论页后用户可简单通过监视页面（或请求评论列表页面）即能达到追踪讨论的效果。

请求评论曾被指“效果不佳”、“难以引导用户参与”，但最近一次试行证明，在未有广发通知的情况下，讨论参与度并不亚于客栈的各提案。若往后配合WP:回馈请求服务，自然能更加鼓励关注及参与讨论。另外，中维设有公告栏，亦是公告社群邀请参与讨论的方式，改用请求评论并不会削弱公告栏广邀意见的效果。

由此，在技术问题已经开始解决的背景下，我谨此提出正式引入WP:请求评论，逐步取代互助客栈方针板（即本页）及条目探讨板的功能。请求评论的讨论方式与现存在互助客栈及集中讨论的方式无异。建议互助客栈方针板在请求评论引入后，转型为就方针指引修订及订立提出初步概念及讨论的场所；而条目探讨板则全面废除，在用户有需要请求更多人意见时使用RFC召集意见，避免迁移讨论。若有共识采纳，亦需修订共识方针相关规定，将RFC纳入接受的场所之中。 --路西法人 2024年2月5日 (一) 16:35 (UTC)

讨论

请踊跃发表意见。--路西法人 2024年2月5日 (一) 16:35 (UTC)

(～)补充：目前互联群中有机器人定期自动推送公告栏的公告事项，RFC亦可考虑新增类似功能，向互联群自动推送讨论主题，以增加讨论曝光度。--路西法人 2024年2月5日 (一) 16:37 (UTC)

支持。其实我觉得即使没有RFC/回馈请求服务机器人也可以这么做：讨论可以仍然在互助客栈发起，当讨论较长时，可以直接移动到RFC下的独立页面 / 方针或条目讨论页，然后互助客栈保留一个"讨论通知"并且暂不存档。公示了也可以在客栈通知下。--及时雨 ^留言 2024年2月5日 (一) 16:49 (UTC)

现在不是讨论过长的问题，而是同时存在十几个议案，每个都不一定过长，但合起来就很多。更何况“移动”讨论的部分才是最可能流失讨论者的情况，从一开头就在别处会比较好。--路西法人 2024年2月5日 (一) 17:07 (UTC)

因为互助客栈方针板将“转型为就方针指引修订及订立提出初步概念及讨论的场所”，所以感觉还是不能做到一开始就在对应讨论页，需要移来移去？--及时雨 ^留言 2024年2月5日 (一) 17:44 (UTC)

方针板所谓“初步概念及讨论”，是指用来提出方针指引相关的问题（若，真正讨论订立、修订方针则不在此处理。若自问题延伸出方针提案，那么最好以“发展出方针修订／订立提案”总结原讨论，并在对应讨论页发起新讨论。请求评论的主要目的是更方便追踪特定话题，如果在客栈提出议案则难以让监视方针页面及讨论页的用户追踪话题变化。

最重要的一点：不要再用机器人剪贴移动讨论存档，这导致难以追查留言修改、deltalk等情况。客栈讨论不应再存档至原始讨论页，而是以原是讨论页发送讨论通知时提供连结取代。--路西法人 2024年2月6日 (二) 02:44 (UTC)

是要直接替代全部职能？还是先以分拆冗长讨论为主？基本上我认为互助客栈话题与条目讨论页请求评论可以并行，前者本来是一种集中讨论，而后者则是提升条目讨论页讨论热度的管道之一，没有一定要谁取代谁的问题。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月5日 (一) 19:15 (UTC)

我认为条目探讨板功能应完全由RFC取代。40个完全不相关的主题集中讨论毫无意义，追踪条目及其讨论页的编者实则完全无从追踪客栈的讨论。既然目前实则要求先在条目探讨页试图解决争议再上升客栈讨论，那么即存在必然之讨论转移，除了难以追踪讨论变化外更容易造成参与者流失。故应修改规定，条目探讨页无法处理，不再转移至客栈讨论，而是原地发起RFC邀请其他编者参与。

方针板可另议。--路西法人 2024年2月6日 (二) 02:49 (UTC)

支持引入，但取代一事仍有疑虑，应当在试用中进行决定。--在下荷花，请多指教（欢迎签到） 2024年2月5日 (一) 23:57 (UTC)

@Ericliu1912：他的原话是“逐步取代”，因此做法自然是逐步逐步来，但具体怎样逐步逐步来他没有明说。个人认为先以分拆冗长讨论为主确实是合适的第一步棋。@Hehua：但其实我们已经试用过一次了。Sanmosa _{Défendre jusqu'à la mort} 2024年2月6日 (二) 00:46 (UTC)

这个当然是没问题的，我的意思是在未来的使用中进行检讨。--在下荷花，请多指教（欢迎签到） 2024年2月6日 (二) 05:55 (UTC)

我并不反对以评论请求制度分拆既有话题中较长的讨论，甚至可以立即推动。但通常要等讨论持续加长以后才能判断是否分拆的。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月7日 (三) 00:44 (UTC)

由于现行WP:共识#提案讨论及公示时间的规定（7DAYS）是只有在互助客栈的提案才需要遵守如此规定，因此有必要考量是否需要要求RFC的提案同样遵守7DAYS规定，或是索性直接废除该从一开始就不该存在的规定。我个人会倾向于仅保留“正当合理的意见”的定义，其余一概废除。Sanmosa _{Défendre jusqu'à la mort} 2024年2月6日 (二) 00:55 (UTC)

@Hehua、Sanmosa：取代一事，第一步一定是完全废除条目探讨板（理由已前述，若有疑虑可至上面回应），同时可以不再将方针板订为唯一可以修订方针指引的有效场所，并要求讨论要么在相关方针指引页发送通知（包括发起讨论、公示等），或者直接在相关方针指引页讨论，鼓励编者在合适的场所提出，而避免在难以追踪、集合数十个不相关话题的互助客栈讨论订立和修订方针。方针板大概不会被完全取代，始终必须有一个场所给人问方针相关的问题。--路西法人 2024年2月6日 (二) 02:54 (UTC)

支持。--在下荷花，请多指教（欢迎签到） 2024年2月6日 (二) 05:56 (UTC)

不反对这个做法。Sanmosa _{起视四境　而秦兵又至矣} 2024年2月6日 (二) 09:51 (UTC)

想问一下目前相关机器人的运作方式？--冥王欧西里斯（留言） 2024年2月6日 (二) 01:20 (UTC)

请参阅维基百科:机器人/申请/LuciferianBot/5说明。--路西法人 2024年2月6日 (二) 02:55 (UTC)

稍微看了一下机器人的运作效果，不反对正式引入WP:RFC（可能需要修订Wikipedia:共识#征求外部意见以形成共识一节），同时废除互助客栈的条目探讨子板面，至于方针板届时应该改说明就可以了。--冥王欧西里斯（留言） 2024年2月6日 (二) 03:07 (UTC)

不支持过度依赖RFC，只有涉及可能需要长时间的长篇讨论的话，才有需要一个专门的讨论页面，也就是类似RFC的方式来解决。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月6日 (二) 12:54 (UTC)

原因？讨论谈论据，没论据就只能当您这是个人观点而非讨论的论据。--路西法人 2024年2月6日 (二) 14:11 (UTC)

同意Cwek的观点（注：此句为厘清回复性质添加）。实际上集中讨论也有不同于分散于各该条目讨论页的好处，编者不需要再同时反复来回查阅多个讨论页，尤其是部分涉及许多条目的讨论。所以纵使禁止直接在条目探讨区提案，至少仍应保留其汇整集中讨论的门户作用。当然，目前大多数编者的习惯仍应是追踪互助客栈讨论，为此监视一众条目讨论页及个别话题者应属极少数。另外提案人可能忽略的一个重点是也有人根本不监视任何页面，而是定时查阅互助客栈讨论（这种作法仍然是相当有效的）。尝试在短时间内以制度强制改变编者习惯并不实际。故就仅涉及单一条目的讨论而言，虽然可以考虑在未来推行回归以条目讨论页为基础，但仍需要有较长时的过渡期。是以现阶段个人亦不支持直接废除条目探讨区（及其讨论功能）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月6日 (二) 14:18 (UTC)

若技术上可行，应该考虑先鼓励改成嵌套条目讨论章节，这样既可以保留互助客栈集中讨论的特性，并保留个别情况直接使用互助客栈页面的弹性，也应当可以避免提案人所说讨论搬移的情形。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月6日 (二) 14:27 (UTC)

逐点回应：

• 编者不需要再同时反复来回查阅多个讨论页并不准确，首先理论上若条目探讨区所有讨论都是按规则发起，理应全部都要先在条目讨论页讨论过，这时理论上所有参与讨论的负责任用户都必须翻阅过往讨论才能了解前文后理，客栈等集中讨论模式实际并无解决这个问题（反而产生了缺失原始讨论的问题，因多数讨论都不会整串移动）。更何况，负责任的编者更是需要翻查条目的过往其他讨论，实际上仍然有来回翻查的需要，条目探讨区的存在反而变相导致编者不会特地去翻查过往讨论。
• 同时，在同一页反复来回查阅完全不关联的主题实则上并不具备效率，在长长的客栈中等候载入才能点章节连结，还要很常走过头翻到其他不相关的讨论，实则上更是降低了讨论效率。
• 条目探讨区并非直接删除，而是废止不再作讨论之用，实质操作可如阁下所言禁止提案。条目探讨区可添加嵌入如维基百科:请求评论/全部的请求评论列表，自动追踪讨论，而不再需要人手发通告。
• 部分涉及许多条目的讨论应改以开请求评论子页面讨论。涉及多个条目不是垃圾场般推到客栈同时进行毫不相关的讨论的原因。
• 有人根本不监视任何页面，而是定时查阅互助客栈讨论，请求评论仍有讨论列表，“点去章节”只是变了“点去讨论页”，根本没分别，显然不是“客栈优胜于RFC”的问题。
• 嵌套整串讨论在早前不知道什么时候已证会产生很多问题（见T:集中讨论重定向编辑历史）。

以上。--路西法人 2024年2月6日 (二) 14:39 (UTC)

目前涉及较多条目的话题，基本没有所谓“垃圾场般推到客栈同时进行毫不相关的讨论”，多半是紧密相连的几个条目。例如上次华侨相关讨论，明明讨论内容实际上都是一个议题，但有人偏要一个独立条目拆出一个讨论话题，这当然不比整体讨论再同时存档至三、四个页面要好。此等状况是实际存在而非孤例的，也是符合编者讨论惯性的。我想具体怎么处理这种话题，社群可以详细讨论（例如用机器人同步讨论至其他条目的讨论页之类），但我想应该没有必要为了推进制度“踩一捧一”，开头就“垃圾不离嘴”贬抑他人讨论习惯，一竿子打翻一船人吧？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月6日 (二) 15:42 (UTC)

“垃圾场般推到客栈同时进行毫不相关的讨论”写的是“同时进行毫不相关的讨论”，不是“涉及多个条目的讨论毫不相关”，而是“涉及多个条目的讨论与客栈其他议题不相关。客栈的实践方式确实是“什么都可以过来开”，客栈确实是垃圾场般运作，只是送来的是五花八门、互不相关的讨论，而不是垃圾而已。--路西法人 2024年2月6日 (二) 16:01 (UTC)

另外还存在一种话题，就是不针对特定条目，而是比较广泛存在的现象发起的讨论。这之中固然有部分情况可以归类于维基专题（也就与条目讨论页类似），但也有不强调特定主题而不适合硬性归类者。强行为这些讨论指定发起标的条目讨论页是非常不合理的。我想提案人没有注意到的是，互助客栈并不只是“个别条目讨论的集成”，而实较之更加复杂得多。个人认为，激进地废除直接讨论功能、以评论请求制度取而代之看似理想（至少理论上还挺自洽），但与互助客栈现实运作情况则略有脱节之虞。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月6日 (二) 16:09 (UTC)

（编辑冲突）—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月6日 (二) 16:10 (UTC)

就广泛现象的讨论，则显然适合另开启独立的请求评论页，从来未曾要求发起讨论必须在对应讨论页而不能另开请求评论页，这一点在我2239的留言也有提到（应改以开请求评论子页面讨论）。请不要选择性阅读。--路西法人 2024年2月6日 (二) 16:16 (UTC)

请求评论独立页面应只适用于较长篇幅而有个别讨论需要的话题。为了保持页面列表“纯洁性”而动辄设立单独子页面，不仅效果甚差，实际上也是毫无必要。现在这样运作的提案方式，本身有什么问题（注意：这与页面载入等技术问题无关）？这是典型的“没坏别修”。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月7日 (三) 00:44 (UTC)

现在这样运作的提案方式，本身有什么问题，提案及其他回复中已详述技术问题以外的其他原因（需翻查过往讨论、无法主从特定议题等），加上技术上的问题，显然不是没坏。请求评论独立页面应只适用于较长篇幅而有个别讨论需要的话题又是一个观点而没论证原因，为何涉及多个条目而讨论篇幅未必长的就不能开请求评论页？为何就必须跟其他话题堆在同一个“集中讨论”的客栈？--路西法人 2024年2月7日 (三) 06:11 (UTC)

一、唯一认同引进相关制度的理由，只有部分页面确实存在话题堆积的问题，这也是众所皆知了。但阁下显然过度夸大互助客栈页面载入及浏览相关章节时间所产生的负面效应。不然章节及页面导言的目次及topic list是设计来做什么的？凡是知道怎么利用这些工具的人，都不会轻易为上述问题所困扰。何况只要等待一个长页面载入，与改成在不同页面之间反复横跳耗费的总时间加起来对照，也不见得会比较好。是哪一种方式讨论效率比较差，还很难说呢。

二、实际上，包括互助客栈在内，几乎所有站务页面都是如此运作，以一个或多个主题为核心，聚集所有相关讨论。除了讨论总长度，我不认为互助客栈方针区与条目探讨区及其他一部分站务页面在讨论格式上有决定性区别。真要说的话，互助客栈消息区消息之间、求助区求助各该话题之间，或者档案存废讨论各讨论之类，差不多也都是互不相关，但归根究底，客栈页面（及多数站务集成页面）本来就是如此设计的——在宗旨是讨论“条目、模板、主题相关”事项的页面提出“条目、模板、主题相关”的话题，这本身并没有问题；互助客栈其他区块及大多数站务页面同理。我想不应该为了宣称评论请求制度的“优越”，反过来批评这样的讨论形式叫做“垃圾场”。我认为这是不公道的。退一步说，就算这么多页面的运作方式真的都像垃圾场，那也没关系吧？凭什么社群讨论页面不能以垃圾场的形式运作？

三、“‘点去章节’只是变了‘点去讨论页’，根本没分别”并不符合事实，实际上光所需步骤就多了一倍，而且会随欲参与的讨论话题数量等距增加。互助客栈（及多数站务页面）聚集相关讨论的一个好处在于，编者在浏览自己本欲参与主要讨论的同时，也有很大机会“顺便”就其他话题发言（如果实际参与过任何社群讨论，就知道这有多么容易），结果就是得以有效扩大社群在许多讨论的参与（或许也可以视为“维基兔子洞”的缩小版？XD）。我不知道这是不是当初页面设计所预期的情况（或许维基讨论系统本来就有这样的特点），但其效果则是明显可见。不要小看编者讨论的惯性；制度是设计给人类，而不是给一群“讨论机器人”用的。强制分拆请求评论回各条目或方针与指引页面，甚至于禁止直接在客栈提案（条目探讨而言），将客观上大幅增加参与讨论的成本，削减编者在主要讨论以外针对更多话题发表宝贵意见之动机。道理很简单，若要参与十个来自各条目或政策话题的讨论，却要在不同页面之间来回点击数十次，我想至少相当数量的编者衡量机会成本，肯定将放弃参与许多本有讨论潜力的话题，只专注于自己最偏好的几个主题。就增加话题平均bias程度而言，这是不是利大于弊呢？

四、我非常怀疑多少人有“自动追踪所有特定话题相关讨论”的需求。许多编者大概不会为了参与单一话题的讨论，就希望自动订阅所有类似话题。无论条目探讨或方针，大概都是如此。当然，必须指出，这方面需求也并不是不存在，所以就引进评论请求制度、增进条目讨论页讨论热度本身而言，个人并没有特别反对的理由。甚至先推动分拆既有冗长讨论以为测试，评估该制度在本地运作效果如何，亦无不可，反而还挺欢迎的。但是在未有实证研究佐证相关正面效果且有完全替代作用的情况下，不尝试推动该制度与既有互助客栈页面并存“良性竞争”，而是企图直接取而代之，则恐怕操之过急。从过往实际参与讨论的经验，我完全认为两种提案方式各有利弊，不应该径行独尊其中一种。无论如何，在彻底推行如此巨大的变革之前，社群也应当完全有权利以试行的形式观察相关制度运作情况。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月7日 (三) 00:44 (UTC)

回：

1. 以我相当不错的网速在客栈方针板储存一次留言需要10秒以上的时间，不同于在其他板块不足3秒就完成储存，即显然为缓慢载入；我网速已经算不错，对网速更慢的人来说显然会更加吃力。再者，超长页面亦会存在点选章节标题后浏览器跳错位置的问题，这是我仅在互助客栈发现的问题，其他讨论页均不存在，这显然已经展现客栈已经长到会导致技术问题。
2. 几乎所有站务页面都是如此运作，并没看到如此。AIV的共通点是全部都是破坏提报、RFPP全部都是保护提报，范围定义明确；而我长久诟病的AFD、DRV格式正是如客栈般容易导致过长且相关业务范围过广，导致难以查找过往记录。VPD各讨论的唯一共同点是“需要其他用户注意／提供意见的条目”，这个业务范围显然已经过广。并不是请求评论制度优越，而是目前客栈、AFD等制度是真的垃圾。VPO、VPN、VPT等板块我尚能理解是没有其他位置可以放的讨论所以集中处理，VPP、VPD显然是有其他更合理的位置放讨论，根本就不应该需要集中讨论的主题。
3. 社群页面本来就按照业务有分列不同板块，本来就是在找寻不同板块的路途上跳来跳去的。更何况，条目也是每一个主题放在不同标题之下，也是需要点来点去的，编辑多个条目的用户本来就习惯在监视清单跳来跳去。如果“跳来跳去”是如此不方便，要不要弄一个页面是集中全站所有业务来“提高用户参与度”？所以“跳来跳去”会成问题一点本来就是站务精才会有的问题。要做什么就该去那个地方，不应该因为不方便而不去做。不方便就不做的就是陋习，不值得鼓励。
4. 阁下说我非常怀疑多少人有“自动追踪所有特定话题相关讨论”的需求，却遗忘了维基百科最大的重点是编辑条目的人。这些人监视自己编辑或有兴趣的条目的同时，必然会自动追踪了对应的讨论页（这是MediaWiki设计）。多数编者都会有参与自己有兴趣的条目的讨论的需求，但互助客栈的设计显然没有推动到这一点。
5. 再者，我说过十万遍：分拆讨论才是万恶之源，理论上应该什么话题都直接在对应的讨论页（或者开全新的请求评论集中讨论页）处理，这样才不会出现讨论流失。阁下非常清楚这一点，却要求先行推动“分拆讨论”，这显然无助检视请求评论效果的同时，会反向营造请求评论不好用的非建设性效果。我完全无法理解为什么阁下这么爱提出毫无建设性、反而对议案存在反效果的建议，这里是如此，ArbCom讨论亦是如此。这不是制度间的“良性竞争”，而是以手段去伪造公平竞争，然后伪证一方无效；更何况平行运行两个不相容的制度根本无助任何编者参与。

--路西法人 2024年2月7日 (三) 01:47 (UTC)

回复收到了，但不认同，而且认为上述宣称有很大商榷空间。其他的等过年完再详细说。我也想好好过年放个假的。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月7日 (三) 02:51 (UTC)

我不知道评论请求本来是否打算针对冗长之条目及政策讨论而言？毕竟提案一开始就指出互助客栈讨论过度冗长为一大理由，那我想多数人预期该制度对于较长讨论特别有效，也应该不差错。怎么会是反过来“营造请求评论不好用”呢？显然并不会是这个意思。那我就不太理解阁下反对先行以此制度分拆部分较长讨论来试验评论请求制度效果的理由了。如果这样提议就会招致“毫无建设性”、“存在反效果”的批评，那若全面在所有形式相关讨论实施该制度，社群就大概更要有疑虑了吧？还是说此制度实际上对分流篇幅较小的讨论比较有效？个人确实搞不懂。或许是措辞有模棱两可之处，导致误会。

有一个前提需要注意：依据实际观察经验，目前条目探讨区的讨论，反而实际多次搬移者较少，而多是直接在互助客栈发起，尔后再存档至讨论页；尤其是涉及多个条目者，自然倾向一次在客栈提案讨论，而不是在多个条目同时发起话题。此一现象的本质或有可批评之处，但基本上我不认为“讨论流失”是用评论请求全面推翻目前互助客栈运作形式的主要理由。至于如何照顾监视条目者，我想在不涉及评论请求的情况下，有一个明显更简单且有效的解方，那就是直接在条目讨论页寄发通知；这个方法过往也有其他人用过，符合本地社群实际运作情况，而且或许还更方便（半）自动化；只要侦测存档至模板填入哪些对应讨论页，就可以用机器人或人工自动寄发通知。如果再搭配评论请求制度，提升条目讨论页本身既有讨论的热度，相信将能充分发挥互补作用。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月11日 (日) 15:44 (UTC)

至于目前相当一部分话题直接在互助客栈而非条目讨论页发起的“问题”，若既有情况如此，则或许我们更应该先检讨这样的规定是否符合设计初衷，还是已经脱离社群实践共识而需要修订了？又例如同时承认两种方式的效果是不是比较照顾倾向使用不同提案方式的编者？诸如此类建设性问题，大概都比反过来直接批评这种“劣迹”要得体一些。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月7日 (三) 01:06 (UTC)

为什么垃圾就不能被批评？同时承认多种制度反倒造成更多规则漏洞，根本就不是建设性，而是给予机会编者更懒更不愿意去遵守合理的规定。不要自以为是地觉得提出伪公允观点就是“公平”“良性竞争”，实则带来更多反效果。--路西法人 2024年2月7日 (三) 01:50 (UTC)

只能说这多半是价值观及理念上差异，你谈你的理论，我讲我的经验，大家各自畅言，汇聚意见，把多一点可能性摊开来，自然能够促进提案完善；就算无法尽善尽美、让所有人满意，至少也能说有好好交流过了。我想阁下并没有在此必要上纲上线给他人安个什么“伪公允”的帽子，不然以后都别讨论或认真写论述，也不用假装请社群“踊跃发表意见”（引开头语），互相拆台就得了。这样无礼的作为才是真正的自以为是。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月7日 (三) 02:56 (UTC)

发表意见的基础在于推论和反驳，但阁下发言屡屡漏洞百出，我指出阁下发言的漏洞、批评阁下推论有问题、批评阁下的“观点”看似公允实则反效果居多、批评制度的腐烂，却又成了我上纲上线、我不接受意见。--路西法人 2024年2月7日 (三) 04:13 (UTC)

我（大概）也没说过自己的观点是（最）“公允”的，所以所谓“伪公允”议题应纯属虚构。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月11日 (日) 15:51 (UTC)

口说“公平竞争”却说自己期望的做法不是公允，这不就自打嘴巴了吗？不公允的建议如何公平竞争？--路西法人 2024年2月11日 (日) 16:04 (UTC)

或者可以这样说，我的想法是与其直接作废，不如把条目探讨区改造成提案人所说的一种“请求评论列表页面”，这样就不用再生造一个页面出来。当然具体怎么改可以再商量。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月6日 (二) 14:42 (UTC)

条目探讨区既然不再作讨论之用，实则即是废除。导向新制格式与废除不冲突，WP:VPD废除后挂{{historical}}同时提供导向RFC列表两件事可以同时发生，正如WP:HAM也可以提供连结按账号查询存档至SPI的用户查核记录一样。--路西法人 2024年2月6日 (二) 14:48 (UTC)

完全可以沿用页面本身。傀儡调查分立页面的原因，主要是因为性质产生重大变化，且中间有数次更迭。相关列表显然从头到尾都是要用作汇整条目相关讨论用的，所以若没有打算保留原页面之作用，则不需要新开一个页面。我觉得我们单纯在这个议题上不存在冲突。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月6日 (二) 15:25 (UTC)

维基百科:请求评论/全部并非仅收录条目相关讨论，显然不适合整个放在废除后的VPD；同时我从来没说过要开一个新页面去放条目相关的讨论列表，从来都是在说在VPD直接放置非维基百科专案相关的列表，完全不理解阁下是在“不需要新开一个页面”是在说什么。--路西法人 2024年2月6日 (二) 16:06 (UTC)

既然如此，那就好啦！—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月6日 (二) 16:10 (UTC)

必须注意，阁下眼中的“RFC”只是社群目前使用请求评论系统的冰山一角，并非所有RFC都需要专门设置一个页面去处理RFC，而是可以直接在讨论页挂RFC模板邀请其他用户参与，阁下所言的“类似RFC的方式”根本就不是这个提案要提的“RFC”。--路西法人 2024年2月6日 (二) 14:21 (UTC)

首先感谢LuciferianThomas的在理论和技术上的贡献。(＋)支持当前提案。另外请提案人适时起草修订WP:RFC。并请注意最近一次试行使用的是集中讨论而非请求评论，具体到某个主体下的讨论效果还未有实践。考虑到有些编辑不经常参与站务讨论，建议在提案通过后，给活跃用户发消息。

主题破碎，海涵。--落花有意12138 2024年2月6日 (二) 16:14 (UTC)

必须注意请求评论和集中讨论并非互斥的措施，请求评论容许共识框架下的任何讨论方式，集中讨论是其中之一。“集中讨论而非请求评论”并不准确，RFC/RFA2024是“集中讨论模式的请求评论”，只是因为RFC尚未正式启用而未使用有关RFC模板而已。--路西法人 2024年2月6日 (二) 16:20 (UTC)

您说的对，我这里的意思是RFA2024是全站的讨论，区别于特定主题之下的讨论，理应更多人讨论。所以需要试行查看后者的讨论效果。

另外其他发言内容我默认您看到了。--落花有意12138 2024年2月8日 (四) 16:27 (UTC)

如果要建立话题索引，界面大概可以沿用目前topic list的样子？看起来还不错。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月7日 (三) 01:06 (UTC)

大致同意，客栈反而是经常监视关注的地方，也考虑到部分议题可能长期讨论下去可能变长而不便阅读和推进讨论的问题。所以我还是维持意见：小讨论可以保留在条目探讨、方针版上，但如果有可能讨论长期大幅增长或有必要长时间讨论的，可以用RFC解决，并保留一个路径在客栈版上链去，而不是破除传统做法。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月7日 (三) 05:45 (UTC)

请阁下回应我所指，“将进行中讨论分拆至其他讨论页导致流量及参与度下降核心问题，而当（大多数）讨论本身就在适当的讨论页发起才不会存在这个问题”。另外，仍未见阁下论证观点，“传统做法”不等于“必然适合继续运行下去”，所谓“传统做法”似乎只是有坏仍不修的借口。--路西法人 2024年2月8日 (四) 16:08 (UTC)

这不是为了论证，而是一个观点，我就这么认为，也不要求你去认同这个观点。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月10日 (六) 10:46 (UTC)

那么就当您这是观点而非反对（议案特定部分）的意见了。反对意见需要论述，观点确实不需。--路西法人 2024年2月11日 (日) 00:33 (UTC)

建议深思，避免到时候被当成公示时排除“有效意见”考量的借口。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月11日 (日) 06:52 (UTC)

不对提案进行实则性点评的意见、并非正当合理的意见，以及与提案本身无关的意见，皆不视作此条文所指的“新留言”与“相关意见”。此为共识方针条文，不是排除有效意见“借口”而是“正当理由”。--路西法人 2024年2月11日 (日) 09:25 (UTC)

“引进评论请求”跟“互助客栈转型”基本是两个互不妨碍的议题。那既然没人反对前者，那应该已经可以开始提出制度运作细节，准备部署相关技术了。毕竟目前评论请求在本地几无有效运用，这也是客观事实，所以我想无论是要支持还是反对用这个社群相对陌生的讨论形式来改革互助客栈，都需要引进本地实际运作以后才知道具体效果究竟如何。目前参与讨论者意见所云“试用”大致如此，而这与提案人所说的“逐步取代”也应该不相违才是。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月11日 (日) 06:49 (UTC)

我唯一可以给的让步是在客栈方针板及条目探讨板大字置顶建议改用请求评论制、嵌入请求评论的讨论列表等，否则无鼓励自然没人用，完全无法比对效果。建议的大字置顶通告如下：

由于客栈板过长导致载入及储存过慢等问题，用户可以改用请求评论系统请求更广泛意见；〔影响一整个主题的讨论／关于现有方针指引的探讨〕则在此发文。〔请建立新的请求评论子页面讨论影响多条方针的修订案。〕

同时在共识方针关于互助客栈的章节添加通告：

应2024年X月社群共识，使用请求评论系统的讨论亦执行以下规定。方针将于稍后修订。

不同意在完全无鼓励的情况下直接引入请求评论，用户难以接触新系统的情况下，一来难测试新系统的效果，二来会自动给予“请求评论效果不佳”的结果。望能同意以上第一阶段鼓励转移的妥协安排。--路西法人 2024年2月11日 (日) 09:22 (UTC)

既然如此，您也应该意识到在这种情况下直接废除互助客栈既有讨论制度不太可行了吧。个人当然没理由不支持用评论请求分流讨论缓解互助客栈压力——而不是直接取代——甚至可以考虑在相关方针与指引明文写出“先在条目讨论页提出讨论，（回响不大的话）进而提出评论请求，（涉及较广泛条目或确有其他必要时）最后才是在客栈提案”的“三步骤”建议。当然，还是希望能提出评论请求在条目讨论页的执行细节，现在看起来似乎还比较不明了（尤其跟回馈请求服务好像还有一点混淆？我感觉评论请求在本地实际上比较接近前者的角色）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月11日 (日) 15:17 (UTC)

我并不认为不应该废除客栈，只是阁下一直坚持，而我也说过是分阶段，那么阶段可以改，以让议案推进，但最终目标仍没改变。不要猜度我的思想，妥协不等于放弃。--路西法人 2024年2月11日 (日) 15:27 (UTC)

请求评论单纯就是挂个模板，让机器人自动载入需要邀请广泛意见的讨论而已，并无特别的执行细节。回馈请求纯粹是RFC的延伸部分，透过机器人发讯息随机邀请用户参与关注了的主题的讨论而已，并非RFC的必然构成部分。--路西法人 2024年2月11日 (日) 15:29 (UTC)

您可以不放弃革命，我也不非要“独尊”旧制度，但总是不应该拿客栈当实验场。我始终相信不用以推倒互助客栈为起手式，也能妥善运用评论请求。至于其效果是否有好到可取彼而代之，就得让社群评断。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月11日 (日) 15:44 (UTC)

贵站问题在于爱造轮子，将别人运行得非常成功的制度不必要地左改右改，出错的位置却也总是与别人不同的部分。“Village pump”、“客栈”如其名，只是设计来非正式议事的地方，贵站却越改越偏，变成“议事厅”的款式，“互助”更是无稽之谈。阁下对着“互助客栈”这个标题，在这么不正式的场所却用来正式议事，没觉得过怪吗？究竟现行的真的是“旧制度”，还是“走偏不成原样的老制度”？--路西法人 2024年2月11日 (日) 16:20 (UTC)

@其余参与提案讨论的用户@94rain、Hehua、Sanmosa、S8321414、落花有意12138：：是否同意首阶段采上述折衷方案（见此留言）？若无异议，请问各参与用户（及@Ericliu1912君），是否同意让此折衷方案按Wikipedia:共识#非方针指引相关提案简易规定免除公示并于达到简易规定条件的三日后执行？--路西法人 2024年2月12日 (一) 13:09 (UTC)

不反对。Sanmosa _{起视四境　而秦兵又至矣} 2024年2月12日 (一) 13:11 (UTC)

觉得可以。--Borschts^{™ 欢迎外带一碗罗宋汤} 2024年2月12日 (一) 16:37 (UTC)

同意。--在下荷花，请多指教（欢迎签到） 2024年2月13日 (二) 00:16 (UTC)

不反对。--冥王欧西里斯（留言） 2024年2月14日 (三) 23:31 (UTC)

首先声明，我未仔细阅读上面的讨论，故仅就提案内容发表意见。我认为，所谓三大缺陷，至少对我而言均不存在。一、我尝试载入条目探讨页面，结果5秒左右（估测）能完全载入，这一速度可以接受，并且可以在同一页面阅读和发表对多个议题的意见，较为便利。（但是，如果只关注一项议题，则浪费了载入其他议题的时间。）二、维基百科的回复功能，点击订阅即可订阅二级标题下的更新，并不麻烦。三、使用move from，move to等模板，似乎也没有难于追踪的问题。不过，虽然如此，我并不反对，乃至支持推广RFC机制，如果真能鼓励讨论的话。Fire Ice 2024年2月11日 (日) 17:11 (UTC)

较为便利：这个便利建基于什么都混在一起，如我上面所说，要“便利”的话，不如所有专案页面都集合在同一页面下？显然“便利”不是一个合理的解释原因。

点击订阅即可订阅二级标题下的更新：本来就不是指追踪单一话题，而是单一主题下的所有话题。如果一个人要追踪“可供查证”相关方针讨论，则必须手动前往客栈查看有没有相关话题再订阅，而RFC（回归讨论页）就只要监视页面（自动监视对应讨论页）即可追踪所有相关方针讨论。

使用move from，move to等模板，似乎也没有难于追踪的问题，丧失所有编辑历史，难以查找留言编辑、删除记录，甚或是否曾被伪造都难以查证，始终客栈有十数万编辑。

以上回复。--路西法人 2024年2月11日 (日) 17:32 (UTC)

初步的议题分类（方针、条目探讨等），将每个页面的话题限制在几十个，因此初步分类有合理性。至于追踪方针讨论，只能说可能有人有这种需求，要关心某一方针的每次讨论。--Fire Ice 2024年2月12日 (一) 01:28 (UTC)

方针只是讨论的范畴之一。互助客栈只能提供监视两个页面，且包含大量读者未必感兴趣的话题；WP:RFC光是机器人支持分类的主题就14个范畴，别说追踪个别条目、方针，追踪整个主题的讨论都还行；客栈就难以提供不重复、不冗余的讨论索引。我不认为一个页面有“几十个”讨论算是合理，尤其是各讨论之间实则近乎无任何关联之时更是不合理，跟把AFD和AIV合并在一起没什么分别。--路西法人 2024年2月12日 (一) 02:29 (UTC)

---

折衷方案（见此留言）已获三名用户同意按非方针指引公示规则处理，如无其他异议将于2024年2月16日 (五) 00:16 (UTC)后生效执行。--路西法人 2024年2月13日 (二) 04:09 (UTC)

( π )题外话：“请求评论”翻译腔太重，可否改为“××咨询／征询××”之类的地道说法？避免再像这个名称引人误入歧途、（基本）不服务过客的地方被称为“客栈”（旅客服务设施）一般积重难返、残留20年。虽然此前并不迫切，但要设立恒常制度，以改名为宜。--— Gohan 2024年2月13日 (二) 08:16 (UTC)

“意见征求”？台湾及大陆等地都有在用。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月13日 (二) 08:27 (UTC)

感觉“征求意见”更顺口，大量文书标题使用，也有栏目使用[2]。“意见征集”[3]等也可以，征集更像非定向。主名称不确定，但都可以作为别名。--YFdyh000（留言） 2024年2月13日 (二) 09:02 (UTC)

可以在正文中使用，如“评论请求是维基百科社群征求意见的一种手段”之类。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月13日 (二) 14:31 (UTC)

不反对。--— Gohan 2024年2月14日 (三) 04:35 (UTC)

既然系统取名自RFC备忘录，那么翻译也最好参考该备忘录。该条目来源1提供了数个翻译选择，其中就有请求评论。如此，既然“请求评论”本身足够准确地说明了系统的功用，且有来源支持这个翻译方法，我不认为有改变目前名称的需要。最少也不像客栈那样，不是互助也不是客栈。--路西法人 2024年2月13日 (二) 09:01 (UTC)

该备忘录纸面上有中文名称吗？在来源1中也有出现“意见征求”。--— Gohan 2024年2月14日 (三) 04:45 (UTC)

看似没有中文版。既然目前翻译正确也没歧义，那么自然没需要改。--路西法人 2024年2月14日 (三) 04:51 (UTC)

互助客栈名称是历史遗留，求助等版块是互助的，不感觉是什么问题。没有将争论等完全分流是管理问题。--YFdyh000（留言） 2024年2月13日 (二) 09:04 (UTC)

大字通告应该明确什么“应该”在此讨论，什么“可以”请求评论。建议改成：由于客栈板过长导致载入及储存过慢等问题，用户可以改用请求评论系统请求更广泛意见；但关于现有方针指引的不涉及修订的探讨则应在此发文。影响多条方针的修订案建议创建新的请求评论子页面讨论。

另外，这个修订案相当于引入了请求评论机制，所以建议稍后根据实际进一步修订WP:RFC和WP:DR。--落花有意12138 2024年2月13日 (二) 11:57 (UTC)

可。--路西法人 2024年2月13日 (二) 12:22 (UTC)

个人认为应该确立实施细节（及操作方法）才正式引流，不然编者被引流去了也不知道怎么做。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月13日 (二) 14:31 (UTC)

WP:RFC本来就有操作指南，这一点从来就不是问题；落花有意建议的调整仅是改了“应”“可”等优先次序，全部都不是绝对性用词，也只是强烈建议、没做到时可作提醒的做法，实施细节基本已定。--路西法人 2024年2月14日 (三) 00:01 (UTC)

对仅部分编辑同意或者提案者只挑选认同意见后就强行推进提案的做法感到诧异，我依然保持认为应该保留客栈简易的提案讨论方式，RFC用于预期需要长期或详细讨论的提案；如果希望无论大小，提案都应该用RFC解决的话，应该保留在客栈上带出简易的讨论链接指引来引导编辑前往参与讨论。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月14日 (三) 02:16 (UTC)

后者“提供连结导向”本来就在上方我与Ericliu的辩论中已指出是取代客栈二板块后会做的事情；阁下持续未能就观点提出推论和理据，却径称我挑选意见、强行推行。对于阁下没读讨论就发言、不就自己观点提出理据而强行要他人接受您的观点等不负责任的讨论操守感到诧异。--路西法人 2024年2月14日 (三) 03:46 (UTC)

目前他应该是接受了折衷意见，只打算要在互助客栈页面置顶说明而已（吧）。希望不是我眼花了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月14日 (三) 14:39 (UTC)

我上次查阅的时候还有若干未本地化的内容，既然已经清理完毕，就没什么问题。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年2月14日 (三) 14:42 (UTC)

---

已执行折衷方案。望社群能学会“对的地方做对的事”。--路西法人 2024年2月16日 (五) 00:56 (UTC)

@Ericliu1912：请协助复检执行效果是否符合阁下现阶段期望。--路西法人 2024年2月16日 (五) 02:52 (UTC)

本页上方那个存档是否做成折叠的

已经有20个年度了，是否考虑折叠或者省略一部分早年的年份，在另一页（如Wikipedia:互助客栈/技术/档案馆）展示全部存档页面？（互助客栈其他页同。） --达师 - 370 - 608 2024年3月16日 (六) 05:59 (UTC)

我直接试着改了，参考Wikipedia:当前的破坏/存档，您看可不可以。--Cookai饼块🍪_{（💬留言）} 2024年3月16日 (六) 06:57 (UTC)

客栈的都改好了。--Cookai饼块🍪_{（💬留言）} 2024年3月16日 (六) 11:16 (UTC)

重要：涉及限制互助客栈条目探讨区讨论之政策修订

近月有若干修订共识方针提案，将限制编者在互助客栈条目探讨区发起讨论，大略意涵如下：

一、禁止在互助客栈条目探讨区发起“仅影响单一条目的讨论”（也就是涉及单一条目的讨论，例如讨论“最大政党列表”条目之原创研究问题等），也禁止将此等讨论移动至客栈，只能发送讨论通告；

二、禁止在互助客栈条目探讨区发起“影响多个属相同主题的条目的讨论”（也就是涉及多于一篇类似领域条目的讨论，例如讨论“中华民国”及“台湾”条目之架构等），也禁止此等讨论移动至客栈，只能发送讨论通告；

三、在互助客栈条目探讨区发起“影响多个属相同主题的条目的讨论”时，应当在主题条目发送讨论通告（但我不确定这是什么意思）。

因提案影响既有权益甚大，却未曾通知日常使用互助客栈的多数编者，故在此特别予以公告提醒，请编者注意并踊跃参与相关讨论。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月18日 (六) 10:01 (UTC)

以下则纯粹是个人意见：提案若获得通过，代表目前客栈条目探讨区超过三分之二提案都将遭到取缔，只能改置所谓“讨论通告”，根本形同废除；至于讨论通告究竟有多少用处，请参见目前征求意见制度成效，本人实际参与条目相关话题的经验是从冷清到平淡左右。互助客栈有许多显性及隐性功能及作用是单一讨论页所难以取代者，我认为此提案未考虑客栈实际运作情况，纵然移植外来制度，企图以行政手段改变流行习惯，为所谓“确保各讨论页获得善用”（提案理由）箝制编者选择讨论管道之自由，损害运用客栈页面讨论之公益，是错误的形式主义及官僚主义政策（完整论述在讨论页）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月18日 (六) 10:01 (UTC)

老实说我觉得这么做会严重分流潜在的讨论参与者。就比如我来说，我会偶尔逛一下互助客栈、看看大家的讨论、有兴趣就发表意见，没有就离开。但是那些用rfc的我几乎不会点进去看，除非有人ping我。不过路西法君的话也在理，全部都挤到互助客栈确实造成页面过大、难找diff之类的问题，如果社群能接受这些缺点我觉得倒也不必强推一定要到讨论页讨论。因为不是针对该条文的意见我就发在这里了。--微肿头龙（留言） 2024年5月18日 (六) 11:26 (UTC)

反对此提案。这属于是彻底与本讨论区的初心（详“维基百科:互助客栈/条目探讨/存档/2010年10月#建议维基客栈增开“/条目”分栈”）相违背。我认为现状至少令人勉强满意，没有改动的必要。—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2024年5月18日 (六) 23:33 (UTC)

@王桁霽：原来当时就有讨论了，正反意见还与今日相去不远。不过依据过往经验，您单纯在这里讲是没有用的 :( —— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月19日 (日) 11:18 (UTC)

互助客栈条目讨论区同样自创立至今都有任何条目或模板的交流应考虑先在其讨论页发表，而若无人加入讨论才可在此发起。（后半句直至RFC启用前都仍然存在）的要求，本讨论区自设立之初更是有跟当今提案意义完全相同的要求（任何条目或模版的问题、疑虑、怀疑、参考文献、有关文章的论战或者评论应该先在相关的条目讨论页提出来并在讨论段落加上{{indiscussion}}模板，最近7天在条目对话页上的讨论会出现在讨论索引，而若无人加入该讨论才在此发起，若否则可能被移动回{{Moveto}}原条目讨论页，讨论页指导方针亦在此适用。），现在全部讨论塞在这里才是真正“彻底与本讨论区的初心相违背”的体现。贵站用户选择性“初心”的操作真的很难看。--路西法人 2024年5月21日 (二) 00:39 (UTC)

你说得对，路西法人，我选择性初心的操作真的很难看，太难看了。问题是我也不是没有用过条目讨论页，被搭理的情况微乎其微。—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2024年5月21日 (二) 03:09 (UTC)

楼上王桁霁君说的的确是，在讨论页发起讨论很大概率不被理会。我前几天在Talk:1954年克里米亚转交事件和Talk:苏阿战争挂了rfc至今无人参与讨论，可见社群有多么不重视rfc。（Talk:1954年克里米亚转交事件的那些讨论是在挂rfc前讨论的）。另外，最近@LuciferianThomas的机器人好像没发讨论邀请，难怪没人参与。请不要告诉我去ping人，因为有时候我不知要ping谁。--微肿头龙（留言） 2024年5月21日 (二) 03:25 (UTC)

依据我目前正在公示的版本，以Talk:苏阿战争为例，你应直接先跟作出争议编辑的用户交涉（就ping他一个），然后无法达成共识就ping过往参与编辑有关主题和条目的用户，从页面历史中都ping一下就已经是了。仍没人参与再请求外部意见。

另外，“不被理会”始终在于客栈目前仍然是有大量话题，#正在广泛征求意见的议题一节自然难以引起注意；机器人坏了是因为User:Ericliu1912非常善心地手痒破坏了机器人自动阅读列表的格式@Special:Diff/82499812。--路西法人 2024年5月21日 (二) 03:57 (UTC)

再者，共识方针本来就有当无法透过讨论页讨论时[…]，维基百科还有几套既定的流程去征询外部编者的意见。共识本来就是从小讨论慢慢展开到大讨论，“征询外部编者的意见”的前提是“当无法透过讨论页讨论时”。现在配备了更多机制供在原始讨论页讨论，但现况显然是“没有充分尝试”而非“无法”。--路西法人 2024年5月21日 (二) 00:53 (UTC)

大概的看法和一些实际操作来看：一般情况，只针对特定条目或者模板的单一页面的讨论问题，应该是先在讨论页讨论解决，在无法在单一页面达成讨论共识（可能需要更大范围的共识讨论）甚至范围扩大的情况时，才拉到条目探讨版处理。也存在预期需要更大范围共识讨论（或者认为对应讨论页关注程度偏小而寻求更瞩目的关注）的情况下，就出出现一步拉到条目探讨版而非先在对应讨论页讨论的情况。现有的调整意味着以明文的方式限制后一种情况，但这可能与实际操作上存在矛盾，所以虽然过往的规则上是希望循序渐进，但实际上存在这样的跳岛路径。至于是否为了保证现在为先单一讨论页进行讨论同时为了保证引起关注而利用（或者从提案者的角度来看，更像是推广自己的成品）讨论提醒机制的情况，我认为还是尊重现有的做法，当然爱循规蹈矩的和爱用那东西的，随便。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月21日 (二) 02:41 (UTC)

WP:IAR，法则仅仅是原则而非死例。就条目讨论共识，我还是不认为限制位置或者使用工具的方式。我认为条目探讨版还是可以作为更高可见度的条目内容探讨或讨论的主要板块。该愿意在这里讨论的还是这样做，愿意用RFC或者讨论提醒的就让他们去吧。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月20日 (一) 00:48 (UTC)

互助客栈（或是任何讨论）存档到空的讨论页需改为加上Template:Talk header

例如这个部分，当机器人存档到一个空讨论页时，会自动加上存档模板。但问题是有时目标本身就是一个正常的讨论页，加上存档模板不合常理。因此希望这个机制改一下，正常页面就改成用{{Talk header}}加注，存档页面才是存档模板。台湾杉在此发言 (会客室) 2024年6月18日 (二) 04:20 (UTC)

副知@Jimmy Xu。台湾杉在此发言 (会客室) 2024年6月18日 (二) 04:21 (UTC)

没必要必须加上Talk header模板吧,如果都要加的话，不如善加利用MediaWiki:Talkpageheader--百無一用是書生 (☎) 2024年6月18日 (二) 07:33 (UTC)

@Shizhao：我刚刚看了看历史版本（顺便恢复了），以前一段期间（二〇一三年左右）曾预设有Talk header，乃尔后经社群讨论停用。您当时还有参加讨论XD —— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月18日 (二) 20:03 (UTC)

不如直接邀请当年放模板的@Liangent及讨论参与者@Gakmo、Bluedeck、Jasonzhuocn来发表意见（才发现连同Makecat全是管理员啊）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月18日 (二) 20:06 (UTC)

都加有违该模板的文档。--YFdyh000（留言） 2024年6月18日 (二) 12:49 (UTC)

@Taiwania Justo：其实应该改成要加上专题模板，条目可以没有Talk header（甚至大部分没必要“割鸡用牛刀”），但多半要有归属专题。机器人可考虑检测是否有WikiProject banner shell，若无则显示错误讯息，请使用者加上以后才会自动存档。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月18日 (二) 15:20 (UTC)

都可以，只要能解决存档目标页面的判断就行。台湾杉在此发言 (会客室) 2024年6月18日 (二) 17:34 (UTC)

我甚至忘记存档到空讨论页会加上那个公告！其实主空间应该都是不需要的。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月18日 (二) 19:59 (UTC)

机器人检测WikiProject banner shell没必要--百無一用是書生 (☎) 2024年6月19日 (三) 02:57 (UTC)

有关互助客栈方针版的长度压力问题

通过：

公示期间无合理异议。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月24日 (五) 01:23 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

---

此前，互助客栈方针版的长度一度逾60万字节，在我搬运了若干已结束或stale了的讨论后才降到40多万，然而这个长度还是比起其他互助客栈的版块来得长（互助客栈其他版的长度现在是20多万字节，条目探讨版是10多万，消息、技术与求助版不超过10万），而且在页面载入与编辑上也产生了一些问题（我在电脑尝试载入或编辑页面的话，页面完全载入所需的时间显著地延长了）。有鉴于此前曾有讨论提议以WP:征求意见机制取代互助客栈方针版的机能，我认为现在是合适的时机来提出这件事情。Sanmosa _新朝雅政 2024年10月23日 (三) 00:30 (UTC)

就着我对互助客栈条目探讨版在讨论递进机制开始试行后的情况的观察，在依照WP:共识/讨论页及共识方针试行案#试行条文第1a及1b条搬运部分讨论串后，互助客栈条目探讨版的运行状况大致良好。考虑到大部分的方针指引提案一般只涉及或主要涉及一个方针指引页面，我认为这个情况与WP:共识/讨论页及共识方针试行案#试行条文第1a及1b条所述的情况是类似的，因此我认为可以考虑对只涉及或主要涉及一个方针指引页面的方针指引提案实行同样的要求，以较大程度上减轻互助客栈方针版的长度压力。当然，有鉴于部分方针指引提案会同时主要涉及多个方针指引页面，又或是部分提议新立方针指引的提案起初并无对应的条文页面（与WP:共识/讨论页及共识方针试行案#试行条文第1c及1d条所述的情况类似），因此我并不寻求直接废除互助客栈方针版，我认为互助客栈方针版在现阶段还是存在保留的必要性的。Sanmosa _新朝雅政 2024年10月23日 (三) 00:39 (UTC)

@LuciferianThomas、Ericliu1912。Sanmosa _新朝雅政 2024年10月23日 (三) 00:43 (UTC)

我认为相对条目探讨板而言，方针板还是有部分存在的必要，比如探讨设置新方针或机制（但未有任何预备条文）的情况还是要有一个地方讨论。其余小修订既然已经有bulletin负责公告，那我不觉得一些不大不小的修订有什么维持在客栈方针板讨论的必要。--路西法人 2024年10月23日 (三) 01:18 (UTC)

是的，所以我有特别说明我并不寻求直接废除互助客栈方针版。Sanmosa _新朝雅政 2024年10月23日 (三) 01:46 (UTC)

我现在都不敢点开互助客栈/方针，通常会让浏览器无响应10s以上 囧rz……--自由雨日🌧️（留言｜贡献） 2024年10月23日 (三) 04:41 (UTC)

几周前，那些大讨论存档前，我用手机测试了一下。以这个版本为例（⚠️慎入！Firefox F12模式情报: 完成: 18.72 秒；DOMContentLoaded: 10.96 秒；load: 13.48 秒）；用【历史版本→编辑源代码→预览】来看，后台计算就要CPU 使用时间: 4.577 秒；实际使用时间；5.756 秒。用手机点下互助客栈实测要心中默数12秒才会开始出现内容(但不至于浏览器无响应，其他功能仍可操作)，测试地点台电大楼站、5G网络、450Mb/s。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年10月26日 (六) 23:28 (UTC)

其实此前情况更严重的是WT:COVID-19条目共识，在我处理前长度超过90万字节，我甚至连搬运已结束讨论到存档页也出现困难。Sanmosa _新朝雅政 2024年10月23日 (三) 05:03 (UTC)

如果你知道这几个月以来付诸“征求意见”的方针相关话题讨论多么冷清而惨不忍睹，就不应该认为提出舍本逐末的所谓“取代”方案是有益社群的上策。本站政策讨论的复杂乃属天然，长度是一时问题，不是持久问题。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月23日 (三) 05:32 (UTC)

我尝试抽验了2024年各月末的VPP长度，除了2月末、3月末与4月末外，没有一个月末的VPP长度是少于20万字节的，9月末的时候VPP长度甚至还将近90万字节了。而且，唯独VPP会动辄出现长度逾20万字节的情况，VPD与VPO是顶多偶然如此，但VPP的情况是经常发生。如果将近半年也算是“一时”的话，那我不相信社群有如此好的忍耐能力。说真的，要不是这个问题持续将近半年，我也不用特地为此提这个案，页面的载入问题实在令我非常痛苦。Sanmosa _新朝雅政 2024年10月23日 (三) 08:30 (UTC)

某管理员长期对于您站设备持故步自封的态度，为了合理化所谓“天然”的杂乱无章且造成极严重困扰的机制，肆意抹黑任何试图解决问题的新机制。这些人从来不考究问题是否长期存在，不考量别人是否跟他一样拥有良好的设备和网络能顺利载入不合理长度的社群讨论板块。这般不食人间烟火，只站在他自己的道德制高点的人的这种发言根本不用理会。--路西法人 2024年10月23日 (三) 17:13 (UTC)

在社群反映存在实际问题时，作为管理员的不尝试协助社群解决问题，反而事事添堵还说你说的问题根本不存在，这不是解决提出问题的人是什么（--路西法人 2024年10月23日 (三) 17:15 (UTC)

看似解决了一个问题，结果恐怕制造更多问题。此问题本无一方案完美，社群乃于多个方案中选择缺点最少者，故本人就某特定方案提出商榷意见，其来有自。至于阁下就社群若干事务实际运作观察是否全面，或你我在此议题向来之歧见等，则自是毋庸再论。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月24日 (四) 08:36 (UTC)

另查阅存档，我收回对长度属一时问题之发言，确实社群长年以来受此问题困扰甚多，本人判断不周。但此议题兹事体大，当详加检讨如何处理，而本人认为现有所谓征求意见制度运作至少相对不彰，不能当作唯一手段，有必要多管齐下。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月24日 (四) 08:45 (UTC)

就拿WT:命名常规#调整地名命名常规的规定来说吧，我当时没ping自由雨日，但他还是参与讨论了，由此可见RFC在规则讨论方面的情况应该没有你说得那么悲观的。至于如何提升讨论的参与度，我认为可以鼓励开展讨论者ping一些相关的用户，这样应该比较能够产生一些有用的意见。Sanmosa _新朝雅政 2024年10月24日 (四) 14:10 (UTC)

本来MediaWiki系统的监视功能、讨论追踪功能等都能让编者追踪自己感兴趣的页面的讨论。只是不是很多人爱善用内设功能，硬要以“便利”这个理由来制造更多混乱：这些人的主张是本末倒置地不使用设计的讨论页面，却去认为“互助客栈是天造地设”，还反指让讨论回归讨论页是“本末倒置”，连“本”是什么都没分清楚。

发起讨论通知有关编者（不论是通过@ping通知、RFC/FRS还是公告栏）是基本讨论礼仪，连这个观念都不建立好，如何期望您维人能建立良好的讨论价值？显然通知相关用户并非“可以鼓励”而是“需要”。--路西法人 2024年10月25日 (五) 02:15 (UTC)

我说的是走RFC机制以外另外再ping一次，这样做有reinsurance的效果。另外我认为用户不使用讨论追踪功能其实是可以理解的，对于不时就有新留言的讨论来说，开了讨论追踪功能以后其实还挺扰民的，这是我自己的使用经验，自从那次以后我就没再开过讨论追踪功能了。Sanmosa _新朝雅政 2024年10月25日 (五) 02:43 (UTC)

此正所以相关制度施行有必要咨询更广泛社群意见之故。盖社群以人为本，各人体验不同，故自以为面面俱到者，恐适得其反。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月26日 (六) 09:11 (UTC)

我知道你应该不是在说我，但你把我也打进你说的那类人里总归是不合适的。Sanmosa _新朝雅政 2024年10月26日 (六) 13:12 (UTC)

@Sanmosa、LuciferianThomas：两位如何看待这个讨论（注意彼讨论并非修改方针指引，恰恰是根据现存指引取消一些模板中的斜体格式）？--自由雨日🌧️（留言｜贡献） 2024年10月23日 (三) 17:34 (UTC)

这样说吧，又不是只有RFC才冷清，我看VPT与VPA也挺冷清的，就更别说VPN了，你直接go ahead就是了，毕竟他的意见只是“总是觉得”而已。Sanmosa _新朝雅政 2024年10月23日 (三) 23:34 (UTC)

补提了一些意见（ —— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月24日 (四) 09:07 (UTC)

或者像近来某些话题，在客栈提出讨论一段时间，再移步回各该方针与指引页面继续讨论，也是一种解方。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月24日 (四) 08:36 (UTC)

重点是认定话题一般讨论到什么程度才应移往他处？往年反映多是社群就特定政策议题激辩过长，以致拖累整个客栈页面，而非全部议题都有必要另起炉灶。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月24日 (四) 08:57 (UTC)

以一个一般留言长度约200至300字节来计算的话，那我认为长度逾1.5万字节的讨论就应该搬运，留言总数逾30个的也应该搬运。Sanmosa _新朝雅政 2024年10月24日 (四) 14:18 (UTC)

考虑到征求意见本质是扩大参与或关注，或可以话题发言人数为初步基准，有一定人数即可迁回各该政策讨论页。但涉及超过一个方针与指引者，则建议一概不迁移，直至讨论结束自动存档为止。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月24日 (四) 17:30 (UTC)

VPP现时还是比较少同时讨论多于一个规则的讨论串的，但如果真的有这么一个讨论串，而且还真的非常长，我认为该讨论串仍然无可避免地必须被搬运。Sanmosa _新朝雅政 2024年10月25日 (五) 00:46 (UTC)

另外，我想了一下，以发言人数为基准可能比较容易误中副车，现在的情况是有些讨论串长度非常长，有些讨论串长度则偏短，但两个讨论串的讨论人数有可能相当，比如VPP里公布管理人员任免案投票人数的提案与引入ONUS的提案（这个讨论串我搬运了）都有13人发言，但两者的长度可以说不是一个量级。Sanmosa _新朝雅政 2024年10月25日 (五) 08:49 (UTC)

长度判断或较主观。不过大可简约规定“过长讨论可予迁移”之类即可，俾编者灵活决定空间。多元议题方面，可先搁置，观察长讨论迁移情况，再做打算。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月26日 (六) 09:11 (UTC)

不行，这方面的规定不能模糊，中文维基百科的社群现在都快沦落到连什么叫“过长讨论”也能吵一通的地步了。讨论长度真的不行的话，用留言总数来判断应该也是好的。Sanmosa _新朝雅政 2024年10月26日 (六) 13:11 (UTC)

如果你的意见是要有“硬基础”，那鉴于强制规定应代表最低容许标准，我认为这种基础情况的移动初始门槛应尽量拉高，减少误判几率。若届时实际运用发现不足，再逐步调降。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月26日 (六) 13:27 (UTC)

留言总数逾30个其实也算高了，这也是我从VPP的情况看出来的结果。Sanmosa _新朝雅政 2024年10月27日 (日) 01:46 (UTC)

或者也可以改成所有方针与指引至少讨论一定期间，此后若满足人数或发言等某些要件，即可移回各该讨论页继续讨论。本来条目探讨区也应该要是这样比较好，但无奈提议不受待见。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月28日 (一) 12:39 (UTC)

另亦可提早自动存档期限（本人曾有提议，惟尚未有下文），尽早结束难有共识之讨论。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月24日 (四) 08:37 (UTC)

我记得OA2021后首次修订7DAYS时还有人说应该延后自动存档期限，这点不太好处理。Sanmosa _新朝雅政 2024年10月24日 (四) 14:11 (UTC)

就实务上来说，现在最应该做的是赶紧处理那一大篇电视格式手册讨论，看是要移动回指引讨论页还是什么的都行。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月26日 (六) 21:36 (UTC)

那个提案正在公示当中，恐怕是不能动的。Sanmosa _新朝雅政 2024年10月27日 (日) 01:48 (UTC)

总之要赶快解决，那个话题即便已经存档大部分，现在也还占了客栈篇幅至少三分之一⋯⋯ —— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月28日 (一) 12:37 (UTC)

我也想尽快解决，毕竟也维持了差不多一年，但奈何有编辑者玩程序问题（包括挤牙膏式提问+冷待回复以拖延公示+离题讨论），故另提出剪布方案避免这个情况发生，奈何该提案反应不大。--唔好阻住我爱国（留言） 2024年10月28日 (一) 15:56 (UTC)

其实我可以以讨论为持超过30日+足够共识做公示，但某管理员坚持要7日无新发言才可做7日公示。--唔好阻住我爱国（留言） 2024年10月28日 (一) 15:59 (UTC)

另外，整个讨论已有点吃力，基本上这是一个比英维相同连结的格式手册还要详尽得多好多，如果是需要由0开始写一个只有较小空间可以钻空子的格式手册中的一个分段，需要超过500个回复统整，那合理吗？

英维只用了“”English licensed”一词+维基百科不是”就能让编者知道编辑目标，到这里还要按例子解释每一句的定义及目标，最后本提案由一小段变成一大分段才能平息疑问。--唔好阻住我爱国（留言） 2024年10月28日 (一) 16:17 (UTC)

现已将版本十以前讨论全部存档。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月30日 (三) 06:46 (UTC)

就本节原始讨论的议题而言，我个人认为若是要修正既有方针指引，或是提议将既有页面升格为方针指引，最好还是都在该方针指引的讨论页提出，并透过RFC机制邀请社群讨论，至于方针板仍可提供全新提出的方针指引讨论，（如果可行的话）并将方针板顶部的RFC嵌入改为仅嵌入Wikipedia:征求意见/维基百科方针与指引、Wikipedia:征求意见/维基百科提议以及Wikipedia:征求意见/维基百科格式与命名，如此状况应该会好上不少。--冥王欧西里斯（留言） 2024年11月9日 (六) 12:39 (UTC)

@Ericliu1912：行，现在VPP的长度又突破30万了，问题主要出在留言数近或逾50的讨论串，其中一个还是你发起的。如果不尽早处理的话，那问题迟早会恶化成我一开始开这讨论串时的情况。难不成每次VPP长度过长，我就得来这里开个新讨论串吗？Sanmosa _新朝雅政 2024年11月29日 (五) 15:45 (UTC)

基本上我的意见是涉及单一方针或指引讨论有基本进展或累积一定长度者，均得移往各该政策讨论页。如果这样还不够，再看看要加上什么。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年11月29日 (五) 17:46 (UTC)

然而“搬运”这个操作真的不能省却吗？Sanmosa _新朝雅政 2024年11月30日 (六) 01:05 (UTC)

@Ericliu1912：行，现在又破40万了，现在该如何处理？Sanmosa _兰絮 2025年1月7日 (二) 04:00 (UTC)

或许应像条目探讨那样规定，仅涉及单一方针的讨论需在方针讨论页发起？--自由雨日🌧️❄️ 2025年1月7日 (二) 05:52 (UTC)

关注度那讨论快结束了。另外亦可规定仅涉及单一方针或指引者须先在自身讨论页发起话题，若实无进展再考虑移往客栈之类。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年1月7日 (二) 06:32 (UTC)

那这不就是我一开始提的案吗？那你当时说的话又有什么意义？Sanmosa _兰絮 2025年1月8日 (三) 13:12 (UTC)

任何提案都是看情况。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年1月8日 (三) 18:03 (UTC)

另外考虑到相关制度施行后实情，建议明文允许一段长时间无讨论（至少长于既有客栈讨论存档回讨论页者）时得迳移往客栈。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年1月8日 (三) 20:09 (UTC)

不建议这样做，这只会导致一个stale的讨论被不断移来移去，我甚至认为应该要限制这种做法。这也是我从实例中得出的结果。Sanmosa _兰絮 2025年1月10日 (五) 08:25 (UTC)

过往讨论很少“移来移去”。而且现行制度其实相当于把一个政策讨论“自然结束”的期限从近两周（存档回讨论页）拉长到一个月（征求意见模板撤除），前者应该优先。你公示的过程本身也很能说明征求意见的问题，整整七天都没人回。我对这种程序结果是否能真正得致共识感到忧虑。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年1月17日 (五) 14:27 (UTC)

然而你恰好就做了把stale的讨论移来移去的事情。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 08:23 (UTC)

移回客栈一次不叫“移来移去”，顶多你又移回讨论页才算。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年1月19日 (日) 10:56 (UTC)

这是什么话，一开始是我移至讨论页，然后你又将stale了的讨论移回VPP，而导致客栈长度又破20万，后来更是又破40万了。你这种说法未免有些颠倒黑白了。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 13:52 (UTC)

或者反向规定政策先在客栈讨论一段时间（曝光）后再移回讨论页，这也是一种办法。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年1月17日 (五) 14:28 (UTC)

不能这样做，VPP已经过长了。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 08:22 (UTC)

如果要在较长篇幅跟没讨论间，我宁愿选前者。何况这本也不是永远状态。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年1月19日 (日) 10:56 (UTC)

然而最近一次VPP过长是你造成的，你觉得这不是问题不代表这就真的不是问题，VPP过长早在去年10月已经被视为问题了，上面的留言（1、2）就能证明这点。说真的，我在尝试搬运讨论串以缩减VPP长度后知道你又移回部分讨论导致VPP长度再度破20万时，我是很沮丧的，这相当于我白移动讨论串了，于是我就选择摆烂了，结果VPP的长度又破40万了，这直接影响了我使用VPP，因此我也不得不停止摆烂，继续推进此案。要不是我今天再搬运了部分讨论串，我相信VPP长度破20万不成为永远持续的状态也很难。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 13:54 (UTC)

方才参照了有关条目内容的讨论的发起的规定写了这个版本。与有关条目内容的讨论的发起的规定的主要分别在于有关中文维基百科规则的讨论只要不是在VPP进行的都得走RFC，这与有关条目内容的讨论不在VPD进行也被限制使用RFC的情况不同。Sanmosa _兰絮 2025年1月10日 (五) 08:42 (UTC)

依WP:共识#一般公示基本规定，现公示此版提案7日。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 01:23 (UTC)

---

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

能否折叠一下存档

指本页面header中从2003年列到2024年的存档部分。--Fire Ice 2024年10月22日 (二) 15:49 (UTC)

@Fire-and-Ice：可以，但互助客栈的其他存档要吗？--Cmsth11126a02 (留言) 国民党的正确名称是大陆国民党！ 2024年10月22日 (二) 16:40 (UTC)

我认为都需要折叠。--Fire Ice 2024年10月22日 (二) 16:42 (UTC)

全部完成。--Cmsth11126a02 (留言) 国民党的正确名称是大陆国民党！ 2024年10月22日 (二) 16:52 (UTC)

知识问答被遗忘了。--Miyakoo（留言） 2024年10月31日 (四) 15:35 (UTC)

照着WP:互助客栈/其他/档案馆改了下。--Miyakoo（留言） 2024年10月31日 (四) 16:00 (UTC)

更新了客栈其他板的存档折叠方式，看看会不会比直接整个折叠更好（？--路西法人 2024年10月23日 (三) 00:42 (UTC)

@LuciferianThomas：感觉不错，可以套用到客栈其他各区（都留下二〇二一年至今讨论即可）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年10月24日 (四) 08:50 (UTC)