维基百科讨论:共识

共识建立的递进步骤

此讨论正在公示7天，直至2024年5月18日 (六) 02:45 (UTC)结束；如有意见请尽快提出。

推行RFC后，我发现很多人没理会非强制性的提示，导致WP:VPD持续过长。我提议调整方针，明确共识建立的递进步骤，确保各讨论页获得善用。--路西法人 2024年4月8日 (一) 09:58 (UTC)

过往提案版本，公示版本在此

所有讨论均须先在内容页面的对应讨论页发起。在讨论页发起讨论时，应发送通知（@提及或用户讨论页通告）邀请近期编辑有关条目／主题的用户参与讨论。（防止连@都没尝试@就说没人参与讨论） 若影响内容涉及多个条目： 有单一主题条目者（如此讨论）：在主题条目之对应讨论页发起讨论； 有多个主题条目者（如此讨论）：择阅读次数最多的条目的对应讨论页发起讨论，并在其他受影响条目的对应讨论页发送讨论通告（例子）。 无主题条目者：见第3点 在以下三种情况下使用意见征求系统邀请更广泛意见： 影响10个以上条目的内容（此情况亦可考虑发送类此这样的通告至VPD征求更广泛的意见） 经其他用户参与讨论但无法达成共识而需要征求更广泛意见 经通知后仍无人参与讨论，需要征求意见 在影响极为广泛（10个条目以上）而无主题条目者，则可在互助客栈条目探讨板发起讨论。互助客栈条目探讨板可以使用RFC模板以触发WP:FRS的自动通知系统。

理论上，这应该更普及推广至所有讨论。目前观察到WP:VPP的社群站务讨论方面相对克制，使用VPP和RFC的时机相对合适；WP:VPD和RFC条目主题的部分则较少被善用，因此先行提出规范条目相关的讨论。--路西法人 2024年4月8日 (一) 06:49 (UTC)

不认为应该限制编者的发言自由，设立此强制规定并无必要。方针上仅建议即可。--桐生ここ★[讨论] 2024年4月9日 (二) 23:05 (UTC)

(～)补充主要目标：防止过度依赖互助客栈，连讨论都还没尝试讨论就发出来客栈征求第三方意见，这是不好的习惯。--路西法人 2024年4月8日 (一) 06:51 (UTC)

(＋)支持：不过 2.a 预期是会在其中最多阅读次数的条目讨论页提出并使用 RFC 没错吧？--冥王欧西里斯（留言） 2024年4月8日 (一) 07:52 (UTC)

是，这个情况下互助客栈亦可，但能在条目讨论页的情况下当然是善用条目讨论页较好。--路西法人 2024年4月8日 (一) 09:58 (UTC)

另外@对RFC有比较大意见的Ericliu1912参与此讨论。--路西法人 2024年4月8日 (一) 09:59 (UTC)

这难道不是代表大家认为互助客栈讨论比较有效或能见度较高，或可谓征求意见制度在本地尚未成熟之象征？不能因此反过来认为是社群“不理会提示”的错，然后决定强迫先走一次征求意见流程吧。我认为这很明显是互助客栈这种集中讨论系统在实践上确为本地社群所好，而与讨论页相分工产生的自然现象，纵使有意愿要去调整也好，亦不当纯粹以所谓“过度依赖”视之，甚至企图（用甚强硬之措施）去“矫正”；尤以“确保各讨论页获得善用”为理由削减互助客栈职能实属本末倒置，如此贸然推动是会实际损害百科全书讨论运作的。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月8日 (一) 10:41 (UTC)

自互助客栈条目探讨板设立之初，就有任何条目或模板的交流应考虑先在其讨论页发表，而若无人加入讨论才可在此发起。的要求，此提案只是将此要求付诸实行且以RFC配合。阁下将实行客栈长年置顶的要求且提供辅助工具配合以更佳实行如其上方留言般称为“本末倒置”；那摒弃自设立以来就存在的要求、阻碍以工具实践长久以来的要求，不是真正文字上的“本末倒置”吗？“削减互助客栈职能”？什么讨论都直接送去客栈本来就不是互助客栈条目探讨板的职能，自始至今皆是如此。--路西法人 2024年4月9日 (二) 04:30 (UTC)

如果你打算以“应考虑”来反打我说的话，我可以先补一句：我现在就是提案将原先的“应考虑”改为“须”。现在我当然无法强制他人遵守，但正是自始就有这个建议做法而无人遵循，导致产生更多问题，才需要改成强制性。本来就存在的建议做法被阁下打成“本末倒置”，差点以为建议做法是写来当花瓶的。--路西法人 2024年4月9日 (二) 04:37 (UTC)

这是否代表所谓“建议做法”确实不符合本站实际？又是否有因应现阶段共识调整之需要？或可一并商榷。说不定这还真是需要“拿走”的“花瓶”。无论如何，提案限定“所有讨论均须先在内容页面的对应讨论页发起”，则显属矫枉过正。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:58 (UTC)

现在非常显然的结果就是无视这个“建议做法”会造成讨论版面过长的问题，较大程度实现RFC的站务讨论（相对于VPP）则是解决了这个问题，显然是完全符合实际的建议做法。“矫枉过正”没有有效论证如何“过正”。--路西法人 2024年4月9日 (二) 08:40 (UTC)

可以建议、甚至积极推动，但强迫实行，过度箝制编者讨论自由，则是另一回事。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 08:35 (UTC)

另外我记得当初提案人推行征求意见制度的一个理由是声称“回归讨论页后用户可简单通过监视页面（或请求评论列表页面）即能达到追踪讨论的效果。”既然此实足矣，我认为纵使要加强提倡在条目讨论页发起讨论，也不必以通知特定一群人参与讨论为必要条件（当然若有需要仍可额外提及）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月8日 (一) 10:59 (UTC)

通知参与讨论是礼仪、是推荐做法，防止有人说“你没通知我，所以这个讨论没能得到我意见”。如近期写进方针的WP:RULES#方针及指引的用词：“应”提醒不代表不能不提醒，但也不代表想不做就不做。发送通知是“应”，先在内容页面的对应讨论页发起才是“须”。请读清楚提案才发言。--路西法人 2024年4月9日 (二) 04:34 (UTC)

（涉及多于一个制度页面，改在互助客栈扩大讨论。）—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月8日 (一) 10:55 (UTC)

仅涉及修订共识方针，RFC、互助客栈没有要修订的事情，不存在“涉及多个制度”。已移回。--路西法人 2024年4月8日 (一) 23:16 (UTC)

实际上还牵涉互助客栈调整、征求意见制度推广，不只是改方针条文的事情。再说一次，不要揪著字眼不放。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:31 (UTC)

RFC已有与客栈讨论相等效力，请停止扰乱性移动讨论。相等效力的讨论不存在“扩大”讨论。--路西法人 2024年4月9日 (二) 08:10 (UTC)

不知为何坚持要使用征求意见制度，还指责我“扰乱”。名义上效力相等，实际上曝光度大有差异。此页面及相关所有征求意见页面，总浏览量仅百余次；相关提案牵涉互助客栈一区运作，本事关重大，为了社群公益，移动至互助客栈扩大讨论，有何不可？何况阁下自己也曾莫名移动互助客栈讨论去征求意见，请问是不是在“扰乱性移动讨论”？以一句“扰乱性移动讨论”塘塞了事，毫无立足点可言。若往后可以此等理由回退条目探讨区类似编辑，则又可想而知将造成何等灾难。“善用制度”跟“扰乱讨论”之别，岂得由尔一人独断？回护一种制度，应不至于如此。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 08:27 (UTC)

呵呵。客栈讨论移动去RFC是基于客栈设立以来的建议做法，并作分流之用，这无论是原有还是最新共识的置顶都支持“在原有讨论页发起讨论”的建议做法，RFC只是辅助；况且光是“客栈版面已经过长”已经是万分合理分拆讨论的例句。反倒是从来没有方针或共识支持“涉及多于一个制度”就应该移动至客栈“扩大讨论”的情况，你甚至连给在这里继续讨论的机会都没给过，怎么就成“扩大”讨论了？--路西法人 2024年4月9日 (二) 08:37 (UTC)

如果你觉得我有bias，在这里不如公开问问社群，此等重要的话题，是否得在互助客栈讨论？还是在此相对狭隘之处了结即可？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 08:32 (UTC)

(－)反对：基本上将话题发起门槛调高到涉及十篇条目以上，实际上就等于架空互助客栈；况且涉及多个主题条目者的讨论（强制）发起方法也实在过于繁琐，恐反不利于促进使用者发起讨论。在征求意见制度运作约一个月来实绩不彰（或至少不如预期，否则本不会有此话题）的情况下，恕没有理由在现阶段支持此等冒进之提案。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月8日 (一) 11:02 (UTC)

不过，既然此处言明是“渐进步骤”，那应该不禁止其他提案吧。我自己提一个较为“渐进”的建议，就是可以先从仅涉及单一条目者做起——就这种话题强制先在讨论页发起讨论（同时可以自由选择是否利用征求意见制度），一定时间后认为参与度不够，再移动到客栈来——看看这样成效如何。据我观察，互助客栈条目探讨区有一大半话题都涉及一篇条目而已，所以若此议行之有效，也足以相当程度缓解互助客栈讨论流量。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月8日 (一) 11:20 (UTC)

我赞同Eric Liu这一说法。我并不觉得征求意见系统目前有滥用情况，所以不需要限制谁要使用征求意见制度。个人不太了解客栈条目探讨区的实况，不过看起来要求单一条目的探讨强制挪到讨论页不妨是个好方案。--0xDeadbeef (留言) 2024年4月8日 (一) 12:44 (UTC)

现在不是RFC被滥用，而是VPD被滥用。先搞清楚状况才来留言。--路西法人 2024年4月8日 (一) 23:06 (UTC)

条目探讨区本来就是用以探讨条目（及模板等），而不探讨相关话题者都会予以移动，不知道哪里存在所谓“滥用”了。请不要自己想像一个平行版本的互助客栈出来。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:29 (UTC)

