维基百科讨论:共识

共识建立的递进步骤

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

以上。由于讨论已达一个月，而上方规范已整合实质有效的意见，我现按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)

因讨论延宕，副知可能未知悉第二阶段讨论之其余参与者@桐生ここ、S8321414、Kethyga、Shizhao、Cwek、Ghren。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月18日 (六) 09:40 (UTC)

感谢通知，我希望提案人先不要急着公示通过，让我们先看看新的方针条款，谢谢。--桐生ここ★[讨论] 2024年5月19日 (日) 08:40 (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)

没有写清楚开始要去哪里发起留言 但是其实我本意就是分开写，一部分写可以移动讨论，另一部分写讨论最好哪里发起。practically，这和仅影响单一条目的讨论须在条目讨论页发起的方针在实行上是没有区别的，只是移动讨论这一行为的依据不同：若方针里侧重在于移动发起位置不理想的讨论串，则在移动的时候可说“方针说要移动讨论，所以要移动讨论”。若使用你的版本，则在移动的时候要说“因为方针要求你必须在这里发起讨论，所以我必须移动你的讨论串”。这两个的区别就在于后者容易遇到人的异议“凭什么限制我发起讨论串的地方？”而前者则更难有人反驳（因为本来移动到正确的地方没什么人有异议吧）。--0xDeadbeef (留言) 2024年5月18日 (六) 14:25 (UTC)

今早回复其他用户时没看到您的留言。您的版本是“叫你做就做，我不会告诉你为什么有这个要求”，绝对会产生疑问和异议；我的版本是配有完整理据的规范，“凭什么”从来都不是在维基百科的有效异议（类同“凭什么维基百科限制/让我创建自关于自己条目”）。规范连带理据通过的话，“凭什么”类异议是无效也无需反驳的，而“为什么”的问题更是不需回应（因方针已经有写，没看到不是执行人的问题）。--路西法人 2024年5月19日 (日) 08:59 (UTC)

叫你做就做，我不会告诉你为什么有这个要求 显然不是。我上面的是在指实行时的论证而不是写方针的论证。 若问题是客栈讨论太多，移动讨论串是更明显的解决办法。我的版本也完全可以加入为善用社群讨论资源更完整。我的版本主要是基于助推的一种实行方式。多的就没什么可说的，我没时间。--0xDeadbeef (留言) 2024年5月19日 (日) 14:54 (UTC)

已添加一项错误场合发起的讨论可被关闭（需指出重新发起讨论的合适场所）或移动（需保留讨论讨论主题及移动目标页面连结）。--路西法人 2024年5月21日 (二) 00:30 (UTC)

---

已按HK5201314的异议调整条文、我和Sanmosa也已回应其后续疑问，视作意见已解决。Ericliu1912所指出的反对论点均已清晰回应，其除了不断重复已回应论点也未能对我已经多次作出的反驳作进一步驳论；依共识方针，已获正当回应的意见应视作意见已解决，后续重复提出该等意见无需再回应。其余用户的意见已获回应。

由于较大幅度调整过条文， 重行公示7日，2024年5月25日 (六) 02:45 (UTC) 结束。--路西法人 2024年5月18日 (六) 02:56 (UTC)

支持提案。不过请问提案的文字准备要放在哪一份方针的哪个段落呢?--CaryCheng（留言） 2024年5月18日 (六) 09:07 (UTC)

我倾向先以实践为重心。共识方针始终有大量文本的翻译、内容组织问题需要改善。目前推行的规范可以不用这么生硬地塞在方针内，而是调整段落文本来反映这个目标和效果。目前先作维护讨论秩序的措施实施，往后确认效果后再调整方针文字亦可。如果目前有需要，暂时整段放进方针就行。--路西法人 2024年5月18日 (六) 10:37 (UTC)

了解。支持先以实践为重心，未来调整文字后再放进方针。--CaryCheng（留言） 2024年5月19日 (日) 15:42 (UTC)

可笑，无可奈何，随意。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月18日 (六) 09:40 (UTC)

不过就事论事，还是要确定“多个属相同主题的条目”跟“多个主题条目”的差别在哪里？应该说提案混用了“主题”一词，加上“受影响”等不同用法，导致很难确定究竟所指为何。并建议给提案各项提供几个范例，俾编者较好确定范畴。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月18日 (六) 09:51 (UTC)

无法提出新论据回应反驳就拉布大概才是可笑的一方。

提案早在原始提案版本已经提供例子，不知反方是否没认真读提案。“多个属相同主题的条目”即原提案“涉及多个条目的讨论”下的“有单一主题条目者”；“多个主题条目”就是“有多个主题条目者”。所谓“主题条目”即最贴近需讨论条目的主题条目，例如：

• HK5201314提出的案例就同属“香港巴士路线（列表）”的主题，在该主题条目的讨论页发起即可（甚或“香港巴士”也可）；
• 上例如会影响更多地区的巴士路线条目，那么就不是最贴近的主题条目，即可视作多个主题处理（此情况推荐使用专题布告版讨论）；
• 台湾各条目地理及政治内容架构的就涉及多个主题（因国家和地理并不同属同一主题，且常人可判断这些也是主题的中心条目），那么在任何一个（主题）条目或客栈发起并在其他主题条目讨论页发通告即可。

--路西法人 2024年5月18日 (六) 11:27 (UTC)

混淆至极，难以想像这是设计给一般编者看的政策条文。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月24日 (五) 21:52 (UTC)

想请问如果我违反了上述条文，直接在客栈发起讨论而不在讨论页发起讨论会被采取措施或被惩罚吗？可能上面的一连串讨论有提到，但我不是很想读完。--微肿头龙（留言） 2024年5月18日 (六) 13:12 (UTC)

错误地方发起的讨论可被关闭或移动，目前无罚则。当然除非是有人蓄意扰乱客栈和讨论秩序。--路西法人 2024年5月18日 (六) 13:50 (UTC)

另外我才发现此提案不仅禁止编者在条目探讨区发起若干讨论，甚至禁止行之有效的“讨论参与不足，移动至客栈扩大讨论”惯例，只允许在客栈发什么“讨论通告”，那就实在更加离谱。真把条目探讨区当作“互助客栈 (消息) (条目)”了啊？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月18日 (六) 14:41 (UTC)

显然你还是不懂得认真读提案。除讨论过长需要分拆为独立讨论页、讨论在错误场合发起等情况，不应在发起讨论后移动讨论串，以免造成混乱；讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。讨论串移动本来就有造成混乱的问题，仅有在无其他办法取代的情况下才应执行。在客栈发讨论通告亦能达到从能见度高的客栈招来更多用户参与讨论的目标，目前也有RFC、FRS的配套，显然也能达到“扩大讨论”的效果；在社群习惯讨论不再大量于客栈发起时，“扩大讨论”的曝光方式只是与以往不一样（RFC列表、讨论通知），也避免了讨论串在客栈堆积；过往习惯追踪客栈的用户也能更清晰看到需要关注的议题。移动讨论串是毫无必要的操作。至于“惯例”之类说法，我回应过一千遍，也无意重复回应。

在早前针对“客栈能见度高”论点的反驳中，我写过这么一段话：况且客栈条目探讨板也经常出现近乎没人参与的讨论。以昨天Sanmosa将部分讨论串分开前的时刻（topic list）为例：有将近一半的讨论并没有获得多少人的关注，超过一半以上的讨论的参与者人数也不过五个，而这些参与者更不是来自对话题熟悉的用户而多数是路人。如果在你眼中RFC没什么人回复叫不成熟，那么客栈缺乏用户参与的讨论串不就充分证明所谓“讨论参与不足，移动至客栈扩大讨论”并不是“行之有效”吗？

你把话换个方式说一遍并不会改变你提出争议来来去去都是我已经充分回应过的论点，反而你的每一则留言都只是展现了你根本没有去读提案和我给你的回应，更遑论理解我的论点。--路西法人 2024年5月18日 (六) 17:11 (UTC)

支持目前公示的版本，但希望有工具可以辅助处理RFC的提出步骤。--冥王欧西里斯（留言） 2024年5月19日 (日) 00:44 (UTC)

我六月再开始研究。--路西法人 2024年5月19日 (日) 04:18 (UTC)

请留意一下VPD那边的讨论。Sanmosa _人人皆王 2024年5月20日 (一) 11:45 (UTC)

那其实不是讨论，只是通告，本意是请那些会看条目探讨区的人多来这里参与讨论。但此处讨论已经过长且偏于toxic，可以理解社群不甚愿意就某些立场发言的原因（至少好几个人跟我讲过讨论篇幅太长，他们难以跟进）。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月20日 (一) 11:49 (UTC)

无视方针和讨论板长久以来规范的论点站不住脚能被轻易击破，贵站用户大概需要先有自知之明。这里的讨论就剩你无限鬼打墙拉布、无视实质规范、连提案都没读清楚就来反对，理亏没法回应质疑就开始抹黑“强推”，不骂你骂谁？--路西法人 2024年5月21日 (二) 01:02 (UTC)

您可是谁反对就骂谁，还顺便带上个“异议无效”的帽子，如此推进讨论可不乐活。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月24日 (五) 21:52 (UTC)

(－)反对 👉 影响多个属相同主题的条目的讨论须在主题条目、专题布告板或任一受影响条目的讨论页发起：我认为影响多个条目的讨论可在互助客栈条目探讨板发起，同意避免一刀切所带来的不必要问题，① 未必存在主题条目、专题布告板，即便存在发起人也未必知道存在相关页面，② 如果在任一受影响条目的讨论页发起，其他受影响条目的讨论页就没有讨论存档，而且花多眼乱到底选择哪一条目讨论页发起。 -- 月都 ※ 2024年5月23日 (四) 15:31 (UTC)

很多条目讨论页都挂有专题模板，找专题不是难事；能找到客栈条目探讨板的用户也显然会在该处接触到更多社群页面的连结，找不到专题布告板的新手用户多数也不会找得到互助客栈（对新手而言，客栈条目探讨板甚至比专题页面更难找，因条目讨论页能直接找到专题模板）；找不到主题条目更不是一个问题，直接使用当前受影响条目的讨论页即可。就算用户找到客栈也找不到这些，在客栈发起了讨论后仍可尽早指导其去正确场所发起讨论，这是教导用户更了解社群运作。

其他受影响条目的讨论页没有存档也从来不是问题，当前客栈中影响多个以上个同主题条目的讨论也不会存档去所有受影响条目的讨论页，这未曾造成问题；提案也指出多处存档会难以追踪后续讨论和造成平行讨论的问题，在任一受影响条目的讨论页发起时也会因应情况尽可能向多个受影响讨论页发讨论通告。

“花多眼乱”：显然你是几乎没在参与条目编辑的人才会说出这种话。有话题、争议要讨论，自然是在编辑某一条目时衍伸出的问题，在该条目的讨论页直接发起讨论已经是“任一受影响条目”，这不是很直觉的事情吗？

