跳转到内容

维基百科讨论:互助客栈

页面内容不支持其他语言。
维基百科，自由的百科全书

快捷方式

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

本主题或以下段落文字，移动自WP:VPP。执行者：路西法人 2024年2月16日 (五) 08:51 (UTC)。[回复]

续上个月存在初步共识的讨论（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)[回复]
感觉“征求意见”更顺口，大量文书标题使用，也有栏目使用[1]。“意见征集”[2]等也可以，征集更像非定向。主名称不确定，但都可以作为别名。--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)[回复]

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2024年3月26日 (二) 16:14 (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)[回复]

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2024年5月31日 (五) 08:14 (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)[回复]

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

此前，互助客栈方针版的长度一度逾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)[回复]
检索自“https://wikicn.playgoteam.workers.dev/w/index.php?title=Wikipedia_talk:互助客栈&oldid=84856297”