条目探讨去本来是用来讨论在讨论页发起过但不够人关注的讨论，这是从设立至今都存在在置顶的“原意”，未经讨论页充分讨论、未善用现在提供的工具去试图在讨论页充分讨论就跑去客栈发起议题，这显然是滥用。“把所有讨论都塞在客栈”才是与长久以来互助客栈设立的“本意”平行时空的想法。--路西法人 2024年4月9日 (二) 08:47 (UTC)

如果RFC没有被滥用，为什么要给提RFC加上前提呢？--0xDeadbeef (留言) 2024年4月9日 (二) 13:31 (UTC)

目前没有被滥用不代表永远不会被滥用。既然可以预想到RFC跟客栈同样存在“讨论还没开始就烙人”的潜在问题，而客栈明显已存在这个问题，RFC也同步实施对应限制不会有坏。当初客栈也没预想到现在的人会有这个问题，结果也是被滥用了。--路西法人 2024年4月9日 (二) 13:43 (UTC)

原谅我不能理解。我没见过RFC被滥用，我也想象不出来RFC被滥用。我个人的意见是害怕这会有WP:CREEP的问题。也许你维人太少，导致没什么可聊的话题被挂上RFC之后也没人管，也许你维人太多，你一句我一句导致VPD讨论太多。若存在有人只讨论一个条目又不在条目的talk页面发起讨论的问题的话，应当处理这样的问题。如果存在VPD讨论太长而影响到阅读，则确实应该想办法把一些本不应该在上面的讨论挪走。我目前还是没时间去了解具体问题是什么。0xDeadbeef (留言) 2024年4月9日 (二) 16:15 (UTC)

@0xDeadbeef：实际上经过观察，征求意见现阶段在本站最有效的运用，应该是挂在那些本来就在讨论页发起的话题上面增加流量，而不是反过来把讨论到一半的互助客栈话题移回某个页面去减少流量。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:54 (UTC)

这提案本来就是提倡讨论本身从讨论页发起，而不再在客栈发起，是阁下不知为何坚持理解为移回，这是两码子的事情。移回是因为配套已容许，在客栈页面过长时将讨论拆回讨论页征求意见；这个提案是在要求讨论本身就从讨论页发起，在不够人时不再“重新在客栈发起讨论，直接在讨论页开始征求更多意见”。两者的观点是相近而不相同。--路西法人 2024年4月9日 (二) 09:28 (UTC)

征求意见制度运作约一个月来实绩不彰乃是我从阁下口中听来最可笑和可悲的言论。现在不是征求意见制度“实绩不彰”，而是太多人根本连有这个系统也不知道，也不甚了解讨论页面过长的后果。阁下屡次以各种小手段阻止提高征求意见制度的可见度，然后跑过来说“实绩不彰”、“不如预期”，这是“在你的负面干预后，再以结果论评断制度效益”的最荒谬做法。--路西法人 2024年4月8日 (一) 23:15 (UTC)

实际上就等于架空互助客栈又怎么了？客栈是用来“互助”而非“互煮”、闲聊而非正规议事，该煮的本来就应该在适合的讨论页煮，阁下无视互助客栈设立本意就以“架空互助客栈”来反对此案，恕难以接纳为有效论点。--路西法人 2024年4月8日 (一) 23:32 (UTC)

涉及多个条目的讨论再怎样也就是选择一个看起来多人会关注（不需要真的去查证是否最多人阅读的条目）的主要主题讨论页，然后向其他讨论页和编者发送通知。前面的步骤是新改的，后面的步骤理论上不论是提到客栈还是讨论页讨论都是应该要做的。这里并不存在“比原先制度更为繁琐”的步骤。--路西法人 2024年4月8日 (一) 23:32 (UTC)

本站不是拿来实验制度的地方。而且真让你实验过了，甚至在客栈放了个横幅置顶，也没见有什么作用。条目探讨区页面浏览量以万计，现在所有征求意见话题加起来大概还不到一千，极不利于促进有效讨论。配套措施也是七零八落，在这种情况下还要继续抛一堆要求出来折磨编者？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:36 (UTC)

当然没用啊。阁下为阐述个人观点，屡次阻碍置顶横幅设置，将置顶文字埋藏在其他文字内；况且是人都知道多数人是不读置顶的。在存在较深入了解RFC的方针相关讨论，显然能非常有效地使用RFC；但条目讨论方面根本没给予RFC有跟VPD公平竞争的机会，就结果论说RFC没作用，这根本就是在循环论证。--路西法人 2024年4月9日 (二) 08:45 (UTC)

声称本人为“阐释观点”调整客栈顶栏视觉排版，令人遗憾。你知道置顶横幅盖在上面有多丑吗？何况我（一）没删掉文字本身，还梳理语句、加了几段粗体凸显重点，（二）未阻止在客栈失能（过于庞大）时重新加强横幅提醒（虽然很丑）。若你觉得原本横幅挂两周不够，要学RELIST搞“永久试行”，多挂几个月也行啊（至于别人观感那是另一回事）；真觉得还不够，现在给所有人发通知说此制度已经启用了，以后甚至定期通知，我也没意见。我想社群都乐见征求意见制度得到善用。但掐住整个条目探讨区及编者现行讨论习惯以为交换，那就过了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 08:52 (UTC)

丑怎么了？我不是第一天说你拿你的个人美学来评断“美观”、“合理”这个问题，“丑”是主观的，“因为丑就得改成没人看见的款式”更是完全说不上理。如果你觉得丑，那更是完全符合引起注意的目标。单纯因为你觉得丑而缩小，反而导致引起关注的意义全无，这不是为阐述个人观点而作出损害改善客栈过长这个目标的行为是什么？--路西法人 2024年4月9日 (二) 09:11 (UTC)

讨论制度核心是实用，社群若认为互助客栈好用，自然会用客栈，若征求意见好用，自然会用征求意见。实际上我也看到一些本来在讨论页发起的话题，利用征求意见制度以后，参与度有一些提高。但这完全不应该是反过来消灭互助客栈的理由。你现在弄这一套冠冕堂皇的复杂制度出来，当然大家都只能去讨论页用征求意见，使用率百分之九十，那不就好啦！但这究竟能凸显什么？只是因为编者被迫走官僚程序罢了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:40 (UTC)

自己对提案理解错误就来咬我。我这里提出的是要求讨论先在讨论页发起并充分试图邀请讨论，重点在于讨论页本身先有充分讨论再征求更广泛意见，实质也限制了不要一来就想着RFC，却被你理解成“消灭互助客栈”。客栈本来就不是设计来这样用的，被滥用的就自然应该被阻止。--路西法人 2024年4月9日 (二) 08:54 (UTC)

至于所谓“客栈是用来‘互助’而非‘互煮’、闲聊而非正规议事”这种无视本站二十余年来实况的望文生义观点，竟然会出现在讨论中，我想任何实际参与过互助客栈方针或条目探讨的编者都不用花费唇舌驳斥就能看出为了推动一个制度能有多离谱了。现在整个客栈除了消息区或其他区偶尔来点休闲话题，有谁敢闲聊或认为客栈本来是闲聊之处的？另外，按照现在这提案，我要寻求其他编者在某篇或某几篇条目相关话题的帮助，得特地凑齐超过十篇条目才能拿来客栈“互助”，要互助还这么高门槛，这岂不可笑？如此轻视带过“架空互助客栈”对本站讨论制度的立即危害（“又怎么了？”），也不会帮助征求意见制度确立在本站独一无二的作用。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:45 (UTC)

“闲聊”意味的是非正式的讨论（即初步讨论、初步想法、问问题等）而不是离题、“休闲”讨论。如果我这叫“为了推动一个制度”的离谱行为，我更应该将阁下“为了推动无视客栈条目探讨板设立以来的建议做法，而用尽的手段阻拦配合设立原意和建议做法的配套”称为更离谱的论点。--路西法人 2024年4月9日 (二) 08:58 (UTC)

况且，“架空互助客栈”本来就不存在任何“立即危害”，阁下从头到尾都只是在幻想没了客栈就不会再有活跃参与讨论的情形；反而完全无视互助客栈现在无视原定建议做法造成如讨论重复移动造成编辑历史损失、引用编辑差异讨论难以查找最终的完整讨论、重复存档至多个位置导致讨论混乱（难以阻止进一步留言而产生平行时空的讨论）、载入及储存困难等多种已经完全体现的危害。还你一句，如此轻视不实践互助客栈本来就存在的建议做法导致互助客栈各种问题对本站讨论制度已经造成的危害，也不会帮助论证客栈在本站有独一无二、不可取代的作用。--路西法人 2024年4月9日 (二) 09:02 (UTC)

“而是太多人根本连有这个系统也不知道，也不甚了解讨论页面过长的后果。”然后结论是要强制大家只能用这个系统发起多数讨论，推翻互助客栈条目探讨区？这又是什么办法？罗马不是一天造成的，设想正式引进制度一个月就能广为人知、获得妥善运用，甚至取代固有讨论体制，本来也根本是不合理的。所以我说此案极为冒进，殆无疑问。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 08:15 (UTC)

目前制度存在问题，但又不停用目前制度并给新制度任何机会，这叫故步自封。--路西法人 2024年4月9日 (二) 09:04 (UTC)

我不知道阁下凭什么指责我“用小手段”、“负面干预”。本人未曾阻挠征求意见制度本身之推行，对于技术部署、制度命名等事宜乐观其成，且过去一个月来，不仅亲自参与使用此制度之众多讨论，与编者多打交道，甚至多次尝试加强其作用，例如向Kanashimi君提议置topic list，可惜未成等。参酌近月实际讨论运作情况，我认为征求意见制度现阶段未成熟到足以替代客栈既有讨论作用（这不单纯是推广的问题，而是征求意见制度本身存在局限），但同时也认为有发展潜力，故提出先在涉及单一条目者实行的折衷提案。但我想阁下这等高傲的态度，连移动讨论都能给人家扣扰乱帽子，大概是别想讨论了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 08:48 (UTC)

阁下屡次阻挠我挂横幅、缩小文字甚至将文字缩进显然没人会去认真看的置顶文内，这不叫“负面干预”叫什么？阁下连一个新制度更好运行、排除旧制度中各项问题的机会都不给，在目前社群很多人明显不知道可以用新系统的状况下，就直接称那个新制度是“实绩不彰”，这才叫高傲吧。--路西法人 2024年4月9日 (二) 09:06 (UTC)

