维基百科讨论:共识

共識建立的遞進步驟

推行RFC後，我發現很多人沒理會非強制性的提示，導致WP:VPD持續過長。我提議調整方針，明確共識建立的遞進步驟，確保各討論頁獲得善用。--路西法人 2024年4月8日 (一) 09:58 (UTC)

1. 所有討論均須先在內容頁面的對應討論頁發起。在討論頁發起討論時，應發送通知（@提及或用戶討論頁通告）邀請近期編輯有關條目／主題的用戶參與討論。（防止連@都沒嘗試@就說沒人參與討論）
   若影響內容涉及多個條目：
   1. 有單一主題條目者（如此討論）：在主題條目之對應討論頁發起討論；
   2. 有多個主題條目者（如此討論）：擇閱讀次數最多的條目的對應討論頁發起討論，並在其他受影響條目的對應討論頁發送討論通告（例子）。
   3. 無主題條目者：見第3點
2. 在以下三種情況下使用意見徵求系統邀請更廣泛意見：
   1. 影響10個以上條目的內容（此情況亦可考慮發送類此這樣的通告至VPD徵求更廣泛的意見）
   2. 經其他用戶參與討論但無法達成共識而需要徵求更廣泛意見
   3. 經通知後仍無人參與討論，需要徵求意見
3. 在影響極為廣泛（10個條目以上）而無主題條目者，則可在互助客棧條目探討板發起討論。互助客棧條目探討板可以使用RFC模板以觸發WP:FRS的自動通知系統。

理論上，這應該更普及推廣至所有討論。目前觀察到WP:VPP的社群站務討論方面相對剋制，使用VPP和RFC的時機相對合適；WP:VPD和RFC條目主題的部分則較少被善用，因此先行提出規範條目相關的討論。--路西法人 2024年4月8日 (一) 06:49 (UTC)

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

(～)補充主要目標：防止過度依賴互助客棧，連討論都還沒嘗試討論就發出來客棧徵求第三方意見，這是不好的習慣。--路西法人 2024年4月8日 (一) 06:51 (UTC)

(＋)支持：不過 2.a 預期是會在其中最多閱讀次數的條目討論頁提出並使用 RFC 沒錯吧？--冥王歐西里斯（留言） 2024年4月8日 (一) 07:52 (UTC)

是，這個情況下互助客棧亦可，但能在條目討論頁的情況下當然是善用條目討論頁較好。--路西法人 2024年4月8日 (一) 09:58 (UTC)

另外@對RFC有比較大意見的Ericliu1912參與此討論。--路西法人 2024年4月8日 (一) 09:59 (UTC)

這難道不是代表大家認為互助客棧討論比較有效或能見度較高，或可謂徵求意見制度在本地尚未成熟之象徵？不能因此反過來認為是社群「不理會提示」的錯，然後決定強迫先走一次徵求意見流程吧。我認為這很明顯是互助客棧這種集中討論系統在實踐上確為本地社群所好，而與討論頁相分工產生的自然現象，縱使有意願要去調整也好，亦不當純粹以所謂「過度依賴」視之，甚至企圖（用甚強硬之措施）去「矯正」；尤以「確保各討論頁獲得善用」為理由削減互助客棧職能實屬本末倒置，如此貿然推動是會實際損害百科全書討論運作的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月8日 (一) 10:41 (UTC)

自互助客棧條目探討板設立之初，就有任何條目或模板的交流應考慮先在其討論頁發表，而若無人加入討論才可在此發起。的要求，此提案只是將此要求付諸實行且以RFC配合。閣下將實行客棧長年置頂的要求且提供輔助工具配合以更佳實行如其上方留言般稱為「本末倒置」；那摒棄自設立以來就存在的要求、阻礙以工具實踐長久以來的要求，不是真正文字上的「本末倒置」嗎？「削減互助客棧職能」？什麼討論都直接送去客棧本來就不是互助客棧條目探討板的職能，自始至今皆是如此。--路西法人 2024年4月9日 (二) 04:30 (UTC)

如果你打算以「應考慮」來反打我說的話，我可以先補一句：我現在就是提案將原先的「應考慮」改為「須」。現在我當然無法強制他人遵守，但正是自始就有這個建議做法而無人遵循，導致產生更多問題，才需要改成強制性。本來就存在的建議做法被閣下打成「本末倒置」，差點以為建議做法是寫來當花瓶的。--路西法人 2024年4月9日 (二) 04:37 (UTC)

這是否代表所謂「建議做法」確實不符合本站實際？又是否有因應現階段共識調整之需要？或可一併商榷。說不定這還真是需要「拿走」的「花瓶」。無論如何，提案限定「所有討論均須先在內容頁面的對應討論頁發起」，則顯屬矯枉過正。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:58 (UTC)

現在非常顯然的結果就是無視這個「建議做法」會造成討論版面過長的問題，較大程度實現RFC的站務討論（相對於VPP）則是解決了這個問題，顯然是完全符合實際的建議做法。「矯枉過正」沒有有效論證如何「過正」。--路西法人 2024年4月9日 (二) 08:40 (UTC)

可以建議、甚至積極推動，但強迫實行，過度箝制編者討論自由，則是另一回事。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 08:35 (UTC)

另外我記得當初提案人推行徵求意見制度的一個理由是聲稱「回歸討論頁後用戶可簡單通過監視頁面（或請求評論列表頁面）即能達到追蹤討論的效果。」既然此實足矣，我認為縱使要加強提倡在條目討論頁發起討論，也不必以通知特定一群人參與討論為必要條件（當然若有需要仍可額外提及）。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月8日 (一) 10:59 (UTC)

通知參與討論是禮儀、是推薦做法，防止有人說「你沒通知我，所以這個討論沒能得到我意見」。如近期寫進方針的WP:RULES#方針及指引的用詞：「應」提醒不代表不能不提醒，但也不代表想不做就不做。發送通知是「應」，先在內容頁面的對應討論頁發起才是「須」。請讀清楚提案才發言。--路西法人 2024年4月9日 (二) 04:34 (UTC)