为什么能提出如此荒谬的“反对意见”呢？不就只能是因为你参与维基百科但不认真了解参与条目编辑会发生什么事（简称不务正业）吗？--路西法人 2024年5月24日 (五) 01:40 (UTC)

确实，在涉及较少条目而非整个主题的讨论中，要“选”一篇条目发起话题是不合理的。已经没什么量能批评其他地方，也不相信有什么用处，不过提案人虽然到处攻击反对者，甚至声称他人“不务正业”，但恐怕只有真的“不务正业”才能研发出这种蔑视社群惯性的制度。今日尚无可多言，来日当有所证明。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月24日 (五) 02:44 (UTC)

我能论证选一篇条目发起话题的合理性，你却自始至终无法提出要“选”一篇条目发起话题是不合理的的“不合理性”的论证，甚至一而再再而三地回避回应任何实质反驳论点。

月都实际长时间未有参与任何条目讨论，也长期未使用条目探讨板，更在其论证中展现其未曾实际阅读提案也未曾了解社群讨论的机制，不是不务正业是什么？反方不受得任何批评，就指控我“攻击”反对者；反方自己却自始至终无法提供实质站得住脚的驳论，也充分展现了为了反对提案可以无视多少方针、扭曲“初心”“惯性”“架空”“自由”等词语，难道作为正方就不能批评反方荒谬且站不住脚的论证？--路西法人 2024年5月24日 (五) 03:10 (UTC)

我已无心做冗长之政策辩论，须知遇到对手“裁判兼球员”的赛局是打不赢的。只可惜互助客栈这样一种适切本地社群自然发展出来的讨论制度，将为官僚追求形式的强迫之举所毁，最后受害的只会是编者及读者。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月24日 (五) 21:52 (UTC)

( ✓ )同意：在涉及较少条目而非整个主题的讨论中，要“选”一篇条目发起话题可使发起人感到困惑。 -- 月都 ※ 2024年5月25日 (六) 20:09 (UTC)

关于指引。

一、在我看来无非是确实是“征求意见制度运作约一个月来实绩不彰”。Sanmosa在2024-05-11将VPD的六项讨论移动到对应讨论页，包括Talk:福建人、Talk:丹巴·冈呼雅格、Talk:丹巴·冈呼雅格、Talk:陈牧驰、Template_talk:Infobox_officeholder#h-模板问题六处，六处无一例外之后都没有回应。尤其是Talk:福建人，本来讨论串是由“编辑争议”版移动过来，已增加能见度，然后在“互助客栈”得到更多人的参与，然后在讨论在条目讨论页中完全得不到回复。

一之一。且客栈条目探讨板也经常出现近乎没人参与的讨论。以昨天Sanmosa将部分讨论串分开前的时刻（topic list）为例：有将近一半的讨论并没有获得多少人的关注，超过一半以上的讨论的参与者人数也不过五个，而这些参与者更不是来自对话题熟悉的用户而多数是路人。确是事实，问题是互助客栈的讨论热情不高，但RFC下条目讨论页较互助客栈更为低。这是相对性的问题。不能证明所谓“讨论参与不足，移动至客栈扩大讨论非行之有效”。

二、我想提案的重点和RFC不可能是不可分的。所谓“互助客栈”之所以会成为整个中维的集中讨论地方，完全是因为其他讨论页、专题讨论页几乎完全没有能见度。我想“把RFC拆了我还是要推行”这种想法完全是天马行空。

三、专题布告板。如大家所知，专题布告板只属于签名板，除了极少数专题有活跃之外（ACG等），完全没有作用。提案方针中写“应以通知专题布告板”，我只认为是害了一些不知道专题运作制度的人。英维可行制度不一定合于中维。

四、既然“太多人根本连有这个系统也不知道”，那应该首先推广此制度才是。我想这是制定政策的根本常识才是。应该先去将替代品搞好，然后再去将既有产品、服务取消才是对吧？我想社群最担忧是这点才是。“条目探讨”平均浏览次数为400左右，“征求意见/全部”则只有40。两者相差一个量纲级，带到具体“议题”，即使加上FRS带给的流量，和讨论页本身的可能流量和关注列表等，又可能拉平多少？能见度高不代表能解决争议，但能见度高往往对于推进议案、争取共识有相当大的作用。

五、我过去一直都有提出互助客栈过长的问题。也过去一直支持RFC的制度的（参Wikipedia_talk:征求意见/存档1#WP:RFC需要两个bot）。提案中谈的问题（Wikipedia_talk:共识#c-LuciferianThomas-20240410103300-Ghren-20240410073200），除了二、三项，我承认旧制度较新制度为佳，然而这些所谓“好处”有没有大到要社群在短时间内吸引使用呢？完全没有。坏处存在，但带来的负面影响也不大，这样的话操之过急的理由是什么？

关于条文。

甲、（1c）款：“影响多个主题条目的讨论可在任一受影响主题条目的讨论页或互助客栈条目探讨板发起，并应在互助客栈及受影响的主题条目的讨论页发送讨论通告”。“应”应为“可”。是否发送讨论应由编者自由决定。

乙、须与应之别。五大支柱之一WP:5P5给予了突破既有指引的空间、而“应”也给予突破指引的空间，使用“须”、“应”的分别何在，我看上方已有一些解释，但依然不明确。比如虽然只影响一条条目，但因为影响甚众，故初期置于“条目讨论”区作讨论（比如“中华民国”的内容结构），是否有立即回退，“指引”其正确讨论方式之必要。RFC 2119之所以定“须”为“必须满足”，明显是因为“不满足”会明显带来较大负面后果，乃至危害运作。“仅影响单一条目的讨论须在条目讨论页发起”是否带来足够大的负面后果呢，您所举的“陋习”缺乏即时性的危害，影响亦有有限。

总的来说，维基百科是典型由下至上运作的社会，在不涉及违反方针指引的前提下，不带来重大或即时性的恶果，对于社群陋习应该慢慢因势利导才是，这不是所谓“懒”，而是社群根本缺乏诱因去改变，在此情况迫使社群做什么根本不现实。依靠一纸公文解决问题根本不现实。这种问题明明拖一年半载，自然成熟解决。即使解决不了，到时候提出来的迫切性也高了。然而目前反对声音众，支持声音寡，非得要强硬闯关，浪费大量社群资源，实在不无遗憾。我已经可以想像您给什么说话我听了，无非是“Stoneball”“非合理意见”“老调重弹不新鲜”之类。我本就应该如Fire Ice所说的不别花这样多口水的。叹叹！--Ghren🐦🕓 2024年5月24日 (五) 20:42 (UTC)

回：

（一）、（四）：征求意见制度运作约一个月来实绩不彰、太多人根本连有这个系统也不知道：互助客栈条目探讨板总长70页，RFC讨论列表一节仅占1.5页。这不是“征求意见制度实绩不彰”，而是互助客栈条目探讨板的长度完全使RFC讨论列表难以被注意。现在的情况跟在一整页报纸上仅有一个小卡大小的版面说是有公告那样。RFC根本尚未被给予完整的机会去运作，任何形式去扩大RFC能见度的动作又被抹黑成“推销”，简单而言就是反对RFC、不认为RFC有用的用户实质上无限压缩RFC的运作空间后说RFC没人用。阁下说“包括（……）六处[讨论]”，却只给了五个连结，还有两个是重复的，这不是虚假论述？列出“Talk:福建人、Talk:丹巴·冈呼雅格、Talk:陈牧驰”三个例子，没有任何一则讨论是挂过RFC模板的，拿没有经过过RFC制度的讨论来说RFC没用是否虚假论述？

（一之一）：问题是互助客栈的讨论热情不高，但RFC下条目讨论页较互助客栈更为低。这是相对性的问题。当然有相对性问题。在70页的讨论篇幅中仅有1.5页的篇幅去邀请讨论，相对性论述下RFC完全没有被给予跟互助客栈同等证明效度的机会，没给过机会就不要说没用。

（二）：此提案没有RFC完完全全能正常运作，只是有了RFC能更好运作。没有机器人的帮助，且在客栈不会被70页的五花八门互不关联讨论占据下，用户发送讨论通告能很容易被注意到。既然客栈如此“有能见度”，在没有人海战术淹没讨论通告的前提下，客栈应当完全能达到引流效果。反观，有了RFC自动登录讨论列表和发送讨论通告的机制，理论上客栈的讨论通告能完全吸收原有能见度加上发送邀请个别专题用户讨论的通告，能见度反而会高于客栈本身，当然在没有人海战术淹没讨论通告的前提下。

（三）：关于专题布告板，我确实同意当前状态下专题布告板几乎没有能见度。追根究底，不是因为“没有用户去维护专题”，而是什么讨论都被鼓励送往客栈讨论，而不先与熟悉有关主题的用户讨论，所以才没有人有动力去维护、组织专题，因为根本没有专题内先尝试自行讨论的诱因。客栈无限扩大使用范围是夺走这个基础诱因的主因。补充一句：当下特定主题涉及大量条目的讨论往往都需要大量ping相关专题用户，实际反映完全有回归专题的需求，只是所有讨论导向客栈的背景下难以鼓励新用户第一下就是去参与专题。

（五）：带来的负面影响也不大：即时负面影响当然不大，但长期负面影响一大堆。同时比对而言，若层递式讨论规范通过，在没有人海战术淹没讨论通告的情况下，当前唯一问题“缺乏用户关注和使用机制”也获得解决。反方除了“没人用”以外未曾能提出任何其他新机制会造成长期负面影响的重大问题，拿比较没有负面影响的新制度跟有一堆重大问题（包括你所同意的第二三点）的旧制度比较，为啥要继续使用有问题的旧制度？

（甲）：不论是什么讨论，向其他受影响条目/主题的讨论页发送讨论通告应是基本讨论礼仪。在条目讨论页发起的讨论，因主题影响重大需要较多关注则当然应该向客栈发讨论通告；在互助客栈发起的讨论，需要参与有关条目编辑的用户关注，自然也应该向有关条目讨论页发送讨论通知。“应”已经包含“非强制满足的条件”而只是“强烈建议”的做法，没做没有后果但绝对可以被其他人提醒或要求做，做了自然是最好。

（乙）：“仅影响单一条目的讨论须在条目讨论页发起”是否带来足够大的负面后果呢，您所举的“陋习”缺乏即时性的危害，影响亦有有限。最显而易见的多个即时性危害包括：造成互助客栈讨论板过长、影响不大的条目埋在其他巨型讨论中无法被关注（所谓互助客栈的部分讨论串热度不高）、损害用户间先行通过个别讨论解决问题的基础沟通交流。另外，依客栈长年置顶的要求，讨论应是先在讨论页发起后无果才转移至客栈。假设用户遵守了这一点，那么在讨论页中已经开展了一段时间的讨论再转移到客栈的讨论往往出现平行讨论和讨论断层的问题。你没看到的问题不等于不存在。