我就想问一个问题：你们这样把讨论串不断移来移去合适吗？Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 00:27 (UTC)

(！)意见有个想法，这个RFC是否可以和相关专题联动，比如讨论1，或许关注单个条目和讨论页的少，但是相对来说关注香港专题的应该大有人在，关联到专题模板可能会让更多编辑或读者关注到。另外对应（优良）条目评审也可以考虑加入RFC中。

在en:Wikipedia:WikiProject Biography/Article alerts专题条目动态中支持Requests for comments，可以在条目动态中直接跳转到条目页面对应的rfc页。比如en:Talk:Ariana_Grande#RFC:_LEAD_IMAGE就出现在上面的传记条目动态里面。这个可能要问下@Shizhao

另外维基数据和英维分别有d:Template:Ping project与en:Template:Mass notification，可以ping到相关专题的参与者，也是个不错的方法。--Kethyga（留言） 2024年4月9日 (二) 01:03 (UTC)

近期我实在没精力去做大量写代码的工作....--百無一用是書生 (☎) 2024年4月9日 (二) 03:47 (UTC)

我是愿意写，但力气暂无。暑假吧。--路西法人 2024年4月9日 (二) 04:38 (UTC)

这倒是可以，虽然在目前本站的专题环境下不确定会发生什么事就是了。--冥王欧西里斯（留言） 2024年4月9日 (二) 09:06 (UTC)

还是认为以自愿为原则，用RFC还是客栈，要视项目讨论者的意愿，而不是依靠兄台你卖力地推销。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月9日 (二) 02:26 (UTC)

无法实现RFC的好处，只保留了社群继续使用VPD的坏处，这不是意愿不意愿的问题。现在就是VPD的做法很不好，有坏就得修，而不是谁选择怎样的问题。Ericliu所指基本上将话题发起门槛调高到涉及十篇条目以上，实际上就等于架空互助客栈，我完全可以原话还给他：将客栈开话题的门槛订为0，实际上就就是在架空条目讨论页的作用；甚至是违背了先行与关联编者沟通，实在无果才征求社群广泛意见的基本沟通步骤。说到底，就是养成不愿意吵的懒人试图把话题抛出去盖过其他当事用户意见的不良手法。--路西法人 2024年4月9日 (二) 04:26 (UTC)

坏处只是你的主观认为，你现在的做法纯属强制推销，爱用RFC的可以在RFC推进讨论，不爱用或者不需要用到小心讨论可以维持在客栈进行。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月9日 (二) 05:33 (UTC)

你晓得什么叫“推销”吗？我推行的是改制，是摒弃目前VPD的不良讨论习惯，而不是“跟VPD争宠”。--路西法人 2024年4月9日 (二) 06:30 (UTC)

有什么“不良讨论习惯”？只要能促进讨论，那就是有效制度。征求意见有他之所以有效之处，但互助客栈本来也有，两者不属于替代关系。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:54 (UTC)

VPD过长要找讨论议题很烦不是赶客？载入、储存缓慢不是赶客？不通知近期讨论用户不是赶客？不尝试先跟近期参与／争议用户讨论就去征求他人意见有尊重对方？无法通过监视列表关注特定主题讨论不是无助关注讨论？这些问题我都提过十万遍，既然你说得出只要能促进讨论，那就是有效制度，为什么就不懂得转换思考，有一大堆问题的是不良讨论习惯、无助促进讨论、是无效制度？你在讨论中，往往只有downplay VPD造成的问题而不需改善“维持现状”“给予选择”，而RFC存在的问题却往往被提出后统统要尽可能改善解决才能“更有效推行”。--路西法人 2024年4月9日 (二) 10:00 (UTC)

客栈的en来源（Village pump）如果放到Google上搜索就可以发现就是一家酒吧，这也可能就是它的典故来源，其叫什么名字不是重点，其重点就是它的定性：社群的一个通用讨论区。所以为什么需要广泛讨论的内容更适宜放到这边上，当然考虑到社群纷争太多，会偶发性导致页面膨胀，导致某些用户体验不佳，所以RFC可以充当分流的单独“雅座”。但如果滥用“雅座”的话，甚至强求分流到“雅座”的话，无论怎么解释，都看上去在架空某些东西。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月9日 (二) 05:39 (UTC)

“客栈”还是“village pump”还是“酒吧”都显而易见不是用来谈正事的地方，充其量就是非正式的讨论、聊天。以“雅座”类比RFC完全不合适，RFC本来就不是用来“分流”用，而是辅助在原先设计的正确场所讨论时邀请更多人参与的工具。每个条目都像是一个公司的部门，讨论正事在会议室（条目讨论页），在酒吧、客栈只应该是闲聊。RFC只不过是将开会这件事公告在公司内联网里，FRS是发邮件邀请其他人参与会议，“雅座”根本就不是RFC的主要用途。你说出RFC是“雅座”的时候你已经不适合参与此讨论，因为你连客栈、RFC的主要目的是什么都还没搞清楚。--路西法人 2024年4月9日 (二) 06:29 (UTC)

不同范围的共识在哪里确立并不应该限定其出处，从极小范围的条目讨论页，限定特定编辑主题的专题讨论页，到更广泛影响的大型讨论页，包括客栈，或者RFC。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月9日 (二) 05:42 (UTC)

正是因为这些讨论都影响不同范围，所以他们应该在适当的场所去讨论，而不是堆在同一处讨论。不会一国政府然后全部共用同一个办公室和会议室吧。--路西法人 2024年4月9日 (二) 06:32 (UTC)

集中讨论也不会让某话题“影响”到其他范围去，此言差矣。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 07:54 (UTC)

会。版面过长导致载入、储存困难就是“影响”其他话题的最佳例证。--路西法人 2024年4月9日 (二) 08:40 (UTC)

很简单，索性像英维一样，废除大型讨论页，以方针指引及模版为主导（大前提是所有方针指引及模版需要正就读学前班的小孩也能理解），剩下的在条目讨论页作轻微讨论，反正大型讨论页来来去去也是那十多个只会背书的编辑者踊跃发言，相关话题的编辑者也不会在大型讨论页发言。--唔好阻住我爱国（留言） 2024年4月9日 (二) 06:13 (UTC)

本应如此。--路西法人 2024年4月9日 (二) 06:32 (UTC)

换句话说，真正应重点讨论的是方针区，而非条目客栈。而且每一条目类别需要有统一的成文格式手册，规定行文段落应如何分布，事件收录准则及来源要求，但中维只有极少数类别才有格式手册。以阁下监察的港铁相关条目来说例子（碍于身份而不能编辑），现时有一位D君经常阻吓新编辑者编辑，他经常回退相片及重大事故，但又拿不出任何方针……格式手册证明其观点，因而制造编辑争议。所以，在未有完善的方针……格式手册之前，大型讨论页应保留，而供“集思广益”。--唔好阻住我爱国（留言） 2024年4月9日 (二) 06:45 (UTC)

甚至乎可以疯狂起来，每一经巡查的新条目讨论页都由巡查员挂上适用的大类别或总条目。可让大幅增加巡查员的工作量。例如九巴1A线可被归类为九巴、香港巴士、中国巴士、巴士的讨论区，而编辑者于九巴1A线的讨论会自动同步至九巴、香港巴士、中国巴士、巴士的讨论区，WP:DYK正实现这项技术。--唔好阻住我爱国（留言） 2024年4月9日 (二) 06:54 (UTC)

你完全离题了，这里并非在讨论此问题。我并不支持你最新两则留言的任何意见。--路西法人 2024年4月9日 (二) 07:16 (UTC)

不啊，我并没有离题，你提出的方案根本没有配套（方针指引模版及格式手册）支持。在没有配套（方针指引模版及格式手册）支持下，你的方案很难成功。而且刚刚又有移动扰乱我评论，如果阁下的方案生效，我究竟要写多少次相同的言论？--唔好阻住我爱国（留言） 2024年4月9日 (二) 07:30 (UTC)

我提出的全部也是方针…以至格式手册及讨论页应如何运用才能达到阁下的期待，但你说离题，那我只可在没有配套支持下提出(－)反对。--唔好阻住我爱国（留言） 2024年4月9日 (二) 07:39 (UTC)

方针指引模板跟格式手册跟此讨论完全无关，无关论点将视作共识方针下的无效论点。若阁下持续，将要求管理员实施禁制。--路西法人 2024年4月9日 (二) 08:12 (UTC)

@Ericliu1912：我没力气跟你吵下去，我唯一可以给的妥协就是“需要征求更广泛意见时，除了使用RFC外，也可以同时在客栈发送讨论通知邀请其他社群成员参与讨论”。无论怎样，讨论都不应该再移来移去造成一万个问题；绝对不会接受让讨论在客栈重复展开，更不能接受为了贬低RFC的作用而开始无视甚至提议取走客栈页顶长年存在且显然可见有实际意义的建议做法，而继续容许社群用户过度依赖客栈而产生不良的讨论习惯。--路西法人 2024年4月9日 (二) 09:18 (UTC)

WP:共识#形成共识的误区和错误：

持续、过分地寻求某个编辑目标十分扰民，应该避免。只有编者愿意互相倾听、回应和合作编写一篇更好的条目，共识过程才可顺利运作。如若编者拒绝任何共识而固执己见，无限期地发表冗长辩论以实现其目标，那么他／她将会破坏掉共识过程。固执己见的人永远不能解决问题，因为总会有比他／她更加固执的人出现；有社群支持的页面本身才是这场长跑的赢家。

如果上面还是打算继续如此的讨论的话，倒不如不要讨论了，我是真的不知道你们现在这样做到底有何意义，这完全不是有效的讨论。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 14:54 (UTC)

我已自有折衷提案，也有人支持；再不然，照彼案原样试行一段时间（但必须有严格退场程序及检验方法，不能像RELIST一样无限拖延不决）也罢，实际上方法多得是，只是提案人要不要讨论的问题。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月9日 (二) 15:20 (UTC)