（涉及多於一個制度頁面，改在互助客棧擴大討論。）—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月8日 (一) 10:55 (UTC)

僅涉及修訂共識方針，RFC、互助客棧沒有要修訂的事情，不存在「涉及多個制度」。已移回。--路西法人 2024年4月8日 (一) 23:16 (UTC)

實際上還牽涉互助客棧調整、徵求意見制度推廣，不只是改方針條文的事情。再說一次，不要揪著字眼不放。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:31 (UTC)

RFC已有與客棧討論相等效力，請停止擾亂性移動討論。相等效力的討論不存在「擴大」討論。--路西法人 2024年4月9日 (二) 08:10 (UTC)

不知為何堅持要使用徵求意見制度，還指責我「擾亂」。名義上效力相等，實際上曝光度大有差異。此頁面及相關所有徵求意見頁面，總瀏覽量僅百餘次；相關提案牽涉互助客棧一區運作，本事關重大，為了社群公益，移動至互助客棧擴大討論，有何不可？何況閣下自己也曾莫名移動互助客棧討論去徵求意見，請問是不是在「擾亂性移動討論」？以一句「擾亂性移動討論」塘塞了事，毫無立足點可言。若往後可以此等理由回退條目探討區類似編輯，則又可想而知將造成何等災難。「善用制度」跟「擾亂討論」之別，豈得由爾一人獨斷？迴護一種制度，應不至於如此。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 08:27 (UTC)

呵呵。客棧討論移動去RFC是基於客棧設立以來的建議做法，並作分流之用，這無論是原有還是最新共識的置頂都支持「在原有討論頁發起討論」的建議做法，RFC只是輔助；況且光是「客棧版面已經過長」已經是萬分合理分拆討論的例句。反倒是從來沒有方針或共識支持「涉及多於一個制度」就應該移動至客棧「擴大討論」的情況，你甚至連給在這裏繼續討論的機會都沒給過，怎麽就成「擴大」討論了？--路西法人 2024年4月9日 (二) 08:37 (UTC)

如果你覺得我有bias，在這裡不如公開問問社群，此等重要的話題，是否得在互助客棧討論？還是在此相對狹隘之處了結即可？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 08:32 (UTC)

(－)反对：基本上將話題發起門檻調高到涉及十篇條目以上，實際上就等於架空互助客棧；況且涉及多個主題條目者的討論（強制）發起方法也實在過於繁瑣，恐反不利於促進使用者發起討論。在徵求意見制度運作約一個月來實績不彰（或至少不如預期，否則本不會有此話題）的情況下，恕沒有理由在現階段支持此等冒進之提案。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月8日 (一) 11:02 (UTC)

不過，既然此處言明是「漸進步驟」，那應該不禁止其他提案吧。我自己提一個較為「漸進」的建議，就是可以先從僅涉及單一條目者做起——就這種話題強制先在討論頁發起討論（同時可以自由選擇是否利用徵求意見制度），一定時間後認為參與度不夠，再移動到客棧來——看看這樣成效如何。據我觀察，互助客棧條目探討區有一大半話題都涉及一篇條目而已，所以若此議行之有效，也足以相當程度緩解互助客棧討論流量。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月8日 (一) 11:20 (UTC)

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

現在不是RFC被濫用，而是VPD被濫用。先搞清楚狀況才來留言。--路西法人 2024年4月8日 (一) 23:06 (UTC)

條目探討區本來就是用以探討條目（及模板等），而不探討相關話題者都會予以移動，不知道哪裡存在所謂「濫用」了。請不要自己想像一個平行版本的互助客棧出來。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:29 (UTC)

條目探討去本來是用來討論在討論頁發起過但不夠人關注的討論，這是從設立至今都存在在置頂的「原意」，未經討論頁充分討論、未善用現在提供的工具去試圖在討論頁充分討論就跑去客棧發起議題，這顯然是濫用。「把所有討論都塞在客棧」才是與長久以來互助客棧設立的「本意」平行時空的想法。--路西法人 2024年4月9日 (二) 08:47 (UTC)

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

目前沒有被濫用不代表永遠不會被濫用。既然可以預想到RFC跟客棧同樣存在「討論還沒開始就烙人」的潛在問題，而客棧明顯已存在這個問題，RFC也同步實施對應限制不會有壞。當初客棧也沒預想到現在的人會有這個問題，結果也是被濫用了。--路西法人 2024年4月9日 (二) 13:43 (UTC)

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

@0xDeadbeef：實際上經過觀察，徵求意見現階段在本站最有效的運用，應該是掛在那些本來就在討論頁發起的話題上面增加流量，而不是反過來把討論到一半的互助客棧話題移回某個頁面去減少流量。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:54 (UTC)

這提案本來就是提倡討論本身從討論頁發起，而不再在客棧發起，是閣下不知為何堅持理解為移回，這是兩碼子的事情。移回是因為配套已容許，在客棧頁面過長時將討論拆回討論頁徵求意見；這個提案是在要求討論本身就從討論頁發起，在不夠人時不再「重新在客棧發起討論，直接在討論頁開始徵求更多意見」。兩者的觀點是相近而不相同。--路西法人 2024年4月9日 (二) 09:28 (UTC)

徵求意見制度運作約一個月來實績不彰乃是我從閣下口中聽來最可笑和可悲的言論。現在不是徵求意見制度「實績不彰」，而是太多人根本連有這個系統也不知道，也不甚瞭解討論頁面過長的後果。閣下屢次以各種小手段阻止提高徵求意見制度的可見度，然後跑過來說「實績不彰」、「不如預期」，這是「在你的負面干預後，再以結果論評斷制度效益」的最荒謬做法。--路西法人 2024年4月8日 (一) 23:15 (UTC)

實際上就等於架空互助客棧又怎麽了？客棧是用來「互助」而非「互煮」、閒聊而非正規議事，該煮的本來就應該在適合的討論頁煮，閣下無視互助客棧設立本意就以「架空互助客棧」來反對此案，恕難以接納為有效論點。--路西法人 2024年4月8日 (一) 23:32 (UTC)