诱因是不会凭空变出来的，必须由社群给予诱因才能存在改变的诱因。不愿给予诱因去改变的正是“懒”；社群在某些用户放任有问题制度继续运行同时压缩改良制度空间却期望改变诱因会从天而降才是不切实际、天马行空的幻想。“反对声音众”，却无法拿出真正无法被回驳的论点，有什么用？--路西法人 2024年5月25日 (六) 05:38 (UTC)

一）正如您说的，置顶没有人看；讨论指引没有人看，何以见得之下的讨论有人看。自相矛盾。“Talk:陈牧驰”此处是两个讨论，请您留意S君的{{moved from}}模板。“列出“Talk:福建人、Talk:丹巴·冈呼雅格、Talk:陈牧驰”三个例子，没有任何一则讨论是挂过RFC模板的”，乃是事实。既然而此，我修正我的论述。问题是“条目通告不能起了导流作用”。

二）应该说基本上上方路西法人君提出了大量假设、臆断，社群根本很难去验证、证明。举证责任本应在贵方。近者如此处：

在没有人海战术淹没讨论通告的前提下，客栈应当完全能达到引流效果。。何以见得编者会阅读讨论通告？此点假设是证明您整串讨论串的重要要素，然而您甚至根本没有简单的推论。

有了RFC自动登录讨论列表和发送讨论通告的机制，理论上客栈的讨论通告能完全吸收原有能见度加上发送邀请个别专题用户讨论的通告，能见度反而会高于客栈本身，当然在没有人海战术淹没讨论通告的前提下。空话。问题是不能“完全吸收”。导流模板起了的作用要打折扣。“当然在没有人海战术淹没讨论通告的前提下”这句的前提是讨论少，导流模板就会容易看到。置顶都没有人看，指望人家看导流模板，是不是有点天方夜谈。

而是什么讨论都被鼓励送往客栈讨论，而不先与熟悉有关主题的用户讨论，所以才没有人有动力去维护、组织专题，因为根本没有专题内先尝试自行讨论的诱因。客栈无限扩大使用范围是夺走这个基础诱因的主因。我完全看不到理论成立的基本理据。日维虽没有互助客栈，但专题依然是签名板。说明一连串的推测链根本不成立。连没有人有动力去维护、组织专题都怪互助客栈，是不是有点过了？

远者有：

“不需要限制谁要使用征求意见制度”——以贵站习性，没有好好规范的制度就会被用烂。。个人主观臆断。等

（待续）--Ghren🐦🕑 2024年5月28日 (二) 06:50 (UTC)

• 所谓“条目通告不能起了导流作用”，但移动的三则讨论连“通告”都不存在，同样不能以该三则讨论论证“讨论通告起不了导流作用”。“没有人看”的原因在于客栈极长篇幅下这些列表和通告并不引人注目；但客栈改为限制用作讨论条目讨论页难以满足的讨论后，客栈篇幅大幅缩小，“可以引人注目”的效果显然会大增。
• 关于“何以见得编者会阅读讨论通告”，目前社群习惯阅读客栈本身的topic list，在topic list中的讨论本身就比隐身在下面的RFC讨论列表更好被注意；在篇幅较短的客栈内，每则讨论通告的篇幅占比就会大增，也同样相对会提高讨论通告的能见度。
• “置顶没人看所以推断导流模板没人看”一说显然是滑坡，两者本就无因果关系。置顶没人看，但讨论还是有人看，这就证明问题在于很多人会选择性失明，光是这则讨论中某些用户的论点对方针的选择性理解已经能证明。再者，过往讨论可见部分讨论移交客栈仍然参与度低，这是反映某些不太被重视的话题本来不论在哪里讨论都会存在“参与度低”的问题，话题本身难以吸引流量并不能用以佐证某个制度失效。正如RFC/RFA2024本身是社群关注的议题，那么就算放得多“偏僻”都会有人来参与；某些饱受争议的议题也自然会有同样的情况。在目前的客栈下，不受关注的议题被比较大的议题埋藏；在建议的新制中，讨论通告都会在客栈有近乎相同篇幅的曝光度，这时讨论是否够人参与就在于议题本身而非其他因素了。
• 我说的是“客栈是（本地）无法组织专题的主因”，而并没有说“唯一/必要因素”。我的推论中表明“客栈导致了没有较小群体讨论这个维护专题的诱因”，你未有实际证明这个说法不存在；而你的推论“没有客栈的站点也是这样，因此没有这个因素”中存在否定前件的谬误。如果本地无客栈，而仍然无法组织专题，那倒是则可将“编者本身缺乏组织专题的动力”认定为无法组织专题的主因。从头到尾我的推论永远都是“真的没有第三方因素影响才确定是本身的问题”，我列出客栈的每一个问题都是尽可能排除被第三方因素影响而引致当前的状况。反方的推论却是“就算有第三方因素影响的可能性，都要先归咎在本身的问题”，但这个问题可能从头到尾就只是因为第三方因素导致的。
• “没有好好规范的制度就会被用烂”，本地大量例子啊。AIV没好好规范就被滥用作提报非破坏，导致管理员难以处理；客栈没有好好规范导致目前超出原先设计的使用框架，引发各种问题；RFDA没好好规范就被有心人滥用以报复自己不同意的管理人员，甚至不用顾对方是否真的违规。这些还不足以证明“本地没有好好规范的制度就会被用烂”吗？

--路西法人 2024年5月28日 (二) 09:34 (UTC)

此提案将限制编者在互助客栈条目探讨区发起若干类型之条目相关讨论。该分区自二〇一〇年创立至今已十余年，是本站目前最主要之条目讨论机制，此次政策修订涉及体制全盘变更，兹事体大；又此话题目前仅十五人参与，且长年参与实际编辑事务者可谓更少（如上方LuciferianThomas即指出某些参与讨论的维基人实际上鲜少来客栈条目探讨区），规模就该等重要之政策修订讨论而言显然不足。故除在该页面发送讨论通告外，还有进一步开展咨询之必要。

@20204622hkus、AliceYYin、Aronlee90、Asbtrl361442、August0422、Baomi、BigBullfrog、BlackShadowG、Carrot2333、Chu Tse-tien、Cmsth11126a02、CopperSulfate、Dabao qian、Dakhung、EleniXDD、Factrecordor、Fire-and-Ice、FradonStar、HYHJKJYUJYTTY、Happyseeu、Hat600、Heihaheihaha、Hercoffee、Interaccoonale、Irralpaca、JNO1、Jinxun、Justice3651d、KOKUYO、Kcx36、LHD、Lemonaka、Ma3r、Marvin 2009、Matt Zhuang、MilkyDefer、Milkypine、Miyakoo、Nostalgiacn、Perinbaba、Prince of Erebor、SilverReaper、Sohryu Asuka Langley Not Shikinami、Sprt98、Summerize、T45614631、TGTON、Taydou、The Puki desu：为确保实际参与者之权益在未来政策中获得充分反映，并弥补此前提案未能有效促进社群参与之遗憾，本人在此不论立场偏好，以一次性（不重复）之正式通知，诚挚邀请近一个月内（正好也差不多是此提案出台期间）使用过互助客栈条目探讨区、且未曾参与上方任何讨论的维基人，希望谈谈普罗大众参与客栈及一般条目讨论的经验并做比较，俾评估相关制度调整之利害；更欢迎就此提案之内容及可行性直接提供些许意见（包括支持、反对及其他折衷看法均可），相信将能加速促进真正共识形成。另外，本人及此提案其他某些参与者之意见虽鲜明至甚、甚至趋于对立，但相信诸位当可不受上方包含本人在内诸多正反唇枪舌战影响，自由且不受限制的发言。当然，诸位也可纯粹关注话题发展，监督社群协商过程，或者提前准备“适应”之类，总之必然较“一无所知”为好吧。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月24日 (五) 22:37 (UTC)

@ThomasYehYeh、Thyj、TimWu007、Tp0910、TuhansiaVuoria、UjuiUjuMandan、Vacaliforn、Wengier、Wetrace、What7what8、Wolfch、Xiaoxuang、Yangarui、Yumeto、世界解放者、克勞棣、向史公哲曰、屠麟傲血、彩色琪子、快乐的老鼠宝宝、日期20220626、暁月凛奈、桃花影落飞神剑、桜花雪、王桁霽、甜甜圈真好吃、神秘悟饭、红渡厨、自由雨日、超级核潜艇、迴廊彼端、逐风天地、重庆轨交18、银色雪莉、长乐未央、阿南之人、驻军、魔琴：（技术限制得分成两批，不过倒也可由此见条目探讨区还是很活跃的）—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月24日 (五) 22:37 (UTC)

(＋)支持，如果我理解得没错的话：（以条目讨论为例）如果条目讨论无果，不再去客栈发起讨论，而是通知客栈的人（或者类似的效果）来条目讨论。既然 Ping 到我，我说说个人体验：我一般不去客栈，只是在条目讨论无果（讨论人数也很少，可能就两个）时，才去客栈发起讨论，这样确实能让更多人参与（可能十几二十个）。所以我觉得，如果像我理解的这样，还是很好的：既能吸引更多人参与，又不用去监视客栈。--Ma3r（铁塔） 2024年5月25日 (六) 08:57 (UTC)

(－)反对，无论提案者如何“故意无视”或者“否定”其他不同意者的意见，或者出于推销自己维护的讨论提醒机制，我认为关于条目编写问题的共识，不应该限制其讨论的位置或者使用的工具方式，更应该考虑其他可能涉及的或者期望的参与范围大小，也就是，即使针对单一条目的讨论范围，也不应该其只在或者先在其讨论页进行讨论页，我认为条目探讨版是现在我们社群最具广泛接触性的讨论场合之一，可以作为更广泛的共识确认和接触场所，不应该只依赖于讨论提醒机制。可以鼓励使用，但不应该限制必须使用这套机制。所以第1点的“必须性”并不“必须”，应该倾向建议了，同样第3点同理。无论提案者想拖多久，说得多“动听”的理由，只要提案者不对这种强制性的要求作出改变，或者如此粗暴干涉过往的讨论惯例，我对此仍保持反对意见，并以WP:IAR为依据。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 00:59 (UTC)

总体来说——如果对某个条目方面的问题（范围从单一条目页面、特定专题或者主题（没有对应专题跨专题的情况），到对于整个项目的条目都有涉及的情况）：如果希望能得到整个社群的留意、或者针对特定专题的条目类别的对应专题观察上缺乏活跃，可以选择条目探讨版来讨论；如果针对特定专题的条目类别的对应专题观察上足够活跃并能局限于专题内的讨论，可以选择在专题下的讨论页来讨论；如果只局限于特定单一条目，且参与者都能或者同意只在可控的讨论场所范围进行讨论的话，可以选择在单一条目页面上讨论。条目涉及范围越广，就越可以和应该提升讨论场所的层级（从单一条目讨论页、专题讨论页、到条目探讨版等更大范围的讨论版块（如果有））。而且，上面这些做法，并不强制依赖或者需要讨论提醒机制。