我自己觉得LuciferianThomas定的这个“10个条目”门槛确实有点过高，而且定成这个数字的理据不明，用Shizhao的话来说就是“毫无依据的拍脑袋数字”，但凡有人尝试解释一下定成“10个条目”的背后理据，这里也不至于这么快演变成无效讨论。其实我自己倒不是不支持把讨论分流到RFC的做法，但就算如此强制性的规定真的通过了，也不见得有人会遵守，而且很有可能重蹈原版7DAYS的覆辙。

我本来也有个稍微偏LuciferianThomas方案的alternative的，与LuciferianThomas方案的具体差别大概如下：

• “所有讨论均须先在内容页面的对应讨论页发起”中的“均须”改为“应”，由强制性要求改为建议性要求，以避免一刀切所带来的不必要问题，但我认为仅影响单一条目的与影响多个条目但有单一主题条目的都能适用强制性要求（如果社群还是有疑虑的话，可以进一步收窄为仅影响单一条目的才能适用强制性要求）。
• 合并“有多个主题条目者”与“无主题条目者”两种情况，容许讨论发起者拥有一定的自由度选择发起讨论的地方。
• “10个条目”的门槛下调为“3个条目”，以避免用户因规则而不得不在实际上不合适的地方发起讨论。
• 容许任何用户（包括发起讨论的用户）于第2条所提述的三个情况外，在其认为有必要的情况下使用RFC系统，以利征求外部意见。
• VPD是否能使用RFC系统可能需要额外讨论。

但我不知道我这提案能不能让任何人认真看待就是了。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 16:01 (UTC)

（话说回来，上面说的“条目”可能说是“页面”比较合适，毕竟现在VPD讨论的不止条目，还有模板、模组、分类之类的。）Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 16:50 (UTC)

为何是3个条目？个人认为1个讨论影响3个条目这个要求太容易可以达成。--唔好阻住我爱国（留言） 2024年4月9日 (二) 16:16 (UTC)

“3个条目”确实是比较容易满足的条件，但大部分VPD的讨论都是“仅影响单一条目”或“影响多个条目但有单一主题条目”的情况，而这里的“3个条目”限定的是“有多个主题条目”与“无主题条目”的情况（至于LuciferianThomas方案的“10个条目”则限定仅“无主题条目”的情况）。我认为只要能有效分流“仅影响单一条目”或“影响多个条目但有单一主题条目”的讨论，VPD的积压就能得到显著舒缓。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 16:35 (UTC)

感谢你花时间写下这些。同我上面的回复的一些意见，我觉得这个alternative比较更合适一点。--0xDeadbeef (留言) 2024年4月9日 (二) 16:17 (UTC)

我是不能接受你要把“须”改成“应”的。给了“应”，有些人还是不会遵守（客栈页首挂了“任何条目或模板的交流应考虑先在其讨论页发表，而若无人加入讨论才可在此发起”这么多年，还是没人理会）。条目讨论基本上完全可以明确规范，量多就更板上钉钉不能被轻易扭曲，仅有在极为特例的情况下WP:IAR发起讨论。

“10个条目”是一虚数，实际上我确信没人会去数影响多少个条目，能轻易辨识有哪些条目需要修订的基本上不会多于“10个条目”，多到要找或者整个专题、主题的情况下十有八九都已经大于10个条目需要修订。

“3个条目”的达成条件过于容易，这里针对的是主题条目可能有多个（如“殖民地”“英属香港”）但需要修订的内容涉及大量条目的情况）。

“多个主题条目”本来就有主题，即有办法在条目讨论页甚或维基专题讨论页发起，那么自然应该是在这些更适当的场合发起，而不是“自由选择”（不是不顾客栈问题就选择客栈叫做“自由”，正如散播谣言同样不是言论自由的给予的权利）。不能接受能用条目讨论页而不先行使用的任何方案。更何况，不论是提在客栈还是择一讨论页发起讨论，仍是有义务去在各主题讨论页发送讨论通知，既然要做的事情一样，我没看到“容许自由选择”的需要。

虽然如@0xDeadbeef所说，应该避免在RFC还没出现问题时WP:CREEP限制使用RFC，但主要问题在于这个提案的目标是让社群成员学会逐步递进扩展讨论，而不是一来就依赖客栈或RFC来征求外部意见；鼓励先在编者之间解决的争议，真的不成才向外征求意见。我提出的三种情况基本囊括所有“必要”征求广泛意见的情形，没人参与讨论自然要外人来参与、无法达成共识自然要外人参与、影响广泛也自然可直接征求更广泛意见。如果你有想到任何实际“必要”的情形，当然可以加进去，但“其认为必要”的条件过于空泛，以你维懒惰的讨论态度只会什么都说“我觉得必要”然后抛给RFC（当然，这里说的是条目、模板等讨论，方针修订等讨论要有效力仍是需要通过RFC)。--路西法人 2024年4月10日 (三) 00:08 (UTC)

对，因为你需要推销你的“产品”，所以才不为余力地要求社群必须按照你的想法尽力地使用RFC而无形间地架空客栈，但现时来看，社群认为应该需要用RFC自然会选RFC，不需要的话就还是在客栈等其他讨论页面解决，你不喜欢客栈的讨论氛围，但也不能将你的“美学”强加于社群。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月10日 (三) 00:42 (UTC)

一边鬼打墙重复“架空”客栈，却永远不会回应我已经列明多次的客栈陋习。“架空”是指“凭空捏造，没有事实根据”或“排挤而失权”，既然有事实根据去做，也并非因为排挤而是因为本身的失能而被排除，这显然不符合“架空”的定义。任何“架空”客栈的论点都是显然无效的。--路西法人 2024年4月10日 (三) 01:17 (UTC)

因为你也仅仅基于你认为影响到你的观感（诸如页面加载，或斥之陋习），然后反复推销RFC，甚至现阶段变本加厉地认为应该强制地以确定共识的讨论位置，借着称可以利用RFC和回馈提醒机制来推销自己的RFC。以上不需要我的详细，因为这就是你现在所做的。客栈的现象（或者以你的观所以认为，称之为陋习）我不认为是陋习，或者我更愿意称之为一种惯例。我的最终观点依然认为：共识的确立位置不应该强行地确定其确立的位置，无论是在客栈、各范围的讨论页、还是RFC，我认为现在RFC在客栈的目录列出已经足够彰显其作用，社群爱用RFC就去RFC解决，爱用客栈则在客栈解决，贵您爱用RFC就用你爱的RFC去讨论，现阶段的做法我认为已经足够。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月10日 (三) 06:04 (UTC)

当长年置顶的建议做法不同意此般陋习，还能洗白成“惯例”?“大家都没遵守建议做法所以就不遵守建议做法就是合理”这不是明显的WP:RTRL？岂不是站内管理员失能、不执行社群长久以来的建议做法而造成的陋习？“观感”跟事实上存在的“陋习”是显然不能相提并论的。阁下拒绝回应这些问题为什么存在，不去想想该如何处理这等明显存在的问题，反过来去说这是一种“惯例”，甚至是无视长久以来的建议做法。既然阁下拒绝回应问题所在和如何解决，而统统downplay成“惯例”去洗白此等问题，那么我自然不需要理会你的意见。--路西法人 2024年4月10日 (三) 10:12 (UTC)

回应：

• 能不能先考虑仅强制分流“仅影响单一页面”与“影响多个页面但有单一主题页面”的讨论？这两种情况的争议性应该不大，而且“仅影响单一页面”的讨论显然是占多数的。
• “‘10个条目’是一虚数”一方面正好呼应了我上面所说的“毫无依据的拍脑袋数字”（这个虚数怎么不定成100、1000或10000？），另一方面设定为虚数也不利于社群遵从（“回退不过三”的“三”可不是虚数）。
• “只会什么都说‘我觉得必要’然后抛给RFC”倒不一定，（虽然这种情况可能会落入立心不良的范畴）如果有人想刻意让参与讨论的人数较少（以免人多嘴杂）的话，他不会应用RFC机制。
• 影响高风险主题下的页面的讨论如拟对页面作出非微小修订，应该从一开始就应用RFC机制。
• 我认为社群成员的顾虑有必要获正视，否则我不认为这里能进行任何有效的讨论。

Sanmosa _{Szégyen a futás, de hasznos} 2024年4月10日 (三) 01:14 (UTC)

• 这是必然的，但显然不足够。
• “‘10个条目’是一虚数”虽说是一虚数，但我显然也有解释为什么是10，请自行重新阅读我上方的留言。10作为我观察条目、主题组成的基准数，只是在该基础上取了个齐头数，你可以说为什么不是11、12，就是因为方便在情况下参考。同时只影响4、5、6个条目的多主题讨论比比皆是，这些显然不至于需要一来就扩大讨论。
• 请论述“不一定”。我说得很清楚，显然现在客栈就是存在这个状况（如防止连@都没尝试@就说没人参与讨论）你说为了避免人多嘴杂而不用RFC，也是没有问题，能local解决就local解决。
• 这个可以考虑加，但我觉得并非“必要”。这个真的就“可”使用就好。
• 社群成员的顾虑必须正视这是没错，虽然仍有部分论点缺失了论证，但你在此讨论中确实有给予了非常有效的想法；而不是某些用户空谈“没用”却不详细研究为啥没人用、一来就叫“冒进”、持续拒绝甚至回避讨论客栈的陋习，说的话没有半点方针指引原则论据。

--路西法人 2024年4月10日 (三) 01:26 (UTC)

• 我的意思是可以一步一步来，首先强制分流“仅影响单一页面”与“影响多个页面但有单一主题页面”的讨论，在此以后再讨论其他讨论是否需要强制分流。我相信这总比直接推动一刀切强制分流，然后因遭遇社群较大阻力而无法推行来得好。
• （我一时看漏了）
• 客栈与RFC机制的生态存在一定差别，可能在强制分流部分讨论后你说的情况就已经不会那么严重。
• （这点可以交由社群进一步讨论）
• 这种情况或许代表了社群中的一种非小众意见，不正视这种意见背后的因由不见得能促进有效讨论。

Sanmosa _{Szégyen a futás, de hasznos} 2024年4月10日 (三) 01:36 (UTC)

