维基百科讨论:共识/讨论页及共识方针试行案/原始讨论存档

本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论，请在当前讨论页进行。

讨论1：共识建立的递进步骤

最新留言：在1个月前发布351条留言29人参与讨论

本主题或以下段落文字，复制自Wikipedia_talk:共识#重要：涉及限制互助客栈条目探讨区讨论之政策修订。执行人：台湾杉在此发言 (会客室) 2024年10月5日 (六) 06:38 (UTC)。

以下讨论是征求意见的存档纪录，请勿修改。本次讨论所达成的总结如下：

公示通过，试行方案即日起施行，相关后续讨论请到WP:CON/TRIAL及WT:CON/TRIAL进行。台湾杉在此发言 (会客室) 2024年6月26日 (三) 03:58 (UTC)

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

是否应该修改互助客栈及达成共识的流程，规范讨论必须先在条目讨论页发起，如有必要才发起征求意见或互助客栈讨论，并限缩互助客栈的使用范围？台湾杉在此发言 (会客室) 2024年5月29日 (三) 12:37 (UTC)

依据RFC的规范进行摘要。台湾杉在此发言 (会客室) 2024年5月29日 (三) 12:37 (UTC)

见#重行公示。--路西法人 2024年6月12日 (三) 04:27 (UTC)

#第三次公示。台湾杉在此发言 (会客室) 2024年6月18日 (二) 15:34 (UTC)

第一阶段讨论

原标题为：原始提案

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

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

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

实际上经过观察，征求意见现阶段在本站最有效的运用，应该是挂在那些本来就在讨论页发起的话题上面增加流量，而不是反过来把讨论到一半的互助客栈话题移回某个页面去减少流量。—— 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)