反而，我认为应该控制讨论层级的随意调整，提升层级可以适当放松，但下降层级要限制（例如需要尽可能所有参与者同意的情况下），避免频繁移动讨论层级。这一点我认为更具实际意义。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 01:17 (UTC)

Cwek引用WP:IAR作为依据，说“不墨守成规”，却选择性无视5P5“方针与指引所蕴含的原则和精神比字面措辞更为重要”的字句。建立共识的过程本身就是一层一层慢慢扩大的，方针将互助客栈放在讨论页之后正是反映这个原则，甚至也有明文表明应该如此。在互助客栈发起讨论但未曾有关用户讨论也显然没有展示对解决编辑争议的礼仪。在社群全面使用互助客栈的现况下，所有讨论不经邀请有关联用户参与，专题无法持续有效运作正是反映互助客栈完全抹杀社群建立较小规模群体自行解决问题的能力。同时，Cwek完全无视无所列出互助客栈的多个重大问题，也无视解决客栈长年存在的问题才是提出限制必须使用有关机制的原因，更无视提案继续容许用户在客栈发送讨论通知能维持当前条目探讨板在没有大量讨论掩盖的前提下可以存在“各处的讨论都能获得广泛接触”的优点，还完全无视在影响广泛的议题中仍然容许使用客栈进行讨论的机制。“因为条目探讨板具有广泛关注”而“不应该限制”本来就完全建基于伪逻辑之上，限制并没有没出条目探讨板的优势，且限制是旨在解决客栈本身具有的问题。

简而言之：仅有在VPD大规模限缩使用的情况下，新机制在完全保留并理由互助客栈曾存在的优势的，使客栈的流量被善用的同时，能排除互助客栈的缺点，更能鼓励用户才得以建立自行解决争议而不需事事扩大讨论的能力。--路西法人 2024年5月25日 (六) 05:59 (UTC)

我的观点依然是根据条目的问题所需要的覆盖性或者共识广泛程度，而选择相应的讨论层面，而不是单靠规则（并且使用“应”这样强硬的规则式语气）来限制如何达成共识。无论你说的多冠冕堂皇，我依然指出你所说的“问题”仅仅你自己创造的问题，并且为自己创造的问题创造自己的所谓的答案，包括所谓的加载问题。所以我对IAR在这方面的理解是如上面所说的，而不是死规矩地先在指定的地方讨论问题，并且配合使用那个讨论提醒功能，或者随意地以不符合规则地关闭或者移动讨论。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 06:18 (UTC)

你坚持回避回应我指出5P5规定IAR是不必定要遵守细项而以方针原则为本，同时将其理解为如果你自己不喜欢就连原则都不需要遵守，乃是扭曲IAR、5P5及共识方针理解，就算你重复提多少次我都还是会将其视作无效论点。

你坚持回避回应我指出客栈的各种问题，无论你如何包装，那些问题都是确实存在的，且反方也持续无法真正针对我指出的问题作出回应。鬼打墙并不会使我退缩承认非针对提案回应的反对意见。--路西法人 2024年5月25日 (六) 08:20 (UTC)

“专题无法运作”本身也存在专题缺乏关注参与人员的表象（或者说，由于我们社群活跃强度太低了，必然导致一些专题无法存在足够活跃的参与，或者足够活跃的讨论），而不是原因，不应该以此作为强迫将对应专题的条目问题讨论应该圧回对于专题的讨论页，还是上面所说，如果涉及的需要参阅范围过大，可以一步优先在范围更广的条目探讨版处理，也一定程度上令关注或参与不活跃的专题对应条目也可以得到更多的关注场所。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 06:25 (UTC)

专题缺乏关注人员在于所有讨论都被推到客栈，自然没人去专题发起讨论，更导致没人去关注专题，问题根源在于客栈设计。我也没有强迫只能选择专题讨论页，条目讨论页及（若涉及多个主题）客栈仍可作为选择之一。这本身只是提案的其中一个选项，你的留言却扭曲成提案只提供这一个选项，显然是与提案无关的反对意见，依共识方针注释一将视作无效意见。--路西法人 2024年5月25日 (六) 08:23 (UTC)

注：此处原有文字，因为Cwek发言持续假定恶意、诉诸动机，诽谤本人基于私心鼓励偏颇共识。，已由LuciferianThomas(留言)于2024年5月25日 (六) 13:35 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。

完全属于臆测的留言内容，与提案本身内容无关，也非实际对提案本身的点评，依共识方针注释一将视作无效论点。若再有任何无断臆测、胡乱扭曲提案本质，将作离题以隐藏留言处理，并请求第三方管理员处理假定恶意（“推销”、“提案者鼓励偏差”等）及离题讨论。--路西法人 2024年5月25日 (六) 08:28 (UTC)

另，所谓“使用新规则堵截提升讨论者范围”乃是完全展现反方完全没有在读提案。提案只是先行要求用户尽可能自行解决争议；在自行解决争议无果后通知“特定专题”跟“互助客栈”是同一步的事情（都是征询第三方意见），不会存在“避免无关人士参与”的荒谬说法。若编者无自行解决争议的能力，需要依靠其他人介入才能解决争议，显然只会产生出无法作出有效讨论的社群。

另外，共识方针本身就有WP:CON#共识的级别，一来反映社群本身就可以存在不同级别的共识，所谓“不广泛的共识”也仍是有效的共识；但同时也规限了这些“不广泛的共识”不能凌驾更广泛的社群共识（如方针指引、征求意见和互助客栈所得出的结果等），本来就不会容许更多特定倾向的参与者可以形成对此倾向的把持。能说出这种话仅仅完全表明反方选择性阅读方针、选择性阅读提案，只抓部分内容包装成自己不喜欢的版本然后拿来反对。局部理解当然会产生问题，不然我提整个整体提案来干嘛？反方这种态度不就正正显示了局部理解方针和提案的问题所在、如何无法作为有效意见采纳吗？--路西法人 2024年5月25日 (六) 08:42 (UTC)

注：此处原有文字，因为Cwek发言持续假定恶意、诉诸动机，诽谤本人基于私心鼓励偏颇共识。，已由LuciferianThomas(留言)于2024年5月25日 (六) 13:35 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。

注：此处原有文字，因为Cwek发言持续假定恶意、诉诸动机，诽谤本人基于私心鼓励偏颇共识。，已由LuciferianThomas(留言)于2024年5月25日 (六) 14:32 (UTC))删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。

(－)反对：据我经验，就算关于一个单一条目的讨论，有时也不是依靠活跃于该条目的人就能解决，不少情况下需要寻求更多人的意见，包括对维基规则熟悉的人，或在其他条目有相关经验的人，而这些人不会主动出现在个别条目的讨论页。若依靠个别活跃者去@其他人来发表意见，也很可能会只召唤立场相同的人过来，令更熟知维基人事关系的一方获得优势。就算共识不一定广泛，我们应该尽力让共识广泛，吸收更多人的经验，而不是让个别条目变成活跃者的小圈子。除非设立一个界面显示近来有哪些条目发起了新讨论，才能姑且考虑。另外顺带一提，我反而感到维基人过于喜欢去人家的个人讨论页发起讨论，令到一些牵涉个别条目的争议细节、编辑行为的背后动机，这些来龙去脉有时没法被其他编辑者注意，或令到后来的编辑者难以追溯当时发生什么事，例如令我感觉最差的《中年好声音》在播映期间被全保护三个月一事，在其页面讨论里就没留什么痕迹，整个过程也完全没有询问其他有参与编辑但在编辑战期间没有活动的用户，显得不尊重。虽然这好像是题外话，但也反映到讨论的地方越小众，越少人察知，越易构成危害。我始终主张让多些人察知的精神，这重要过一些行政问题。--Factrecordor（留言） 2024年5月25日 (六) 11:45 (UTC)

又是一个没读提案就来反对的用户。WP:RFC、WP:FRS和向客栈发讨论通告不就是防止有偏见地找人讨论的解决方法吗？又不是只能ping不能招人，只是提供工具下不要移动讨论而已。在社群越发成长之时，每一则讨论都要“广泛共识”显然不可行。--路西法人 2024年5月25日 (六) 11:58 (UTC)

WP:FRS人手有限，只是聊胜于无，帮助不大。WP:RFC似乎原则上是可以的，但我关注的重点是多少人察知，正如被通知来讨论的原因，长期以来互助客栈是主要的平台，我这个不新不旧也算有点贡献的用户甚至从没被介绍过WP:RFC这种机制，所以WP:RFC或同类的机制似乎是需要更大的推广，更多人参与，界面优化之类，再决定全面推行本主题的主张。--Factrecordor（留言） 2024年5月25日 (六) 12:26 (UTC)

我在上方的留言已经提及过为何RFC为何无法全面推行，这里复制一小段出来：互助客栈条目探讨板总长70页，RFC讨论列表一节仅占1.5页。这不是“征求意见制度实绩不彰”，而是互助客栈条目探讨板的长度完全使RFC讨论列表难以被注意。现在的情况跟在一整页报纸上仅有一个小卡大小的版面说是有公告那样。RFC根本尚未被给予完整的机会去运作，任何形式去扩大RFC能见度的动作又被抹黑成“推销”，简单而言就是反对RFC、不认为RFC有用的用户实质上无限压缩RFC的运作空间后说RFC没人用。--路西法人 2024年5月25日 (六) 12:59 (UTC)

作为RFC机制的引进者，难道不应该正视存在有编辑对这些机制的负面意见？——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 13:05 (UTC)

效果不好是在于机制被淹没难以被注意而非机制本身的设计问题，你是哪一只字看不懂？--路西法人 2024年5月25日 (六) 13:39 (UTC)

或者“被埋没”不就是其必然遇到的问题？如果所有乃至大部分编辑自愿使用，那就不会被埋没，甚至也不需要这样强推强制改变？——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 14:04 (UTC)

人没看到何来有人“自愿使用”？被埋没然后归咎在新制度之上，跟检讨受害者有何分别？--路西法人 2024年5月25日 (六) 14:29 (UTC)

如果特定条目内容在有限讨论位置的范围内没有充足或者预期没法有充足的讨论时，自然会考虑将其放到更广泛的讨论地方，也就是条目探讨版。而且可以看出，现时仍然存在编辑不认同或者不了解RFC、FRS，所以不应该以强制要求让这些编辑去关注这些机制，应该使用宽松的“建议”性去推荐使用，不想使用这些机制的编辑完全可以按照已有的讨论惯例做法去完成条目内容的讨论与共识的达成。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 13:03 (UTC)