涉及多個條目的討論再怎樣也就是選擇一個看起來多人會關注（不需要真的去查證是否最多人閱讀的條目）的主要主題討論頁，然後向其他討論頁和編者發送通知。前面的步驟是新改的，後面的步驟理論上不論是提到客棧還是討論頁討論都是應該要做的。這裏並不存在「比原先制度更為繁瑣」的步驟。--路西法人 2024年4月8日 (一) 23:32 (UTC)

本站不是拿來實驗制度的地方。而且真讓你實驗過了，甚至在客棧放了個橫幅置頂，也沒見有什麼作用。條目探討區頁面瀏覽量以萬計，現在所有徵求意見話題加起來大概還不到一千，極不利於促進有效討論。配套措施也是七零八落，在這種情況下還要繼續拋一堆要求出來折磨編者？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:36 (UTC)

當然沒用啊。閣下為闡述個人觀點，屢次阻礙置頂橫幅設置，將置頂文字埋藏在其他文字內；況且是人都知道多數人是不讀置頂的。在存在較深入瞭解RFC的方針相關討論，顯然能非常有效地使用RFC；但條目討論方面根本沒給予RFC有跟VPD公平競爭的機會，就結果論說RFC沒作用，這根本就是在循環論證。--路西法人 2024年4月9日 (二) 08:45 (UTC)

聲稱本人為「闡釋觀點」調整客棧頂欄視覺排版，令人遺憾。你知道置頂橫幅蓋在上面有多醜嗎？何況我（一）沒刪掉文字本身，還梳理語句、加了幾段粗體凸顯重點，（二）未阻止在客棧失能（過於龐大）時重新加強橫幅提醒（雖然很醜）。若你覺得原本橫幅掛兩週不夠，要學RELIST搞「永久試行」，多掛幾個月也行啊（至於別人觀感那是另一回事）；真覺得還不夠，現在給所有人發通知說此制度已經啟用了，以後甚至定期通知，我也沒意見。我想社群都樂見徵求意見制度得到善用。但掐住整個條目探討區及編者現行討論習慣以為交換，那就過了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 08:52 (UTC)

醜怎麼了？我不是第一天說你拿你的個人美學來評斷「美觀」、「合理」這個問題，「醜」是主觀的，「因為醜就得改成沒人看見的款式」更是完全說不上理。如果你覺得醜，那更是完全符合引起注意的目標。單純因為你覺得醜而縮小，反而導致引起關注的意義全無，這不是為闡述個人觀點而作出損害改善客棧過長這個目標的行為是什麼？--路西法人 2024年4月9日 (二) 09:11 (UTC)

討論制度核心是實用，社群若認為互助客棧好用，自然會用客棧，若徵求意見好用，自然會用徵求意見。實際上我也看到一些本來在討論頁發起的話題，利用徵求意見制度以後，參與度有一些提高。但這完全不應該是反過來消滅互助客棧的理由。你現在弄這一套冠冕堂皇的複雜制度出來，當然大家都只能去討論頁用徵求意見，使用率百分之九十，那不就好啦！但這究竟能凸顯什麼？只是因為編者被迫走官僚程序罷了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:40 (UTC)

自己對提案理解錯誤就來咬我。我這裏提出的是要求討論先在討論頁發起並充分試圖邀請討論，重點在於討論頁本身先有充分討論再徵求更廣泛意見，實質也限制了不要一來就想着RFC，卻被你理解成「消滅互助客棧」。客棧本來就不是設計來這樣用的，被濫用的就自然應該被阻止。--路西法人 2024年4月9日 (二) 08:54 (UTC)

至於所謂「客棧是用來『互助』而非『互煮』、閒聊而非正規議事」這種無視本站二十餘年來實況的望文生義觀點，竟然會出現在討論中，我想任何實際參與過互助客棧方針或條目探討的編者都不用花費唇舌駁斥就能看出為了推動一個制度能有多離譜了。現在整個客棧除了消息區或其他區偶爾來點休閒話題，有誰敢閒聊或認為客棧本來是閒聊之處的？另外，按照現在這提案，我要尋求其他編者在某篇或某幾篇條目相關話題的幫助，得特地湊齊超過十篇條目才能拿來客棧「互助」，要互助還這麼高門檻，這豈不可笑？如此輕視帶過「架空互助客棧」對本站討論制度的立即危害（「又怎麼了？」），也不會幫助徵求意見制度確立在本站獨一無二的作用。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:45 (UTC)

「閒聊」意味的是非正式的討論（即初步討論、初步想法、問問題等）而不是離題、「休閒」討論。如果我這叫「為了推動一個制度」的離譜行為，我更應該將閣下「為了推動無視客棧條目探討板設立以來的建議做法，而用盡的手段阻攔配合設立原意和建議做法的配套」稱為更離譜的論點。--路西法人 2024年4月9日 (二) 08:58 (UTC)

況且，「架空互助客棧」本來就不存在任何「立即危害」，閣下從頭到尾都只是在幻想沒了客棧就不會再有活躍參與討論的情形；反而完全無視互助客棧現在無視原定建議做法造成如討論重複移動造成編輯歷史損失、引用編輯差異討論難以查找最終的完整討論、重複存檔至多個位置導致討論混亂（難以阻止進一步留言而產生平行時空的討論）、載入及儲存困難等多種已經完全體現的危害。還你一句，如此輕視不實踐互助客棧本來就存在的建議做法導致互助客棧各種問題對本站討論制度已經造成的危害，也不會幫助論證客棧在本站有獨一無二、不可取代的作用。--路西法人 2024年4月9日 (二) 09:02 (UTC)