• 回3：既然不会阻碍在正常合理的情况下使用RFC，而在三（四）种表列情况外真的存在其他有必要征求更广泛意见的情况下当然可以直接使用。况且我原先提案也没说过“只”有这三种情况使用RFC，更多是“推荐在这三种情况下使用RFC”，其他没说不代表不能，但我觉得绝大多数需要征求更广泛意见的情形已经由表列范围概括。
• 回5：当初苗君解任案也存在看似是“非小众”的意见，但不代表这些意见必然合理，最终截停解任案也是基于这些意见的不成立。无方针指引等合理理据论据的自然就不是有效意见。人多不代表对。“架空客栈”这些言论真的是毫无论据支撑，尤其当客栈本身是因被滥用而形成依赖的背景下，说得好像没客栈就什么都做不了那样。背后没有因由的意见不见得能促进有效讨论。

--路西法人 2024年4月10日 (三) 02:02 (UTC)

因为社群的惯性的确是将各种广泛性的问题放在客栈解决，而你斥之为陋习，就算你没直接声明需要“架空客栈”，但搞出一个RFC机制来分散讨论，甚至还期望强制设立共识确立位置的规定来限制客栈或者推广RFC的使用，但这些做法怎样看都是不满于RFC的利用不足而尝试架空客栈。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月10日 (三) 06:09 (UTC)

“惯性”可以是陋习。两者从来不冲突。惯性的陋习还是要改。客栈既然长期出现问题，那就应该执行建议做法去解决这些问题；在VPP可以很清楚看到执行建议做法后是完全能解决上述问题的。一直坚持守着问题多多的旧制度，却叫嚣他人“架空”问题百出的客栈，我怎不能反过来说你这个观点是不满于客栈被“架空”而阻止更善用社群资源的提案呢？--路西法人 2024年4月10日 (三) 10:15 (UTC)

啊还有，这个提案中RFC本来是可有可无之事，我毫不介意将RFC从提案中移除，因为我主张的是将讨论回归讨论页而非堆在客栈；就算没有RFC系统，我提出的方案仍完完全全能达到我预想中的目的，只是RFC能进一步自动化协助广泛征集意见之余，不再需要移动讨论而已。所有基于“因为我想推行RFC所以才‘架空’客栈”这等言论是完全站不住脚，甚至根本就不是我的目的。没有RFC也不代表可以这样滥用客栈。--路西法人 2024年4月10日 (三) 10:37 (UTC)

Eric和Cwek二位屡屡因为“用到RFC”就来反对，不去正视提案本身提出的原因何在。如果RFC是个人，两位的发言就显然完全是对人不对事的讨论态度。我不是因为“客栈是客栈所以我不同意”，集中讨论区本有其适合用到的场合，但显然现在的客栈已经完全越界，揽上了所有“未解决的争议”。“集中讨论”的最大作用是将有重大关联的议题集合在一起讨论，避免闹双胞，显然客栈将所有毫无关联的议题集合在一起不是“集中讨论”而是“堆在一起讨论”。--路西法人 2024年4月10日 (三) 10:42 (UTC)

方案根本没有解决问题。问题是互助客栈的内容过长，导致开启页面的时间太长。那应该是倒过来，将长讨论引到其他页面讨论。那些影响条目小，影响范围小的主题，很多时候讨论也短，短讨论根本对于页面长度没啥大影响。而且，虽我过去都有批评互助客栈内容长，加载慢的问题；但实际来看这根本不算多大问题。如果提出来的方案得不到社群支持，使用，逆社群之习惯，只怕是得不偿失。Ghren🐦🕒 2024年4月10日 (三) 07:32 (UTC)

阁下究竟是否有真的去阅读过提案内容？我提出的方案从头到尾跟每一则讨论大小无关，而是将VPD留给没有合适地方提出的话题。“影响多个条目”不等于讨论必定长，反而像这个只影响两个条目内容的讨论却远比多数讨论要长。将我方案中交到客栈的讨论说成“长讨论”是false correlation。

我的方案中，仅有“影响广泛且无主题条目”者提交VPD讨论，这个是预期上较少会出现的情况（多数都会存在一个主题条目，或者可以找一个受影响条目的讨论页发起讨论）；这从根源上已经避免了堆积讨论的问题，在基本上多数议题回归条目或专题讨论页讨论之时，何来“无法解决过长的问题”？

讨论重点在于讨论在其他讨论页发起，而不是“长了才去引流”；前者是要从根源解决问题，后者则是治标不治本。我不清楚阁下说“将长讨论引到其他页面讨论”是将RFC理解成“分拆讨论”的作用还是怎样，但我可以很清楚告诉你，RFC不是用来“分拆讨论”而是辅助本身就在讨论页发起的讨论引起注意的工具。

况且提案不是只解决“过长”一个问题：

• 避免移动讨论“存档”导致难以追踪话题
• 解决条目讨论页未被善用作先行讨论
• 要求用户先行自己跟相关用户探讨，跟ArbCom讨论一样，不要事无大小都直接甩手扔给最高层级制度，不是什么讨论都需要广泛征求意见
• 免除互助客栈要“找话题”的问题
• 互助客栈讨论根本是难以查找历史的diff
• 讨论议题无疾而终，却存档至多个讨论页时，若有人添加留言，则变成讨论闹多胞；本来就选好一个地方发起讨论，而不要随意“存档”到N个讨论页就是防止这个问题继续发生。

社群“习惯”不代表这个习惯是好的，在这些习惯造成损害的时候，仍是必须指正。--路西法人 2024年4月10日 (三) 10:33 (UTC)

我觉得你可能还是reconsider一下你的立场会比较好，毕竟这里的意见可以说是几近压倒性地不同意你的见解，而我不认为这可以用“不去正视提案本身提出的原因何在”这种理由来一概而论。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月11日 (四) 00:38 (UTC)

我就是看不惯上面这些人的避重就轻，反驳不了我说的客栈运作问题、甚至连提案原意都没搞清（针对RFC的反对意见）就自然做不成有效反对意见。--路西法人 2024年4月11日 (四) 05:42 (UTC)

社群讨论是一个寻求共识，或至少是寻求妥协的过程，如果大家都摆着“看不惯”的态度来讨论的话，那如我上面所言，倒不如不要讨论了。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月11日 (四) 15:50 (UTC)

共识还要求合理正当意见呢。不回应提案问题，提出一些扯远了还能被我轻易反驳的论点怎能视作合理正当的有效异议？--路西法人 2024年4月12日 (五) 01:27 (UTC)

我的意思是不能把所有反对意见全部仅按著自己的意愿而定性为非“正当合理意见”，这不是共识方针的本意。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月13日 (六) 11:05 (UTC)

最基本：反对意见是否贴题、有任何实质论据、是否直接回应提案中所指问题、是否有效指出提案存在的问题？光是这四点，上面的意见都没能不符合最基本异议的要求，谈何“正当合理意见”？不是因为多人不同意就等于正当合理、必须听从的诶。--路西法人 2024年4月13日 (六) 13:09 (UTC)

例如阁下在此提案中提出的建设性意见和提问（如问10是怎么来、要考虑某某某情形），这些都是贴题、有实质论证的意见，就算我不认同我也不会置之不理；ArbCom讨论中Manchiu条例清晰的意见也能获得我的认可及礼貌回应。不读提案、完全走歪的意见显然不是我有义务去uphold和回应的意见。--路西法人 2024年4月13日 (六) 13:20 (UTC)

阁下可以尝试去拓展他们的异议，先形成完整的论证才抛上来讨论；但如果你并不打算拓展他们空泛或存在根本性错误的意见，那么关于他们意见是否有效的这则讨论可以停止了。--路西法人 2024年4月13日 (六) 13:21 (UTC)

我觉得你先不要急着去定性他们的意见为好。

• 就说Ericliu1912上面说的“或可谓征求意见制度在本地尚未成熟之象征”，我认为这显然并不属于“存在根本性错误”的意见，毕竟RFC制度才刚推行一个多月，社群尚未熟习RFC是很正常的事情；至于他说的“如此贸然推动是会实际损害百科全书讨论运作的”应该是指社群尚未熟习RFC的情况下订立强制性规定要求社群必须且仅可使用RFC会妨碍社群成员参与讨论（而且也可以合理预见这种做法将在实施初期引申混乱，这种混乱应该消除或降至最低）。
• Ericliu11912说的RFC机制“实在过于繁琐”也不是说假的，假如我需要放RFC讨论的连结到{{bulletin}}，我首先要在讨论页放{{rfc}}，然后等bot给hash出来，再把hash当成章节跳转放讨论的连结{{bulletin}}，要公示的RFC提案甚至还要放RFC专用的公示模板（{{公示/rfc}}）。我自己就有手操过上面说的这些程序，说RFC程序不繁琐肯定是骗人的。
• RFC程序本身其实还有很多可以进一步细化的空间，提高RFC的使用率的方式似乎应该是如何让RFC变得更好用，而不是强硬地大规模强制分流，那像Cwek一样对你的提案有“推销‘产品’”的观感的事情也就不难理解了。

我个人认为比较合理的做法应该是在社群习惯使用RFC后才来这样细化相关规范，而不是像现在一样靠行政手段反过来做，至于我上面提议的强制分流“仅影响单一页面”与“影响多个页面但有单一主题页面”的讨论也仅仅是出于分流VPD的考量。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月13日 (六) 15:07 (UTC)

说到这里，我也对你的提案有新的疑问：假如强制分流实行后有人不按强制分流措施发起讨论或应用RFC，那人有什么后果吗？这“强制性措施”是真的“强制性”、真的可以贯彻落实吗？有没有什么机制能协助社群执行强制分流措施？Sanmosa _{Szégyen a futás, de hasznos} 2024年4月13日 (六) 15:18 (UTC)