对于RFC的提案者如此强推态度，我能接受的考虑也就是：对于讨论时间过长（或者预期过长）（长度的判断：可能超过两周，因为从条目探讨版来看，一部分已经不活跃的讨论，基本持续两周以内就似乎能解决）的情况下，应该建议使用RFC另页讨论，避免过度挤占页面（解决页面加载问题）；保留“正在广泛征求意见的议题”在条目探讨，作为FRS在更广泛的场合的提醒引导；使用RFC另页讨论的，应该保留指引路径在条目探讨版，作为提醒引导。——2024年5月25日 (六) 13:18 (UTC)--此条未正确签名的留言由Cwek（讨论｜贡献）于2024年5月25日 (六) 13:18 (UTC)加入。

仅“建议”就代表继续放任有问题的旧机制继续烂下去。反方为了佐证自己的论点，连“这些问题都是你发明出来”这样的话都说的出来，拒绝真正去理解驳论，将问题归在提出问题的人身上，显然开始不讲道理了，我也无义务再放任此类留言扰乱此讨论串。无法真正回应问题之处而声称问题不存在，又无法证明问题实质上不存在的言论将按共识方针注释所指“并非针对提案的发言”一律视作无效意见处理。--路西法人 2024年5月25日 (六) 13:47 (UTC)

看到这个议题已经争论许久了，能不能干脆在客栈列明使用条目讨论页和互助客栈的好处及坏处，然后由社群投票决定是否强制规定须在讨论页发起讨论？现在正反双方再辩经下去没完没了，议题观点来来去去就那些且双方谁也不服对方。而且如果强制通过但后续大部分人不愿遵守也没用啊。先声明，我对这个提案的初衷和想法十分认同，互助客栈也确实有许多毛病，但好像不是所有人很在意这些毛病。--微肿头龙（留言） 2024年5月25日 (六) 14:02 (UTC)

正正是这个问题，如果仍然有相当一部分编辑不认为这套方案好用，就算提案者强推，依据过往好用的讨论方式继续（也就是IAR的“如果有规则妨碍您恰当地改进或维护维基百科”，这种强制方式阻碍了这些不满意这套机制去“改进或维护维基百科”），他们也会忽略这套规则，毕竟原来的方法一样能达成条目讨论的共识。“仅“建议”就代表继续放任有问题的旧机制继续烂下去。”不就是提案者认为的“问题”？说了这么久不是仍有一批编辑不满意这些方式（即使你否认这些意见）？应该采取宽松的方式，或者按照现时对RFC、FRS在条目探讨版的使用，各走罗马路，作为对比，让编辑们自己选择好的方式。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 14:17 (UTC)

或者如所说，这套机制看着烂（屎山那种），但有编辑们愿意用，或者不在意，能维持下来：很恶心但又无奈。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 14:24 (UTC)

“有人满意”不等于“问题不存在”；“很恶心但又无奈”更代表需要改。--路西法人 2024年5月25日 (六) 14:34 (UTC)

“有人满意”、“有人不在意”就给了这个提案的“非必须”性，如果将这些措施的强度倾向“建议”、“推荐”的力度，或者可以避免这个讨论这么对立（至少我也阔佬懒理，你也不用语气强硬；也可能我也会掂量着什么程度的条目讨论放到什么程度的范围，根本用不到这些规则）。还是上面那句：各走罗马路，作为对比，让编辑们自己选择好的方式。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 15:08 (UTC)

正在组织内容，写了一个下午了。--路西法人 2024年5月25日 (六) 14:05 (UTC)

统整

由于上方有用户通知了大量用户参与讨论，此处开一节重新统整提案及上方正反两方的论点及有关回应，以便新参与用户能更简明的了解上面近200则留言在吵什么。

目前社群探讨条目及模板内容等的“最高场所”为维基百科:互助客栈/条目探讨讨论板，长期都会有大量的讨论于该处发起，也是参与讨论用户最多、阅读流量相对最高的社群讨论板块。经审视，我发现该板的讨论串大多数是在该板直接发起而未有充分尝试在讨论页与有关用户商讨达成共识；也有很大部分都是仅涉及个别条目的讨论，根本不至于需要征求全站用户意见。该讨论板的置顶规则自该板开设至今，一直存在“任何条目或模板的交流应考虑先在其讨论页发表，而若无人加入讨论才可在此发起”的规则，显然没有被严格执行。

有讨论板给各编者踊跃参与讨论固然是一件好事。过往缺乏配套和措施，在个别条目讨论页发起讨论确实难以引起其他用户注意，越来越多人选择在互助客栈条目探讨板发起讨论是可以理解的现象。然而，社群慢慢从“没人参与才来客栈发起讨论”演变成当前“直接在客栈发起讨论”的情况。目前编者毫无节制地滥用（使用而未遵守板规）该讨论板，以及该讨论板本身的机制设计产生了以下问题：

1. 当前制度未能鼓励用户在征求第三方意见前尝试自行解决争议。
2. 条目讨论页未被善用，对条目影响相对重大的讨论反而不在条目讨论页商讨，不知情的用户浏览对应的条目讨论页根本无从得知有讨论正在进行，更有机会在讨论页发起平行的讨论串。
3. 部分先在条目讨论页发起的讨论无法达成共识就移师互助客栈条目探讨板征求第三方意见，在原处之讨论却几乎从来不会在此时关闭，形成平行讨论。
4. 互助客栈并非新用户“直觉”就知道是讨论的场所。条目讨论页往往不会附有互助客栈的连结，新用户发起或寻找讨论最直觉就是在页顶就有连结的条目讨论页。客栈便利旧用户，也仅仅会变成旧用户围炉，新用户除非被ping，否则都几乎不会主动找上客栈。
5. 讨论板页面过长会导致载入及编辑储存越发缓慢，在社群逐渐发展、需要讨论的议题只会越来越多之下，这个问题只会越发恶劣。目前互助客栈条目探讨板长度长期大于20万字节，过往亦曾发生讨论时使用过多模板而无法载入的问题，显然页面过长是一个非常需要解决的问题。
6. 互助客栈讨论串过多，本身性质比较不受关注的讨论会更难被注意到，导致“以为迁移至客栈后能获得解决”的议题送去客栈后也仅有寥寥数人参与讨论，屡次发生讨论无疾而终的情形。
7. 目前设计下，互助客栈的讨论串可同时被存档至多个讨论页。
   • 客栈经常发生讨论无疾而终后自动存档的情形。自动存档后，讨论未曾正式关闭，其他用户看到讨论就会以为讨论仍然活跃，最终可形成平行讨论串。
   • 就算讨论已结束后存档，重复的存档亦可导致后续需要补充讨论时出现平行讨论串；分支存档后的讨论亦难以追踪及维护。
   • 存档后，难以在互助客栈的“存档”中（存档移动至讨论页后客栈仅存档标题）查找话题有相当的困难，因为根本不知道存档到哪里去。
8. 客栈讨论串过多时，讨论于互助客栈发起，仅关注该单一主题的用户需要多追踪一个页面的讨论，每次来互助客栈检查讨论进度也需要找讨论串。
9. 客栈无法让用户持续追踪特定感兴趣类别的话题，用户仅能通过不断查看并人肉筛查去找感兴趣的话题。（比对专题讨论页和征求意见机制）

有鉴于此，我提出了以下规范讨论的递进机制：

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

除了解决上方提及互助客栈条目探讨板的种种核心问题，亦期望建议机制协助完成以下长期目标：

1. 重新建立编者间不需依赖第三方意见，建立自行理解方针指引要求、自行与发生争议的用户进行商讨解决争议的基本讨论参与能力。
2. 减少互助客栈条目探讨板的使用压力，最大限度解决旧制度问题之余，继续善用互助客栈的流量及其他讨论机制的优点辅助进行各类型讨论。
3. 重新建立编者间自行组织专题协调内容建设及讨论的能力。

以下综合记录反方提出的论点及有关回应（已按意见修订提案的意见不列入此处）：

1. 建议机制依赖征求意见，而征求意见成效不彰——分两部分回应：
   • 征求意见在建议机制中仅是作为辅佐工具使用。没有征求意见协助推广个别讨论不代表社群应该毫无节制地将讨论都塞进互助客栈。在条目讨论页等合适场所发起讨论需要征求外部意见时，仍可向互助客栈发送讨论邀请通告，而并不需要重新在互助客栈发起或将讨论移动至互助客栈。
   • “征求意见成效不彰”跟“征求意见未能彰显成效”是完全不同的概念。前者表示机制本身缺陷导致效果不好，后者表示机制因外部因素而效果不好。条目探讨方面，目前征求意见引起其他用户关注的方法仅有在互助客栈的置顶通告及那一节的讨论列表。置顶通告没人关注或跟从是预期的结果，该板置顶模板存在了十数年的规则也是完全被无视。讨论列表置于互助客栈的topic list之下，用户往往在topic list找完主题就跳过讨论列表，自然容易被忽略。更何况，互助客栈条目探讨板（下笔时版本）70页A4的篇幅，征求意见列表仅占1.5页。这些都反映征求意见本身都还没获得足够机会完整展现效果，根本不可能迳下判断说征求意见机制效果不好。另外，有反方Ericliu1912的“善意”编辑损毁机器人阅读WP:FRS的页面格式，导致FRS停止运作将近半个月（且无人反映），当然无法展现效果。
2. 架空互助客栈——根据定义，架空是“比喻暗中受到排挤而失去实权”。此反对论点暗示了互助客栈的作用是被不公平地排挤了，然而我能轻易列出会对编者造成实际影响的众多问题，有问题而被排除就显然不是被“不公平”地排挤，而是因出现问题而淘汰。
3. 目前客栈还没有非常明显的负面影响——负面影响一直存在，版面过长导致载入困难或出现模板限制等都是非常明确的体现。其余负面效果也当然存在，认真观察不同讨论的后续就能看到这些负面影响。只会逛客栈不逛条目讨论页的用户当然看不到。
4. 违背互助客栈条目探讨板设立初心——条目探讨板设立之初已经存在讨论须先在讨论页发起一段时间无人参与才能转移的规则，这也是条目探讨板的“设立初心”，目前互助客栈的使用情况才是真正违背该板设立初心的体现。
5. 不应限制/强制编者选择在何处发起讨论的自由——“自由”不代表“无政府”，也不代表可以造成伤害。目前无规范下，用户无法遵守讨论板规则而正确使用各讨论板，那自然就要规范（WP:NOTANARCHY）。
6. 维基百科不是官僚体系或避免说明泛滥：理想情况下确实不需要如此明确的规则去规范，但社群目前缺乏自制能力下才必须如此。共识方针本来就已经包含“先在讨论页讨论再在客栈发起讨论”的有关条文，改变社群陋习后就不再需要如此明确的限制了。
7. 征求意见制度应被视作互助客栈的“雅座”，不应强制分流——征求意见本来就不是用来“分流”用，而是从源头鼓励用户在讨论页发起讨论后不要再移动。所谓“分流”仅会有移动讨论的负面后果。
8. 讨论发起人未必知道哪个主题条目、专题讨论页合适——新机制本来就容许在当下发生争议的讨论页或（若涉及多个不同主题的条目）互助客栈，“主题条目”的定义也并不严谨，与有关条目的最有关联的主条目的讨论页都能作为主持讨论的场所，没可能“找不到”。固然，目前专题的活跃度极低，这个期望编者们在更新制度，让互助客栈不再被滥用积累过多讨论时，编者们自然就会慢慢重新组织专题。
9. 机制鼓励有同样倾向的人士把持讨论——机制设计让编者ping人，拉票方针的规定依然有效，如果有用户为了偏移讨论共识而只拉特定倾向的用户参与讨论，仍然违反拉票方针。征求意见、客栈发送讨论邀请则无此忧虑。