「而是太多人根本連有這個系統也不知道，也不甚瞭解討論頁面過長的後果。」然後結論是要強制大家只能用這個系統發起多數討論，推翻互助客棧條目探討區？這又是什麼辦法？羅馬不是一天造成的，設想正式引進制度一個月就能廣為人知、獲得妥善運用，甚至取代固有討論體制，本來也根本是不合理的。所以我說此案極為冒進，殆無疑問。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 08:15 (UTC)

目前制度存在問題，但又不停用目前制度並給新制度任何機會，這叫故步自封。--路西法人 2024年4月9日 (二) 09:04 (UTC)

我不知道閣下憑什麼指責我「用小手段」、「負面干預」。本人未曾阻撓徵求意見制度本身之推行，對於技術部署、制度命名等事宜樂觀其成，且過去一個月來，不僅親自參與使用此制度之眾多討論，與編者多打交道，甚至多次嘗試加強其作用，例如向Kanashimi君提議置topic list，可惜未成等。參酌近月實際討論運作情況，我認為徵求意見制度現階段未成熟到足以替代客棧既有討論作用（這不單純是推廣的問題，而是徵求意見制度本身存在局限），但同時也認為有發展潛力，故提出先在涉及單一條目者實行的折衷提案。但我想閣下這等高傲的態度，連移動討論都能給人家扣擾亂帽子，大概是別想討論了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 08:48 (UTC)

閣下屢次阻撓我掛橫幅、縮小文字甚至將文字縮進顯然沒人會去認真看的置頂文內，這不叫「負面干預」叫什麼？閣下連一個新制度更好運行、排除舊制度中各項問題的機會都不給，在目前社群很多人明顯不知道可以用新系統的狀況下，就直接稱那個新制度是「實績不彰」，這才叫高傲吧。--路西法人 2024年4月9日 (二) 09:06 (UTC)

我就想問一個問題：你們這樣把討論串不斷移來移去合適嗎？Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 00:27 (UTC)

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

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

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

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

我是願意寫，但力氣暫無。暑假吧。--路西法人 2024年4月9日 (二) 04:38 (UTC)

這倒是可以，雖然在目前本站的專題環境下不確定會發生什麼事就是了。--冥王歐西里斯（留言） 2024年4月9日 (二) 09:06 (UTC)

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

無法實現RFC的好處，只保留了社群繼續使用VPD的壞處，這不是意願不意願的問題。現在就是VPD的做法很不好，有壞就得修，而不是誰選擇怎樣的問題。Ericliu所指基本上將話題發起門檻調高到涉及十篇條目以上，實際上就等於架空互助客棧，我完全可以原話還給他：將客棧開話題的門檻訂為0，實際上就就是在架空條目討論頁的作用；甚至是違背了先行與關聯編者溝通，實在無果才徵求社群廣泛意見的基本溝通步驟。說到底，就是養成不願意吵的懶人試圖把話題拋出去蓋過其他當事用戶意見的不良手法。--路西法人 2024年4月9日 (二) 04:26 (UTC)

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

你曉得什麼叫「推銷」嗎？我推行的是改制，是摒棄目前VPD的不良討論習慣，而不是「跟VPD爭寵」。--路西法人 2024年4月9日 (二) 06:30 (UTC)

有什麼「不良討論習慣」？只要能促進討論，那就是有效制度。徵求意見有他之所以有效之處，但互助客棧本來也有，兩者不屬於替代關係。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:54 (UTC)

VPD過長要找討論議題很煩不是趕客？載入、儲存緩慢不是趕客？不通知近期討論用戶不是趕客？不嘗試先跟近期參與／爭議用戶討論就去徵求他人意見有尊重對方？無法通過監視列表關注特定主題討論不是無助關注討論？這些問題我都提過十萬遍，既然你說得出只要能促進討論，那就是有效制度，為什麼就不懂得轉換思考，有一大堆問題的是不良討論習慣、無助促進討論、是無效制度？你在討論中，往往只有downplay VPD造成的問題而不需改善「維持現狀」「給予選擇」，而RFC存在的問題卻往往被提出後統統要儘可能改善解決才能「更有效推行」。--路西法人 2024年4月9日 (二) 10:00 (UTC)

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

「客棧」還是「village pump」還是「酒吧」都顯而易見不是用來談正事的地方，充其量就是非正式的討論、聊天。以「雅座」類比RFC完全不合適，RFC本來就不是用來「分流」用，而是輔助在原先設計的正確場所討論時邀請更多人參與的工具。每個條目都像是一個公司的部門，討論正事在會議室（條目討論頁），在酒吧、客棧只應該是閒聊。RFC只不過是將開會這件事公告在公司內聯網裡，FRS是發郵件邀請其他人參與會議，「雅座」根本就不是RFC的主要用途。你說出RFC是「雅座」的時候你已經不適合參與此討論，因為你連客棧、RFC的主要目的是什麼都還沒搞清楚。--路西法人 2024年4月9日 (二) 06:29 (UTC)

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

正是因為這些討論都影響不同範圍，所以他們應該在適當的場所去討論，而不是堆在同一處討論。不會一國政府然後全部共用同一個辦公室和會議室吧。--路西法人 2024年4月9日 (二) 06:32 (UTC)

集中討論也不會讓某話題「影響」到其他範圍去，此言差矣。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 07:54 (UTC)

會。版面過長導致載入、儲存困難就是「影響」其他話題的最佳例證。--路西法人 2024年4月9日 (二) 08:40 (UTC)

很簡單，索性像英維一樣，廢除大型討論頁，以方針指引及模版為主導（大前提是所有方針指引及模版需要正就讀學前班的小孩也能理解），剩下的在條目討論頁作輕微討論，反正大型討論頁來來去去也是那十多個只會背書的編輯者踴躍發言，相關話題的編輯者也不會在大型討論頁發言。--唔好阻住我愛國（留言） 2024年4月9日 (二) 06:13 (UTC)

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