• 问题是，提案的重点从来不在于RFC，我上面也说过就算这个提案中把RFC拆了我还是要推行。还是“本地社群不成熟，不懂得善用条目讨论页发起讨论及邀请更广泛意见”？整个提案RFC都只是“辅助工具”而非重点，这个才是对提案的理解的根本性错误所在之处。
• 回应你后面关于“过于繁琐”的部分：bulletin不一定要用hash啊，直接用讨论章节标题亦可。共识挂额外模板也不是强制要求，只是协助辨识。这些optional的选项说是繁琐也还真的说不过去，不过也感谢指出怎么繁琐了。
• 请详述。你知道我最讨厌人说“需要改善”但不提要怎样改善，说了跟没说一样。新idea是不会无端从我脑子里蹦出来的。
• 关于“强制措施”，RFC我不实在太care（始终目前被滥用的不是RFC，如果到时候真的被滥用再从建议条件升格为要求也可以）；我也再说一遍，客栈不是“本来就是这样，然后要分流”，而是“本来就不该是这样，应该正常使用讨论页”，“移回”（本应如此）跟“移去”（分流）意义完全不同。关于如何落实递进式征求意见而不再让客栈被滥用，就很简单是把开在客栈而没有征求全站用户广泛意见需求的讨论直接关闭或移回讨论页。就算未来再有新的重大议题在客栈发起，也应避免再存档至多个讨论页，而是直接在客栈存档，方便查找（在哪里发起的讨论就在哪里存档）。

--路西法人 2024年4月13日 (六) 16:21 (UTC)

• 但这并不影响我说的事情，这只不过是把我原本的说法调整一下而已：我个人认为比较合理的做法应该是让社群习惯在客栈以外的地方发起讨论后才来这样细化相关规范，而不是像现在一样靠行政手段反过来做。原版7DAYS多少也跟“本来就不该是这样”沾点边，最终不也是被现版取代了吗？
• （见第三点）
• 就比如说，弄些小工具之类的？而且只说“需要改善”但不提要怎样改善也可能是因为想不到改善方案的缘故，但想不到改善方案不一定代表不需要改善。
• （见第一点）

Sanmosa _{Szégyen a futás, de hasznos} 2024年4月14日 (日) 07:28 (UTC)

不要总是习惯将未发生的事情就交给明天的社群，你不会知道社群陆续退步的有多严重。现在放宽松，未来再收紧，还是会再出现更多问题。有需要改善的点再来谈“需要改善”，不然一切只是空谈。--路西法人 2024年4月30日 (二) 04:38 (UTC)

公示版本

经过一整个月的讨论，异议方一直未能提出实质有效的反对理据。本案提出需要解决的问题仍未见有用户提出实质的处理方式，表示此案仍有推行的必要。基于上方有效的意见，微调本案建议措施的实施力度：

• “多主题讨论”部分作“建议”措施；
• “RFC使用”部分作“应该”措施；
• “单一条目讨论”、“单一主题讨论”部分作“强制”措施。

即新增规范如下：

1. 为善用社群讨论资源，
   1. 仅影响单一条目的讨论须在条目讨论页发起；
   2. 影响多个属相同主题的条目的讨论须在主题条目、专题布告板或任一受影响条目的讨论页发起，并在情况许可下其余受影响条目的讨论页发送讨论通告（若受影响条目过多，应以通知专题布告板及@提及为主）；
   3. 影响多个主题条目的讨论可在任一受影响主题条目的讨论页或互助客栈条目探讨板发起，并应在互助客栈及受影响的主题条目的讨论页发送讨论通告。
2. 编者应先尽可能自行透过讨论解决争议，过早征求第三方意见可能使争议另一方认为其意见不被尊重。在条目讨论页发起讨论时，应发送通知（@提及或用户讨论页通告）涉争议的用户参与讨论（如有）；在无法解决时邀请近期编辑有关条目／主题的用户参与讨论。
3. 经讨论页讨论仍无果或下列情况下——
   1. 过往曾讨论而未达成共识或需要改变共识的议题；
   2. 讨论影响多个条目；
   3. 高风险主题条目的讨论，
   编者可在以下情况往互助客栈发送讨论邀请通告及将讨论加入征求意见系统以获取第三方意见。
4. 在其他页面发送讨论邀请通告时，应在讨论串中申报以免造成拉票误会。会显示文本的@提及则不需重复申报。
5. 除讨论过长需要分拆为独立讨论页、讨论在错误场合发起等情况，不应在发起讨论后移动讨论串，以免造成混乱；讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。
6. 社群可考虑新增机器人任务向受影响讨论页发送讨论通告及结论。

以上。由于讨论已达一个月，而上方规范已整合实质有效的意见，我现按WP:1MONTH将上方提案付诸公示， 公示7日，2024年5月18日 (六) 02:45 (UTC) 结束。--路西法人 2024年5月11日 (六) 02:45 (UTC)

在以下情况下，编者可[..]将讨论加入征求意见系统以获取第三方意见：我的疑问是这一句话是否代表如果以下情况下不适用的话是不是就不能用RFC系统了？--0xDeadbeef (留言) 2024年5月11日 (六) 03:28 (UTC)

1.可以IAR；2.实际上还有什么通常需要RFC但不符合那四个情形的讨论？--路西法人 2024年5月11日 (六) 03:49 (UTC)

例如

• 以前讨论过但无法形成共识的
• 以前讨论过、也形成共识的，但共识貌似已经改变了（或需要试图改变）的讨论
• 从一开始便能知道影响较大、应当有很多人来参与的讨论，例如这里？

--0xDeadbeef (留言) 2024年5月11日 (六) 09:03 (UTC)

@0xDeadbeef：只要将具有排他性的“可”改为软性的“建议”，即应可避免行文暗示其他情况“不可”使用征求意见制度。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月11日 (六) 20:01 (UTC)

对于调整后的强制分流范围没有意见。Sanmosa _{全方贫工之联合} 2024年5月11日 (六) 03:50 (UTC)

(－)反对:针对巴士路线条目，按照“1b.影响多个属相同主题的条目的讨论须在主题条目或任一受影响条目的讨论页发起，并在其余受影响条目的讨论页发送讨论通告；”，当有东西想讨论时，难道我要将讨论邀请人肉贴上至差不多一万条巴士路线条目的讨论页中，这未免阻碍达成共识？--唔好阻住我爱国（留言） 2024年5月11日 (六) 04:06 (UTC)

这就是配套还没完善还强行通过的后果。

• 各条目现时没有分类
• 没有按分类群发邀请功能
• 难估算准确受影响条目数目

处理了这三项配套，我就可以支持。--唔好阻住我爱国（留言） 2024年5月11日 (六) 04:13 (UTC)

针对“6. 社群可考虑新增机器人任务向受影响讨论页发送讨论通告及结论。”，对于新编辑者如何处理？他们对机器人操作零认识，请问现时有没有一个可让IP使用者随意及零编程知识的机器人可供示范？--唔好阻住我爱国（留言） 2024年5月11日 (六) 04:20 (UTC)

基本上仅有极少数主题存在这种极大量建立条目而没有独立讨论页的情况，这个情况下应建立对应的维基专题，并以ping和通知专题布告板为替代通知方式，已添加有关说明。甚至要在分类讨论页进行讨论也是可行。大多数主题均存在多个子主题页面，不会像巴士那样一个大主题下就几万个条目。多数主题均能做到预设的受影响页面通知，如果遇到这类少数特殊例子，适当时WP:IAR并以合适的方式替代也无不可。

机器人任务方面，会跟RFC机器人原理相同，通过填写模板参数（如{{討論頁邀請|頁面1|頁面2|頁面3}}），并在机器人处理发送通知后自动转换成通知申报即可）。届时引入机器人后会再提供完整说明和安排，反正不会需要“操作”机器人。--路西法人 2024年5月11日 (六) 04:52 (UTC)

除了巴士条目动不动就以万条计算外，还有电视节目、生物、国家地区等…

如果我想就九巴条目达成共识，真的要这样ping [[[讨论页邀请|九巴1|九巴1B|九巴2|……|九巴999]]]?

既然阁下提及WP:IAR，可否有空间说明运用此指引的前提？--唔好阻住我爱国（留言） 2024年5月11日 (六) 06:06 (UTC)

显然不切实际的通知就不需做。如果是影响整体结构，应提出格式手册或内容指引。我晚点再详列例子。--路西法人 2024年5月11日 (六) 08:12 (UTC)

针对“ 通知专题布告板”，阁下有没有统计过有多少专题布告板仍运作，有多少已存废了？--唔好阻住我爱国（留言） 2024年5月11日 (六) 06:13 (UTC)

您维什么都送去客栈，当然没人用专题布告版。没人用不等于不好用。--路西法人 2024年5月11日 (六) 08:10 (UTC)

你最起码在条文生效前将所有条目的讨论页导向至相关专题布告版讨论页，否则如何达成阁下的期望，而且新用户也能知道可在哪里讨论。--唔好阻住我爱国（留言） 2024年5月11日 (六) 09:22 (UTC)

是不会在有需要的时候ping人吗？能先思考再发言吗？--路西法人 2024年5月11日 (六) 10:16 (UTC)

针对第三版1b.“#影响多个属相同主题的条目的讨论须在主题条目或任一受影响条目的讨论页发起，并在情况许可下其余受影响条目的讨论页发送讨论通告（若受影响条目过多，应以通知专题布告板及@提及为主）；”

.

可以这样改

.

“影响多个属相同主题的条目的讨论须在主题条目、专题布告板或任一受影响条目的讨论页发起，并在情况许可下向其余受影响条目的讨论页发送讨论通告。若受影响条目过多，请直接在专题布告板或主题条目发起讨论；”

.

针对第一版2. “在条目讨论页发起讨论时，应发送通知（@提及或用户讨论页通告）邀请近期编辑有关条目／主题的用户参与讨论。”

.

可以这样改

.

“在条目讨论页发起讨论时，应发送通知（@提及或用户讨论页通告）邀请最少？？？个近期编辑有关条目／主题的用户参与讨论。”--唔好阻住我爱国（留言） 2024年5月11日 (六) 13:13 (UTC)

又以九巴作例子，我要先在1A找人，然后在1B找人…最后在999找人才符合阁下的要求，这未免阻碍发起讨论。所以提议设人数下限“最少？？？个 ”即可，增加讨论意欲。--唔好阻住我爱国（留言） 2024年5月11日 (六) 13:18 (UTC)

我觉得你只要通知主条目里作主要编辑的就好。再者，中维大部分条目的近期编辑都寥寥可数，就算你真从（n个）1找到999，也不见得能找到成百上千个用户。Sanmosa _{全方贫工之联合} 2024年5月11日 (六) 15:07 (UTC)