另外补充为何上方讨论的态度会变得如此差劣：Ericliu1912及Cwek等反方用户的多次发言反映未真正阅读、了解提案内容就提出反对，选择性扭曲提案内容之余，还持续拒绝回应对其反对意见的驳论，鬼打墙重复已被回应的观点试图拉布，同时无限扭曲、无视各处方针及规范。Ericliu1912在我要求下一直无法提出实质驳论，就开始指控我“球员兼裁判”Cwek亦开始造谣我推动此议案的动机和目标，完全无意认真讨论。我谨此严正谴责两名反方用户为了阐述其观点，无所不用其极地扭曲方针及提案、对我人格抹黑的行为。

以上。路西法人 2024年5月25日 (六) 14:30 (UTC)

目标宏大，然非一蹴可几。只闻客栈罪大恶极问题多，条目讨论页问题岂少？且上揭问题两者皆有者甚矣，尤其涉及讨论程序部分，如难道换到条目讨论页就能有效关闭讨论？这当然不可能，但既可归咎于客栈罄竹难书，则何乐而不为？本人认为，这才真的是所谓“只会逛客栈不逛条目讨论页的用户当然看不到”的东西，甚至可说是官僚式的“为解方找问题”了，此提案许多声称均是如此。改革管道繁多，举凡存档及讨论机制调整等，可解决前述问题者亦不鲜见，偏选择走此等险路，不顾既有类似之失败结果（远在此提案以前，成效即颇不彰；近期如Sanmosa君尝试活用征求意见制度之发展，则尚有待观察），又不给社群另以折衷测试额外评估之机会，空口说白话承诺理想愿景的“支票”谁都会开。包裹提案条文未臻清晰，强推作为频出，自行定性诋毁意见、扫清异议障碍均在所不惜，也让许多人退却自行备案与分部详细磋商的契机及兴趣，此自不必多言；而妄想以政治手段全面镇压斥之以鼻而须矫正之所谓“陋习”，而非谨慎温和而有敬意地加强引导、扭转十余年来社群自然形成之讨论惯性，或自可收得一切顺利无波澜之死寂表象，然隐约不可见之损害必成于其下。对新手而言，锻炼熟悉写作及沟通技巧，更需要老手议事相助——这正是互助客栈的职能，反而不应该鼓励他们一开始直接去条目讨论页参战。又新手若来互助客栈求助区求助，自然也就知道有条目探讨区，得以踏出熟稔社群的第一步。本人已经不是新手，无欲多加揣测新手心理，但集中讨论在此方面优势极为显著，甚至及于其他有经验编者。

本人尊重编者尽可能想怎么讨论改进维基百科条目之自由，也钦佩愿意在此话题中尝试推动提案修正的朋友。从来没人觉得限制凝聚共识的人数门槛、公意形成要件、改善讨论关闭程序是坏事（实际上包含征求意见在内，多数条目讨论也存在同样严重的问题），甚至积极分流讨论更无妨，但只要有道理地就条目内容达成共识，凭什么限制编者要在哪里开启讨论或禁止在哪里发表什么类型的议题？凭什么用一纸方针条文阻止编者自己找到合适的办法改善条目？又两三个人自己能解决的事，要求一开始就聚众喧哗做什么？这种过度僵化的规定根本没有必要，也没有意义。由此衍生的其余假想实际上都只是窒碍难行的枷锁罢了。是放任自由讨论还是箝制限缩讨论伤害大？本人见过无数人抱怨互助客栈不够好用，也有人认为可以多加善用条目讨论页、更适当移动或存档讨论等，但从来没有人觉得应该据此禁止在互助客栈讨论某几种条目相关话题。提案人当然很明白“推荐”与“强制”之区别，但明确决定要走错的路，这正是现阶段此提案不应该通过的原因。近来无力就此等冗长讨论之多加辩驳是事实，不过在恐怖气氛下铺陈论述有什么用？以为没试过？自从讨论在此荒郊野外之处莫名其妙“续命”延长然后“丝滑”付诸公示之际，本人就已丧失继续辩论下去的动能。换作谁面对这种话题恐怕都没能力应付，上面也有人指出过了。“球员兼裁判”之说法，一点都不过分。其实这本来是个供正反各自充分陈述意见，开放社群讨论协商，然后分节拟订题目、付诸社群投票公决就能解决的议题，但只怕最后仍是一路碾压，“七日无合理正当异议，公示通过”，太平无事。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年5月25日 (六) 15:15 (UTC)

• 上揭问题两者皆有者甚矣，如何“皆有”？
  1. 过早提出征求意见自然会该被其他编者打回，但客栈本就有此规而无人执行，你作为管理员对此不是协助执行而是视若无睹，更强词夺理合理化有关行为。
  2. 此案正是旨在善用条目讨论页，显然不存在此问题。
  3. 此案正是防止了移动讨论而造成的平行讨论问题。
  4. 不需我赘述也知道条目讨论页不会有这个问题。
  5. 讨论页多数情况下仅会有一则讨论持续进行，除非持续讨论很久，否则都很难发生讨论页过长的情况。
  6. 已结束讨论可原地存档，讨论串不会被“淹没”；不太受关注的讨论反而得益于客栈长度缩短而更能被注意到。当然，仍然是无人关注的议题不论放哪里都强迫不来。
  7. 此案设计正是解决分支存档的问题。
  8. 讨论没移过，自然只需追踪该讨论所在的讨论页。
  9. RFC有提供追踪特定主题讨论，显然解决了此问题。
  我有能力论述客栈的问题，请问你在哪里有论述过“两者皆有”的问题，以让社群考量？如无，是否又是空口无凭，不提供论证的反对意见？我提出改革，论证改革要解决的问题的责任自然在我；你提出反对，论证改革存在的问题的责任自然在你，但你还是坚持不做。
• 改革管道繁多，凡存档及讨论机制调整等，可解决前述问题者亦不鲜见，如何“不鲜见”？类似之失败结果，什么的类似的失败结果？Sanmosa移动的部分讨论串连RFC都没挂，何来“活用征求意见制度”？是否又是空口无凭？
• 又不给社群另以折衷测试额外评估之机会，原话奉还给多次实质损害或阻拦各新制测试机会的你。
• 包裹提案条文未臻清晰：此处条文本来就不需要清晰，可选的位置就是写得相对模糊，以让在除了已经论证不合适的场所外任何真正合适的空间都能发起讨论。
• 自行定性诋毁意见、扫清异议障碍均在所不惜，你和Cwek一来就人格抹黑，且持续未能作出实质论证，反过来还给你“自行定性诋毁提案、为了阻挡议案通过而不断扭曲方针和提案均在所不惜”？
• 妄想以政治手段全面箝制、镇压斥之以鼻所谓须矫正之“陋习”，而非谨慎温和而有敬意地加强引导、扭转十余年来社群自然形成之讨论惯性，谨慎温和的任何举动都能被反方冠上“推销”污名、多次以手段实质性负面影响任何温和的引导举动，外加社群本就有在不恰当的时候忽视规则的事实，否则何须严格管控？
• 对新手而言，锻炼熟悉写作及沟通技巧，更需要老手议事相助，这从来不是“互助客栈（条目探讨板）的职能”，这是“所有维基老手的职责”，不论在哪里发起的讨论都应该协助新手。
• 反而不应该鼓励他们一开始直接去条目讨论页参战，这句更是可笑之极。讨论页的讨论就叫“战”，有名字你叫的“互煮客栈”就没有更“战”？那岂不是更不应该鼓励他们一开始就直接去互煮？
• 又新手若来互助客栈求助区求助，自然也就知道有条目探讨区，认真一看VPH就知道区互助客栈求助板的用户多数是因操作受限而求助，而非参与条目讨论；以你的同样逻辑，新手若是编辑甚至只是阅读条目，都能看到页顶“讨论”二字，自然也就知道有条目讨论页。
• 再者，把新手引导至互助客栈条目探讨板，你是想害死他们？连最基本的方针指引能力都缺乏的新手，引导他到眼花缭乱的场所参与编辑本就不合适；不知就里的新手看到自己有兴趣的话题插个嘴，但不熟悉方针指引，是送他们过去讨骂？在客栈参与讨论的用户，多多少少都对方针指引有一定的熟悉度，新手一来就越级挑战客栈很合理？
• 只要能在合理合法的条件下就条目内容达成共识，凭什么限制编者要在哪里开启讨论或禁止在哪里发表什么类型的议题？凭什么用方针阻止编者自己找到合适的办法改善条目？就凭客栈确实存在的问题，造成问题就该被限制。编者自己认为“合适的办法”不等于问题不存在。想当然，你就会想以同一句说我认为合适的办法不等于问题不存在，然而你指出实质的问题所在了吗？
• 又两三个人自己能解决的事，要求一开始就聚众喧哗做什么？提案正是要用户两三个人自己能解决的事就自己解决，要求不要一开始就聚众喧哗，你这不是反而佐证有通过有关要求的需要？
• 从来没有人觉得应该据此禁止在互助客栈讨论某几种条目相关话题，没人提出就代表以后都不能提出？什么道理？
• 明确决定要走错的路，当前客栈运作不遵从反方口中的“初心”，这是已经走错的路，反方还是坚持要继续走；我的提案连运作都没运作，路都没上，何以看见是“走错的路”？你是有穿越未来的能力？你一直坚称我所为是“诋毁意见”，但你自己一直无法作出完整论述，就已经直接判断是“错的路”，何以不是“诋毁”？

每次我都费尽心机以尽可能详细的方式分析你不论有多荒谬的说法，而你每次却都以空泛无论证的论述唬弄过去，还好意思说你自己“无力”继续说下去？--路西法人 2024年5月25日 (六) 18:57 (UTC)