換句話說，真正應重點討論的是方針區，而非條目客棧。而且每一條目類別需要有統一的成文格式手冊，規定行文段落應如何分佈，事件收錄準則及來源要求，但中維只有極少數類別才有格式手冊。以閣下監察的港鐵相關條目來說例子（礙於身份而不能編輯），現時有一位D君經常阻嚇新編輯者編輯，他經常回退相片及重大事故，但又拿不出任何方針……格式手冊證明其觀點，因而製造編輯爭議。所以，在未有完善的方針……格式手冊之前，大型討論頁應保留，而供「集思廣益」。--唔好阻住我愛國（留言） 2024年4月9日 (二) 06:45 (UTC)

甚至乎可以瘋狂起來，每一經巡查的新條目討論頁都由巡查員掛上適用的大類別或總條目。可讓大幅增加巡查員的工作量。例如九巴1A線可被歸類為九巴、香港巴士、中國巴士、巴士的討論區，而編輯者於九巴1A線的討論會自動同步至九巴、香港巴士、中國巴士、巴士的討論區，WP:DYK正實現這項技術。--唔好阻住我愛國（留言） 2024年4月9日 (二) 06:54 (UTC)

你完全離題了，這裏並非在討論此問題。我並不支持你最新兩則留言的任何意見。--路西法人 2024年4月9日 (二) 07:16 (UTC)

不啊，我並沒有離題，你提出的方案根本沒有配套（方針指引模版及格式手冊）支持。在沒有配套（方針指引模版及格式手冊）支持下，你的方案很難成功。而且剛剛又有移動擾亂我評論，如果閣下的方案生效，我究竟要寫多少次相同的言論？--唔好阻住我愛國（留言） 2024年4月9日 (二) 07:30 (UTC)

我提出的全部也是方針…以至格式手冊及討論頁應如何運用才能達到閣下的期待，但你說離題，那我只可在沒有配套支持下提出(－)反对。--唔好阻住我愛國（留言） 2024年4月9日 (二) 07:39 (UTC)

方針指引模板跟格式手冊跟此討論完全無關，無關論點將視作共識方針下的無效論點。若閣下持續，將要求管理員實施禁制。--路西法人 2024年4月9日 (二) 08:12 (UTC)

@Ericliu1912：我沒力氣跟你吵下去，我唯一可以給的妥協就是「需要徵求更廣泛意見時，除了使用RFC外，也可以同時在客棧發送討論通知邀請其他社群成員參與討論」。無論怎樣，討論都不應該再移來移去造成一萬個問題；絕對不會接受讓討論在客棧重複展開，更不能接受為了貶低RFC的作用而開始無視甚至提議取走客棧頁頂長年存在且顯然可見有實際意義的建議做法，而繼續容許社群用戶過度依賴客棧而產生不良的討論習慣。--路西法人 2024年4月9日 (二) 09:18 (UTC)

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

持續、過份地尋求某個編輯目標十分擾民，應該避免。只有編者願意互相傾聽、回應和合作編寫一篇更好的條目，共識過程才可順利運作。如若編者拒絕任何共識而固執己見，無限期地發表冗長辯論以實現其目標，那麼他／她將會破壞掉共識過程。固執己見的人永遠不能解決問題，因為總會有比他／她更加固執的人出現；有社群支持的頁面本身才是這場長跑的贏家。

如果上面還是打算繼續如此的討論的話，倒不如不要討論了，我是真的不知道你們現在這樣做到底有何意義，這完全不是有效的討論。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 14:54 (UTC)

我已自有折衷提案，也有人支持；再不然，照彼案原樣試行一段時間（但必須有嚴格退場程序及檢驗方法，不能像RELIST一樣無限拖延不決）也罷，實際上方法多得是，只是提案人要不要討論的問題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月9日 (二) 15:20 (UTC)

我自己覺得LuciferianThomas定的這個“10個條目”門檻確實有點過高，而且定成這個數字的理據不明，用Shizhao的話來説就是“毫無依據的拍腦袋數字”，但凡有人嘗試解釋一下定成“10個條目”的背後理據，這裏也不至於這麽快演變成無效討論。其實我自己倒不是不支持把討論分流到RFC的做法，但就算如此强制性的規定真的通過了，也不見得有人會遵守，而且很有可能重蹈原版7DAYS的覆轍。

我本來也有個稍微偏LuciferianThomas方案的alternative的，與LuciferianThomas方案的具體差別大概如下：

• “所有討論均須先在內容頁面的對應討論頁發起”中的“均須”改為“應”，由强制性要求改為建議性要求，以避免一刀切所帶來的不必要問題，但我認為僅影響單一條目的與影響多個條目但有單一主題條目的都能適用强制性要求（如果社羣還是有疑慮的話，可以進一步收窄為僅影響單一條目的才能適用强制性要求）。
• 合併“有多個主題條目者”與“無主題條目者”兩種情況，容許討論發起者擁有一定的自由度選擇發起討論的地方。
• “10個條目”的門檻下調為“3個條目”，以避免用戶因規則而不得不在實際上不合適的地方發起討論。
• 容許任何用戶（包括發起討論的用戶）於第2條所提述的三個情況外，在其認為有必要的情況下使用RFC系統，以利徵求外部意見。
• VPD是否能使用RFC系統可能需要額外討論。

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

（話説回來，上面説的“條目”可能説是“頁面”比較合適，畢竟現在VPD討論的不止條目，還有模板、模組、分類之類的。）Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 16:50 (UTC)

為何是3個條目？個人認為1個討論影響3個條目這個要求太容易可以達成。--唔好阻住我愛國（留言） 2024年4月9日 (二) 16:16 (UTC)

「3個條目」確實是比較容易滿足的條件，但大部分VPD的討論都是“僅影響單一條目”或“影響多個條目但有單一主題條目”的情況，而這裏的「3個條目」限定的是“有多個主題條目”與“無主題條目”的情況（至於LuciferianThomas方案的「10個條目」則限定僅“無主題條目”的情況）。我認為只要能有效分流“僅影響單一條目”或“影響多個條目但有單一主題條目”的討論，VPD的積壓就能得到顯著舒緩。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月9日 (二) 16:35 (UTC)

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