香港巴士界有一个特性，就是“巴士爱车”、“巴士爱线”，除了冲GA嘅Thirdthink外，就只有IP用户。按照此特性，每一条目也有不同IP使用者加入及更新车牌信息。根据提案，当我想改巴士条目大整体时，我是需要ping那1000多个条目的不同IP用家。--唔好阻住我爱国（留言） 2024年5月11日 (六) 16:32 (UTC)

IP在技术上是无法被ping的，因此你说的事情不成立。Sanmosa _{全方贫工之联合} 2024年5月12日 (日) 00:45 (UTC)

首先我要到各条目证明只有ip用户编辑先。若有“有名”编辑者，逐个记录，最后一次过ping。

大佬！1000个条目呀！系要我行1000个条目之后先可以发言。--唔好阻住我爱国（留言） 2024年5月12日 (日) 02:09 (UTC)

下方Sanmosa留言已经针对此论点予以反驳。--路西法人 2024年5月12日 (日) 02:25 (UTC)

另一方面，“应发送通知邀请近期编辑有关条目／主题的用户参与讨论”这句话并不是“应发送通知邀请所有近期编辑有关条目／主题的用户参与讨论”，你如果真不知道ping谁的话，只ping自己有印象的那一个或几个就行了，没能ping所有相关用户也不会招致惩罚。Sanmosa _{全方贫工之联合} 2024年5月11日 (六) 15:09 (UTC)

乐见提案人收敛力道，然仍反对未经试行即正式推动此案，尤其反对“单一主题讨论”之强制措施，仅不反对在涉及单一条目时引进此制看看成效如何。在程序上，不理解所谓“实质有效反对理据”由谁来认定，也不知道没提出对案何来即“表示此案仍有推行的必要”（何况本人也有提出对案）；至于必须先以拖延讨论避免征求意见存档，后藉所谓意见“有效”与否径行筛选、甚至忽略包含本人在内其他相当数量使用者之看法，以期塑造公示共识，此亦本人碍难认同且极其不满者。盖讨论近月趋于沉默、无人呼应，显然不代表社群已然对相关方案表达认可，实际上正好相反，表示现行制度未有彻底失能，无须从事激进之所谓“改革”亦得有效运行，遑论试图以制度去“约束”编辑惯例者。甚至据本人过往实际参与条目讨论的观察，究竟此提案是“解决”的旧问题多还是“制造”的新问题多，仍非常有待商榷。有关此案公示之依据，本人完全不信任提案人在此类讨论中悍然“定性”他人意见的实绩，主张提案人当为自己力推多时且亲自参与辩论的提案避嫌，由非当事之他人来认定此话题诸位发言满足“实质有效”与否，省得“球员兼裁判”。又此对互助客栈条目探讨区众多使用者影响何等巨大，社群多数编者却显然浑然不知所参与之互助客栈若干制度即将被直接推翻（当然在此相对偏远之处讨论实为缘故之一），而他们本来完全有权利明悉此议题并就此发表意见；有关公示固然满足方针之最低要求，却仿佛如此已然满足社群知情之公益，此恐乖违于实情。本人认为，应即以系统通知近期实际使用过客栈该区者提供一手见解，甚至就此相当重要之议题付诸公决，最大限度避免吾等少数人参与制定之政策沦为空中楼阁。本人其余意见均已于先前详细阐释，这里便不再重复。基于上述前提，本人反对此突然而冒进之提案公示。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月11日 (六) 17:51 (UTC)

另提案第二及第三点矛盾：盖在个别条目涉及两造或多方面编辑问题的讨论中，伊始即“邀请近期编辑有关条目／主题的用户参与”实际上就是直接引进非当事之第三方意见。又过往诸多实践显示，很多时候争议方只是因为“隔空喊话”缺乏沟通，只要发起话题好好讨论，即可迅速解决问题，不需要徒然造成额外事端；实际上这也根本是此提案第三点前段的意旨才对——两三个人的意见分歧不需要总是立刻邀一堆人来群聊——即给予争议各方面足够之初步讨论空间及尊重，尔后再寻求他人意见。只有在单一方面发起、且一开始即明确需要征求他人意见的场合（例如第三方发起涉及他人编辑条目内容的讨论等），才有必要以邀请他人参与为发起要件。另外只是“扪心自问”，或纯粹给条目内容存疑或备注者亦不在少数，本站没有必要连这点言论自由也箝制，逼迫人家一定要找几个人凑数来“开”讨论。故本人认为就规则及实务而言均不该予以强制，“应发送通知”应改为“得（可）发送通知”或“建议发送通知”。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月11日 (六) 18:22 (UTC)

此外，若是按照往例，此话题早就因不为编者所关注或难有共识而作结，彰显社群意志；正是因为征求意见话题完结界线之模糊，导致讨论可以不断接续，告终之日遥遥无期，而任何话题要一整个月不活跃才算关闭则是雪上加霜，致使若讨论拖延，则其加剧之严重程度要更甚于互助客栈。这实在是当初提案人屡次拒绝本人据彼时情况变化移动话题至互助客栈以利社群扩大讨论，造成话题门可罗雀、讨论难续有共鸣；本人完全有理由相信，若此话题今日尚在客栈，无论客栈运作如何败坏，其讨论流量及踊跃程度决不至于如此惨淡，且至今仍然认为有关举动形近“行为艺术”，即为“证明”征求意见已充分独立可行之观点，坚持使用该彼时未上轨道之制度运作讨论，结果相当程度损害社群公益，反而显示今日之征求意见尚待社群多加爱护参与，并对此深感遗憾。是以本人原欲主张社群现阶段应以时机未至、制度尚不成熟、共识不足或不应以过强政策手段干预编者自然讨论等根本导致制度窒碍难行之客观因素关闭话题，拒绝提案人不断强推此案之尝试；然本人自知此等主张观点强烈、争议较大，或不受多数支持，且本来也是因为征求意见目前尚有若干难以克服之限制所致，相关问题并不应全然归咎于提案人。故社群当前就此议题若确实仍然存在征求意见、乃至于扩大讨论之需求，或诸位认为得以某种折衷试行或其他较受广泛认可之形式推进此案，则大可继续，本人完全不持异议，并此叙明。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月11日 (六) 19:27 (UTC)

回应：

1. 意见有效与否最简单陈述就是“有无道理”，复杂点就是“是否能以实际情况和其他共识推翻提案的前设或构成”。公示前的讨论中出现过的异议：
   • “无强制必要”——已多次说明贵站人显然因为“懒”而不会善用系统和社群提供的平台和机制，光是“建议”是无法从根源解决问题的。
   • “互助客栈能见度较高”——伪命题。能见度高不代表能解决争议；况且客栈条目探讨板也经常出现近乎没人参与的讨论。以昨天Sanmosa将部分讨论串分开前的时刻（topic list）为例：有将近一半的讨论并没有获得多少人的关注，超过一半以上的讨论的参与者人数也不过五个，而这些参与者更不是来自对话题熟悉的用户而多数是路人。“能见度高”一说完全是伪论点。
   • “征求意见制度在本地尚未成熟”——伪命题。已多次予以反驳，在比较便利但比较差的制度和比较不熟悉但更善用资源的制度比较，懒人一定选较差的制度。差的制度一天不汰除，较好的制度也不会被看见。不是征求意见制度不成熟，而是社群拒绝改进；需要改善的不是征求意见制度而是社群本身，而迫使社群改进、善用讨论资源、改变讨论态度的方法只有淘汰明显有问题的旧制度。
   • “架空互助客栈”——伪逻辑。互助客栈本来就不是“本体”，就算反对方把客栈奉为上尊，互助客栈长年的置顶指示也表明客栈本来就不是这样用的。被错误依赖的制度不存在“架空”一说。
   • “不需要限制谁要使用征求意见制度”——以贵站习性，没有好好规范的制度就会被用烂。
   • “社群若认为互助客栈好用，自然会用客栈，若征求意见好用，自然会用征求意见”——伪逻辑。“好用”不等于“适合”。这说法跟“若有公司认为维基百科很好用来宣传，自然就会来改维基百科”或“若学生认为维基百科好用，自然就会用维基百科来做功课”无异，背离本意的使用不等于应该放任。
   • “推销征求意见制度”——伪命题。此提案就算没有征求意见制度也应该要推行以解决客栈存在的问题。征求意见在此提案中仅为辅助工具，以此反对提案简直荒谬。
   • “客栈置顶指引过时”——事实反映当初要求不被遵守就产生客栈的诸多问题，显然是不符合现实的论据。
   这些论点连最基本的逻辑都没理顺，何谈“合理有效”意见？
2. 提案无人呼应完全不代表问题不存在。问题不存在者可能无人呼应，但无人呼应者不必然问题不存在。等到制度彻底失能才来改，这叫“亡羊补牢”，是荒谬至极的做法。过往显示社群等到发生OA后才修补制度显然已经造成严重伤害。
3. 在讨论页的讨论评为“偏远之处”毫无道理，实情就算在客栈提出的讨论也是会出现无人跟进的情况，此处情况并不会比客栈要差。此讨论串9人参与，显然不比平均客栈方针板的讨论活跃度差。
4. 究竟此提案是“解决”的旧问题多还是“制造”的新问题多，仍非常有待商榷。制造的新问题有不同类型的方法可以解决，所谓的“新问题”可能根本在于制度未有全面推行和完整实践过而存在的伪问题。
5. 你在过往意见征集当中大肆宣扬“意见征集仅供参考”并拒绝承认其效力，现在反过来要求“付诸公决”，乃是显而易见的双重标准。我固然不怕以理服人付诸公决，但也非常清楚贵站用户不顾方针指引逻辑而意气用事。本提案本就旨在解决讨论重复迁移的问题，就算是付诸公决也是该维持讨论原地进行。

（待续）--路西法人 2024年5月12日 (日) 05:27 (UTC)