我就想问一个问题：你们这样把讨论串不断移来移去合适吗？San mo sa _{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:共识#形成共识的误区和错误：

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

如果上面还是打算继续如此的讨论的话，倒不如不要讨论了，我是真的不知道你们现在这样做到底有何意义，这完全不是有效的讨论。San mo sa _{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系统可能需要额外讨论。

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

（话说回来，上面说的“条目”可能说是“页面”比较合适，毕竟现在VPD讨论的不止条目，还有模板、模组、分类之类的。）San mo sa _{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的积压就能得到显著舒缓。San mo sa _{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机制。
我认为社群成员的顾虑有必要获正视，否则我不认为这里能进行任何有效的讨论。

San mo sa _{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机制的生态存在一定差别，可能在强制分流部分讨论后你说的情况就已经不会那么严重。
（这点可以交由社群进一步讨论）
这种情况或许代表了社群中的一种非小众意见，不正视这种意见背后的因由不见得能促进有效讨论。

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

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

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

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

我的意思是不能把所有反对意见全部仅按著自己的意愿而定性为非“正当合理意见”，这不是共识方针的本意。San mo sa _{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的考量。San mo sa _{Szégyen a futás, de hasznos} 2024年4月13日 (六) 15:07 (UTC)

说到这里，我也对你的提案有新的疑问：假如强制分流实行后有人不按强制分流措施发起讨论或应用RFC，那人有甚么后果吗？这“强制性措施”是真的“强制性”、真的可以贯彻落实吗？有没有甚么机制能协助社群执行强制分流措施？San mo sa _{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多少也跟“本来就不该是这样”沾点边，最终不也是被现版取代了吗？
（见第三点）
就比如说，弄些小工具之类的？而且只说“需要改善”但不提要怎样改善也可能是因为想不到改善方案的缘故，但想不到改善方案不一定代表不需要改善。
（见第一点）

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

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

第一次公示（已停止）

以下讨论是征求意见的存档纪录，请勿修改。本次讨论所达成的总结如下：

停止公示，进行后续讨论。台湾杉在此发言 (会客室) 2024年6月19日 (三) 11:09 (UTC)

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

原标题为：公示版本

原标题为：第二阶段讨论

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

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

即新增规范如下：

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

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

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

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

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

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

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

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

(！)意见：关于您刚才提到的第三条，可以针对该分类含有的条目数量来判断（例如若分类中的条目数量大于100条，可直接将讨论通告发送至互助客栈）。--WiiUf ——青龙出世，傲视苍穹 2024年6月13日 (四) 10:45 (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，也不见得能找到成百上千个用户。San mo sa _{全方贫工之联合} 2024年5月11日 (六) 15:07 (UTC)

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

IP在技术上是无法被ping的，因此你说的事情不成立。San mo sa _{全方贫工之联合} 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所有相关用户也不会招致惩罚。San mo sa _{全方贫工之联合} 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)

回应：

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

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

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

过往社群缺乏充足配套，以客栈为讨论集中地尚可理解；现在配套充足提案从头到尾都只是在目前本地配套更完善的背景下，将客栈置顶长久以来都存在且仍有重大意义的限制付诸更明确具体的实行；反方却从头到尾拒绝考量当初的规则未被遵守而造成今天的问题。反方打不倒“任何条目或模板的交流应考虑先在其讨论页发表”这条自客栈设立存在至今的置顶要求的意义就甭想阻拦此提案以某种形式实现。我无任欢迎社群用户参与讨论并指出此递进制度的缺陷所在（如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的。San mo sa _{全方贫工之联合} 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的看法。--YF dyh000（留言） 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那边的讨论。San mo sa _人人皆王 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即指出某些参与讨论的维基人实际上鲜少来客栈条目探讨区），规模就该等重要之政策修订讨论而言显然不足。故除在该页面发送讨论通告外，还有进一步开展谘询之必要。

为确保实际参与者之权益在未来政策中获得充分反映，并弥补此前提案未能有效促进社群参与之遗憾，本人在此不论立场偏好，以一次性（不重复）之正式通知，诚挚邀请近一个月内（正好也差不多是此提案出台期间）使用过互助客栈条目探讨区、且未曾参与上方任何讨论的维基人，希望谈谈普罗大众参与客栈及一般条目讨论的经验并做比较，俾评估相关制度调整之利害；更欢迎就此提案之内容及可行性直接提供些许意见（包括支持、反对及其他折衷看法均可），相信将能加速促进真正共识形成。另外，本人及此提案其他某些参与者之意见虽鲜明至甚、甚至趋于对立，但相信诸位当可不受上方包含本人在内诸多正反唇枪舌战影响，自由且不受限制的发言。当然，诸位也可纯粹关注话题发展，监督社群协商过程，或者提前准备“适应”之类，总之必然较“一无所知”为好吧。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年5月24日 (五) 22:37 (UTC)

（技术限制得分成两批，不过倒也可由此见条目探讨区还是很活跃的）—— 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)

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

第二阶段讨论

原标题为：重新统整提案及参与者意见

原标题为：统整

原标题为：第三阶段讨论

LuciferianThomas版本

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

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

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

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

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

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

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

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

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

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

我也是同感 -“我本人虽认同他的初衷，但反对强制推行”--Gluo88（留言） 2024年5月30日 (四) 04:40 (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)

甚至本来是部分支持、不反对阶段性推动，却因为提案人坚持不让步、要立刻施行一些现阶段根本不经济的作法，搞得只能全盘反对，避免砸掉讨论体系。近日本人会考虑另行草拟较温和的版本提出，应可争取社群更多支持。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年5月29日 (三) 17:22 (UTC)

社群合理的决策程序问题重要性可能比提案本身影响更大。如果他仍然把所有反对意见全部仅按著自己的意愿而定性为非“正当合理意见”，是否很难看出是能按共识方针的本意处理提案？
不知您和其他管理员团队成员，是否能先协助按共识方针的本意解决社群合理的决策程序问题？
也请社群发表意见，是否应该先协助按共识方针的本意解决社群合理的决策程序问题？是否可以不故其他人的反对，一直坚持将所有反对意见全部仅按著自己的意愿而定性为非“正当合理意见”？ --Gluo88（留言） 2024年5月30日 (四) 04:38 (UTC)

延伸内容

折叠用户持续扭曲方针理解发表的扰乱发言--路西法人 2024年5月29日 (三) 15:28 (UTC)

您上面逻辑推理论据引用的UjuUjuiMandan在他的RFA中回应问题时的论述，是其回应在下的对四个参选人提出的同样的问题时有争议的表述。UjuUjuiMandan和我在讨论将结束时都认识到我们的观点仍然分歧而且无法说服对方，并表明各自仍然保留各自的看法。
针对他上面关于人数的观点，在下认同这样的表述：总的来说，虽然正确与否不应仅仅基于人数多少，但在实际操作中，民主和社会契约的原则导致了多数决的做法。这是一种平衡个体权利和集体利益的方法，尽管它并不完美，但在许多情况下被认为是最公平的解决方案。详细解释在下面：Wikipedia_talk:共识#少数人的选择是否应该在无法通过讨论来说服多数的反对者情况被采用？--Gluo88（留言） 2024年5月28日 (二) 19:32 (UTC)
背景：UjuUjuiMandan论述是针对我的问题的回应。我向四个参选人提了同样问题。按照我的理解，四个参选人中只有UjuUjuiMandan 认为共识根本和“多数”“少数”无关。
1. Wikipedia:何谓共识#不是多数表决"51%的人倾向的选择通常并不足以形成共识，而只有少数人支持的选择更基本不可能是共识"。
2. 所以我提出：避免采用只有少数人支持的方案。如果一个方案没有得到大多数人的认可，那么它可能不是最佳选择，因为它可能无法代表大多数人的利益。
3. UjuUjuiMandan 不同意上面观点，认为一件事对还是不对和人数多少没关系，主要看论述。但在下觉得UjuUjuiMandan的观点不符合：上面引用的Wikipedia:何谓共识#不是多数表决中的表述。
  - 我的回应为：关于“主要看论述”，双方对同一论述可以有相反看法。总的来说，虽然正确与否不应仅仅基于人数多少，但在实际操作中，民主和社会契约的原则导致了多数决的做法。这是一种平衡个体权利和集体利益的方法，尽管它并不完美，但在许多情况下被认为是最公平的解决方案。
4. 按我的理解，另外三个参选人认可我的观点。我不认为UjuUjuiMandan观点在社群中有共识，我不认可用“共识根本和“多数”“少数”无关”的这个论述做为逻辑推理的合理依据

--Gluo88（留言） 2024年5月29日 (三) 01:43 (UTC)

Wikipedia:何谓共识#不是多数表决不是方针，就算其观点不符合该论述也完全没有问题。本身“不是多数表决”这一点建基于“双方理据都各有道理”，WP:共识方针本身就要求考虑“正当合理”意见。在反方意见被逻辑论证质疑是否正当合理时，反方无法反论证自己的逻辑正确，无法证明自己逻辑正确的论述都站不住脚，不可能是“正当合理”的意见。“不认为UjuUjuiMandan观点在社群中有共识”，没有共识不代表该点并非方针本身的核心观点和原则，正如上方的用户即便再不同意方针或某些规则，都不能否定那些是方针的一部分。WP:5P5指出“方针与指引所蕴含的原则和精神比字面措辞更为重要”，而“多数意见”则自始至终都不是共识的核心原则（参见英文维基百科原版方针），方针中重复出现的“正当合理意见”才是。就算“未曾经过共识检验”，也不代表原则不存在。所谓“民主和社会契约的原则导致了多数决的做法”则根本不可能是在维基百科的合理观点，维基百科不是民主体制，自然无需“跟从”民主制的多数决（尤其是多数决本来就存在多数暴力的问题，不论观点是否合理，人多就赢，这显然不合理）。--路西法人 2024年5月29日 (三) 02:18 (UTC)

维基百科不是民主体制表述：“维基百科不是民主体制或任何政治体制的实验。这里寻求共识的主要方法是讨论，而不是投票”，强调不是单纯投票。
共识一定遵守了民主的原则，因为它涉及到集体讨论和决策，这是民主的基本组成部分。共识强调了参与、包容和多样性的意见，这些都是民主价值观的核心。共识决策是民主决策中，加上集体讨论和决策和一致同意（有时可能略有变通，可另讨论）。
民主不一定遵守了共识讨论、参与、一致同意原则。
共识主要是一致同意，少数人可以否决多数人的提议。目的是避免多数决本来就存在多数对少数暴力的问题（尤其是多数决本来就存在多数暴力的问题，不论观点是否合理，人多就赢，这显然不合理）。
共识决策中中，不论各方观点是否合理，更不容许少数人观点和提议强加于多数人。

--Gluo88（留言） 2024年5月29日 (三) 02:40 (UTC)

你说的最后一点“不论各方观点是否合理”的说法已经跟共识方针的原则有所抵触。不再回应不顾观点是否合理而提出没有共识的观点。--路西法人 2024年5月29日 (三) 02:43 (UTC)

有不同看法是正常的。我认为，“不论各方观点是否合理，更不容许少数人观点和提议强加于多数人”是符合“共识方针的原则”。
我们可以请社群研讨，发表意见，也可查查可信来源的论述。

--Gluo88（留言） 2024年5月29日 (三) 03:22 (UTC)

“不论各方观点是否合理”显然完全违背共识方针，不是你“认不认为”就行。--路西法人 2024年5月29日 (三) 09:16 (UTC)

阁下只取了“不论各方观点是否合理”。
我认为，“不论各方观点是否合理，更不容许少数人观点和提议强加于多数人”是符合“共识方针的原则” 。要点为： 更不容许少数人观点和提议强加于多数人。
在下理解共识表述为，共识不是只是数人头而不讨论不妥协。理想的共识是一致同意，判断一致同意就需要数人头，确信包含了所有人头。所以在讨论和妥协工作后，判断共识时需要数人头。
我们可以在客栈公开讨论。也可以到英维公开讨论。

--Gluo88（留言） 2024年5月29日 (三) 11:15 (UTC)

将不再回应明显扭曲方针理解，“不论观点是否合理都应算进去”和“共识是数人头”这两种不合理的说法显然任何一个有认真参与过社群讨论而非空口说白话的用户都会指出这个说法有非常严重的问题。面对我WP:RFC/RFA2024总结多数共识的时候，不同意我的用户就懂得抛出“共识不是数人头”等说法，现在他们就开始来数人头了，就噤声假装看不到，双标到一个极致。我将折叠以上明显与方针有所抵触的讨论，若再有继续扭曲方针即提报请求处理。--路西法人 2024年5月29日 (三) 15:24 (UTC)

虽然本来真的不想再回复，但补充英维在指引中对共识的诠释协助佐证“不合逻辑的意见值得考量”与方针原则明显抵触，让众人看看这些说法有多荒谬。

en:WP:ROUGHCONSENSUS：Consensus is not determined by counting heads, but by looking at strength of argument and cited recorded consensus. Arguments that contradict policy, are based on unsubstantiated personal opinion rather than fact, or are logically fallacious, are frequently discounted. For instance, if the entire page is found to be a copyright violation, the page is always deleted. If an argument for deletion is that the page lacks sources, but an editor adds the missing references, that argument is no longer relevant.

此处非常明确写明“存在逻辑谬误的观点多数不会被考量”（discount词解：to decide that something or someone is not worth considering or giving attention，译“不值得考量”）。--路西法人 2024年5月29日 (三) 16:07 (UTC)

您提到：“面对我WP:RFC/RFA2024总结多数共识的时候，不同意我的用户就懂得抛出“共识不是数人头”等说法，现在他们就开始来数人头了，就噤声假装看不到，双标到一个极致。”
- “就噤声假装看不到”“双标到一个极致”是否假定我应该看到，并而应该支持您正确理解了共识的识别需要数人头？
- “就噤声假装看不到”“双标到一个极致”是否是假定动机，违反了假定善意？折叠理由是否是假定动机，违反了假定善意？
阁下按自己理解，折叠反对者的发言，而不是由社群中立者的理解，然后继续回应。这是否得当？请社群发表意见。--Gluo88（留言） 2024年5月29日 (三) 17:09 (UTC)

@Gluo88：你上面这样分章节然后置顶发言，别人就算要恢复发言，也不知道之后怎么排版。请反缩排2024年5月29日 (三) 17:01 (UTC)的发言并改放底下，然后把“下面”改成“上面”之类。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年5月29日 (三) 17:31 (UTC)

@Ericliu1912：已经修改。 --Gluo88（留言） 2024年5月29日 (三) 19:58 (UTC)

WP:太长不看；我承认上述的讨论，我可能没有详细完整的看完，在目前的理解下，我不赞成此一提案。我参与过维基百科一段时间，我同意我在有条目相关问题时应该要先在讨论页讨论，若有问题还可以用WP:RFC征求更多人的意见。若还是无法解决，再提报到互助客户的条目研讨。（我跳过维基专题，因为我觉得以现况来说，大部份在维基专题上的讨论效果不大。）但这对于刚接触维基百科的新手而言，难度高了一些。而且可能在条目讨论页、维基专题讨论页提出后，就没有下文了（这部份透过WP:RFC可能会有些改善，但效果还不明确）。--Wolfch (留言) 2024年5月29日 (三) 04:08 (UTC)

想请问“难度高”而言，如何定义“难度高”？哪一些操作比较“难”？另外上方也论述过，对新用户而言，最直观能找到的是条目的讨论页，而互助客栈条目探讨板往往是用户遇到过滤器等问题才会找到客栈的求助板，继而才找到客栈的条目探讨板，找客栈条目探讨板显然不是一件容易的事情。对于两个新用户之间的讨论而言，大概本身就不懂得找客栈烙人讨论，不懂得使用RFC也应该可以理解的。

另外，请真的读一下#第三阶段讨论所整理的论点。我的整理中指出了此提案除了处理原则性问题外，还有处理了客栈被滥用的问题。您不赞成这个流程，那么对于客栈目前被过度使用的看法是什么？目前对于客栈众多问题没有全面改制以外的选项，在该等考量下你认为客栈的有关问题是否应被解决？--路西法人 2024年5月29日 (三) 08:27 (UTC)

阁下，我觉得就上面讨论而言，反对提案的人真的很多，或许你也可以说他们都没有实质理据，不过这种东西不是应该符合大家的意愿吗？要说制定规范条目的方针应该有实质理据，但这种东西就像修改一个图标，你可以说你作为设计师的专业观点认为很好看，大家只说一句新版图标不喜欢就是没有实质理据所以无效吗？--桐生ここ★[讨论] 2024年5月31日 (五) 19:33 (UTC)

界面图标的主要作用是美观和实用性，实用性的探讨显然是客观讨论，而争论设计美观与否是主观、谈感觉的，这种情况下单纯的“不喜欢”当然可以作为实质理据。方针及机制的主要元素是逻辑、功能和理据，逻辑、理据是客观的证据，讨论制定规范当然要讲求逻辑、功能和理据；方针和机制并无“主观”判断的因素，“主观”的“不喜欢”自然就不能作为一个实质的反对理据。--路西法人 2024年6月6日 (四) 05:21 (UTC)

注：此处原有文字，因为用户Gluo88已因有关扰乱性扭曲方针的发言被封锁，已由路西法人于2024年5月30日 (四) 12:50 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。

(＋)支持：我的支持意见应该是被庞大的讨论洗掉了，只好再次投票表达意见，支持U:LuciferianThomas的最新提案。--CaryCheng（留言） 2024年6月3日 (一) 08:27 (UTC)

桐生ここ版本

原标题为：桐生版本

建议简单一点：

为善用社群讨论资源，仅影响单一条目的讨论应先在条目讨论页发起，未先在条目讨论页发起的讨论将被移动；
影响多个条目的讨论可在相关讨论页或互助客栈条目探讨板发起。

这样就可以了。--桐生ここ★[讨论] 2024年5月31日 (五) 19:53 (UTC)

另外真的应该考虑Taiwania Justo所说的，发起一个意见调查，问问大家喜欢在集中一个地方讨论然后存档到各个讨论页，还是分散在各个讨论页，解决不了问题再到客栈。这基本上就是一个UI设计问题，而不是适用于条目内容的原则性问题，没有什么有效无效理据，只是问大家喜欢哪一种。客栈本身也只是一个UI，当初的设计者也不一定就会制定条目探讨这个版块，讨论页也只是一个UI，如果开发者没有设计出讨论页功能，现在大家都是在客栈讨论了。--桐生ここ★[讨论] 2024年5月31日 (五) 20:08 (UTC)

另外回馈请求这个东西很好，我觉得应该允许客栈的讨论使用中，甚至应该允许存废复核、存废讨论、评GA/FA、乃至除权争议和ANM、AN3等。--桐生ここ★[讨论] 2024年5月31日 (五) 20:16 (UTC)

本来就应该是这样。落实此原则便足以解决现存多数问题。另应确定讨论转移机制，如当年条目探讨区建立时，好像粗浅订了个一周没什么人参与就可移步客栈的规定。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月1日 (六) 07:53 (UTC)

补个(＋)支持，这样显眼一些（ —— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月10日 (一) 18:59 (UTC)

所谓“简单一点”就是完全没了“编者应先尽可能自行透过讨论解决争议”的最基本要求，也没了如何善用讨论资源的指导。这两个是修改规则的最重要原因，两样都消失了那跟没修没分别。Ericliu口中所谓“落实此原则便足以解决现存多数问题”又是毫无论证，甚至连提供了的九个问题都没能指出解决了哪一项，只留“解决了问题”一句话但实际没有反映如何解决问题的议事方式实在不负责任。就九个问题的分析：

当前制度未能鼓励用户在征求第三方意见前尝试自行解决争议——桐生版本仅局部解决了这个问题，但仍有很多情况都未能推动改善讨论习惯。桐生版本没有要求用户先行跟涉争议的用户自行展开讨论、没有要求二人商议无果邀请其他编辑该条目的编者参与讨论，没写的显然社群多数都不会做。影响同一主题下的条目的讨论根本不应该容许直接在条目探讨板发起，而是应采用能鼓励编者先行与编辑相同专题的用户商讨协调如何在社群方针指引框架下编辑，同主题跟单一条目的情况都存在“应该先进行的更下层讨论”，同主题但多个条目的讨论没有实际理由能支撑一开始就跑去客栈发起的选择。
跟条目有关的讨论无法在讨论页中找到——几乎没解决，多数“相对重大”的讨论的问题仍然存在（尤其是桐生版本没要求在适当的讨论页发送讨论通告，更是无法解决
客栈再开讨论形成平行讨论——完全没解决，不限制从讨论页转移讨论至客栈则仍然会继续有这个问题，仍需要用户额外巡查确保原处讨论已经关闭（反观从客栈移到讨论页多数会整串移走或关闭）
互助客栈并非新用户“直觉”就知道是讨论的场所——无对应措施解决，新用户仍然难以参与任何在客栈的讨论。
客栈过长——拿“分流”的说法来说，个别条目的讨论反而比较多是相对较短的讨论串，反而影响条目众多的条目才是讨论会比较长的话题（更容易引起争议），桐生版本解决客栈过长问题的效果非常有限。
互助客栈讨论串过多，本身性质比较不受关注的讨论会更难被注意到——无对应措施解决。
V
- 客栈讨论结束在多处自动存档形成平行讨论——无对应措施解决。
- 难以在客栈查找讨论存档——无对应措施解决，存档仍然存回讨论页，无法搜寻在客栈进行过什么讨论。
讨论串过多，想参与讨论的用户每次都要在字海中找话题——无对应措施解决。
客栈无法让用户持续追踪特定感兴趣类别的话题——无对应措施解决，但这个开放在客栈使用RFC机制已经能解决。

请问“解决”了什么问题？还是又是未经实际分析而自由心证的结论？我推的是能解决问题的提案，桐生阁下建议的是解决0个问题的提案，那请问这个提案有什么作用？很老实那句，上述部分问题（2、4、6、8、9）能直接通过开放在客栈使用〔RFC机制及讨论通告〕去辅助尽可能解决，但既然都用到RFC，那倒不如直接在条目讨论页发起讨论还实际，还能解决剩馀的问题？--路西法人 2024年6月1日 (六) 08:31 (UTC)

关于新手的问题，我觉得新手确实会直观地认为讨论页为讨论该条目的地方，大部分也确实会先于讨论页发起讨论。但是我相信他们肯定不知道有rfc之类的东西，所以他们发起的讨论我觉得大概率也不会有人注意到吧。阁下的方案有办法解决这个问题吗？--微肿头龙（留言） 2024年6月1日 (六) 08:45 (UTC)

就我观察，两个新手之间的争议不外乎直接在条目打编辑战开干和两个人在讨论页吵起来。监视最近修改作为反破坏的工作甚至比客栈更多人长期监视，老手们不难发现新人在吵架或打编辑战。老手发现编辑战并提报保护的同时，就能引导用户在条目讨论页发起讨论。这时候，很多老手都会协调两名用户了解方针指引规范，也能作为适时协助请求扩大讨论。就算这名老手就算该用户本身无意参与讨论，也等于留了一个“老手联络人”，解决不了ping他也是可以。（DiscussionTools在本地预设启用，ping用户有界面辅助输入@号）这是循序渐进教导新手的体现。

再者，可统一在新手最直观切入社群讨论的讨论页增加编辑提示（Template:Editnotices/Namespace/Talk），亦能作为长期悬挂讨论页规则（Template:Talk header，甚至在MediaWiki:Talkpageheader加入该模板），该处已有“遇到争议时请寻求解决方法”的连结供用户查找RFC或客栈等方法。（倒是才发现RFC没写进去WP:DR，不过这个新增在该指引大概不会遇到争议）--路西法人 2024年6月1日 (六) 09:10 (UTC)

前面早就提过该类讨论占客栈大宗，数量及篇幅都是。减少此类话题，正好将客栈留给大型讨论，可为适当分工。桐生的版本实际上兼顾了讨论页善用及编者发起讨论的自由，本人认为切实可行。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月10日 (一) 19:03 (UTC)

能自己话打自己话的人真的非你莫属。你的说法是“单一条目讨论数量及篇幅‘占客栈大宗’所以适合‘分流’”，（其他类型讨论）归类“大型讨论”；但“大型讨论”却不是“篇幅占多数”，反而留在客栈，却不是应被“分流”的对象，由得“大型讨论”继续制造客栈一直存在的问题？空口一句“实际兼顾了讨论页善用”，却回避回应种种仍然存在的客栈问题，“实际”去哪里？来来去去都是同一句“编者发起讨论的自由”，却不管任何前设，实际变成“不管种种问题，编者的选择发起讨论场所自由都应该受到保障，就算造成客栈种种问题也不该被限制”，这跟“不管编者写的内容是什么，编者的编辑自由都应该受到保障，就算内容不恰当也不该被限制”有何分别？--路西法人 2024年6月11日 (二) 05:06 (UTC)

所以反方是没办法提出站得住脚又不跟方针抵触的反对意见了吗？我花心机去尽可能完善我的提案，确保我的发言尽可能没有错误和漏洞，反方还是要用“不喜欢”这种共识方针本来就不接纳的意见作为反对论点吗？没有的话我24小时后就重新公示了。--路西法人 2024年6月10日 (一) 16:17 (UTC)

所以所谓“站得住脚又不跟方针抵触”仍是由提案人自行认定与否？也不知道“不喜欢”是怎么归类出来的意见。即便有大规模提及，社群多数成员仍然没兴趣推进如此程度的提案（实际上大概是没意愿卷入死缠烂打冗长辩论，前面几位也已经表明了），根本不代表提案具备足以实施的共识。何况制度是死的、人是活的，每个人编辑体验不同，偏好的讨论管道、遭遇的事件也不同，本来就没有某种一以贯之的道理；这又不是条目，本人认为纵使真是单纯“不喜欢”某种使用者设计，也完全可以成为反对理由（遑论并非如此，某些互助客栈有的问题讨论页可也不缺），提案人自行认定何者属于所谓“有效意见”的弊病再度浮现。共识方针也指出，就算一致认为要作出改变，但不代表（一定）要作出改变。此提案并非无人支持，但显然不足够，这时本来应该做的是吸纳众多新意见、适当调整提案范围及实施细节，尽可能争取社群最大支持；但提案人仅是做些无关紧要的微调（贬斥他人意见、宣告他人意见无效给自己“让道”的时间或许还更多），就屡次再三坚持公示，是根本无视此提案尚没有共识的现实。本人认为，应就LuciferianThomas版本及桐生ここ版本提交征求意见，付诸社群以安全投票公决。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月10日 (一) 18:25 (UTC)

考虑到在此情况下先前大规模邀请讨论效果不彰完全可以预期，本人并另外主张，应该先从事意见调查（同样也是使用安全投票），让社群不必陷于长篇大论之泥沼中，即可提供有益意见。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月10日 (一) 18:30 (UTC)

反方能自行认定自己意见在合理有效，而不作任何逻辑论证；而我认定反方意见无效基于种种逻辑推论、论证。所谓“死缠烂打”“冗长辩论”岂不是反方用户坚持无法给出符合逻辑、符合方针指引原则的任何论证？所谓反方“没意愿死缠烂打”，还是是根本从头到尾自己说法站不住脚，不断得用更多的伪逻辑伪论证，一个大话掩盖另一个大话，最后辩不过就归根对方死缠烂打？我给反方认定论据不符合“合理有效”都还需要大量论证，反方至今都无法论证我的逻辑依据、方针指引依据存在任何错误，然后就可以给我冠上“自行认定”“死缠烂打”？岂不是反方自己“自行认定”自己的论据合理有效，而不接受我指出反方说法中的种种荒谬逻辑谬误？--路西法人 2024年6月11日 (二) 04:57 (UTC)

更好笑的是，Eric君你指出方针中“就算一致认为要作出改变，不代表一定要作出改变”，这个从来都不是共识方针的原则，甚至只是过往修订方针时未经任何讨论、无人提出过增加这一点的偷渡增订，英文原版也未曾有此道理；菲菇修订共识方针时，也极度强调虽然共识也看重多数意见，但观点合理性所占的权重，要大于其支持者多寡的权重（至于如何判断合理，我觉得能否说服对方观点阵营的部分人，或者至少能说服不涉事的其他编者，是一个重要因素）。反方的观点无方针指引支持、不符合方针指引原则、甚至存在大量逻辑谬误，这些都是客观上的不合理而不是单纯我认定；而我指出客栈存在的问题等也获部分反方用户接纳。

当年制定当今共识方针，已经有用户针对“自认合理”的论证表示担忧。反方除了空口说“不认为存在这些问题”和回避回应以外，未曾实际推出我的论证存在不合理；反而是反方一直对自己已被指出大量逻辑谬误的论点是“自认合理”，更是完全佐证了反方观念上就存在问题的情况。

当初Reke和菲菇分别表达过这样的说法：

合理的意见即使当下是少数，也可以在不断推广后形成多数，从而写入共识之中不是吗？
所以，我觉得如果真正是共识过程的话，合理的意见要比不合理的意见更加容易被采纳，哪怕在表面上只有少数的支持者。

这不就完全反映“合理的意见”比“多数意见”更重要吗？--路西法人 2024年6月11日 (二) 05:24 (UTC)

第二次公示（因进行修改而停止）

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

由于反对提案的用户一直未能提出能被逻辑、方针指引及共识方针本身的基本原则合理支撑的论点回应提案，存在逻辑谬误的论点本来就是客观认定的“invalid arguments”（某大学资源、人文作家、GPT辅助解释、另一大学资源）。共识方针自制定时的讨论也非常明确“观点合理性所占的权重，要大于其支持者多寡的权重”的原则，这一点不论是本地方针还是英文原版方针都有指明。由此，此讨论中已考量并回应和按需处理合理有效意见（逻辑通顺且不与方针指引的基础原则抵触），符合共识方针要求“考虑所有正当合理的意见”。

综上，在已无有效异议的背景下，重新将此提案付诸 公示7日。--路西法人 2024年6月12日 (三) 04:26 (UTC)

(＋)倾向支持。--WiiUf ——青龙出世，傲视苍穹 2024年6月13日 (四) 10:50 (UTC)

我想请问你的根本鼓励用户在征求第三方意见前尝试自行解决争议到底有没有想过如何成立？你跟EL吵了几个月请问有解决争议吗？你们双方一路各说各话，你是认为你的意见已经得到另一方尊重？我怎么看不出来？EL也这么想吗？

所谓自行解决争议的本质是一方服软让步，这个就是现实不用质疑。如果按你的走法，像我这种不喜欢跟疯狗吵架的人是不是连把问题提交给社群的机会都等不到？是不是意味着以后只要谁敢于吵乐于吵善于吵，他的观点就可以凌驾维基百科？--。->>Vocal&Guitar->>_留言 2024年6月13日 (四) 23:53 (UTC)

这里写的是“尝试”自行解决争议。若经过一段时间，或短时间而非常密集的讨论后仍无果，那就上一级征求其他人意见，然后再征求广泛意见。未来若能成功设置仲裁委员会，或许可以制裁坚持己见但无合理依据支撑论点的用户。没有说必须其中一方让步才能找更多人讨论，让步了反而是不需要再向上的情况。所以如果你认为对方理据不妥而无法让步，经过交涉尝试后即能找其他用户参与。--路西法人 2024年6月14日 (五) 00:46 (UTC)

中文维基百科愿意开煮的不都是坚持己见但无合理依据支撑论点的用户，跟他们尝试自行解决争议不就等于上门约架？说难听点如果都像你一样一通红字粗字甩出来，谁还有毅力继续煮下去？正常人遇到傻子会让步，遇到疯子会让步，你是期待这样解决问题吗？你维的现状是即便客栈有第三方介入的情况下也需要很长时间收拾，以后一对一，一对朋党，朋党对朋党，这样会令社群更好吗？我不怀疑这套体系，但这套体系在华人社会死路一条。--。->>Vocal&Guitar->>_留言 2024年6月14日 (五) 22:53 (UTC)

事实上站内条目讨论大多数都不存在这样的人，多数讨论都可以通过先跟当事用户沟通而解决。真的比较大争议、难以解决的问题，连尝试都没有尝试过，怎么知道对方不是只是不清楚问题所在而产生的争议，而根本说一声就可以解决？

至于红字粗字，若非对方有明显扭曲方针、错误逻辑，仍然坚持己见，大概也没必要红字粗字强调。社群讨论与条目讨论不同，在条目讨论页的基础讨论若失效（对方拒绝接受方针及逻辑论述），可以在找上一级的用户参与。条目的内容规范各方面站务讨论的行为规范更完整，除了中立性永远存在争议外，其他方针都甚少会有人可以有个人的理解，所以几乎可以预见除了某些如高风险主题外，绝大多数讨论都不太会出现这个问题。--路西法人 2024年6月15日 (六) 00:01 (UTC)

(！)抗议：对此公示，我感到非常遗憾，若通过，对此规定之有效性表示(？)异议。--桐生ここ★[讨论] 2024年6月14日 (五) 13:32 (UTC)

过往的反方意见言之无物，与方针相悖、与逻辑抵触，百多则留言没几则比得上Ohtashinichiro上方两则留言内明确指出心中疑虑（与善战之人吵难以有好结局的问题）。--路西法人 2024年6月15日 (六) 00:14 (UTC)

1.针对WP:OWN，方针提及如有人声称拥有某个条目的控制权、主导权（如“黑色怪物”于港铁相关条目的编辑），编辑者可到条目探讨区与其他编辑者反映。阁下的条文成立后，这个反映机制是不是失效了？

.

如果您发现自己与其他贡献者陷入编辑战时，为何不静下心来？暂休息一段时间可化解纠纷，待一两个星期后再来重新检视。又或者，如果某人声称“拥有”某个条目，您可以在相关讨论页提出，或通过维基百科:互助客栈/条目探讨等管道向其他贡献者反映。

.

2.假设我在条目讨论区ping了5个近期相关编辑者参与讨论，唯五日后仍没有人发言（这个状况英维时常发生）。在阁下的提案中，不能因此在讨论发起六日后把讨论邀请挂在条目讨论区，对吗？--唔好阻住我爱国（留言） 2024年6月14日 (五) 17:44 (UTC)

若有人声称拥有条目控制权，新机制下仍能在客栈发讨论通告（这次可以写明“有人声称对主题/条目拥有控制权，请求协助”这类），仍然是可以在客栈求助；再不是，挂个RFC请求协助也是可以吧。新制只是把社群用户带回原有讨论串参与，而避免讨论出现分支造成混乱。（注：未来有仲裁委员会，若社群无法解决用户声称控制权，那么就可以提报仲裁处理）
“经讨论页讨论仍无果或下列情况”，无人参与实质上是你发起了讨论页讨论而无果，这时确实可以往客栈发讨论邀请和开展RFC等等。

--路西法人 2024年6月15日 (六) 00:08 (UTC)

1. 应扩大至方针指引要求条目探讨区处理的议案，而非单一WP:OWN。

2. 我开始望到有bug了。只要我ping正在放维基假期的编辑者／长期离线编辑者(如2000年于该条目类别活跃的且现退休的编辑者)/当刻被封锁的编辑者（黑色怪物曾经尝试并成功）/不在讨论区发言的编辑者/到该类别编辑量极少且冷门的条目发起讨论（如我到任一2000年的日本动画条目发出讨论，关于整体日本动画条目），并等待数天。即可以“ 无人参与实质上是你发起了讨论页讨论而无果”为由到条目探讨区发起讨论。--唔好阻住我爱国（留言） 2024年6月15日 (六) 15:16 (UTC)

我觉得“近期”这个词已经写得很明白了，而且如果有这个问题，依照常识也可以处理。台湾杉在此发言 (会客室) 2024年6月16日 (日) 15:03 (UTC)

探讨案例1：A编辑者大幅度变更B条目后于个人页宣布放自己一个维基假期，在B条目，最后编辑条目的编辑者是A君且最近的编辑均由他发起。

探讨案例2: C编辑者用工馀时间编写了D系列条目，最近一年也没有任何其他编辑者进行更新。有一天，C编辑者因犯了3RR而被管理员封锁3个月。在C君被封锁当天，E编辑者提出要大辐度变更D系列条目。--唔好阻住我爱国（留言） 2024年6月16日 (日) 15:16 (UTC)

上述案例我觉得在程序合规下，直接发互助客栈也没什么不可以，之后如果其他编者认为“宜”进入RFC，自然就会处理了。台湾杉在此发言 (会客室) 2024年6月16日 (日) 16:20 (UTC)

面对如此蛮横之举，本人祇有建议维基人继续预设在互助客栈发布所有条目相关讨论（其他类型因仍不受限就不必提），这样一来可以确保仍获得些许互助客栈既有之流量及编者有效参与，最大程度避免遭此等不合理之规定损及条目改善机会及自身权益，二来纵使尔后话题遭移动，尚能在一段时间内留下讨论页连结，相当于引流，往后访问互助客栈的维基人看到标题，也知道该去哪里讨论，即不用再回头发一次讨论通告。此外，不知道或不确定要在哪里发起讨论的维基人，更仍欢迎在客栈上发布话题，这样就不用担心没有人帮忙处理。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月15日 (六) 18:18 (UTC)

另外我也呼吁所有反对此种逆施之维基人，保留不满意见，往后纵使此提案遭强行推动，实际造成编者不便后，才有回退之可能。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月17日 (一) 05:01 (UTC)

@Ericliu1912什么时候阁下可以收回条目探讨区通告里，以下自相冲突的两点，什么时候我才能支持阁下的其他主张：

“

二、禁止在互助客栈条目探讨区发起“影响多个属相同主题的条目的讨论”，也禁止此等讨论移动至客栈，只能发送讨论通告；

三、在互助客栈条目探讨区发起“影响多个属相同主题的条目的讨论”时，应当在主题条目发送讨论通告。

”

--Liuxinyu970226（留言） 2024年6月17日 (一) 06:25 (UTC)

第三阶段讨论

原标题为：公示后关闭讨论文字叙述

Taiwania Justo初次版本

由于本次讨论各方对于其持有的论点有所坚持，而且参与各方无论是谁关闭，可能仍然会有不服情况。本人作为参与讨论程度较低的编辑者，依据WP:ACD的精神，由我本人在公示后进行关闭，并做出以下结论：“公示通过，但由于各方存在激烈争论，而且对于讨论中的各方观点需要长时间的观察及分析才能得知，因此无法评估此次共识是否广泛。建议争论各方在公示通过后，就实施的真实情形，滚动讨论并达成更广泛的共识。”

如有任何问题，请提出。如果本人不适格担任关闭者，请与本次讨论无关的管理员进行关闭。台湾杉在此发言 (会客室) 2024年6月16日 (日) 15:39 (UTC)

感谢阁下愿意站出来主持。某些用户主张未经实现就以显然可以用其他原因解释的现象来佐证提议机制无效或不合理的想法显然就已经说不过去。如同AFD relisting，持续讨论有助找出机制问题所在，我完全同意并也曾多次主张在正式推行机制后持续检视问题并予以解决。由于此提案是推动广大编者回归讨论基础本质（在多数情况下先与涉及争议的编者交涉，而非毫无疑问越过对方），实际也不适宜再次fallback至客栈机制（鉴于其本身就非系统给予的预设做法），应尽可能通过推动用户活跃回归讨论页参与讨论。--路西法人 2024年6月17日 (一) 02:03 (UTC)

这么多(？)异议，恐怕难以通过啊--WiiUf ——青龙出世，傲视苍穹 2024年6月17日 (一) 07:18 (UTC)

根本不难通过，根据现行公示规则，在公示期间所有合理疑问于提出后已获提案人解决，而解决后3天内没有进一步追问，即可通过公示。而且基于共识不是点票，即使有大量人反对或支持也没有用，因只按提案内容是否合理而行。换句话说，这句是可以删除“ ，但由于各方存在激烈争论，而且对于讨论中的各方观点需要长时间的观察及分析才能得知，因此无法评估此次共识是否广泛。建议争论各方在公示通过后，就实施的真实情形，滚动讨论并达成更广泛的共识”。

唯公示结束日肯定不是6月19日星期三，因为提案人还未解决所有问题。--唔好阻住我爱国（留言） 2024年6月17日 (一) 11:00 (UTC)

如果这样强行通过的话，(－)反对。--WiiUf ——青龙出世，傲视苍穹 2024年6月17日 (一) 11:02 (UTC)

如果阁下对这个公示程序有什么不满，另请阁下提出修改。--唔好阻住我爱国（留言） 2024年6月17日 (一) 11:26 (UTC)

(＆)建议按照@Taiwania Justo的提案先试行一个月，如果能高效地解决条目探讨区讨论过多的的问题，那恐怕就没多少(？)异议了。--WiiUf ——青龙出世，傲视苍穹 2024年6月17日 (一) 11:51 (UTC)

“只按”提案内容是否合理而行？那就算提案完全合理，会有人乐意实行？--WiiUf ——青龙出世，傲视苍穹 2024年6月17日 (一) 11:04 (UTC)

以我的意见，如果改成“试行”一个月之后，依据成效来进行讨论，我想反弹不会那么大，如果提案人愿意的话。台湾杉在此发言 (会客室) 2024年6月17日 (一) 11:11 (UTC)

这样还可以，(＋)倾向支持。--WiiUf ——青龙出世，傲视苍穹 2024年6月17日 (一) 11:13 (UTC)

其实现在提案人已偷步试行。你可以测试那些已偷步试行的例子是否具成效。--唔好阻住我爱国（留言） 2024年6月17日 (一) 11:25 (UTC)

其实也没别的方法了吧？—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月18日 (二) 02:59 (UTC)

WiiUf版本

此次讨论并未能取得广泛共识，各方均坚持自己的观点。综合各方意见，我提出以下方案：

“公示将于此讨论结束后试行30日，并在试行结束后根据公示的有效性及真实情形进行进一步讨论，决定是否通过此公示。”

如有任何问题，请提出。如果本人不适格担任关闭者，请与本次讨论无关的管理员进行关闭。

—WiiUf ——青龙出世，傲视苍穹 2024年6月18日 (二) 07:19 (UTC)

+0 --Liuxinyu970226（留言） 2024年6月18日 (二) 08:29 (UTC)

这个可以。--唔好阻住我爱国（留言） 2024年6月18日 (二) 11:13 (UTC)

再次讨论合法性问题

@Taiwania Justo、WiiUf：有鉴于WP:共识#什么是共识有特别说明“重大修改更应获得绝大多数的同意”，因此我想先确认路西法人的提案到底是否属于“重大修改”，以及是否“获得绝大多数的同意”。如果路西法人的提案属于“重大修改”，但并未“获得绝大多数的同意”的话，那这个提案无论如何都不能被认定为通过，否则这就相当于提案在不存在共识的情况下（实际上）通过。我所指的“（提案）不能被认定为通过”意指完全不执行或停止执行提案提到的任何措施。San mo sa _{Snipe–Clam Grapple} 2024年6月18日 (二) 13:17 (UTC)

“获得绝大多数的同意”是绝对没有的，但是是否属于“重大修改”还需要进一步讨论。我(＋)倾向支持认为这是重大修改。--WiiUf ——青龙出世，傲视苍穹 2024年6月18日 (二) 13:58 (UTC)

就这两方面来回应。

是不是重大修改：依照目前讨论的激烈程度，重大修改应该合理吧。
是否是大多数人同意：那就要回到共识到底是单纯的数人头，还是考虑各个观点的合理性。依照英语维基百科和中文维基百科的共识页面精神，以及目前我正在翻译的WP:ACD，都建立于“合理”的权重。依据目前的讨论来看，路君的论述合理比重比较高，可以看作主要的合理论据；而反方论点逻辑上确实有瑕疵，但所担心的点无非是影响新手或特定领域的编辑者可能因为不熟悉“先在讨论页讨论再进行其他管道”的优先程序而求助无门。这两方以人数来看，确实相当，但在论点合理性方面，路君的合理性较高。不过，反方意见的担忧处也必须纳入考虑。

因此，今天我在思考的是，如果不熟悉，那就来真的“试行”，除了测试接受度，也让该提案有一次尝试的机会，期限30日或一个月为限。目前这个试行共识看起来接受度算高，应可成为本案的共识。以上。台湾杉在此发言 (会客室) 2024年6月18日 (二) 14:04 (UTC)

(＋)支持。--WiiUf ——青龙出世，傲视苍穹 2024年6月18日 (二) 14:05 (UTC)

由于实践才是真理，看似完善的论述，不一定行得通。但既然如此坚持非要“测试”看看，那也就罢了。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月22日 (六) 05:34 (UTC)

第三次公示

经过24小时场外沟通和我介入以后的情况，目前对于“试行”的提案获得大多数认同；但在场外沟通时，@LuciferianThomas提出因为WP:FRS的推广及教育工作需要长时间去推动，最少需要半年的时间，这个部分我也认同（就目前中维的参与者活跃情形不如英维，需要长时间沟通实属合理）。因此，这里改以“试行”模式做为最终公示方案：

下列方案以“试行”方式执行半年，从公示完成之日起算。
第3个月，必须于特定页面进行期中报告，重点要放在是否有提升讨论页的使用频率与参与程度。
试行结束时发表最终报告，并进行讨论是否接纳成为正式方针与/或是否进行修改。
公示后30天内需要讨论报告的呈现方式及指标。
试行期间，违反者尽量以教育为手段，不得采用封禁等禁制使用者参与编辑维基百科的方式。

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

以上试行方案即日起 公示7日，2024年6月25日 (二) 15:20 (UTC) 结束。台湾杉在此发言 (会客室) 2024年6月18日 (二) 15:20 (UTC)

不论试行前后，都不得使用封锁或禁制处理违反此等条款的用户，除非能证明用户是蓄意为之（WP:POINT，例如“我就是要这样啊”）。--路西法人 2024年6月19日 (三) 00:45 (UTC)

@Taiwania Justo:

请提供“ 经过24小时场外沟通和我介入以后的情况，目前对于“试行”的提案获得大多数认同”的证明，谢谢！--唔好阻住我爱国（留言） 2024年6月19日 (三) 13:23 (UTC)

原因：“维基外的讨论。我们不鼓励编者在其他网站、论坛、聊天工具、电子邮件或其他本专案外的地方讨论。这些讨论在“维基内”决定共识时是不予考虑的，并在它们被揭发后会引发猜疑和不信任情绪。尽管我们需要在维基外讨论少数问题以顾及隐私，但绝大多数维基百科相关的事项都应在维基百科上讨论，这样它们将对所有参与者可见。”--唔好阻住我爱国（留言） 2024年6月19日 (三) 13:24 (UTC)

“试行”依据在关闭公示版本讨论的部分可见，没有在场外讨论的因素；场外讨论主要是试行的方案，如上所述。--台湾杉在此发言 (会客室) 2024年6月20日 (四) 03:52 (UTC)

我不认为这是在维基以外地方讨论的合理理由。--唔好阻住我爱国（留言） 2024年6月20日 (四) 10:56 (UTC)

目前场外沟通的只有提案人和Eric Liu，没有其他人，沟通的结果也如实在此说明供大家公评，程序部分已经完备。--台湾杉在此发言 (会客室) 2024年6月20日 (四) 13:52 (UTC)

而且该条例不是“禁止”这样做，而是“避免”这样做，部分沟通还是要有即时性才能完成，只不过做出的结果还是要拿回来维基百科做说明供大家讨论，程序才能完备。--台湾杉在此发言 (会客室) 2024年6月20日 (四) 13:55 (UTC)

我相信有不少人也关注，是什么论点促使路西法人妥协？

另外， “场外沟通的只有提案人和Eric Liu，没有其他人”，请问阁下是如何得知他们的讨论结果？--唔好阻住我爱国（留言） 2024年6月21日 (五) 11:16 (UTC)

我分别和他们进行沟通，主要说服论点就是不能太激进，如果以“试行”方式，反弹声浪会比较小，而且我分别将#公示后关闭讨论文字叙述的结果跟他们进行说明，他们虽然可能还有不同意见，但至少大致都认为“试行”方案可行。--台湾杉在此发言 (会客室) 2024年6月21日 (五) 14:20 (UTC)

(＋)支持--CaryCheng（留言） 2024年6月19日 (三) 15:40 (UTC)

不祇是所谓“沟通”，还有根本制度性问题。但事到如今，都无所谓了。甚至祇是改为“试行”都让我感到惊讶。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月19日 (三) 16:36 (UTC)

(？)疑问-在下以为，在互助客栈讨论不是不行，但应先在、或同时在条目讨论页发起讨论为宜。在下有些疑惑：设置这一新规定，可能有哪些副作用？会否过度限制沟通？会否让维基用户疑惑而却步？Wetrace欢迎参与WP人权专题 2024年6月19日 (三) 17:31 (UTC)

我是觉得提案人很理想，但问题在于“不习惯”。既然如此，一个不习惯的方式突然要变成“正式方针”并且要“强力执行”，一定会有很大的反弹。因此这里改成“试行”也是基于尽早让编辑者习惯的一个重要手段。前几天我私底下和@Ericliu1912讨论的时候，我有提出目前还有其他的配套措施正在引进当中，例如WP:DRN是目前可能的方案，实际上就是条目探讨的复杂版，对于编辑者内容争议进行引导的模式也做得非常完善。我是打算在试行期间完善化DRN，到时候看试行效果再做争议解决指引的修正，甚而解决条目探讨一直以来的过长问题。台湾杉在此发言 (会客室) 2024年6月20日 (四) 04:02 (UTC)

我也正在准备重新翻译WP:DR，如果您有意推行DRN，那么我把DRN写进方针重修提案中吧。--路西法人 2024年6月20日 (四) 04:50 (UTC)

若“禁止发起若干讨论”是一种短期措施，旨在树立分流之惯例，到来日不必禁止之时即可解除，那倒是还好；但此提案的目标既然是“永远禁止”，那就不能回避客栈以外某些讨论方式之固有缺陷。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月21日 (五) 06:10 (UTC)

同意以上观点，如果半年之后效果有出来以及配套措施建成，可以考虑放宽或是停止这个条款。这也是“试行”的另一个层面的意义。--台湾杉在此发言 (会客室) 2024年6月21日 (五) 10:43 (UTC)

其实我也看过英语维基百科的共识方针（以下Chatgpt翻译并经过润饰）：

当仅通过编辑无法达成共识时，形成共识的过程会变得更为明确：编辑者会在相关的讨论页上开设一个新章节，尝试通过讨论来解决争议，并使用基于方针、来源和常识的理由；他们还可以提出替代解决方案或妥协方案，以满足所有人的关切。最终的结果可能是一个无法完全满足所有人的协议，但代表了整体小组的共识。在维基百科上，共识是一个持续的过程；通常接受一个不完美的妥协——理解到页面会逐步改进——比试图立即实施一个特定的偏好版本更好。

当编辑者特别难以达成共识时，有几个流程可以帮助建立共识（如第三方意见、争议解决布告板、征求意见），甚至有一些更极端的流程会采取权威措施结束争议（如管理员干预、仲裁）。然而，请记住，管理员主要关注方针和编辑行为，不会权威地决定内容问题。他们可能会因干扰共识过程的行为（如编辑战、滥用多个帐号或缺乏礼貌）而封禁编辑。他们也可能会决定某些编辑是否符合方针，但通常不会超出这些行动。

其实根本上在英语维基百科也没有特别出现“应”怎样，“须”怎样的文字叙述。我是希望试行半年或是三个月之后，可以换成这种比较温和的文字描述。台湾杉在此发言 (会客室) 2024年6月21日 (五) 14:32 (UTC)

实际上以后若编者能自然形成什么程度重要的议题适合伊始即在客栈讨论的共识，且其行之有效，那自然要好于用行政手段强制规范。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月22日 (六) 05:34 (UTC)

@Taiwania Justo(？)疑问：第4条是不是在说，某些情况下不能将讨论加入征求意见系统？似乎有些议题并非从争议开始，而是从对意见的征求开始；在低浏览量条目讨论页发起的这种议题，要是不加入征求意见系统，可能一年都不会有人看到。--CuSO₄ · 龙年大吉 2024年6月22日 (六) 19:25 (UTC)

这个情况下，编者应先尝试提及近期参与过该条目编辑的用户讨论（因没有特定的争议对象）。真的没人能提及的情况下就等同讨论无果的情况而可以开RFC了吧。--路西法人 2024年6月23日 (日) 00:51 (UTC)

这样的话，既然已经有RFC系统了，那在下并不反对上述提案。--CuSO₄ · 龙年大吉 2024年6月23日 (日) 14:05 (UTC)

“若有人声称拥有条目控制权，新机制下仍能在客栈发讨论通告（这次可以写明“有人声称对主题/条目拥有控制权，请求协助”这类），仍然是可以在客栈求助；再不是，挂个RFC请求协助也是可以吧。新制只是把社群用户带回原有讨论串参与，而避免讨论出现分支造成混乱。（注：未来有仲裁委员会，若社群无法解决用户声称控制权，那么就可以提报仲裁处理）”

.

这个还未解决。--唔好阻住我爱国（留言） 2024年6月23日 (日) 08:02 (UTC)

这个部分不是“条目内容”的问题，而是“使用者行为”的问题，在仲裁委员会还没有建立的情形下，直接在WP:互助客栈/其他处理就好。--台湾杉在此发言 (会客室) 2024年6月23日 (日) 10:40 (UTC)

该方针明文指向这里解决，请二位检视一下还有什么方针指引明文指向条目探讨区解决问题，一并进行修改。--唔好阻住我爱国（留言） 2024年6月23日 (日) 10:54 (UTC)

刚看完英语维基百科对于条目所有权的规范，的确是先在讨论页讨论，不行才必须进行争议解决程序。这个部分等公示完成进行试行之后，一并进行修正，在此之前条目所有权问题仍然照旧，不知@LuciferianThomas意下如何。--台湾杉在此发言 (会客室) 2024年6月23日 (日) 11:19 (UTC)

本地将条目所有权当作行为问题处理也没有什么问题，应考虑在条目探讨中无视声称条目所有权的说法以外，同步开启对有关声称的行为争议解决。--路西法人 2024年6月24日 (一) 02:00 (UTC)

(！)意见：未参加先前讨论，但条款（4）中“编者可往互助客栈发送讨论邀请通告及将讨论加入征求意见系统以获取第三方意见。”与条款（1）中的强制规定显然有冲突，如果条款（1）中的讨论长期无法达成共识（具体为a.b.两项中限制讨论的情况），但却没有强制编者采用条款（4）在互助客栈发起第三方讨论引入共识，则可能导致部分条目长期出于编辑战状态，亦导致本方针效力下降。如果希望本方针可以切实解决部分长期冲突，则条款（4）应当变为条款（1）的强制性补充条款（也即，如果条款（1）所发起的讨论不能够达成共识，条款（4）应当被强制启用；或者将条款（4）改为须在互助客栈发起讨论引入相关共识），并且增加判定论仍无果的方法（比如增加具体的时间判定）。--Sinet（讨论） 2024年6月23日 (日) 16:12 (UTC)

任何人都能执行条款四。我确信如果社群已经注意到特定主题长期编辑战，必然有人会就有关议题发起征求意见，基本上不太可能出现“长期编辑战，而双方及第三方都不发起征求意见”的情况。--路西法人 2024年6月24日 (一) 02:02 (UTC)

还是建议修改，否则按照原条款（4）的执行可能出现如下问题：

如果当事方或第三方中任意一方采用条款（4）启动页面外讨论，那么页面外讨论的共识引入页面内可能基于两种原因受阻：
1. 反对方基于条款（4）“经讨论页讨论仍无果”判定标准不明确拒绝承认页面外共识或反向指控提请方违反本方针。
2. 基于条款（4）发起的页面讨论与基于条款（1）发起的页面内讨论间效力关系不明，究竟是页面外讨论的共识效力“更高”还是页面内讨论的共识效力“更高”缺乏方针背书。
有些长期编辑战的当事方往往是新手，而新手并不熟知或者没有兴趣去熟知条款（4）相关内容，如果不增加强制性动机，则很难触发条款（4）；
条款（4）本身就是一种需要让社群注意到长期编辑战的方式，如果不更改触发机制，则成了“为何需要先有一部分人注意到再让社群其他人知道，如此给予那部分先注意到的人一些不应有的裁量权”。

题外话，之前的法论功主题貌似就属于“长期编辑战”这一范畴，而且并没有人尝试去互助客栈引入共识，反而是互相提报WP:VIP和WP:AN3。--Sinet（讨论） 2024年6月24日 (一) 11:11 (UTC)

1. 在新规范下，不应存在“页面外共识”（条文六：不应移动讨论串，平行讨论亦是移动讨论的一种），讨论仍然会继续在该讨论串进行，只是邀请了更多人参与。
2. 同上，不再存在“页面外讨论”。
新手不熟知条款，新增强制性也不会使他们忽然就知道这条条款。新规范的目的之一是让老手教导用户正确使用维基百科的讨论机制，而有争议、新手讨论或编辑战，很多时候都能在RecentChanges中被发现。
长期编辑战光是在RFPP或管理员布告板等已经能引起社群注意，条款四并非“让社群发现编辑战”，我上一则留言的说法是顺序相反的“社群发现后执行条款四”。另，就算是局部共识也是有效共识，而后来的人仍然可以通过新共识去推翻旧共识，“先注意到”的人并不会“达成共识后就不能再改”，这个并不叫“裁量权”。

而你说FLG没人去客栈引入共识就完全反映您没关注客栈。光是Talk:法轮功未存档的讨论已经有五串是移动或存档自互助客栈。你的通篇留言仅仅反映你没有查证事实、没有认真读我的留言。--路西法人 2024年6月25日 (二) 02:08 (UTC)

试行专门讨论页

WP:CON/TRIAL。台湾杉在此发言 (会客室) 2024年6月23日 (日) 06:46 (UTC)

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

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

最新留言：在1个月前发布18条留言9人参与讨论

本主题或以下段落文字，复制自Wikipedia_talk:共识#重要：涉及限制互助客栈条目探讨区讨论之政策修订。执行人：台湾杉在此发言 (会客室) 2024年10月5日 (六) 06:37 (UTC)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我赞同"只闻客栈罪大恶极问题多，条目讨论页问题岂少"。现实中就有类似的制度，为了让上级部门减负、提高解决重大问题的能力，所以就禁止下级人员直接到上级部门处理事务，那就是历朝历代的逐级上访制度，结果在基层解决不了的事情到最后也是烂尾，反而起到了正当化“基层问题”的作用。我承认从条目讨论页开始，一级级扩大讨论是一种最佳实践，但是现实告诉我们，最佳实践的强制化、法条化最终只会得到适得其反的结果。现实就是没有多少人把条目的讨论页当一会事，甚至不少编者都没有自动订阅自己创建页面的讨论页，也没有多少争端是在讨论页就得到解决。再给出现实中相反的实践，苹果CEO库克对于任何用户的来信向来有求必应，这也不见得他会因为这种做法降低效率。

最后再讲讲这些条款的预设前提，第一客栈讨论的内容一定要比一般讨论页来得“高级”，第二讨论的重要性只能由影响条目的数量决定；第一个前提我完全觉得这就是官僚做派，所以维基百科最大的流量入口之一只能讨论国家大事不能讨论民间疾苦，所谓的站务就一定比普通人之间的讨论更为重要、更为高贵；而第二个前提我也难以苟同，再这么长的讨论串中我也难以确定规则的制定者到底是为了什么才给出这种规定，这又是有哪种理论支持这种观点，如何证明维基百科访问量最大的“中华民国”条目的讨论比涉及100个低流量条目的小修改要低级一些，我觉得这种判定方法难言科学。--Cat on Mars 2024年5月31日 (五) 16:48 (UTC)

我觉得CatOnMars说的很好！如果限制在客栈发言就是相当于逐级上访制度。--桐生ここ★[讨论] 2024年5月31日 (五) 20:02 (UTC)

逐项回复：

层递讨论与逐级上访制度比较：逐级制度是A找B（AB尝试解决问题）、不行再找C（AC尝试解决问题），其中B和C作为较“高级”的人员可能存在官僚或滥权，更会有人试图阻止A向上声请；层递讨论是A加B然后再加C，而ABC都是平等的用户，无所谓“上下级”观念，无人能阻挡其他人再向声请其他人参与。显然是不可比拟的情况。你所说逐级上访制度，在基层解决不了的事情到最后也是烂尾，起到了正当化“基层问题”；认真分析一下上方用户讨论，却会发现反对削减互助客栈的用户存在“没给基层讨论解决问题的机会，正当化‘基层讨论存在问题’，然后以此阻碍全面鼓励基层讨论尝试解决问题的机会”，社群的情况显然与逐级上方制度是完全相反的。
讨论页的重要性：一来社群的机制设计本身不鼓励使用讨论页，自然没人当讨论页一回事；二来用户只要有监视自己创建的内容空间页面，连带的讨论页也是会自动监视；三来“没有多少争端是在讨论页就得到解决”完全是幸存者偏差的观念，解决了的问题根本轮不到社群广泛注意到。
苹果CEO库克的例子：库克对于任何用户的来信都是有求必应是一件好事，但若所有人事无大小（一切苹果相关的问题）都直接找他，他的处理管道不就会出现拥塞，导致难以及时分配资源跟进从而机制失效了吗？现在的客栈不正是“原先是一件好事，但现在因被过度使用而是失效”吗？维基百科依赖社群的自我管理和协作，而非集中化的高层决策。这种模式下，讨论页提供了一个基层参与和解决问题的平台，这是其运作方式的基础。
条款的前提：同上。另，就算是“100个低流量条目的小修改”，我仍然是鼓励在条目讨论页开启讨论。给我真的全面推这个议案，我是情愿不再让用户在客栈发起任何讨论，而仅用作引流，只是现在被反方用户弄得必须给这个选项而已。我的理念是所有讨论都是平等的，没有一条条目讨论比其他“重要”，而仅应有讨论本身是否具争议性、话题性或“影响力”而由编者决定是否参与。也如同我上面反驳桐生最新提案及Ericliu回应的留言中提及，“影响广泛的讨论本身就是导致客栈过长的主要食粮，这些需要分流分拆到其他地方讨论；影响较低的讨论很多本身就不至于需要整体社群关注（甚至在客栈也不多人参与），直接在讨论页使用征求意见或许已能满足该类讨论需求。”长的不适合放在客栈（会过长），短的也不需要放在客栈（现在有同等效力的替代工具，客栈给予曝光引流即可），这个才是以上提案条款的前提。

--路西法人 2024年6月1日 (六) 17:22 (UTC)

原始RFC搬移者的回应

作为原始RFC翻译者，看完最近的讨论之后，有些话要说。

以个人立场，我是同意互助客栈必须要做一定程度的减压，所以才会尝试引入其他机制，只不过当时不知道如何建置机器人而已。
如果观察到英语维基百科和中文维基百科的首页配置，可以发现到中维有“互助客栈”的连结，而英维没有。这就可能导致中维的新手使用者直接点入互助客栈而不是中英维都有的“社群入口”。其实英维的设计我觉得更好，必须要凸显“社群入口”当作新手获取维基百科社群资源的第一站，而不是互助客栈。
我不知道集中式讨论是不是我们独有的特性，所以特别偏爱单一页面就能够解决所有问题，这个可以再好好讨论，甚至可以做一下意见调查。例如：
您喜欢的是互助客栈集中讨论，还是先在条目讨论页讨论，如有需要才去互助客栈讨论？

您认为为何条目讨论页很好用/难用？

目前中文维基百科开始引入了“征求意见”、“请求回馈系统”等相应措施，您是否已经开始使用？

如果有使用，您认为是否有效解决互助客栈的问题？如果没有使用，请问您的考量点为何？

您认为中文维基社群要如何行动，才能改善条目讨论页功能不足的问题？

大概是这样。台湾杉在此发言 (会客室) 2024年5月31日 (五) 14:23 (UTC)

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

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

最新留言：在1个月前发布8条留言7人参与讨论

本主题或以下段落文字，复制自Wikipedia_talk:共识#重要：涉及限制互助客栈条目探讨区讨论之政策修订（续）。执行人：台湾杉在此发言 (会客室) 2024年10月5日 (六) 06:40 (UTC)。

本主题或以下段落文字，移动自WP:VPD。执行者：路西法人 2024年6月26日 (三) 08:36 (UTC)。

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

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

一、禁止在互助客栈条目探讨区发起“仅影响单一条目的讨论”，也禁止将此等讨论移动至客栈，只能发送讨论通告；

二、禁止在互助客栈条目探讨区发起“影响多个属相同主题的条目的讨论”，也禁止此等讨论移动至客栈，只能发送讨论通告；

三、在互助客栈条目探讨区发起“影响多个主题条目的讨论”时，应当在主题条目发送讨论通告。

因提案已重行公示，且涉及目前此页面多数讨论，故再一次予以公告提醒，请编者注意并踊跃参与相关讨论。—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月12日 (三) 18:25 (UTC)

三是笔误？是第二项所禁止的。--YF dyh000（留言） 2024年6月13日 (四) 06:10 (UTC)

根据原提案，三应该是指“影响多个不同主题的条目的讨论”，和二没有冲突。--Wolfch (留言) 2024年6月13日 (四) 09:20 (UTC)

按所谓“重行公示”版本调整了内容。但我还是有看没有懂，相信以后其他编者也将如此。行文都这副样子，未来强行执行之效果恐怕是一言难尽！—— Eric Liu_{創造は生命（留言・留名・学生会）} 2024年6月17日 (一) 06:34 (UTC)

(－)反对二和三，因为自相矛盾，恐存选择性执行之漏洞，Wolfch的和二没有冲突说法恐怕语焉不详。--Liuxinyu970226（留言） 2024年6月17日 (一) 06:23 (UTC)

不知道会怎样。但是我相信LuciferianThomas肯定会持之以恒并忠诚地守着这个版块来将不符合他的理念的讨论移到他认为合适的地方，并持续地推广那套机制。

——Sakamotosan路过围观 | 避免做作，免敬 2024年6月26日 (三) 07:54 (UTC)

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