“该讨论板的置顶规则自该板开设至今，一直存在“任何条目或模板的交流应考虑先在其讨论页发表，而若无人加入讨论才可在此发起”的规则，显然没有被严格执行。”或者就是IAR的体现：“如果有规则妨碍您恰当地改进或维护维基百科”，或者编辑认为“若无人加入讨论”特定范围的讨论页（针对特定条目或者特定专题（可能是缺乏活跃的专题）），他是不是可以直接提升到条目探讨版去处理？关于问题点：点1、只是阐述现状，没意见。点2、前面说了，如果相应的讨论参与者本身就不想用？点3、讨论版的“存档问题”（完成讨论应该即时存档（页）），或者部分讨论参与者急眼了会没留意条目探讨的讨论，应该指导位置继续讨论，另外也存在部分过了良久的讨论（可能超过一个月）已经停止讨论后，仍有编辑试图接续，而不是重开新讨论（并可以提及前讨论）。点4，当新用户接触编辑熟悉的话，互助客栈迟早是需要了解的地方，而且部分规则也提到互助客栈的存在。老用户也应该适当做出引导。点5，加载问题是一定程度存在，但可以借助RFC等机制解决，而且观察来看，一部分讨论能在2周内讨论静默，或者可以进入存档处理。点6，单一个讨论过长的情况，无论何种方式都有可能存在编辑因为冗长而不愿意继续讨论情况。点7，与点3 “存档问题”类似，而且应该意识到这样的移动讨论可能已经完结（可能变成无法达成共识），而不应该接续；而且正确使用saveto的话，现时自动存档是能保留原来在条目探讨的标题和讨论对应的页面（看不出这算是问题或者缺点）。点8，与编辑的习惯有关，存在只关注“（关心需要广泛性讨论）互助客栈+关心的特定专题+关心的特定条目（+不使用讨论单独监视）”，如果不关心相应版块的，可以不监视对应。点9，不反对意见。提案者虽然提出对于这些问题，的确存在一定的合理性，甚至提案者表达出强烈的“希望社群参与者自己先自行在有限小范围内解决条目规范问题”，但似乎也不完全是必要必须地改掉的，也就是如前面讨论的存在编辑提到“但好像不是所有人很在意这些毛病。”。如果这个提案者与RFC、FRS的关系没有这么明显的话，或者有些编辑不会这么介意“必须”这种强硬规则措辞。如果将这些措施的强度倾向“建议”、“推荐”的力度，或者可以避免这个讨论这么对立，并且给这些机制一个展现的机会（至少现在放在方针、条目探讨版应该足够不埋没，对于愿意关注的人来说），各走罗马路，作为对比，在满足现时讨论需要和规范的情况，让编辑们自己选择好的方式。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 15:33 (UTC)

（准备休息，并且不想再为这种应该是可选的规则浪费精力，后续不再回应，只能说大路朝天，各走罗马路）我期望的让步就是（前面的）“对于讨论时间过长的情况下，应该建议使用RFC另页讨论，避免过度挤占页面（解决页面加载问题）；保留“正在广泛征求意见的议题”在条目探讨，作为FRS在更广泛的场合的提醒引导；使用RFC另页讨论的，应该保留指引路径在条目探讨版，作为提醒引导”，最终的规则应该偏向“建议”、“推荐”而不是通过“必须”搞规则“革命”。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 15:33 (UTC)

（有关IAR）“忽略所有规则”并不意味着所有行为都有正当性。在过往没有任何配套下，忽略有关规则是“尚可理解”但绝非“应被接受”；新制能提供改善配套下仍忽略有关规则显然缺乏正当性。

（二）现在问题不在于用户想不想用，而是客栈从来就不应该（置顶规则）不能再如此使用。

（三）移动讨论除了有平行讨论的问题，还有流失原先留言论点的问题；整串迁移更是让不熟悉运作的用户摸不着头脑。新制虽说要将在不合适场所发起的讨论移动，但我更倾向于将不合时机在客栈发起的讨论尽早关闭并指导合适的讨论区；如果讨论已经开始，也应通知所有已参与用户讨论串已被移动。另，在讨论页发起且无重复存档的讨论，就算是停止了讨论也是能原串直接重新开启（各方论点完整可以被继承）。

（四）既然互助客栈是需要“引导”的，那正是证明互助客栈并不是适合基础条目讨论的场所，而是后来才参与较广泛主题讨论的合适场所。

（六）“应该意识到”，期望新手“应该意识到”吗？

（七）在客栈保留标题，是期望用户背讨论标题关键字吗？更何况讨论标题并不必然包含需要搜的字。仅有标题不是明显比在各讨论页原处存档直接能搜讨论内容更好？另，讨论通告也会有简单的介绍内容（类似RFC的主题句），不是比寥寥数个字的标题更好搜？

（八）你都能说出“（关心需要广泛性讨论）互助客栈”，请问互助客栈现在仅仅被用作探讨“需要广泛讨论的话题”吗？显然不是。关注特定专题这一点是RFC赋予的便捷之处，互助客栈一天继续掩埋RFC列表，用户不但不能关注客栈“需要广泛性讨论”的话题，也无法关注“特定专题”（因不多人知道用RFC），症结点不是正正在于客栈目前的滥用状况吗？

如果这个提案者与RFC、FRS的关系没有这么明显的话，或者有些编辑不会这么介意“必须”这种强硬规则措辞。所以是论证你们说话是对人不对事咯？

倾向“建议”、“推荐”的力度，我也已经论证过“推荐”是没人会去遵从的，单单是继续容许任何的漏洞都会继续扩大互助客栈的缺点，直到再一次爆破为止。--路西法人 2024年5月25日 (六) 18:57 (UTC)

(！)意见虽然EricLiu通知的是没参与本页面讨论的用户，不过我一直有看讨论，没想到越吵越烈。还是建议别弄得像立法院一样，维基百科是很直接行动的，很多事情是在实际运作中解决，而不是辩论解决。我个人认为这种事情从实际上讲只能是“建议”。有用户提到页面长、加载速度慢，但实际上页面内容长期以来都是文本为主，加载速度往往是受到MediaWiki为有个人设置的注册用户渲染而非直接使用缓存、用户个人js过多（例如用来编辑特定页面或命名空间的js因缺乏设置在任何页面都加载一遍）等影响。btw上面有些用户的js加起来可能比互助客栈还长。——暁月凛奈 (留言) 2024年5月25日 (六) 16:14 (UTC)

您说的对，其实真的没有规则阻止我在不将此案纳入方针下照样做这些动作以解决客栈问题。有关“建议”，我也已经论证过十万次“建议”是没人会去遵从的，目前使用RFC已经是“建议”，有用吗？--路西法人 2024年5月25日 (六) 18:57 (UTC)

@LuciferianThomas：那个机器人停止运作半个月都无人反映问题，说明绝大部分用户完全不在乎那个机器人的通知以至于这么长时间没有受到通知都没察觉。我个人也放过几次rfc，但基本应者寥寥，但一丢到客栈就有一堆讨论了。这是否说明目前社群还未能够适应新的机制，或者说是“不思进取”、“甘于现状”？我觉得如此倒不好强逼所有人都到讨论页讨论，否则恐怕会引起巨大反弹。还有，我觉得Wikipedia:回馈请求服务的订阅人数目前不太够，需要考虑怎么推广，可能可以把订阅的链接放在客栈或其他较为显眼处？感谢阁下细心整理讨论，不过看样子阁下的提议是不会被多数人接受了。--微肿头龙（留言） 2024年5月25日 (六) 17:09 (UTC)

70页的互助客栈里，RFC的讨论列表仅占1.5页，多数客栈的参与者更是在RFC之上的客栈话题列表直接点章节标题跳过该处讨论列表，“应者寥寥”的原因不显而易见吗？RFC并不是因为自身设计而“失败”，而是因为现有制度压挤而未曾实际以full capacity运作作测试。这部分不能说“不思进取”，而是“连能进取都未必知道”。

至于将FRS放在显眼处，客栈的讨论规则也是在置顶模板的显眼处、页面过长建议使用RFC的通告也是在置顶的显眼处，但显然仍然没几个人会去注意，光是放在“显眼处”显然是行不通也不足够的。--路西法人 2024年5月25日 (六) 18:57 (UTC)

RFC的讨论列表占的篇幅短只是一点，有许多人收到机器人发的通知后都没有前来讨论。虽说参与与否是个人自由，但如果尝试数次都无人积极响应可能会令rfc使用者怀疑，究竟有没有人在乎那个机器人的通知，还是说大家都是直接点掉通知栏的小蓝点然后当作没事发生了。因此我觉得社群现在的心态显然还没做好准备接受这套新机制，十多年的老顽疾确实很难一夜之间改过来。

那个RFC放得地方其实完全不显眼，因为大家都是直接跳到感兴趣的章节里的。我觉得放在目录的上方可能效果会更好，虽然会有点怪。--微肿头龙（留言） 2024年5月26日 (日) 01:11 (UTC)

RFC的核心在于用户浏览不同类别的讨论列表找到自己想要讨论的话题，FRS只是附加的协助。当RFC核心的讨论列表被淹没，RFC仅剩下FRS的通知，当然是不够人参与。另外，可以观察到：有些讨论很常连涉及有关条目的编者都没通知过就直接转客栈或RFC，这正正也是建议机制要求用户先通知有关编者的原因。补充一点：我之所以说Ericliu1912不断使手段压缩RFC测试机会正是因为他对RFC相关内容做的动作很多都是不断缩小、隐藏有关内容，比如在客栈页顶模板试图隐藏RFC讨论列表使RFC列表更容易被忽略。即使不是他的原意，他的小动作确实有压缩RFC空间的效果，然后再来论述RFC效果不好，显然不可理喻。--路西法人 2024年5月26日 (日) 04:40 (UTC)

中维活人人数本来就够呛，经常是丢一个问题结果半天没人理，再限制讨论单一条目那更完犊子。--BigBullfrog（𓆏） 2024年5月25日 (六) 19:08 (UTC)

究竟你有没有认真读提案和论点？目前的讨论都放在客栈，新手无从参与，当然难以鼓励新人加入讨论，当然“活人人数本来就够呛”“完犊子”；每天却不乏用户在条目讨论页发起话题讨论，显然证明条目讨论页对新手老手都是最直觉的讨论场所，新手也容易加入讨论并从讨论慢慢往社群其他讨论发展和理解。--路西法人 2024年5月26日 (日) 04:46 (UTC)

(！)意见：我相信在哪里发起讨论，包括发起人在内的社群自有公论；提案要每个页面点击一次才能参与条目讨论。 -- 月都 ※ 2024年5月25日 (六) 20:09 (UTC)

你是没编辑条目多久了？难道参与讨论的时候就不需要先阅读条目内容是什么？本来就是要点开看条目的，问题在哪？新制下不论从条目往讨论区或从讨论区往条目或从客栈浏览讨论列表去讨论区都只是点一次，旧制下从条目去客栈讨论才是跳级的事情吧？更何况，很多用户都是在客栈页顶的讨论列表点章节标题下去讨论，这也是“点击一次”啊，有何分别？--路西法人 2024年5月26日 (日) 04:43 (UTC)

WP:太长不看；相对而言大概也有“太多连结不点”吧。不过我也是支持不试试看是要怎么知道效果如何那边的，本维都有个无限试行的RELIST了，这怎么不也来试行一下。（虽然我个人是怀疑会点进VPD的人应该都有预期要看长页面了，再多按好几次连结是否只是徒增无谓的操作次数）--WiTo🐤💬 2024年5月26日 (日) 06:00 (UTC)