我是不能接受你要把「須」改成「應」的。給了「應」，有些人還是不會遵守（客棧頁首掛了「任何條目或模板的交流應考慮先在其討論頁發表，而若無人加入討論才可在此發起」這麼多年，還是沒人理會）。條目討論基本上完全可以明確規範，量多就更板上釘釘不能被輕易扭曲，僅有在極為特例的情況下WP:IAR發起討論。

「10個條目」是一虛數，實際上我確信沒人會去數影響多少個條目，能輕易辨識有哪些條目需要修訂的基本上不會多於「10個條目」，多到要找或者整個專題、主題的情況下十有八九都已經大於10個條目需要修訂。

「3個條目」的達成條件過於容易，這裏針對的是主題條目可能有多個（如「殖民地」「英屬香港」）但需要修訂的內容涉及大量條目的情況）。

「多個主題條目」本來就有主題，即有辦法在條目討論頁甚或維基專題討論頁發起，那麼自然應該是在這些更適當的場合發起，而不是「自由選擇」（不是不顧客棧問題就選擇客棧叫做「自由」，正如散播謠言同樣不是言論自由的給予的權利）。不能接受能用條目討論頁而不先行使用的任何方案。更何況，不論是提在客棧還是擇一討論頁發起討論，仍是有義務去在各主題討論頁發送討論通知，既然要做的事情一樣，我沒看到「容許自由選擇」的需要。

雖然如@0xDeadbeef所說，應該避免在RFC還沒出現問題時WP:CREEP限制使用RFC，但主要問題在於這個提案的目標是讓社群成員學會逐步遞進擴展討論，而不是一來就依賴客棧或RFC來徵求外部意見；鼓勵先在編者之間解決的爭議，真的不成才向外徵求意見。我提出的三種情況基本囊括所有「必要」徵求廣泛意見的情形，沒人參與討論自然要外人來參與、無法達成共識自然要外人參與、影響廣泛也自然可直接徵求更廣泛意見。如果你有想到任何實際「必要」的情形，當然可以加進去，但「其認為必要」的條件過於空泛，以你維懶惰的討論態度只會什麼都說「我覺得必要」然後拋給RFC（當然，這裏說的是條目、模板等討論，方針修訂等討論要有效力仍是需要通過RFC)。--路西法人 2024年4月10日 (三) 00:08 (UTC)

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

一邊鬼打牆重複「架空」客棧，卻永遠不會回應我已經列明多次的客棧陋習。「架空」是指「憑空捏造，沒有事實根據」或「排擠而失權」，既然有事實根據去做，也並非因為排擠而是因為本身的失能而被排除，這顯然不符合「架空」的定義。任何「架空」客棧的論點都是顯然無效的。--路西法人 2024年4月10日 (三) 01:17 (UTC)

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

當長年置頂的建議做法不同意此般陋習，還能洗白成「慣例」?「大家都沒遵守建議做法所以就不遵守建議做法就是合理」這不是明顯的WP:RTRL？豈不是站內管理員失能、不執行社群長久以來的建議做法而造成的陋習？「觀感」跟事實上存在的「陋習」是顯然不能相提並論的。閣下拒絕回應這些問題為什麼存在，不去想想該如何處理這等明顯存在的問題，反過來去說這是一種「慣例」，甚至是無視長久以來的建議做法。既然閣下拒絕回應問題所在和如何解決，而統統downplay成「慣例」去洗白此等問題，那麼我自然不需要理會你的意見。--路西法人 2024年4月10日 (三) 10:12 (UTC)

回應：

• 能不能先考慮僅強制分流「僅影響單一頁面」與「影響多個頁面但有單一主題頁面」的討論？這兩種情況的爭議性應該不大，而且「僅影響單一頁面」的討論顯然是佔多數的。
• 「『10個條目』是一虛數」一方面正好呼應了我上面所說的「毫無依據的拍腦袋數字」（這個虛數怎麼不定成100、1000或10000？），另一方面設定為虛數也不利於社羣遵從（「回退不過三」的「三」可不是虛數）。
• 「只會什麼都說『我覺得必要』然後拋給RFC」倒不一定，（雖然這種情況可能會落入立心不良的範疇）如果有人想刻意讓參與討論的人數較少（以免人多嘴雜）的話，他不會應用RFC機制。
• 影響高風險主題下的頁面的討論如擬對頁面作出非微小修訂，應該從一開始就應用RFC機制。
• 我認為社羣成員的顧慮有必要獲正視，否則我不認為這裏能進行任何有效的討論。

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

• 這是必然的，但顯然不足夠。
• 「『10個條目』是一虛數」雖說是一虛數，但我顯然也有解釋為什麼是10，請自行重新閱讀我上方的留言。10作為我觀察條目、主題組成的基準數，只是在該基礎上取了個齊頭數，你可以說為什麼不是11、12，就是因為方便在情況下參考。同時只影響4、5、6個條目的多主題討論比比皆是，這些顯然不至於需要一來就擴大討論。
• 請論述「不一定」。我說得很清楚，顯然現在客棧就是存在這個狀況（如防止連@都沒嘗試@就說沒人參與討論）你說為了避免人多嘴雜而不用RFC，也是沒有問題，能local解決就local解決。
• 這個可以考慮加，但我覺得並非「必要」。這個真的就「可」使用就好。
• 社群成員的顧慮必須正視這是沒錯，雖然仍有部分論點缺失了論證，但你在此討論中確實有給予了非常有效的想法；而不是某些用戶空談「沒用」卻不詳細研究為啥沒人用、一來就叫「冒進」、持續拒絕甚至迴避討論客棧的陋習，說的話沒有半點方針指引原則論據。

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

• 我的意思是可以一步一步來，首先強制分流「僅影響單一頁面」與「影響多個頁面但有單一主題頁面」的討論，在此以後再討論其他討論是否需要強制分流。我相信這總比直接推動一刀切強制分流，然後因遭遇社羣較大阻力而無法推行來得好。
• （我一時看漏了）
• 客棧與RFC機制的生態存在一定差別，可能在強制分流部分討論後你說的情況就已經不會那麼嚴重。
• （這點可以交由社羣進一步討論）
• 這種情況或許代表了社羣中的一種非小眾意見，不正視這種意見背後的因由不見得能促進有效討論。

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

