维基百科讨论:共识

共识建立的递进步骤

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

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

“征求意见公示写入相关方针指引”提案公示通知

已通过：

已修改WP:保护方针与WP:共识。0xDeadbeef (留言) 2024年4月18日 (四) 09:20 (UTC)

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

---

征求意见公示写入相关方针指引 已通过征求意见系统在方针讨论页取得共识，现于公示中，2024年4月17日 (三) 15:52 (UTC) 结束，由于方针修正前规定公示只能在客栈页面下，则在此通知相当于在客栈下公示。如有意见请在链接中讨论页提出。--0xDeadbeef (留言) 2024年4月10日 (三) 15:59 (UTC)

@0xDeadbeef：公示期似已结束。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月18日 (四) 05:43 (UTC)

---

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