维基百科讨论:征求意见/存档2
 | 本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论，请在当前讨论页进行。 |
根据其讨论页，回馈请求服务和RFC（同见维基百科讨论:请求评论）最后好像是因为没有公示和没人来运作机器人最后不了了之。最近有一些大型讨论，引入回馈请求服务的话就能把这些标成RFC之后给在页面下订阅的用户发提示邀请参与讨论，对于一些问题带来点曝光度。
我最近"可能"有点时间，也许可以研究一下试运行机器人，比如添加Flow支持什么的。如果大家觉得引用过来比较有益的话我就可以尝试一下。--0xDeadbeef（留言） 2024年1月7日 (日) 12:46 (UTC)
- 主要是机器人的问题。我是支持的。--Ghren🐦🕗 2024年1月7日 (日) 12:52 (UTC)
- 本站讨论试过几次请求评论，除了特地扩大讨论的一两次以外，效果多半不佳。现阶段还是互助客栈最适合集中讨论。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月7日 (日) 15:54 (UTC)
- 不过对于集中一般讨论，个人倒是乐观其成的。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月17日 (三) 09:27 (UTC)
- 支持。有机器人通知的话感觉会比客栈效果好一点。--及时雨 留言 2024年1月7日 (日) 22:36 (UTC)
- 支持。先考虑调试引入机器人吧。--在下荷花，请多指教（欢迎签到） 2024年1月8日 (一) 07:42 (UTC)
- 不反对，但建议先引入机器人来试着执行看看效果。--冥王欧西里斯（留言） 2024年1月10日 (三) 03:58 (UTC)
- Flow别支持了，都要寄了 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年1月10日 (三) 04:04 (UTC)
- 啊，这倒是，Flow连基金会都要弃坑了（--冥王欧西里斯（留言） 2024年1月10日 (三) 05:06 (UTC)
- (＋)支持--Taeas（留言） 2024年1月17日 (三) 13:49 (UTC)
引入WP:请求评论取代互助客栈方针板及条目探讨板功能
已解决
- 下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
续上个月存在初步共识的讨论（Wikipedia_talk:请求评论#引入WP:回馈请求服务与WP:请求评论），再次提出引入WP:请求评论机制。目前，我经已开始开发负责运行请求评论的机器人（Wikipedia:机器人/申请/LuciferianBot/5），并有初步成功的测试结果。WP:回馈请求服务尚未引入，英维也暂时没了这个服务，似乎也并不至于必须即时引入。@参与上次讨论的用户--路西法人 2024年2月5日 (一) 16:35 (UTC)
提案内容
中文维基百科目前使用互助客栈作方针指引修订及条目探讨，运作多年算是运行得不错，但有重大的缺陷需要正视：
- 互助客栈方针及条目探讨二板块常年存在过长问题（大于100KB），常有载入缓慢或留言储存缓慢的问题；
- 用户无法长期追踪特定方针指引／特定页面的修订讨论，因为无法自动选择性订阅特定讨论主题；
- 条目探讨板的讨论往往是条目讨论页迁移过来，难以追踪。
以上两个问题均能通过RFC系统解决：
- 将讨论回归至各条目及方针指引页面讨论页，不再会轻易造成过长讨论页面。
- 回归讨论页后用户可简单通过监视页面（或请求评论列表页面）即能达到追踪讨论的效果。
请求评论曾被指“效果不佳”、“难以引导用户参与”，但最近一次试行证明，在未有广发通知的情况下，讨论参与度并不亚于客栈的各提案。若往后配合WP:回馈请求服务，自然能更加鼓励关注及参与讨论。另外，中维设有公告栏，亦是公告社群邀请参与讨论的方式，改用请求评论并不会削弱公告栏广邀意见的效果。
由此，在技术问题已经开始解决的背景下，我谨此提出正式引入WP:请求评论，逐步取代互助客栈方针板（即本页）及条目探讨板的功能。请求评论的讨论方式与现存在互助客栈及集中讨论的方式无异。建议互助客栈方针板在请求评论引入后，转型为就方针指引修订及订立提出初步概念及讨论的场所；而条目探讨板则全面废除，在用户有需要请求更多人意见时使用RFC召集意见，避免迁移讨论。若有共识采纳，亦需修订共识方针相关规定，将RFC纳入接受的场所之中。 --路西法人 2024年2月5日 (一) 16:35 (UTC)
讨论
请踊跃发表意见。--路西法人 2024年2月5日 (一) 16:35 (UTC)
- (～)补充：目前互联群中有机器人定期自动推送公告栏的公告事项，RFC亦可考虑新增类似功能，向互联群自动推送讨论主题，以增加讨论曝光度。--路西法人 2024年2月5日 (一) 16:37 (UTC)
- 支持。其实我觉得即使没有RFC/回馈请求服务机器人也可以这么做：讨论可以仍然在互助客栈发起，当讨论较长时，可以直接移动到RFC下的独立页面 / 方针或条目讨论页，然后互助客栈保留一个"讨论通知"并且暂不存档。公示了也可以在客栈通知下。--及时雨 留言 2024年2月5日 (一) 16:49 (UTC)
- 现在不是讨论过长的问题，而是同时存在十几个议案，每个都不一定过长，但合起来就很多。更何况“移动”讨论的部分才是最可能流失讨论者的情况，从一开头就在别处会比较好。--路西法人 2024年2月5日 (一) 17:07 (UTC)
- 因为互助客栈方针板将“转型为就方针指引修订及订立提出初步概念及讨论的场所”，所以感觉还是不能做到一开始就在对应讨论页，需要移来移去？--及时雨 留言 2024年2月5日 (一) 17:44 (UTC)
- 方针板所谓“初步概念及讨论”，是指用来提出方针指引相关的问题（若，真正讨论订立、修订方针则不在此处理。若自问题延伸出方针提案，那么最好以“发展出方针修订／订立提案”总结原讨论，并在对应讨论页发起新讨论。请求评论的主要目的是更方便追踪特定话题，如果在客栈提出议案则难以让监视方针页面及讨论页的用户追踪话题变化。
- 最重要的一点：不要再用机器人剪贴移动讨论存档，这导致难以追查留言修改、deltalk等情况。客栈讨论不应再存档至原始讨论页，而是以原是讨论页发送讨论通知时提供连结取代。--路西法人 2024年2月6日 (二) 02:44 (UTC)
- 因为互助客栈方针板将“转型为就方针指引修订及订立提出初步概念及讨论的场所”，所以感觉还是不能做到一开始就在对应讨论页，需要移来移去？--及时雨 留言 2024年2月5日 (一) 17:44 (UTC)
- 现在不是讨论过长的问题，而是同时存在十几个议案，每个都不一定过长，但合起来就很多。更何况“移动”讨论的部分才是最可能流失讨论者的情况，从一开头就在别处会比较好。--路西法人 2024年2月5日 (一) 17:07 (UTC)
- 是要直接替代全部职能？还是先以分拆冗长讨论为主？基本上我认为互助客栈话题与条目讨论页请求评论可以并行，前者本来是一种集中讨论，而后者则是提升条目讨论页讨论热度的管道之一，没有一定要谁取代谁的问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月5日 (一) 19:15 (UTC)
- 我认为条目探讨板功能应完全由RFC取代。40个完全不相关的主题集中讨论毫无意义，追踪条目及其讨论页的编者实则完全无从追踪客栈的讨论。既然目前实则要求先在条目探讨页试图解决争议再上升客栈讨论，那么即存在必然之讨论转移，除了难以追踪讨论变化外更容易造成参与者流失。故应修改规定，条目探讨页无法处理，不再转移至客栈讨论，而是原地发起RFC邀请其他编者参与。
- 方针板可另议。--路西法人 2024年2月6日 (二) 02:49 (UTC)
- 支持引入，但取代一事仍有疑虑，应当在试用中进行决定。--在下荷花，请多指教（欢迎签到） 2024年2月5日 (一) 23:57 (UTC)
- @Ericliu1912：他的原话是“逐步取代”，因此做法自然是逐步逐步来，但具体怎样逐步逐步来他没有明说。个人认为先以分拆冗长讨论为主确实是合适的第一步棋。@Hehua：但其实我们已经试用过一次了。Sanmosa Défendre jusqu'à la mort 2024年2月6日 (二) 00:46 (UTC)
- 这个当然是没问题的，我的意思是在未来的使用中进行检讨。--在下荷花，请多指教（欢迎签到） 2024年2月6日 (二) 05:55 (UTC)
- 我并不反对以评论请求制度分拆既有话题中较长的讨论，甚至可以立即推动。但通常要等讨论持续加长以后才能判断是否分拆的。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 00:44 (UTC)
- @Ericliu1912：他的原话是“逐步取代”，因此做法自然是逐步逐步来，但具体怎样逐步逐步来他没有明说。个人认为先以分拆冗长讨论为主确实是合适的第一步棋。@Hehua：但其实我们已经试用过一次了。Sanmosa Défendre jusqu'à la mort 2024年2月6日 (二) 00:46 (UTC)
- 由于现行WP:共识#提案讨论及公示时间的规定（7DAYS）是只有在互助客栈的提案才需要遵守如此规定，因此有必要考量是否需要要求RFC的提案同样遵守7DAYS规定，或是索性直接废除该从一开始就不该存在的规定。我个人会倾向于仅保留“正当合理的意见”的定义，其余一概废除。Sanmosa Défendre jusqu'à la mort 2024年2月6日 (二) 00:55 (UTC)
- @Hehua、Sanmosa：取代一事，第一步一定是完全废除条目探讨板（理由已前述，若有疑虑可至上面回应），同时可以不再将方针板订为唯一可以修订方针指引的有效场所，并要求讨论要么在相关方针指引页发送通知（包括发起讨论、公示等），或者直接在相关方针指引页讨论，鼓励编者在合适的场所提出，而避免在难以追踪、集合数十个不相关话题的互助客栈讨论订立和修订方针。方针板大概不会被完全取代，始终必须有一个场所给人问方针相关的问题。--路西法人 2024年2月6日 (二) 02:54 (UTC)
- 支持。--在下荷花，请多指教（欢迎签到） 2024年2月6日 (二) 05:56 (UTC)
- 不反对这个做法。Sanmosa 起视四境 而秦兵又至矣 2024年2月6日 (二) 09:51 (UTC)
- @Hehua、Sanmosa：取代一事，第一步一定是完全废除条目探讨板（理由已前述，若有疑虑可至上面回应），同时可以不再将方针板订为唯一可以修订方针指引的有效场所，并要求讨论要么在相关方针指引页发送通知（包括发起讨论、公示等），或者直接在相关方针指引页讨论，鼓励编者在合适的场所提出，而避免在难以追踪、集合数十个不相关话题的互助客栈讨论订立和修订方针。方针板大概不会被完全取代，始终必须有一个场所给人问方针相关的问题。--路西法人 2024年2月6日 (二) 02:54 (UTC)
- 想问一下目前相关机器人的运作方式？--冥王欧西里斯（留言） 2024年2月6日 (二) 01:20 (UTC)
- 稍微看了一下机器人的运作效果，不反对正式引入WP:RFC（可能需要修订Wikipedia:共识#征求外部意见以形成共识一节），同时废除互助客栈的条目探讨子板面，至于方针板届时应该改说明就可以了。--冥王欧西里斯（留言） 2024年2月6日 (二) 03:07 (UTC)
- 不支持过度依赖RFC，只有涉及可能需要长时间的长篇讨论的话，才有需要一个专门的讨论页面，也就是类似RFC的方式来解决。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月6日 (二) 12:54 (UTC)
- 原因？讨论谈论据，没论据就只能当您这是个人观点而非讨论的论据。--路西法人 2024年2月6日 (二) 14:11 (UTC)
- 同意Cwek的观点（注：此句为厘清回复性质添加）。实际上集中讨论也有不同于分散于各该条目讨论页的好处，编者不需要再同时反复来回查阅多个讨论页，尤其是部分涉及许多条目的讨论。所以纵使禁止直接在条目探讨区提案，至少仍应保留其汇整集中讨论的门户作用。当然，目前大多数编者的习惯仍应是追踪互助客栈讨论，为此监视一众条目讨论页及个别话题者应属极少数。另外提案人可能忽略的一个重点是也有人根本不监视任何页面，而是定时查阅互助客栈讨论（这种作法仍然是相当有效的）。尝试在短时间内以制度强制改变编者习惯并不实际。故就仅涉及单一条目的讨论而言，虽然可以考虑在未来推行回归以条目讨论页为基础，但仍需要有较长时的过渡期。是以现阶段个人亦不支持直接废除条目探讨区（及其讨论功能）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 14:18 (UTC)
- 若技术上可行，应该考虑先鼓励改成嵌套条目讨论章节，这样既可以保留互助客栈集中讨论的特性，并保留个别情况直接使用互助客栈页面的弹性，也应当可以避免提案人所说讨论搬移的情形。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 14:27 (UTC)
- 逐点回应：
编者不需要再同时反复来回查阅多个讨论页
并不准确，首先理论上若条目探讨区所有讨论都是按规则发起，理应全部都要先在条目讨论页讨论过，这时理论上所有参与讨论的负责任用户都必须翻阅过往讨论才能了解前文后理，客栈等集中讨论模式实际并无解决这个问题（反而产生了缺失原始讨论的问题，因多数讨论都不会整串移动）。更何况，负责任的编者更是需要翻查条目的过往其他讨论，实际上仍然有来回翻查的需要，条目探讨区的存在反而变相导致编者不会特地去翻查过往讨论。- 同时，在同一页反复来回查阅完全不关联的主题实则上并不具备效率，在长长的客栈中等候载入才能点章节连结，还要很常走过头翻到其他不相关的讨论，实则上更是降低了讨论效率。
- 条目探讨区并非直接删除，而是废止不再作讨论之用，实质操作可如阁下所言禁止提案。条目探讨区可添加嵌入如维基百科:请求评论/全部的请求评论列表，自动追踪讨论，而不再需要人手发通告。
部分涉及许多条目的讨论
应改以开请求评论子页面讨论。涉及多个条目不是垃圾场般推到客栈同时进行毫不相关的讨论的原因。有人根本不监视任何页面，而是定时查阅互助客栈讨论
，请求评论仍有讨论列表，“点去章节”只是变了“点去讨论页”，根本没分别，显然不是“客栈优胜于RFC”的问题。- 嵌套整串讨论在早前不知道什么时候已证会产生很多问题（见T:集中讨论重定向编辑历史）。
- 以上。--路西法人 2024年2月6日 (二) 14:39 (UTC)
- 目前涉及较多条目的话题，基本没有所谓“垃圾场般推到客栈同时进行毫不相关的讨论”，多半是紧密相连的几个条目。例如上次华侨相关讨论，明明讨论内容实际上都是一个议题，但有人偏要一个独立条目拆出一个讨论话题，这当然不比整体讨论再同时存档至三、四个页面要好。此等状况是实际存在而非孤例的，也是符合编者讨论惯性的。我想具体怎么处理这种话题，社群可以详细讨论（例如用机器人同步讨论至其他条目的讨论页之类），但我想应该没有必要为了推进制度“踩一捧一”，开头就“垃圾不离嘴”贬抑他人讨论习惯，一竿子打翻一船人吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 15:42 (UTC)
- “垃圾场般推到客栈同时进行毫不相关的讨论”写的是“同时进行毫不相关的讨论”，不是“涉及多个条目的讨论毫不相关”，而是“涉及多个条目的讨论与客栈其他议题不相关。客栈的实践方式确实是“什么都可以过来开”，客栈确实是垃圾场般运作，只是送来的是五花八门、互不相关的讨论，而不是垃圾而已。--路西法人 2024年2月6日 (二) 16:01 (UTC)
- 另外还存在一种话题，就是不针对特定条目，而是比较广泛存在的现象发起的讨论。这之中固然有部分情况可以归类于维基专题（也就与条目讨论页类似），但也有不强调特定主题而不适合硬性归类者。强行为这些讨论指定发起标的条目讨论页是非常不合理的。我想提案人没有注意到的是，互助客栈并不只是“个别条目讨论的集成”，而实较之更加复杂得多。个人认为，激进地废除直接讨论功能、以评论请求制度取而代之看似理想（至少理论上还挺自洽），但与互助客栈现实运作情况则略有脱节之虞。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 16:09 (UTC)
- （编辑冲突）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 16:10 (UTC)
- 就广泛现象的讨论，则显然适合另开启独立的请求评论页，从来未曾要求发起讨论必须在对应讨论页而不能另开请求评论页，这一点在我2239的留言也有提到（
应改以开请求评论子页面讨论
）。请不要选择性阅读。--路西法人 2024年2月6日 (二) 16:16 (UTC)- 请求评论独立页面应只适用于较长篇幅而有个别讨论需要的话题。为了保持页面列表“纯洁性”而动辄设立单独子页面，不仅效果甚差，实际上也是毫无必要。现在这样运作的提案方式，本身有什么问题（注意：这与页面载入等技术问题无关）？这是典型的“没坏别修”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 00:44 (UTC)
现在这样运作的提案方式，本身有什么问题
，提案及其他回复中已详述技术问题以外的其他原因（需翻查过往讨论、无法主从特定议题等），加上技术上的问题，显然不是没坏。请求评论独立页面应只适用于较长篇幅而有个别讨论需要的话题
又是一个观点而没论证原因，为何涉及多个条目而讨论篇幅未必长的就不能开请求评论页？为何就必须跟其他话题堆在同一个“集中讨论”的客栈？--路西法人 2024年2月7日 (三) 06:11 (UTC)
- 请求评论独立页面应只适用于较长篇幅而有个别讨论需要的话题。为了保持页面列表“纯洁性”而动辄设立单独子页面，不仅效果甚差，实际上也是毫无必要。现在这样运作的提案方式，本身有什么问题（注意：这与页面载入等技术问题无关）？这是典型的“没坏别修”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 00:44 (UTC)
- 就广泛现象的讨论，则显然适合另开启独立的请求评论页，从来未曾要求发起讨论必须在对应讨论页而不能另开请求评论页，这一点在我2239的留言也有提到（
- 一、唯一认同引进相关制度的理由，只有部分页面确实存在话题堆积的问题，这也是众所皆知了。但阁下显然过度夸大互助客栈页面载入及浏览相关章节时间所产生的负面效应。不然章节及页面导言的目次及topic list是设计来做什么的？凡是知道怎么利用这些工具的人，都不会轻易为上述问题所困扰。何况只要等待一个长页面载入，与改成在不同页面之间反复横跳耗费的总时间加起来对照，也不见得会比较好。是哪一种方式讨论效率比较差，还很难说呢。
- 二、实际上，包括互助客栈在内，几乎所有站务页面都是如此运作，以一个或多个主题为核心，聚集所有相关讨论。除了讨论总长度，我不认为互助客栈方针区与条目探讨区及其他一部分站务页面在讨论格式上有决定性区别。真要说的话，互助客栈消息区消息之间、求助区求助各该话题之间，或者档案存废讨论各讨论之类，差不多也都是互不相关，但归根究底，客栈页面（及多数站务集成页面）本来就是如此设计的——在宗旨是讨论“条目、模板、主题相关”事项的页面提出“条目、模板、主题相关”的话题，这本身并没有问题；互助客栈其他区块及大多数站务页面同理。我想不应该为了宣称评论请求制度的“优越”，反过来批评这样的讨论形式叫做“垃圾场”。我认为这是不公道的。退一步说，就算这么多页面的运作方式真的都像垃圾场，那也没关系吧？凭什么社群讨论页面不能以垃圾场的形式运作？
- 三、“‘点去章节’只是变了‘点去讨论页’，根本没分别”并不符合事实，实际上光所需步骤就多了一倍，而且会随欲参与的讨论话题数量等距增加。互助客栈（及多数站务页面）聚集相关讨论的一个好处在于，编者在浏览自己本欲参与主要讨论的同时，也有很大机会“顺便”就其他话题发言（如果实际参与过任何社群讨论，就知道这有多么容易），结果就是得以有效扩大社群在许多讨论的参与（或许也可以视为“维基兔子洞”的缩小版？XD）。我不知道这是不是当初页面设计所预期的情况（或许维基讨论系统本来就有这样的特点），但其效果则是明显可见。不要小看编者讨论的惯性；制度是设计给人类，而不是给一群“讨论机器人”用的。强制分拆请求评论回各条目或方针与指引页面，甚至于禁止直接在客栈提案（条目探讨而言），将客观上大幅增加参与讨论的成本，削减编者在主要讨论以外针对更多话题发表宝贵意见之动机。道理很简单，若要参与十个来自各条目或政策话题的讨论，却要在不同页面之间来回点击数十次，我想至少相当数量的编者衡量机会成本，肯定将放弃参与许多本有讨论潜力的话题，只专注于自己最偏好的几个主题。就增加话题平均bias程度而言，这是不是利大于弊呢？
- 四、我非常怀疑多少人有“自动追踪所有特定话题相关讨论”的需求。许多编者大概不会为了参与单一话题的讨论，就希望自动订阅所有类似话题。无论条目探讨或方针，大概都是如此。当然，必须指出，这方面需求也并不是不存在，所以就引进评论请求制度、增进条目讨论页讨论热度本身而言，个人并没有特别反对的理由。甚至先推动分拆既有冗长讨论以为测试，评估该制度在本地运作效果如何，亦无不可，反而还挺欢迎的。但是在未有实证研究佐证相关正面效果且有完全替代作用的情况下，不尝试推动该制度与既有互助客栈页面并存“良性竞争”，而是企图直接取而代之，则恐怕操之过急。从过往实际参与讨论的经验，我完全认为两种提案方式各有利弊，不应该径行独尊其中一种。无论如何，在彻底推行如此巨大的变革之前，社群也应当完全有权利以试行的形式观察相关制度运作情况。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 00:44 (UTC)
- 回：
- 以我相当不错的网速在客栈方针板储存一次留言需要10秒以上的时间，不同于在其他板块不足3秒就完成储存，即显然为缓慢载入；我网速已经算不错，对网速更慢的人来说显然会更加吃力。再者，超长页面亦会存在点选章节标题后浏览器跳错位置的问题，这是我仅在互助客栈发现的问题，其他讨论页均不存在，这显然已经展现客栈已经长到会导致技术问题。
几乎所有站务页面都是如此运作
，并没看到如此。AIV的共通点是全部都是破坏提报、RFPP全部都是保护提报，范围定义明确；而我长久诟病的AFD、DRV格式正是如客栈般容易导致过长且相关业务范围过广，导致难以查找过往记录。VPD各讨论的唯一共同点是“需要其他用户注意／提供意见的条目”，这个业务范围显然已经过广。并不是请求评论制度优越，而是目前客栈、AFD等制度是真的垃圾。VPO、VPN、VPT等板块我尚能理解是没有其他位置可以放的讨论所以集中处理，VPP、VPD显然是有其他更合理的位置放讨论，根本就不应该需要集中讨论的主题。- 社群页面本来就按照业务有分列不同板块，本来就是在找寻不同板块的路途上跳来跳去的。更何况，条目也是每一个主题放在不同标题之下，也是需要点来点去的，编辑多个条目的用户本来就习惯在监视清单跳来跳去。如果“跳来跳去”是如此不方便，要不要弄一个页面是集中全站所有业务来“提高用户参与度”？所以“跳来跳去”会成问题一点本来就是站务精才会有的问题。要做什么就该去那个地方，不应该因为不方便而不去做。不方便就不做的就是陋习，不值得鼓励。
- 阁下说
我非常怀疑多少人有“自动追踪所有特定话题相关讨论”的需求
，却遗忘了维基百科最大的重点是编辑条目的人。这些人监视自己编辑或有兴趣的条目的同时，必然会自动追踪了对应的讨论页（这是MediaWiki设计）。多数编者都会有参与自己有兴趣的条目的讨论的需求，但互助客栈的设计显然没有推动到这一点。 - 再者，我说过十万遍：分拆讨论才是万恶之源，理论上应该什么话题都直接在对应的讨论页（或者开全新的请求评论集中讨论页）处理，这样才不会出现讨论流失。阁下非常清楚这一点，却要求先行推动“分拆讨论”，这显然无助检视请求评论效果的同时，会反向营造请求评论不好用的非建设性效果。我完全无法理解为什么阁下这么爱提出毫无建设性、反而对议案存在反效果的建议，这里是如此，ArbCom讨论亦是如此。这不是制度间的“良性竞争”，而是以手段去伪造公平竞争，然后伪证一方无效；更何况平行运行两个不相容的制度根本无助任何编者参与。
- --路西法人 2024年2月7日 (三) 01:47 (UTC)
- 回复收到了，但不认同，而且认为上述宣称有很大商榷空间。其他的等过年完再详细说。我也想好好过年放个假的。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 02:51 (UTC)
- 我不知道评论请求本来是否打算针对冗长之条目及政策讨论而言？毕竟提案一开始就指出互助客栈讨论过度冗长为一大理由，那我想多数人预期该制度对于较长讨论特别有效，也应该不差错。怎么会是反过来“营造请求评论不好用”呢？显然并不会是这个意思。那我就不太理解阁下反对先行以此制度分拆部分较长讨论来试验评论请求制度效果的理由了。如果这样提议就会招致“毫无建设性”、“存在反效果”的批评，那若全面在所有形式相关讨论实施该制度，社群就大概更要有疑虑了吧？还是说此制度实际上对分流篇幅较小的讨论比较有效？个人确实搞不懂。或许是措辞有模棱两可之处，导致误会。
- 有一个前提需要注意：依据实际观察经验，目前条目探讨区的讨论，反而实际多次搬移者较少，而多是直接在互助客栈发起，尔后再存档至讨论页；尤其是涉及多个条目者，自然倾向一次在客栈提案讨论，而不是在多个条目同时发起话题。此一现象的本质或有可批评之处，但基本上我不认为“讨论流失”是用评论请求全面推翻目前互助客栈运作形式的主要理由。至于如何照顾监视条目者，我想在不涉及评论请求的情况下，有一个明显更简单且有效的解方，那就是直接在条目讨论页寄发通知；这个方法过往也有其他人用过，符合本地社群实际运作情况，而且或许还更方便（半）自动化；只要侦测存档至模板填入哪些对应讨论页，就可以用机器人或人工自动寄发通知。如果再搭配评论请求制度，提升条目讨论页本身既有讨论的热度，相信将能充分发挥互补作用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 15:44 (UTC)
- 回：
- 至于目前相当一部分话题直接在互助客栈而非条目讨论页发起的“问题”，若既有情况如此，则或许我们更应该先检讨这样的规定是否符合设计初衷，还是已经脱离社群实践共识而需要修订了？又例如同时承认两种方式的效果是不是比较照顾倾向使用不同提案方式的编者？诸如此类建设性问题，大概都比反过来直接批评这种“劣迹”要得体一些。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 01:06 (UTC)
- 为什么垃圾就不能被批评？同时承认多种制度反倒造成更多规则漏洞，根本就不是建设性，而是给予机会编者更懒更不愿意去遵守合理的规定。不要自以为是地觉得提出伪公允观点就是“公平”“良性竞争”，实则带来更多反效果。--路西法人 2024年2月7日 (三) 01:50 (UTC)
- 只能说这多半是价值观及理念上差异，你谈你的理论，我讲我的经验，大家各自畅言，汇聚意见，把多一点可能性摊开来，自然能够促进提案完善；就算无法尽善尽美、让所有人满意，至少也能说有好好交流过了。我想阁下并没有在此必要上纲上线给他人安个什么“伪公允”的帽子，不然以后都别讨论或认真写论述，也不用假装请社群“踊跃发表意见”（引开头语），互相拆台就得了。这样无礼的作为才是真正的自以为是。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 02:56 (UTC)
- 发表意见的基础在于推论和反驳，但阁下发言屡屡漏洞百出，我指出阁下发言的漏洞、批评阁下推论有问题、批评阁下的“观点”看似公允实则反效果居多、批评制度的腐烂，却又成了我上纲上线、我不接受意见。--路西法人 2024年2月7日 (三) 04:13 (UTC)
- 我（大概）也没说过自己的观点是（最）“公允”的，所以所谓“伪公允”议题应纯属虚构。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 15:51 (UTC)
- 口说“公平竞争”却说自己期望的做法不是公允，这不就自打嘴巴了吗？不公允的建议如何公平竞争？--路西法人 2024年2月11日 (日) 16:04 (UTC)
- 我（大概）也没说过自己的观点是（最）“公允”的，所以所谓“伪公允”议题应纯属虚构。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 15:51 (UTC)
- 发表意见的基础在于推论和反驳，但阁下发言屡屡漏洞百出，我指出阁下发言的漏洞、批评阁下推论有问题、批评阁下的“观点”看似公允实则反效果居多、批评制度的腐烂，却又成了我上纲上线、我不接受意见。--路西法人 2024年2月7日 (三) 04:13 (UTC)
- 只能说这多半是价值观及理念上差异，你谈你的理论，我讲我的经验，大家各自畅言，汇聚意见，把多一点可能性摊开来，自然能够促进提案完善；就算无法尽善尽美、让所有人满意，至少也能说有好好交流过了。我想阁下并没有在此必要上纲上线给他人安个什么“伪公允”的帽子，不然以后都别讨论或认真写论述，也不用假装请社群“踊跃发表意见”（引开头语），互相拆台就得了。这样无礼的作为才是真正的自以为是。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 02:56 (UTC)
- 为什么垃圾就不能被批评？同时承认多种制度反倒造成更多规则漏洞，根本就不是建设性，而是给予机会编者更懒更不愿意去遵守合理的规定。不要自以为是地觉得提出伪公允观点就是“公平”“良性竞争”，实则带来更多反效果。--路西法人 2024年2月7日 (三) 01:50 (UTC)
- 目前涉及较多条目的话题，基本没有所谓“垃圾场般推到客栈同时进行毫不相关的讨论”，多半是紧密相连的几个条目。例如上次华侨相关讨论，明明讨论内容实际上都是一个议题，但有人偏要一个独立条目拆出一个讨论话题，这当然不比整体讨论再同时存档至三、四个页面要好。此等状况是实际存在而非孤例的，也是符合编者讨论惯性的。我想具体怎么处理这种话题，社群可以详细讨论（例如用机器人同步讨论至其他条目的讨论页之类），但我想应该没有必要为了推进制度“踩一捧一”，开头就“垃圾不离嘴”贬抑他人讨论习惯，一竿子打翻一船人吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 15:42 (UTC)
- 或者可以这样说，我的想法是与其直接作废，不如把条目探讨区改造成提案人所说的一种“请求评论列表页面”，这样就不用再生造一个页面出来。当然具体怎么改可以再商量。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 14:42 (UTC)
- 条目探讨区既然不再作讨论之用，实则即是废除。导向新制格式与废除不冲突，WP:VPD废除后挂
{{historical}}同时提供导向RFC列表两件事可以同时发生，正如WP:HAM也可以提供连结按账号查询存档至SPI的用户查核记录一样。--路西法人 2024年2月6日 (二) 14:48 (UTC)- 完全可以沿用页面本身。傀儡调查分立页面的原因，主要是因为性质产生重大变化，且中间有数次更迭。相关列表显然从头到尾都是要用作汇整条目相关讨论用的，所以若没有打算保留原页面之作用，则不需要新开一个页面。我觉得我们单纯在这个议题上不存在冲突。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 15:25 (UTC)
- 维基百科:请求评论/全部并非仅收录条目相关讨论，显然不适合整个放在废除后的VPD；同时我从来没说过要开一个新页面去放条目相关的讨论列表，从来都是在说在VPD直接放置非维基百科专案相关的列表，完全不理解阁下是在“不需要新开一个页面”是在说什么。--路西法人 2024年2月6日 (二) 16:06 (UTC)
- 既然如此，那就好啦！—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 16:10 (UTC)
- 维基百科:请求评论/全部并非仅收录条目相关讨论，显然不适合整个放在废除后的VPD；同时我从来没说过要开一个新页面去放条目相关的讨论列表，从来都是在说在VPD直接放置非维基百科专案相关的列表，完全不理解阁下是在“不需要新开一个页面”是在说什么。--路西法人 2024年2月6日 (二) 16:06 (UTC)
- 完全可以沿用页面本身。傀儡调查分立页面的原因，主要是因为性质产生重大变化，且中间有数次更迭。相关列表显然从头到尾都是要用作汇整条目相关讨论用的，所以若没有打算保留原页面之作用，则不需要新开一个页面。我觉得我们单纯在这个议题上不存在冲突。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月6日 (二) 15:25 (UTC)
- 条目探讨区既然不再作讨论之用，实则即是废除。导向新制格式与废除不冲突，WP:VPD废除后挂
- 必须注意，阁下眼中的“RFC”只是社群目前使用请求评论系统的冰山一角，并非所有RFC都需要专门设置一个页面去处理RFC，而是可以直接在讨论页挂RFC模板邀请其他用户参与，阁下所言的“类似RFC的方式”根本就不是这个提案要提的“RFC”。--路西法人 2024年2月6日 (二) 14:21 (UTC)
- 首先感谢LuciferianThomas的在理论和技术上的贡献。(＋)支持当前提案。另外请提案人适时起草修订WP:RFC。并请注意最近一次试行使用的是集中讨论而非请求评论，具体到某个主体下的讨论效果还未有实践。考虑到有些编辑不经常参与站务讨论，建议在提案通过后，给活跃用户发消息。
- 主题破碎，海涵。--落花有意12138 2024年2月6日 (二) 16:14 (UTC)
- 必须注意请求评论和集中讨论并非互斥的措施，请求评论容许共识框架下的任何讨论方式，集中讨论是其中之一。“集中讨论而非请求评论”并不准确，RFC/RFA2024是“集中讨论模式的请求评论”，只是因为RFC尚未正式启用而未使用有关RFC模板而已。--路西法人 2024年2月6日 (二) 16:20 (UTC)
- 您说的对，我这里的意思是RFA2024是全站的讨论，区别于特定主题之下的讨论，理应更多人讨论。所以需要试行查看后者的讨论效果。
- 另外其他发言内容我默认您看到了。--落花有意12138 2024年2月8日 (四) 16:27 (UTC)
- 必须注意请求评论和集中讨论并非互斥的措施，请求评论容许共识框架下的任何讨论方式，集中讨论是其中之一。“集中讨论而非请求评论”并不准确，RFC/RFA2024是“集中讨论模式的请求评论”，只是因为RFC尚未正式启用而未使用有关RFC模板而已。--路西法人 2024年2月6日 (二) 16:20 (UTC)
- 如果要建立话题索引，界面大概可以沿用目前topic list的样子？看起来还不错。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月7日 (三) 01:06 (UTC)
- 大致同意，客栈反而是经常监视关注的地方，也考虑到部分议题可能长期讨论下去可能变长而不便阅读和推进讨论的问题。所以我还是维持意见：小讨论可以保留在条目探讨、方针版上，但如果有可能讨论长期大幅增长或有必要长时间讨论的，可以用RFC解决，并保留一个路径在客栈版上链去，而不是破除传统做法。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月7日 (三) 05:45 (UTC)
- 请阁下回应我所指，“将进行中讨论分拆至其他讨论页导致流量及参与度下降核心问题，而当（大多数）讨论本身就在适当的讨论页发起才不会存在这个问题”。另外，仍未见阁下论证观点，“传统做法”不等于“必然适合继续运行下去”，所谓“传统做法”似乎只是有坏仍不修的借口。--路西法人 2024年2月8日 (四) 16:08 (UTC)
- 这不是为了论证，而是一个观点，我就这么认为，也不要求你去认同这个观点。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月10日 (六) 10:46 (UTC)
- 那么就当您这是观点而非反对（议案特定部分）的意见了。反对意见需要论述，观点确实不需。--路西法人 2024年2月11日 (日) 00:33 (UTC)
- 建议深思，避免到时候被当成公示时排除“有效意见”考量的借口。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 06:52 (UTC)
不对提案进行实则性点评的意见、并非正当合理的意见，以及与提案本身无关的意见，皆不视作此条文所指的“新留言”与“相关意见”。
此为共识方针条文，不是排除有效意见“借口”而是“正当理由”。--路西法人 2024年2月11日 (日) 09:25 (UTC)
- 这不是为了论证，而是一个观点，我就这么认为，也不要求你去认同这个观点。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月10日 (六) 10:46 (UTC)
- 请阁下回应我所指，“将进行中讨论分拆至其他讨论页导致流量及参与度下降核心问题，而当（大多数）讨论本身就在适当的讨论页发起才不会存在这个问题”。另外，仍未见阁下论证观点，“传统做法”不等于“必然适合继续运行下去”，所谓“传统做法”似乎只是有坏仍不修的借口。--路西法人 2024年2月8日 (四) 16:08 (UTC)
- “引进评论请求”跟“互助客栈转型”基本是两个互不妨碍的议题。那既然没人反对前者，那应该已经可以开始提出制度运作细节，准备部署相关技术了。毕竟目前评论请求在本地几无有效运用，这也是客观事实，所以我想无论是要支持还是反对用这个社群相对陌生的讨论形式来改革互助客栈，都需要引进本地实际运作以后才知道具体效果究竟如何。目前参与讨论者意见所云“试用”大致如此，而这与提案人所说的“逐步取代”也应该不相违才是。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 06:49 (UTC)
- 我唯一可以给的让步是在客栈方针板及条目探讨板大字置顶建议改用请求评论制、嵌入请求评论的讨论列表等，否则无鼓励自然没人用，完全无法比对效果。建议的大字置顶通告如下：
由于客栈板过长导致载入及储存过慢等问题，用户可以改用请求评论系统请求更广泛意见；〔影响一整个主题的讨论／关于现有方针指引的探讨〕则在此发文。〔请建立新的请求评论子页面讨论影响多条方针的修订案。〕
- 同时在共识方针关于互助客栈的章节添加通告：应2024年X月社群共识，使用请求评论系统的讨论亦执行以下规定。方针将于稍后修订。
- 不同意在完全无鼓励的情况下直接引入请求评论，用户难以接触新系统的情况下，一来难测试新系统的效果，二来会自动给予“请求评论效果不佳”的结果。望能同意以上第一阶段鼓励转移的妥协安排。--路西法人 2024年2月11日 (日) 09:22 (UTC)
- 既然如此，您也应该意识到在这种情况下直接废除互助客栈既有讨论制度不太可行了吧。个人当然没理由不支持用评论请求分流讨论缓解互助客栈压力——而不是直接取代——甚至可以考虑在相关方针与指引明文写出“先在条目讨论页提出讨论，（回响不大的话）进而提出评论请求，（涉及较广泛条目或确有其他必要时）最后才是在客栈提案”的“三步骤”建议。当然，还是希望能提出评论请求在条目讨论页的执行细节，现在看起来似乎还比较不明了（尤其跟回馈请求服务好像还有一点混淆？我感觉评论请求在本地实际上比较接近前者的角色）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 15:17 (UTC)
- 我并不认为不应该废除客栈，只是阁下一直坚持，而我也说过是分阶段，那么阶段可以改，以让议案推进，但最终目标仍没改变。不要猜度我的思想，妥协不等于放弃。--路西法人 2024年2月11日 (日) 15:27 (UTC)
- 请求评论单纯就是挂个模板，让机器人自动载入需要邀请广泛意见的讨论而已，并无特别的执行细节。回馈请求纯粹是RFC的延伸部分，透过机器人发讯息随机邀请用户参与关注了的主题的讨论而已，并非RFC的必然构成部分。--路西法人 2024年2月11日 (日) 15:29 (UTC)
- 您可以不放弃革命，我也不非要“独尊”旧制度，但总是不应该拿客栈当实验场。我始终相信不用以推倒互助客栈为起手式，也能妥善运用评论请求。至于其效果是否有好到可取彼而代之，就得让社群评断。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 15:44 (UTC)
- 贵站问题在于爱造轮子，将别人运行得非常成功的制度不必要地左改右改，出错的位置却也总是与别人不同的部分。“Village pump”、“客栈”如其名，只是设计来非正式议事的地方，贵站却越改越偏，变成“议事厅”的款式，“互助”更是无稽之谈。阁下对着“互助客栈”这个标题，在这么不正式的场所却用来正式议事，没觉得过怪吗？究竟现行的真的是“旧制度”，还是“走偏不成原样的老制度”？--路西法人 2024年2月11日 (日) 16:20 (UTC)
- 您可以不放弃革命，我也不非要“独尊”旧制度，但总是不应该拿客栈当实验场。我始终相信不用以推倒互助客栈为起手式，也能妥善运用评论请求。至于其效果是否有好到可取彼而代之，就得让社群评断。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 15:44 (UTC)
- @其余参与提案讨论的用户：是否同意首阶段采上述折衷方案（见此留言）？若无异议，请问各参与用户（及@Ericliu1912君），是否同意让此折衷方案按Wikipedia:共识#非方针指引相关提案简易规定免除公示并于达到简易规定条件的三日后执行？--路西法人 2024年2月12日 (一) 13:09 (UTC)
- 不反对。Sanmosa 起视四境 而秦兵又至矣 2024年2月12日 (一) 13:11 (UTC)
- 觉得可以。--Borschts™ 欢迎外带一碗罗宋汤 2024年2月12日 (一) 16:37 (UTC)
- 同意。--在下荷花，请多指教（欢迎签到） 2024年2月13日 (二) 00:16 (UTC)
- 不反对。--冥王欧西里斯（留言） 2024年2月14日 (三) 23:31 (UTC)
- 既然如此，您也应该意识到在这种情况下直接废除互助客栈既有讨论制度不太可行了吧。个人当然没理由不支持用评论请求分流讨论缓解互助客栈压力——而不是直接取代——甚至可以考虑在相关方针与指引明文写出“先在条目讨论页提出讨论，（回响不大的话）进而提出评论请求，（涉及较广泛条目或确有其他必要时）最后才是在客栈提案”的“三步骤”建议。当然，还是希望能提出评论请求在条目讨论页的执行细节，现在看起来似乎还比较不明了（尤其跟回馈请求服务好像还有一点混淆？我感觉评论请求在本地实际上比较接近前者的角色）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月11日 (日) 15:17 (UTC)
- 我唯一可以给的让步是在客栈方针板及条目探讨板大字置顶建议改用请求评论制、嵌入请求评论的讨论列表等，否则无鼓励自然没人用，完全无法比对效果。建议的大字置顶通告如下：
- 首先声明，我未仔细阅读上面的讨论，故仅就提案内容发表意见。我认为，所谓三大缺陷，至少对我而言均不存在。一、我尝试载入条目探讨页面，结果5秒左右（估测）能完全载入，这一速度可以接受，并且可以在同一页面阅读和发表对多个议题的意见，较为便利。（但是，如果只关注一项议题，则浪费了载入其他议题的时间。）二、维基百科的回复功能，点击订阅即可订阅二级标题下的更新，并不麻烦。三、使用move from，move to等模板，似乎也没有难于追踪的问题。不过，虽然如此，我并不反对，乃至支持推广RFC机制，如果真能鼓励讨论的话。Fire Ice 2024年2月11日 (日) 17:11 (UTC)
较为便利
：这个便利建基于什么都混在一起，如我上面所说，要“便利”的话，不如所有专案页面都集合在同一页面下？显然“便利”不是一个合理的解释原因。点击订阅即可订阅二级标题下的更新
：本来就不是指追踪单一话题，而是单一主题下的所有话题。如果一个人要追踪“可供查证”相关方针讨论，则必须手动前往客栈查看有没有相关话题再订阅，而RFC（回归讨论页）就只要监视页面（自动监视对应讨论页）即可追踪所有相关方针讨论。使用move from，move to等模板，似乎也没有难于追踪的问题
，丧失所有编辑历史，难以查找留言编辑、删除记录，甚或是否曾被伪造都难以查证，始终客栈有十数万编辑。- 以上回复。--路西法人 2024年2月11日 (日) 17:32 (UTC)
- 初步的议题分类（方针、条目探讨等），将每个页面的话题限制在几十个，因此初步分类有合理性。至于追踪方针讨论，只能说可能有人有这种需求，要关心某一方针的每次讨论。--Fire Ice 2024年2月12日 (一) 01:28 (UTC)
折衷方案（见此留言）已获三名用户同意按非方针指引公示规则处理，如无其他异议将于2024年2月16日 (五) 00:16 (UTC)后生效执行。--路西法人 2024年2月13日 (二) 04:09 (UTC)
- ( π )题外话：“请求评论”翻译腔太重，可否改为“××咨询／征询××”之类的地道说法？避免再像这个名称引人误入歧途、（基本）不服务过客的地方被称为“客栈”（旅客服务设施）一般积重难返、残留20年。虽然此前并不迫切，但要设立恒常制度，以改名为宜。--— Gohan 2024年2月13日 (二) 08:16 (UTC)
- “意见征求”？台湾及大陆等地都有在用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月13日 (二) 08:27 (UTC)
- 感觉“征求意见”更顺口，大量文书标题使用，也有栏目使用[1]。“意见征集”[2]等也可以，征集更像非定向。主名称不确定，但都可以作为别名。--YFdyh000（留言） 2024年2月13日 (二) 09:02 (UTC)
- 可以在正文中使用，如“评论请求是维基百科社群征求意见的一种手段”之类。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月13日 (二) 14:31 (UTC)
- 不反对。--— Gohan 2024年2月14日 (三) 04:35 (UTC)
- 感觉“征求意见”更顺口，大量文书标题使用，也有栏目使用[1]。“意见征集”[2]等也可以，征集更像非定向。主名称不确定，但都可以作为别名。--YFdyh000（留言） 2024年2月13日 (二) 09:02 (UTC)
- 既然系统取名自RFC备忘录，那么翻译也最好参考该备忘录。该条目来源1提供了数个翻译选择，其中就有请求评论。如此，既然“请求评论”本身足够准确地说明了系统的功用，且有来源支持这个翻译方法，我不认为有改变目前名称的需要。最少也不像客栈那样，不是互助也不是客栈。--路西法人 2024年2月13日 (二) 09:01 (UTC)
- 该备忘录纸面上有中文名称吗？在来源1中也有出现“意见征求”。--— Gohan 2024年2月14日 (三) 04:45 (UTC)
- 看似没有中文版。既然目前翻译正确也没歧义，那么自然没需要改。--路西法人 2024年2月14日 (三) 04:51 (UTC)
- 粗劣翻译尚且可被快速删除，翻译腔太重、太不地道的译词自然是缺陷，正如每每在对话页看见“回馈请求”都令人水土不服、望而却步，从未点过相关连结。--— Gohan 2024年2月18日 (日) 06:04 (UTC)
- 看似没有中文版。既然目前翻译正确也没歧义，那么自然没需要改。--路西法人 2024年2月14日 (三) 04:51 (UTC)
- 该备忘录纸面上有中文名称吗？在来源1中也有出现“意见征求”。--— Gohan 2024年2月14日 (三) 04:45 (UTC)
- 互助客栈名称是历史遗留，求助等版块是互助的，不感觉是什么问题。没有将争论等完全分流是管理问题。--YFdyh000（留言） 2024年2月13日 (二) 09:04 (UTC)
- “意见征求”？台湾及大陆等地都有在用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月13日 (二) 08:27 (UTC)
- 大字通告应该明确什么“应该”在此讨论，什么“可以”请求评论。建议改成：由于客栈板过长导致载入及储存过慢等问题，用户可以改用请求评论系统请求更广泛意见；但关于现有方针指引的不涉及修订的探讨则应在此发文。影响多条方针的修订案建议创建新的请求评论子页面讨论。
- 另外，这个修订案相当于引入了请求评论机制，所以建议稍后根据实际进一步修订WP:RFC和WP:DR。--落花有意12138 2024年2月13日 (二) 11:57 (UTC)
- 可。--路西法人 2024年2月13日 (二) 12:22 (UTC)
- 个人认为应该确立实施细节（及操作方法）才正式引流，不然编者被引流去了也不知道怎么做。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月13日 (二) 14:31 (UTC)
- WP:RFC本来就有操作指南，这一点从来就不是问题；落花有意建议的调整仅是改了“应”“可”等优先次序，全部都不是绝对性用词，也只是强烈建议、没做到时可作提醒的做法，实施细节基本已定。--路西法人 2024年2月14日 (三) 00:01 (UTC)
- 对仅部分编辑同意或者提案者只挑选认同意见后就强行推进提案的做法感到诧异，我依然保持认为应该保留客栈简易的提案讨论方式，RFC用于预期需要长期或详细讨论的提案；如果希望无论大小，提案都应该用RFC解决的话，应该保留在客栈上带出简易的讨论链接指引来引导编辑前往参与讨论。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月14日 (三) 02:16 (UTC)
- 后者“提供连结导向”本来就在上方我与Ericliu的辩论中已指出是取代客栈二板块后会做的事情；阁下持续未能就观点提出推论和理据，却迳称我挑选意见、强行推行。对于阁下没读讨论就发言、不就自己观点提出理据而强行要他人接受您的观点等不负责任的讨论操守感到诧异。--路西法人 2024年2月14日 (三) 03:46 (UTC)
- 目前他应该是接受了折衷意见，只打算要在互助客栈页面置顶说明而已（吧）。希望不是我眼花了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月14日 (三) 14:39 (UTC)
- 我上次查阅的时候还有若干未本地化的内容，既然已经清理完毕，就没什么问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月14日 (三) 14:42 (UTC)
- 对仅部分编辑同意或者提案者只挑选认同意见后就强行推进提案的做法感到诧异，我依然保持认为应该保留客栈简易的提案讨论方式，RFC用于预期需要长期或详细讨论的提案；如果希望无论大小，提案都应该用RFC解决的话，应该保留在客栈上带出简易的讨论链接指引来引导编辑前往参与讨论。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月14日 (三) 02:16 (UTC)
- WP:RFC本来就有操作指南，这一点从来就不是问题；落花有意建议的调整仅是改了“应”“可”等优先次序，全部都不是绝对性用词，也只是强烈建议、没做到时可作提醒的做法，实施细节基本已定。--路西法人 2024年2月14日 (三) 00:01 (UTC)
已执行折衷方案。望社群能学会“对的地方做对的事”。--路西法人 2024年2月16日 (五) 00:56 (UTC)
- @Ericliu1912：请协助复检执行效果是否符合阁下现阶段期望。--路西法人 2024年2月16日 (五) 02:52 (UTC)
- 本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
- WP:RFCST中“
部分讨论分类的意义
”是不是写错了？ - 一个新手如要针对一个串联特定主题各条目的模板的内容问题，会（倾向于）选择、以及应当选择现有的“条目主题 ”下属类别抑或是“维基百科技术议题与模板”类别？