• 回3：既然不會阻礙在正常合理的情況下使用RFC，而在三（四）種表列情況外真的存在其他有必要徵求更廣泛意見的情況下當然可以直接使用。況且我原先提案也沒說過「只」有這三種情況使用RFC，更多是「推薦在這三種情況下使用RFC」，其他沒說不代表不能，但我覺得絕大多數需要徵求更廣泛意見的情形已經由表列範圍概括。
• 回5：當初苗君解任案也存在看似是「非小眾」的意見，但不代表這些意見必然合理，最終截停解任案也是基於這些意見的不成立。無方針指引等合理理據論據的自然就不是有效意見。人多不代表對。「架空客棧」這些言論真的是毫無論據支撐，尤其當客棧本身是因被濫用而形成依賴的背景下，說得好像沒客棧就什麼都做不了那樣。背後沒有因由的意見不見得能促進有效討論。

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

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

「慣性」可以是陋習。兩者從來不衝突。慣性的陋習還是要改。客棧既然長期出現問題，那就應該執行建議做法去解決這些問題；在VPP可以很清楚看到執行建議做法後是完全能解決上述問題的。一直堅持守着問題多多的舊制度，卻叫囂他人「架空」問題百出的客棧，我怎不能反過來說你這個觀點是不滿於客棧被「架空」而阻止更善用社群資源的提案呢？--路西法人 2024年4月10日 (三) 10:15 (UTC)

啊還有，這個提案中RFC本來是可有可無之事，我毫不介意將RFC從提案中移除，因為我主張的是將討論回歸討論頁而非堆在客棧；就算沒有RFC系統，我提出的方案仍完完全全能達到我預想中的目的，只是RFC能進一步自動化協助廣泛徵集意見之餘，不再需要移動討論而已。所有基於「因為我想推行RFC所以才『架空』客棧」這等言論是完全站不住腳，甚至根本就不是我的目的。沒有RFC也不代表可以這樣濫用客棧。--路西法人 2024年4月10日 (三) 10:37 (UTC)

Eric和Cwek二位屢屢因為「用到RFC」就來反對，不去正視提案本身提出的原因何在。如果RFC是個人，兩位的發言就顯然完全是對人不對事的討論態度。我不是因為「客棧是客棧所以我不同意」，集中討論區本有其適合用到的場合，但顯然現在的客棧已經完全越界，攬上了所有「未解決的爭議」。「集中討論」的最大作用是將有重大關聯的議題集合在一起討論，避免鬧雙胞，顯然客棧將所有毫無關聯的議題集合在一起不是「集中討論」而是「堆在一起討論」。--路西法人 2024年4月10日 (三) 10:42 (UTC)

方案根本沒有解決問題。問題是互助客棧的內容過長，導致開啟頁面的時間太長。那應該是倒過來，將長討論引到其他頁面討論。那些影響條目小，影響範圍小的主題，很多時候討論也短，短討論根本對於頁面長度沒啥大影響。而且，雖我過去都有批評互助客棧內容長，加載慢的問題；但實際來看這根本不算多大問題。如果提出來的方案得不到社群支持，使用，逆社群之習慣，只怕是得不償失。Ghren🐦🕒 2024年4月10日 (三) 07:32 (UTC)

閣下究竟是否有真的去閱讀過提案內容？我提出的方案從頭到尾跟每一則討論大小無關，而是將VPD留給沒有合適地方提出的話題。「影響多個條目」不等於討論必定長，反而像這個只影響兩個條目內容的討論卻遠比多數討論要長。將我方案中交到客棧的討論說成「長討論」是false correlation。

我的方案中，僅有「影響廣泛且無主題條目」者提交VPD討論，這個是預期上較少會出現的情況（多數都會存在一個主題條目，或者可以找一個受影響條目的討論頁發起討論）；這從根源上已經避免了堆積討論的問題，在基本上多數議題回歸條目或專題討論頁討論之時，何來「無法解決過長的問題」？

討論重點在於討論在其他討論頁發起，而不是「長了才去引流」；前者是要從根源解決問題，後者則是治標不治本。我不清楚閣下說「將長討論引到其他頁面討論」是將RFC理解成「分拆討論」的作用還是怎樣，但我可以很清楚告訴你，RFC不是用來「分拆討論」而是輔助本身就在討論頁發起的討論引起注意的工具。

況且提案不是只解決「過長」一個問題：

• 避免移動討論「存檔」導致難以追蹤話題
• 解決條目討論頁未被善用作先行討論
• 要求用戶先行自己跟相關用戶探討，跟ArbCom討論一樣，不要事無大小都直接甩手扔給最高層級制度，不是什麼討論都需要廣泛徵求意見
• 免除互助客棧要「找話題」的問題
• 互助客棧討論根本是難以查找歷史的diff
• 討論議題無疾而終，卻存檔至多個討論頁時，若有人添加留言，則變成討論鬧多胞；本來就選好一個地方發起討論，而不要隨意「存檔」到N個討論頁就是防止這個問題繼續發生。

社群「習慣」不代表這個習慣是好的，在這些習慣造成損害的時候，仍是必須指正。--路西法人 2024年4月10日 (三) 10:33 (UTC)

我覺得你可能還是reconsider一下你的立場會比較好，畢竟這裏的意見可以説是幾近壓倒性地不同意你的見解，而我不認為這可以用“不去正視提案本身提出的原因何在”這種理由來一概而論。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月11日 (四) 00:38 (UTC)

我就是看不慣上面這些人的避重就輕，反駁不了我說的客棧運作問題、甚至連提案原意都沒搞清（針對RFC的反對意見）就自然做不成有效反對意見。--路西法人 2024年4月11日 (四) 05:42 (UTC)