6. 提案第二及第三点矛盾：已修订用词，确实遗漏。
7. RFC部分不用“可”：条文本身并未表示“仅”或什么情况“不可”，若有人如此超译则显然应无视。但亦已稍微修改用词用句。
8. “损失流量”：此提案仍然存在让用户在广邀意见的时候往客栈发讨论通告邀请讨论，而客栈也会长期挂着讨论连结，不见得在清空客栈积压后会有非常严重的流量损失（尤其是目前客栈流量显然也不比RFC多很多）。点段落标题跟点进讨论页都是一步的事。
9. 讨论不活跃、无共识本就随时可以重启，但以完全站不住脚、未曾能完整回应我反驳的所谓“反对”论点来以“社群不采纳”结案就绝对不可能。我推提案每次都是正面回应问题，反方就“侧侧膊”装作看不到我对其论点的反驳，甚至将过往至今显然仍然对此案有重大意义而目前制度无法做到的规则指引等诉诸无用、过时，谈何我“强推”议案？

过往社群缺乏充足配套，以客栈为讨论集中地尚可理解；现在配套充足提案从头到尾都只是在目前本地配套更完善的背景下，将客栈置顶长久以来都存在且仍有重大意义的限制付诸更明确具体的实行；反方却从头到尾拒绝考量当初的规则未被遵守而造成今天的问题。反方打不倒“任何条目或模板的交流应考虑先在其讨论页发表”这条自客栈设立存在至今的置顶要求的意义就甭想阻拦此提案以某种形式实现。我无任欢迎社群用户参与讨论并指出此递进制度的缺陷所在（如RFC使用情形、程序遗漏），欢迎提出，但恕不接受上方已完整反对而反方完全无法继续维持的无效论点。--路西法人 2024年5月12日 (日) 09:44 (UTC)

至于有关“试行”，此案与其他可“试行”的提案不同之处在于该等程序是不做就不做，但此案在于需要替代原先有问题的制度。试行与否，都是要尽量执行才能达到善用讨论资源的效果，故此看不到“试行”与否在此除了给反方心理上“这只是试行”的效果外毫无效果。旧制度的积弊过多（且也是不被反方回应、正视的弊端），新制度有问题也是应该改善新制度而不能倒退，“试行”在此处并不合适。--路西法人 2024年5月12日 (日) 10:01 (UTC)

没有细读上面的讨论。我唯一害怕的是这其实是一个XY问题，而可能是工具规律下造成的WP:CREEP。我仍然不反对这个提案，但是如果说最大的问题是有人不在正确的地方开讨论，我觉得更好点的切入点应该是鼓励他人移动讨论，所以最需要改的应该是明确指出哪里是读者应当开启讨论串的地方。英维的区别就是英维有一群知道自己在做什么的编辑，能在讨论早期的时候便给你指出来在哪里讨论才是最正确的。当然，之前通过移动战已经看到这方面还没出现共识，我的想法是条目讨论除了很重要的事情不要在客栈上（事实上英维没有讨论条目的客栈）。0xDeadbeef (留言) 2024年5月14日 (二) 10:20 (UTC)

根据我对LuciferianThomas之前的言论的印象，他是期望中维最终完全废除VPD的。Sanmosa _{全方贫工之联合} 2024年5月14日 (二) 10:44 (UTC)

本人认为，社群对加强单一条目讨论分流措施并非没有共识，也曾指出该类话题常年占现有客栈话题二分之一至三分之二以上，若得据此先行拟定试行方案，一方面落实原提案主旨缓解互助客栈压力，另一方面亦得藉以评估该制度能否在本地运作流畅，再搭配社群主动而积极之宣导，当已十分足够。然而，提案人坚持继续推动一次性激进而不实际的“全面改革”，无视本人指出相关外来制度尚难全然契合社群过往讨论惯例与当前讨论程序实务运作情况，及社群其他编者基于自身参与经验所提出相当一部分适切允妥之意见或折衷看法等，甚而在推进讨论时径行宣告他人异议“无效”云，此等行为在在见于上该讨论过程，且不只及于本人；本人基于此前已详加叙述之理由，参酌在此话题中及其之外诸多编者提出之合理切身意见，不认为当前提案版本足以取得社群共识，不认为提案内容仰赖之过渡机制足够完善而得起预期之替代作用，不认为此提案有妥善考虑本地目标受众真正需求，不认为提案执行结果能多大方便多数一般编者就涉及较广泛议题发起、展开并延续建设性讨论，亦不认同当事人为推进提案通过所从事若干过当程序性及实质性操作符合本站编者切磋达成较普遍共识所需之精神，更不乐见如此限制（甚至干涉）编者讨论自由的所谓“递进步骤”，未得大多数实际参与既有讨论机制运作者全面深入、诚恳之商议而遂行通过。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月14日 (二) 17:31 (UTC)

反方持续回避、拒绝正面回应对其论点的反驳，屡屡发表对提案错误理解的所谓“意见”，甚至连长年存在的讨论板规则都选择无视，本就无法构成任何有效意见。上方12日之留言已回应反方提出的所有争议点，反方都选择不回应；依共识方针：任何正当合理的意见（无论是否于公示前或公示后提出）若已获提案人正当合理的回应，且自该回应起计的3日后无进一步再回应，应视为该意见已解决。已获解决的意见若被任何用户重复提出，可提示该用户相关意见已获解决，除此以外无须另作回应。先不论反方的论点如何站不住脚，就算视作有效意见，已经被我多次反驳而反方无法进一步回应、推翻的意见本就按方针视作已解决意见，后续鬼打墙重复我已清楚回应的反方意见都只是重复提出已解决意见，我本就无义务回应或视作有效阻挡提案的意见。反方持续将方针指引及讨论板的置顶规则视若无物，又不愿意去回应我的反驳，我看不出来反方哪里来的建设性讨论。--路西法人 2024年5月15日 (三) 04:06 (UTC)

再进一步细回应Ericliu1912回避回应过往反驳后又再提的所谓“有效论点”：

• 相关外来制度尚难全然契合社群过往讨论惯例与当前讨论程序实务运作情况：提案在于过往讨论管理和讨论程序实务运作出现问题，这个说法就是“A提案要解决B问题，但因为B问题是习惯（陋习）所以不可以去解决”，是非常显然的诉诸传统论述。
• 合理意见：上方已清晰叙明反方一直无法回应反驳等同其意见应视作已回应，不赘述。
• 不认为提案内容仰赖之过渡机制足够完善而得起预期之替代作用：显然的prejudicial dismissal，在有大量问题但“比较方便”的旧机制主导下，没人用新机制是完全可以预测到的事情；部分机制更是未曾实行就判定无效，显然是“未经试验即断定失败”的论点。
• 不认为此提案有妥善考虑本地目标受众真正需求：以普通编者而言，讨论的目的就是针对自己熟悉的话题提出意见并形成共识，这一点在任何讨论页发起的讨论都能做到；需要扩大讨论时，新配套仍有考虑到客栈的高流量而允许用户发通告征求意见，且有直接向用户讨论页发FRS通告的配套，完全能满足该需求；对于想参与更多讨论的编者而言，征求意见列表、往客栈发讨论通告、FRS发用户讨论页通告、DiscussionTools提供的追踪讨论工具合起来比现在会有更高的能见度，完全能满足这个非主要的需求；以社群而言，讨论除了解决争议外，还有建立社群成员核心价值的需求，这一点新提案能做到（要求首先跟争议用户讨论、再请熟悉相关主题的第三方用户讨论），反而客栈没做到。反方除了空谈“不认为”之外能给出任何实质需求是这个提案没能给到而过往制度存在的需求吗？
• 不认为提案执行结果能多大方便多数一般编者就涉及较广泛议题发起、展开并延续建设性讨论：此提案并无阻挡用户在广泛议题使用客栈发起讨论，是连提案都没读好就反对的意见。
• 限制（甚至干涉）编者讨论自由的所谓“递进步骤”：自由不是无王管。造成问题的自由就会被限制，正如言论自由并不保障对他人有负面影响的言论。显然现在的“自由”制度有非常清晰可见的问题，那就该管。

如果Eric君仍然是完全没有办法提出实质且能回应反驳的论点，只会鬼打墙重复已经被多次回应也站不住脚的论点或提出空泛无论证的论点，我应按共识方针的明确规定将已多次回应的意见视作已解决，并不再回应。--路西法人 2024年5月15日 (三) 04:36 (UTC)

其实这个方针也可以这样写：在互助客栈条目探讨板发起，且仅影响单一条目或影响多个属相同主题的条目的讨论应被移动至任意受影响条目讨论页或专题布告板进行讨论。

我这样写的原因是认为就算你用多强硬的须，你改变不了仍然会有人使用WP:VPD讨论单一条目的现实。所以你能怎么办呢？如果最终结果一样，都是要去移动讨论串，那是不是还不如从一开始就写移动讨论串。要是以后有人说“你在这里发起讨论违反了方针”是真的听上去有点冲。

但是你们俩在讨论什么，我没看懂。。--0xDeadbeef (留言) 2024年5月15日 (三) 09:34 (UTC)

您这个写法只能作为“从客栈移走”的依据，而达不到“鼓励/建议从一开始在适当的地方做适当的事”。--路西法人 2024年5月15日 (三) 09:46 (UTC)

没仔细看上面，但有依据且不建议移回，本身就是鼓励了。以习惯养成的循序渐进和需要观察来说，不应一竿子打死在VPD发起。同0xDEADBEEF的看法。--YFdyh000（留言） 2024年5月15日 (三) 10:01 (UTC)

看来阁下看漏了“从一开始”四个字。我的提案是两方面，一面处理被不恰当的发起于VPD的讨论，一面在规定上写清楚best practice。Deadbeef版本而言，没有写清楚开始要去哪里发起留言即全部人都要撞一次铁板才知道哪里对，这显然是不理想的，更是对我提案其中一个目标“避免/减少移动讨论”相违背。我期望的是看指示的人能明确知道讨论一开始在哪里发起合适，而不是仅依靠有人长期监视客栈每则移走。

当然，我的提案无法杜绝不读指示的用户在VPD发起讨论（从客栈长期存在类似指示却无人遵守得知），但起码写清楚了指示就有明确的移动理据，而不能被胡乱质疑移动的目的。--路西法人 2024年5月15日 (三) 10:21 (UTC)