会点进VPD的人应该都有预期要看长页面了是否反映客栈对新手和仅追踪单一讨论的用户不友善？另，如上方所述，参与讨论的时候就不需要先阅读条目内容是什么？正常参与讨论的人本来就是要点几次去看看条目内容如何、争议版本是什么，在VPD讨论并不代表这些动作就会消失不见（当然，不读条目就讨论的人是另一种问题）。若讨论在客栈以外的页面发起，多点一次连结能防止客栈出现讨论过多造成的问题，那么如何能叫做“无谓”？--路西法人 2024年5月26日 (日) 08:01 (UTC)

共识同时考虑支持者多少和意见是否合适两者。问题是整串讨论串我只能找到“路西法人”君一人实际支持而已，和一两票的无论述、无参与式的支持。这违反共识应采纳多数人的意见，并和重要少数的意见作出适当妥协。一项。我建议阁下最基本的是找第三方管理试著调停，判断共识。谢谢。--Ghren🐦🕑 2024年5月28日 (二) 06:59 (UTC)

确实，目前看来只有路西法君一人支持该提案。我本人虽认同他的初衷，但反对强制推行。--微肿头龙（留言） 2024年5月28日 (二) 07:04 (UTC)

贵方真的很爱选择性摘录方针，就算再违背方针背后的原则都要选择性摘录。共识方针表明“共识应当考虑到所有正当合理的意见”，请问反方存在极大量逻辑谬误的滑坡论证叫做“正当合理意见”吗？共识方针源自英文维基百科，原文A consensus decision takes into account all of the proper concerns raised. Ideally, it arrives with an absence of objections, but often we must settle for as wide an agreement as can be reached. When there is no wide agreement, consensus-building involves adapting the proposal to bring in dissenters without losing those who accepted the initial proposal. 哪里有提及过“采纳多数人意见”？更何况，讨论不是点人头，维基百科也不是民主体制，所谓“少数服从多数”本来就是本站对共识的超译，这一点UjuUjuiMandan在他的RFA中回应问题时的论述共识根本和“多数”“少数”无关，只和“反对意见有没有被考虑、有没有向反对意见妥协”有关说的非常清晰也十分合理。

在这则讨论当中，反方提出的论据大多空泛无实质论证，仅有少数论述还能叫做有论证过（虽然存在非常显然的逻辑谬误）；反方的反对因素我也有非常积极的考量，并在提案中提供对应措施去解决反对意见中提及新制可能面对的问题，在我提案部分有遗漏的地方也适时采纳部分反方意见修订提案。相反而言，反方除了给我强加标签抹黑之外，在我多番提出客栈存在的问题后，一直到25号才终于有用户正面回应我列出客栈的问题。该用户回应认同部分问题存在，其余的表述也有反向证明客栈存在问题。

至于所谓“无其他人实质支持此提案”，这显然是因为正方同意提案自然不会有什么打意见，反方不同意提案才会有大篇幅留言回应，以此来认定那些是“非实质”的支持显然并不合理。有明确支持提案的用户有冥王欧西里斯、CaryCheng、Ma3r；与Sanmosa的来回讨论也在进一步修订条文后获得其“不反对”、WiTo也指出可以试行（上面已经论述过此提案本身就是方针原则的执行，有问题则应改善新制，而非一棒打回原先的问题，所以“试行”除了“安慰反方”外无意义）。Kethyga提出可以参考的项目也大概同意提案的推行。认为应该只是“建议”而非“强制”的用户意见（0xDeadbeef、微肿头龙、桐生ここ）则显然可理解作认同理念而仅不认同执行方式，不是“支持”也不是“完全反对”。提出反对意见也就你Ghren、Ericliu1912、Cwek、HK5201314（有按其提出的情况调整提案，异议可视作已解决)、月都（整个论述跟实际情况毫不相符而不考量）和Factrecordor（仅是因RFC“未成熟”），这个情况下要把“反对意见”视作“多数”更是难以置信。

我当然能理解用户对强制的限制有所疑虑，例如“真的有需要时会被过度限制”。我在上面的表述有说过，强制性的措施在于尽可能改变本站编者会造成问题的“习惯”，未来在重新全面审视共识方针错误翻译、违反核心原则的条文时，以最佳做法（而非强制措施）的形式重新融入方针（如明确共识需要逐层建立的原则），而不再需要强制性措施。

所以真的不用再出来搬弄方针来营造提案和用户意见缺乏任何效力的假象，反方真的不需要也不能因为无法以没有明显谬误的逻辑回应驳论就开始玩程序战拉布。--路西法人 2024年5月28日 (二) 10:24 (UTC)

社群整体如何客观公正判断各方意见是否是“正当合理的意见”？

(？)疑问 关于社群对论证的客观判断和社群合理的决策程序问题。讨论已经进行了一段时间，有大量的论证和反驳等等。由于这些问题的复杂性和模糊性，好像难像形式逻辑的命题那样，通过纯粹的严密逻辑推理来做出判断和说服。因而有下面问题：

• 如果一方提出"反方存在极大量逻辑谬误的滑坡论证", 如果反方没有直接回应， 社群是否能认为反方认可了他的“存在极大量逻辑谬误的滑坡论证"判定？
• 社群整体如何客观公正判断各方意见是否是“正当合理的意见”？和 是否"存在极大量逻辑谬误的滑坡论证" ？

--Gluo88（留言） 2024年5月28日 (二) 13:12 (UTC)

我作为提案人，当然有责任指出并回驳反方论述不符合逻辑之处。反方多名用户一直没有办法严密地论证其逻辑，甚至提出的观点一则比一则多逻辑谬误、选择性摘录并扭曲提案条文和方针原则等荒诞议事行为。每一次我都以尽所能及缜密的逻辑去分析其观点中存在的谬误之处才会将意见视作“非正当合理意见”；反方不予回应、辩驳，然后就径自给我冠上“强推讨论”、指控我“球员兼裁判”等污名。“合理”，词解“合乎道理或事理”，该等反方用户的论证能够被轻易挑出逻辑问题，甚至连多条重大方针都能扭曲理解，显然不可能“合乎道理或事理”而构成“正当合理”的意见。

你所指由于这些问题的复杂性和模糊性，好像难像形式逻辑的命题那样，通过纯粹的严密逻辑推理来做出判断和说服，这一点说得对，但还有一点需要延伸。虽然确实无法非常全面地针对问题的每一个向度进行严密的逻辑推理，但针对每一个用户提出的每一个观点则能被检验逻辑，这也是我正在做的。如果我的提案中存在逻辑错误，例如早前其中一位反方用户指出我原先提案一来就ping其他未涉事用户与我提案要求逐步递进讨论有所抵触，我也非常乐意接受意见并修正。逻辑有错就认、逻辑有错就改，而不是像该等反对用户辩不过逻辑就开始给我冠恶名。--路西法人 2024年5月28日 (二) 15:55 (UTC)

关于逻辑谬误和讨论中的角色定位问题是非常重要的。可能我们都同意，社群应当努力确保讨论的客观性和公正性。您作为提案人当然有责任指出反方的逻辑问题，以便双方沟通。如果当事两人就是否有逻辑问题互不认同，也许可以设法邀请在逻辑问题判断有分歧的两人以外的其他社群成员来评估这些逻辑问题，以保持讨论的中立性。最后，我认为您提到的“逻辑有错就认、逻辑有错就改”的态度是非常宝贵的。这种开放和自我反思的态度对于任何公正的讨论都是必不可少的。--Gluo88（留言） 2024年5月28日 (二) 17:04 (UTC)

(！)意见

1. 在讨论中，如果一方提出对另一方的批评，如“存在极大量逻辑谬误的滑坡论证”，而另一方没有直接回应，在下认为沉默可能有多种原因，包括但不限于缺乏时间回应、或者选择不参与进一步争论。
2. 在下觉得，如果争辩的双方中的任何一方认为自己的理由已经在之前的讨论中得到了充分阐述，认为另一方的新质疑仍然无法说服自己，但缺乏时间详细回应或者选择不参与进一步争论。 在暂时退出争论时，是否可以至少简单表明仍有分歧：对方的解释仍然没有说服自己，双方可各自保留观点，继续收集信息和社群意见，以便在未来找到更好的解决方案。
3. “简单表明仍有分歧”可以让社群了解到各方是否默认了被指出的“逻辑错误”， 还是仍有分歧。这样的透明度有助于其他关心该议题的社群成员进行评估和判断。 --Gluo88（留言） 2024年5月28日 (二) 17:49 (UTC)

少数人的选择是否应该在无法通过讨论来说服多数的反对者情况被采用？

(？)疑问 社群合理的决策程序问题。少数人的选择是否应该在无法通过讨论来说服多数的反对者情况被采用？

前面讨论中提到：“更何况，讨论不是点人头，维基百科也不是民主体制，所谓“少数服从多数”本来就是本站对共识的超译，这一点UjuUjuiMandan在他的RFA中回应问题时的论述共识根本和“多数”“少数”无关，只和“反对意见有没有被考虑、有没有向反对意见妥协”有关说的非常清晰也十分合理”。

背景：UjuUjuiMandan论述是针对我的问题的回应。 我向四个参选人，提了同样问题，按照我的解读， 只有UjuUjuiMandan 认为共识根本和“多数”“少数”无关 。

1. 我提出：避免采用只有少数人支持的方案。如果一个方案没有得到大多数人的认可，那么它可能不是最佳选择，因为它可能无法代表大多数人的利益。
2. 在下觉得UjuUjuiMandan的观点不符合： Wikipedia:何谓共识#不是多数表决"51%的人倾向的选择通常并不足以形成共识，而只有少数人支持的选择更基本不可能是共识"。
3. UjuUjuiMandan 不同意上面观点， 认为一件事对还是不对和人数多少没关系，主要看论述 。
   • 我的回应为： 关于“主要看论述”， 双方对同一论述可以有相反看法。总的来说，虽然正确与否不应仅仅基于人数多少，但在实际操作中，民主和社会契约的原则导致了多数决的做法。这是一种平衡个体权利和集体利益的方法，尽管它并不完美，但在许多情况下被认为是最公平的解决方案。
4. 按我的理解，另外三个参选人认可我的观点。 我不认为UjuUjuiMandan观点在社群中有共识， 我不认可用“共识根本和“多数”“少数”无关”的这个论述做为逻辑推理的合理依据。
5. 不知您是否认同 Wikipedia:何谓共识#不是多数表决"51%的人倾向的选择通常并不足以形成共识，而只有少数人支持的选择更基本不可能是共识"？ 少数人的选择更不能在无法通过讨论来说服多数的反对者情况下， 被强行采用。？
6. 或者需要讨论产生共识以便修改表述，以便认可少数人支持的选择可以是共识？--Gluo88（留言） 2024年5月28日 (二) 19:13 (UTC)