社羣討論是一個尋求共識，或至少是尋求妥協的過程，如果大家都擺著“看不慣”的態度來討論的話，那如我上面所言，倒不如不要討論了。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月11日 (四) 15:50 (UTC)

共識還要求合理正當意見呢。不回應提案問題，提出一些扯遠了還能被我輕易反駁的論點怎能視作合理正當的有效異議？--路西法人 2024年4月12日 (五) 01:27 (UTC)

我的意思是不能把所有反對意見全部僅按著自己的意願而定性為非“正當合理意見”，這不是共識方針的本意。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月13日 (六) 11:05 (UTC)

最基本：反對意見是否貼題、有任何實質論據、是否直接回應提案中所指問題、是否有效指出提案存在的問題？光是這四點，上面的意見都沒能不符合最基本異議的要求，談何「正當合理意見」？不是因為多人不同意就等於正當合理、必須聽從的誒。--路西法人 2024年4月13日 (六) 13:09 (UTC)

例如閣下在此提案中提出的建設性意見和提問（如問10是怎麽來、要考慮某某某情形），這些都是貼題、有實質論證的意見，就算我不認同我也不會置之不理；ArbCom討論中Manchiu條例清晰的意見也能獲得我的認可及禮貌回應。不讀提案、完全走歪的意見顯然不是我有義務去uphold和回應的意見。--路西法人 2024年4月13日 (六) 13:20 (UTC)

閣下可以嘗試去拓展他們的異議，先形成完整的論證才拋上來討論；但如果你並不打算拓展他們空泛或存在根本性錯誤的意見，那麼關於他們意見是否有效的這則討論可以停止了。--路西法人 2024年4月13日 (六) 13:21 (UTC)

我覺得你先不要急著去定性他們的意見為好。

• 就説Ericliu1912上面説的“或可謂徵求意見制度在本地尚未成熟之象徵”，我認為這顯然並不屬於“存在根本性錯誤”的意見，畢竟RFC制度才剛推行一個多月，社羣尚未熟習RFC是很正常的事情；至於他説的“如此貿然推動是會實際損害百科全書討論運作的”應該是指社羣尚未熟習RFC的情況下訂立强制性規定要求社羣必須且僅可使用RFC會妨礙社羣成員參與討論（而且也可以合理預見這種做法將在實施初期引申混亂，這種混亂應該消除或降至最低）。
• Ericliu11912説的RFC機制“實在過於繁瑣”也不是說假的，假如我需要放RFC討論的連結到{{bulletin}}，我首先要在討論頁放{{rfc}}，然後等bot給hash出來，再把hash當成章節跳轉放討論的連結{{bulletin}}，要公示的RFC提案甚至還要放RFC專用的公示模板（{{公示/rfc}}）。我自己就有手操過上面説的這些程序，說RFC程序不繁瑣肯定是騙人的。
• RFC程序本身其實還有很多可以進一步細化的空間，提高RFC的使用率的方式似乎應該是如何讓RFC變得更好用，而不是强硬地大規模强制分流，那像Cwek一樣對你的提案有“推銷‘產品’”的觀感的事情也就不難理解了。

我個人認為比較合理的做法應該是在社羣習慣使用RFC後才來這樣細化相關規範，而不是像現在一樣靠行政手段反過來做，至於我上面提議的強制分流「僅影響單一頁面」與「影響多個頁面但有單一主題頁面」的討論也僅僅是出於分流VPD的考量。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月13日 (六) 15:07 (UTC)

説到這裏，我也對你的提案有新的疑問：假如強制分流實行後有人不按強制分流措施發起討論或應用RFC，那人有甚麽後果嗎？這“強制性措施”是真的“強制性”、真的可以貫徹落實嗎？有沒有甚麽機制能協助社羣執行強制分流措施？Sanmosa _{Szégyen a futás, de hasznos} 2024年4月13日 (六) 15:18 (UTC)

• 問題是，提案的重點從來不在於RFC，我上面也說過就算這個提案中把RFC拆了我還是要推行。還是「本地社群不成熟，不懂得善用條目討論頁發起討論及邀請更廣泛意見」？整個提案RFC都只是「輔助工具」而非重點，這個才是對提案的理解的根本性錯誤所在之處。
• 回應你後面關於「過於繁瑣」的部分：bulletin不一定要用hash啊，直接用討論章節標題亦可。共識掛額外模板也不是強制要求，只是協助辨識。這些optional的選項說是繁瑣也還真的說不過去，不過也感謝指出怎麽繁瑣了。
• 請詳述。你知道我最討厭人說「需要改善」但不提要怎樣改善，說了跟沒說一樣。新idea是不會無端從我腦子裏蹦出來的。
• 關於「強制措施」，RFC我不實在太care（始終目前被濫用的不是RFC，如果到時候真的被濫用再從建議條件升格為要求也可以）；我也再說一遍，客棧不是「本來就是這樣，然後要分流」，而是「本來就不該是這樣，應該正常使用討論頁」，「移回」（本應如此）跟「移去」（分流）意義完全不同。關於如何落實遞進式徵求意見而不再讓客棧被濫用，就很簡單是把開在客棧而沒有徵求全站用戶廣泛意見需求的討論直接關閉或移回討論頁。就算未來再有新的重大議題在客棧發起，也應避免再存檔至多個討論頁，而是直接在客棧存檔，方便查找（在哪裏發起的討論就在哪裏存檔）。

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

• 但這並不影響我說的事情，這只不過是把我原本的説法調整一下而已：我個人認為比較合理的做法應該是讓社羣習慣在客棧以外的地方發起討論後才來這樣細化相關規範，而不是像現在一樣靠行政手段反過來做。原版7DAYS多少也跟“本來就不該是這樣”沾點邊，最終不也是被現版取代了嗎？
• （見第三點）
• 就比如説，弄些小工具之類的？而且只說「需要改善」但不提要怎樣改善也可能是因為想不到改善方案的緣故，但想不到改善方案不一定代表不需要改善。
• （見第一點）

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