维基百科讨论:共识

共識建立的遞進步驟

此討論正在公示7天，直至2024年5月25日 (六) 02:45 (UTC)結束；如有意見請儘快提出。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

回應：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

不要總是習慣將未發生的事情就交給明天的社群，你不會知道社群陸續退步的有多嚴重。現在放寬鬆，未來再收緊，還是會再出現更多問題。有需要改善的點再來談「需要改善」，不然一切只是空談。--路西法人 2024年4月30日 (二) 04:38 (UTC)

公示版本

經過一整個月的討論，異議方一直未能提出實質有效的反對理據。本案提出需要解決的問題仍未見有用戶提出實質的處理方式，表示此案仍有推行的必要。基於上方有效的意見，微調本案建議措施的實施力度：

• 「多主題討論」部分作「建議」措施；
• 「RFC使用」部分作「應該」措施；
• 「單一條目討論」、「單一主題討論」部分作「強制」措施。

即新增規範如下：

1. 為善用社群討論資源，
   1. 僅影響單一條目的討論須在條目討論頁發起；
   2. 影響多個屬相同主題的條目的討論須在主題條目、專題佈告板或任一受影響條目的討論頁發起，並在情況許可下其餘受影響條目的討論頁發送討論通告（若受影響條目過多，應以通知專題佈告板及@提及為主）；
   3. 影響多個主題條目的討論可在任一受影響主題條目的討論頁或互助客棧條目探討板發起，並應在互助客棧及受影響的主題條目的討論頁發送討論通告。
   4. 未有條目的討論可在適當的專題佈告板或互助客棧條目探討板發起。
2. 編者應先盡可能自行透過討論解決爭議，過早徵求第三方意見可能使爭議另一方認為其意見不被尊重。在條目討論頁發起討論時，應發送通知（@提及或用戶討論頁通告）涉爭議的用戶參與討論（如有）；在無法解決時邀請近期編輯有關條目／主題的用戶參與討論。
3. 錯誤場合發起的討論可被關閉（需指出重新發起討論的合適場所）或移動（需保留討論討論主題及移動目標頁面連結）。
4. 經討論頁討論仍無果或下列情況下——
   1. 過往曾討論而未達成共識或需要改變共識的議題；
   2. 討論影響多個條目；
   3. 高風險主題條目的討論，
   編者可往互助客棧發送討論邀請通告及將討論加入徵求意見系統以獲取第三方意見。
5. 在其他頁面發送討論邀請通告時，應在討論串中申報以免造成拉票誤會。會顯示文本的@提及則不需重複申報。
6. 除討論過長需要分拆為獨立討論頁、討論在錯誤場合發起等情況，不應在發起討論後移動討論串，以免造成混亂；討論結束後亦應讓討論原地存檔，避免重複在多個頁面存檔後出現討論分支。
8. 社群可考慮新增機械人任務向受影響討論頁發送討論通告及結論。

以上。由於討論已達一個月，而上方規範已整合實質有效的意見，我現按WP:1MONTH將上方提案付諸公示， 公示7日，2024年5月18日 (六) 02:45 (UTC) 結束。--路西法人 2024年5月11日 (六) 02:45 (UTC)

在以下情况下，编者可[..]将讨论加入征求意见系统以获取第三方意见：我的疑问是这一句话是否代表如果以下情况下不适用的话是不是就不能用RFC系统了？--0xDeadbeef (留言) 2024年5月11日 (六) 03:28 (UTC)

1.可以IAR；2.實際上還有什麼通常需要RFC但不符合那四個情形的討論？--路西法人 2024年5月11日 (六) 03:49 (UTC)

例如

• 以前讨论过但无法形成共识的
• 以前讨论过、也形成共识的，但共识貌似已经改变了（或需要试图改变）的讨论
• 从一开始便能知道影响较大、应当有很多人来参与的讨论，例如这里？

--0xDeadbeef (留言) 2024年5月11日 (六) 09:03 (UTC)

@0xDeadbeef：只要將具有排他性的「可」改為軟性的「建議」，即應可避免行文暗示其他情況「不可」使用徵求意見制度。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月11日 (六) 20:01 (UTC)

對於調整後的強制分流範圍沒有意見。Sanmosa _{全方貧工之聯合} 2024年5月11日 (六) 03:50 (UTC)

(－)反对:針對巴士路線條目，按照「1b.影響多個屬相同主題的條目的討論須在主題條目或任一受影響條目的討論頁發起，並在其餘受影響條目的討論頁發送討論通告；」，當有東西想討論時，難道我要將討論邀請人肉貼上至差不多一萬條巴士路線條目的討論頁中，這未免阻礙達成共識？--唔好阻住我愛國（留言） 2024年5月11日 (六) 04:06 (UTC)

這就是配套還沒完善還強行通過的後果。

• 各條目現時沒有分類
• 沒有按分類群發邀請功能
• 難估算準確受影響條目數目

處理了這三項配套，我就可以支持。--唔好阻住我愛國（留言） 2024年5月11日 (六) 04:13 (UTC)

針對「6. 社群可考慮新增機器人任務向受影響討論頁發送討論通告及結論。」，對於新編輯者如何處理？他們對機械人操作零認識，請問現時有沒有一個可讓IP使用者隨意及零編程知識的機械人可供示範？--唔好阻住我愛國（留言） 2024年5月11日 (六) 04:20 (UTC)

基本上僅有極少數主題存在這種極大量建立條目而沒有獨立討論頁的情況，這個情況下應建立對應的維基專題，並以ping和通知專題佈告板為替代通知方式，已添加有關說明。甚至要在分類討論頁進行討論也是可行。大多數主題均存在多個子主題頁面，不會像巴士那樣一個大主題下就幾萬個條目。多數主題均能做到預設的受影響頁面通知，如果遇到這類少數特殊例子，適當時WP:IAR並以合適的方式替代也無不可。

機械人任務方面，會跟RFC機械人原理相同，通過填寫模板參數（如{{討論頁邀請|頁面1|頁面2|頁面3}}），並在機械人處理發送通知後自動轉換成通知申報即可）。屆時引入機械人後會再提供完整說明和安排，反正不會需要「操作」機械人。--路西法人 2024年5月11日 (六) 04:52 (UTC)

除了巴士條目動不動就以萬條計算外，還有電視節目、生物、國家地區等…

如果我想就九巴條目達成共識，真的要這樣ping [[[討論頁邀請|九巴1|九巴1B|九巴2|……|九巴999]]]?

既然閣下提及WP:IAR，可否有空間說明運用此指引的前提？--唔好阻住我愛國（留言） 2024年5月11日 (六) 06:06 (UTC)

顯然不切實際的通知就不需做。如果是影響整體結構，應提出格式手冊或內容指引。我晚點再詳列例子。--路西法人 2024年5月11日 (六) 08:12 (UTC)

針對「 通知專題佈告板」，閣下有沒有統計過有多少專題佈告板仍運作，有多少已存廢了？--唔好阻住我愛國（留言） 2024年5月11日 (六) 06:13 (UTC)

您維什麼都送去客棧，當然沒人用專題佈告版。沒人用不等於不好用。--路西法人 2024年5月11日 (六) 08:10 (UTC)

你最起碼在條文生效前將所有條目的討論頁導向至相關專題佈告版討論頁，否則如何達成閣下的期望，而且新用戶也能知道可在哪裡討論。--唔好阻住我愛國（留言） 2024年5月11日 (六) 09:22 (UTC)

是不會在有需要的時候ping人嗎？能先思考再發言嗎？--路西法人 2024年5月11日 (六) 10:16 (UTC)

針對第三版1b.「#影響多個屬相同主題的條目的討論須在主題條目或任一受影響條目的討論頁發起，並在情況許可下其餘受影響條目的討論頁發送討論通告（若受影響條目過多，應以通知專題佈告板及@提及為主）；」

.

可以這樣改

.

「影響多個屬相同主題的條目的討論須在主題條目、專題佈告板或任一受影響條目的討論頁發起，並在情況許可下向其餘受影響條目的討論頁發送討論通告。若受影響條目過多，請直接在專題佈告板或主題條目發起討論；」

.

針對第一版2. 「在條目討論頁發起討論時，應發送通知（@提及或用戶討論頁通告）邀請近期編輯有關條目／主題的用戶參與討論。」

.

可以這樣改

.

「在條目討論頁發起討論時，應發送通知（@提及或用戶討論頁通告）邀請最少？？？個近期編輯有關條目／主題的用戶參與討論。」--唔好阻住我愛國（留言） 2024年5月11日 (六) 13:13 (UTC)

又以九巴作例子，我要先在1A找人，然後在1B找人…最後在999找人才符合閣下的要求，這未免阻礙發起討論。所以提議設人數下限「最少？？？個 」即可，增加討論意欲。--唔好阻住我愛國（留言） 2024年5月11日 (六) 13:18 (UTC)

我覺得你只要通知主條目裏作主要編輯的就好。再者，中維大部分條目的近期編輯都寥寥可數，就算你真從（n個）1找到999，也不見得能找到成百上千個用戶。Sanmosa _{全方貧工之聯合} 2024年5月11日 (六) 15:07 (UTC)

香港巴士界有一個特性，就是「巴士愛車」、「巴士愛線」，除了衝GA嘅Thirdthink外，就只有IP用戶。按照此特性，每一條目也有不同IP使用者加入及更新車牌信息。根據提案，當我想改巴士條目大整體時，我是需要ping那1000多個條目的不同IP用家。--唔好阻住我愛國（留言） 2024年5月11日 (六) 16:32 (UTC)

IP在技術上是無法被ping的，因此你説的事情不成立。Sanmosa _{全方貧工之聯合} 2024年5月12日 (日) 00:45 (UTC)

首先我要到各條目證明只有ip用戶編輯先。若有「有名」編輯者，逐個記錄，最後一次過ping。

大佬！1000個條目呀！係要我行1000個條目之後先可以發言。--唔好阻住我愛國（留言） 2024年5月12日 (日) 02:09 (UTC)

下方Sanmosa留言已經針對此論點予以反駁。--路西法人 2024年5月12日 (日) 02:25 (UTC)

另一方面，“應發送通知邀請近期編輯有關條目／主題的用戶參與討論”這句話並不是“應發送通知邀請所有近期編輯有關條目／主題的用戶參與討論”，你如果真不知道ping誰的話，只ping自己有印象的那一個或幾個就行了，沒能ping所有相關用戶也不會招致懲罰。Sanmosa _{全方貧工之聯合} 2024年5月11日 (六) 15:09 (UTC)

樂見提案人收斂力道，然仍反對未經試行即正式推動此案，尤其反對「單一主題討論」之強制措施，僅不反對在涉及單一條目時引進此制看看成效如何。在程序上，不理解所謂「實質有效反對理據」由誰來認定，也不知道沒提出對案何來即「表示此案仍有推行的必要」（何況本人也有提出對案）；至於必須先以拖延討論避免徵求意見存檔，後藉所謂意見「有效」與否逕行篩選、甚至忽略包含本人在內其他相當數量使用者之看法，以期塑造公示共識，此亦本人礙難認同且極其不滿者。蓋討論近月趨於沈默、無人呼應，顯然不代表社群已然對相關方案表達認可，實際上正好相反，表示現行制度未有徹底失能，無須從事激進之所謂「改革」亦得有效運行，遑論試圖以制度去「約束」編輯慣例者。甚至據本人過往實際參與條目討論的觀察，究竟此提案是「解決」的舊問題多還是「製造」的新問題多，仍非常有待商榷。有關此案公示之依據，本人完全不信任提案人在此類討論中悍然「定性」他人意見的實績，主張提案人當為自己力推多時且親自參與辯論的提案避嫌，由非當事之他人來認定此話題諸位發言滿足「實質有效」與否，省得「球員兼裁判」。又此對互助客棧條目探討區眾多使用者影響何等巨大，社群多數編者卻顯然渾然不知所參與之互助客棧若干制度即將被直接推翻（當然在此相對偏遠之處討論實為緣故之一），而他們本來完全有權利明悉此議題並就此發表意見；有關公示固然滿足方針之最低要求，卻彷彿如此已然滿足社群知情之公益，此恐乖違於實情。本人認為，應即以系統通知近期實際使用過客棧該區者提供一手見解，甚至就此相當重要之議題付諸公決，最大限度避免吾等少數人參與制定之政策淪為空中樓閣。本人其餘意見均已於先前詳細闡釋，這裏便不再重複。基於上述前提，本人反對此突然而冒進之提案公示。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月11日 (六) 17:51 (UTC)

另提案第二及第三點矛盾：蓋在個別條目涉及兩造或多方面編輯問題的討論中，伊始即「邀請近期編輯有關條目／主題的用戶參與」實際上就是直接引進非當事之第三方意見。又過往諸多實踐顯示，很多時候爭議方只是因為「隔空喊話」缺乏溝通，只要發起話題好好討論，即可迅速解決問題，不需要徒然造成額外事端；實際上這也根本是此提案第三點前段的意旨才對——兩三個人的意見分歧不需要總是立刻邀一堆人來群聊——即給予爭議各方面足夠之初步討論空間及尊重，爾後再尋求他人意見。只有在單一方面發起、且一開始即明確需要徵求他人意見的場合（例如第三方發起涉及他人編輯條目內容的討論等），才有必要以邀請他人參與為發起要件。另外只是「捫心自問」，或純粹給條目內容存疑或備註者亦不在少數，本站沒有必要連這點言論自由也箝制，逼迫人家一定要找幾個人湊數來「開」討論。故本人認為就規則及實務而言均不該予以強制，「應發送通知」應改為「得（可）發送通知」或「建議發送通知」。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月11日 (六) 18:22 (UTC)

此外，若是按照往例，此話題早就因不為編者所關注或難有共識而作結，彰顯社群意志；正是因為徵求意見話題完結界線之模糊，導致討論可以不斷接續，告終之日遙遙無期，而任何話題要一整個月不活躍才算關閉則是雪上加霜，致使若討論拖延，則其加劇之嚴重程度要更甚於互助客棧。這實在是當初提案人屢次拒絕本人據彼時情況變化移動話題至互助客棧以利社群擴大討論，造成話題門可羅雀、討論難續有共鳴；本人完全有理由相信，若此話題今日尚在客棧，無論客棧運作如何敗壞，其討論流量及踴躍程度決不至於如此慘澹，且至今仍然認為有關舉動形近「行為藝術」，即為「證明」徵求意見已充分獨立可行之觀點，堅持使用該彼時未上軌道之制度運作討論，結果相當程度損害社群公益，反而顯示今日之徵求意見尚待社群多加愛護參與，並對此深感遺憾。是以本人原欲主張社群現階段應以時機未至、制度尚不成熟、共識不足或不應以過強政策手段干預編者自然討論等根本導致制度窒礙難行之客觀因素關閉話題，拒絕提案人不斷強推此案之嘗試；然本人自知此等主張觀點強烈、爭議較大，或不受多數支持，且本來也是因為徵求意見目前尚有若干難以克服之限制所致，相關問題並不應全然歸咎於提案人。故社群當前就此議題若確實仍然存在徵求意見、乃至於擴大討論之需求，或諸位認為得以某種折衷試行或其他較受廣泛認可之形式推進此案，則大可繼續，本人完全不持異議，併此敘明。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月11日 (六) 19:27 (UTC)

回應：

1. 意見有效與否最簡單陳述就是「有無道理」，複雜點就是「是否能以實際情況和其他共識推翻提案的前設或構成」。公示前的討論中出現過的異議：
   • 「無強制必要」——已多次說明貴站人顯然因為「懶」而不會善用系統和社群提供的平台和機制，光是「建議」是無法從根源解決問題的。
   • 「互助客棧能見度較高」——偽命題。能見度高不代表能解決爭議；況且客棧條目探討板也經常出現近乎沒人參與的討論。以昨天Sanmosa將部分討論串分開前的時刻（topic list）為例：有將近一半的討論並沒有獲得多少人的關注，超過一半以上的討論的參與者人數也不過五個，而這些參與者更不是來自對話題熟悉的用戶而多數是路人。「能見度高」一說完全是偽論點。
   • 「徵求意見制度在本地尚未成熟」——偽命題。已多次予以反駁，在比較便利但比較差的制度和比較不熟悉但更善用資源的制度比較，懶人一定選較差的制度。差的制度一天不汰除，較好的制度也不會被看見。不是徵求意見制度不成熟，而是社群拒絕改進；需要改善的不是徵求意見制度而是社群本身，而迫使社群改進、善用討論資源、改變討論態度的方法只有淘汰明顯有問題的舊制度。
   • 「架空互助客棧」——偽邏輯。互助客棧本來就不是「本體」，就算反對方把客棧奉為上尊，互助客棧長年的置頂指示也表明客棧本來就不是這樣用的。被錯誤依賴的制度不存在「架空」一說。
   • 「不需要限制誰要使用徵求意見制度」——以貴站習性，沒有好好規範的制度就會被用爛。
   • 「社群若認為互助客棧好用，自然會用客棧，若徵求意見好用，自然會用徵求意見」——偽邏輯。「好用」不等於「適合」。這說法跟「若有公司認為維基百科很好用來宣傳，自然就會來改維基百科」或「若學生認為維基百科好用，自然就會用維基百科來做功課」無異，背離本意的使用不等於應該放任。
   • 「推銷徵求意見制度」——偽命題。此提案就算沒有徵求意見制度也應該要推行以解決客棧存在的問題。徵求意見在此提案中僅為輔助工具，以此反對提案簡直荒謬。
   • 「客棧置頂指引過時」——事實反映當初要求不被遵守就產生客棧的諸多問題，顯然是不符合現實的論據。
   這些論點連最基本的邏輯都沒理順，何談「合理有效」意見？
2. 提案無人呼應完全不代表問題不存在。問題不存在者可能無人呼應，但無人呼應者不必然問題不存在。等到制度徹底失能才來改，這叫「亡羊補牢」，是荒謬至極的做法。過往顯示社群等到發生OA後才修補制度顯然已經造成嚴重傷害。
3. 在討論頁的討論評為「偏遠之處」毫無道理，實情就算在客棧提出的討論也是會出現無人跟進的情況，此處情況並不會比客棧要差。此討論串9人參與，顯然不比平均客棧方針板的討論活躍度差。
4. 究竟此提案是「解決」的舊問題多還是「製造」的新問題多，仍非常有待商榷。製造的新問題有不同類型的方法可以解決，所謂的「新問題」可能根本在於制度未有全面推行和完整實踐過而存在的偽問題。
5. 你在過往意見徵集當中大肆宣揚「意見徵集僅供參考」並拒絕承認其效力，現在反過來要求「付諸公決」，乃是顯而易見的雙重標準。我固然不怕以理服人付諸公決，但也非常清楚貴站用戶不顧方針指引邏輯而意氣用事。本提案本就旨在解決討論重複遷移的問題，就算是付諸公決也是該維持討論原地進行。

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

6. 提案第二及第三點矛盾：已修訂用詞，確實遺漏。
7. RFC部分不用「可」：條文本身並未表示「僅」或什麼情況「不可」，若有人如此超譯則顯然應無視。但亦已稍微修改用詞用句。
8. 「損失流量」：此提案仍然存在讓用戶在廣邀意見的時候往客棧發討論通告邀請討論，而客棧也會長期掛着討論連結，不見得在清空客棧積壓後會有非常嚴重的流量損失（尤其是目前客棧流量顯然也不比RFC多很多）。點段落標題跟點進討論頁都是一步的事。
9. 討論不活躍、無共識本就隨時可以重啟，但以完全站不住腳、未曾能完整回應我反駁的所謂「反對」論點來以「社群不採納」結案就絕對不可能。我推提案每次都是正面回應問題，反方就「側側膊」裝作看不到我對其論點的反駁，甚至將過往至今顯然仍然對此案有重大意義而目前制度無法做到的規則指引等訴諸無用、過時，談何我「強推」議案？

過往社群缺乏充足配套，以客棧為討論集中地尚可理解；現在配套充足提案從頭到尾都只是在目前本地配套更完善的背景下，將客棧置頂長久以來都存在且仍有重大意義的限制付諸更明確具體的實行；反方卻從頭到尾拒絕考量當初的規則未被遵守而造成今天的問題。反方打不倒「任何條目或模板的交流應考慮先在其討論頁發表」這條自客棧設立存在至今的置頂要求的意義就甭想阻攔此提案以某種形式實現。我無任歡迎社群用戶參與討論並指出此遞進制度的缺陷所在（如RFC使用情形、程序遺漏），歡迎提出，但恕不接受上方已完整反對而反方完全無法繼續維持的無效論點。--路西法人 2024年5月12日 (日) 09:44 (UTC)

至於有關「試行」，此案與其他可「試行」的提案不同之處在於該等程序是不做就不做，但此案在於需要替代原先有問題的制度。試行與否，都是要儘量執行才能達到善用討論資源的效果，故此看不到「試行」與否在此除了給反方心理上「這只是試行」的效果外毫無效果。舊制度的積弊過多（且也是不被反方回應、正視的弊端），新制度有問題也是應該改善新制度而不能倒退，「試行」在此處並不合適。--路西法人 2024年5月12日 (日) 10:01 (UTC)

因討論延宕，副知可能未知悉第二階段討論之其餘參與者@桐生ここ、S8321414、Kethyga、Shizhao、Cwek、Ghren。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月18日 (六) 09:40 (UTC)

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

没有细读上面的讨论。我唯一害怕的是这其实是一个XY问题，而可能是工具规律下造成的WP:CREEP。我仍然不反对这个提案，但是如果说最大的问题是有人不在正确的地方开讨论，我觉得更好点的切入点应该是鼓励他人移动讨论，所以最需要改的应该是明确指出哪里是读者应当开启讨论串的地方。英维的区别就是英维有一群知道自己在做什么的编辑，能在讨论早期的时候便给你指出来在哪里讨论才是最正确的。当然，之前通过移动战已经看到这方面还没出现共识，我的想法是条目讨论除了很重要的事情不要在客栈上（事实上英维没有讨论条目的客栈）。0xDeadbeef (留言) 2024年5月14日 (二) 10:20 (UTC)

根據我對LuciferianThomas之前的言論的印象，他是期望中維最終完全廢除VPD的。Sanmosa _{全方貧工之聯合} 2024年5月14日 (二) 10:44 (UTC)

本人認為，社群對加強單一條目討論分流措施並非沒有共識，也曾指出該類話題常年占現有客棧話題二分之一至三分之二以上，若得據此先行擬定試行方案，一方面落實原提案主旨緩解互助客棧壓力，另一方面亦得藉以評估該制度能否在本地運作流暢，再搭配社群主動而積極之宣導，當已十分足夠。然而，提案人堅持繼續推動一次性激進而不實際的「全面改革」，無視本人指出相關外來制度尚難全然契合社群過往討論慣例與當前討論程序實務運作情況，及社群其他編者基於自身參與經驗所提出相當一部分適切允妥之意見或折衷看法等，甚而在推進討論時逕行宣告他人異議「無效」云，此等行為在在見於上該討論過程，且不只及於本人；本人基於此前已詳加敘述之理由，參酌在此話題中及其之外諸多編者提出之合理切身意見，不認為當前提案版本足以取得社群共識，不認為提案內容仰賴之過渡機制足夠完善而得起預期之替代作用，不認為此提案有妥善考慮本地目標受眾真正需求，不認為提案執行結果能多大方便多數一般編者就涉及較廣泛議題發起、展開並延續建設性討論，亦不認同當事人為推進提案通過所從事若干過當程序性及實質性操作符合本站編者切磋達成較普遍共識所需之精神，更不樂見如此限制（甚至干涉）編者討論自由的所謂「遞進步驟」，未得大多數實際參與既有討論機制運作者全面深入、誠懇之商議而遂行通過。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月14日 (二) 17:31 (UTC)

反方持續迴避、拒絕正面回應對其論點的反駁，屢屢發表對提案錯誤理解的所謂「意見」，甚至連長年存在的討論板規則都選擇無視，本就無法構成任何有效意見。上方12日之留言已回應反方提出的所有爭議點，反方都選擇不回應；依共識方針：任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何用戶重複提出，可提示該用戶相關意見已獲解決，除此以外無須另作回應。先不論反方的論點如何站不住腳，就算視作有效意見，已經被我多次反駁而反方無法進一步回應、推翻的意見本就按方針視作已解決意見，後續鬼打牆重複我已清楚回應的反方意見都只是重複提出已解決意見，我本就無義務回應或視作有效阻擋提案的意見。反方持續將方針指引及討論板的置頂規則視若無物，又不願意去回應我的反駁，我看不出來反方哪裡來的建設性討論。--路西法人 2024年5月15日 (三) 04:06 (UTC)

再進一步細回應Ericliu1912迴避回應過往反駁後又再提的所謂「有效論點」：

• 相關外來制度尚難全然契合社群過往討論慣例與當前討論程序實務運作情況：提案在於過往討論管理和討論程序實務運作出現問題，這個說法就是「A提案要解決B問題，但因為B問題是習慣（陋習）所以不可以去解決」，是非常顯然的訴諸傳統論述。
• 合理意見：上方已清晰敘明反方一直無法回應反駁等同其意見應視作已回應，不贅述。
• 不認為提案內容仰賴之過渡機制足夠完善而得起預期之替代作用：顯然的prejudicial dismissal，在有大量問題但「比較方便」的舊機制主導下，沒人用新機制是完全可以預測到的事情；部分機制更是未曾實行就判定無效，顯然是「未經試驗即斷定失敗」的論點。
• 不認為此提案有妥善考慮本地目標受眾真正需求：以普通編者而言，討論的目的就是針對自己熟悉的話題提出意見並形成共識，這一點在任何討論頁發起的討論都能做到；需要擴大討論時，新配套仍有考慮到客棧的高流量而允許用戶發通告徵求意見，且有直接向用戶討論頁發FRS通告的配套，完全能滿足該需求；對於想參與更多討論的編者而言，徵求意見列表、往客棧發討論通告、FRS發用戶討論頁通告、DiscussionTools提供的追蹤討論工具合起來比現在會有更高的能見度，完全能滿足這個非主要的需求；以社群而言，討論除了解決爭議外，還有建立社群成員核心價值的需求，這一點新提案能做到（要求首先跟爭議用戶討論、再請熟悉相關主題的第三方用戶討論），反而客棧沒做到。反方除了空談「不認為」之外能給出任何實質需求是這個提案沒能給到而過往制度存在的需求嗎？
• 不認為提案執行結果能多大方便多數一般編者就涉及較廣泛議題發起、展開並延續建設性討論：此提案並無阻擋用戶在廣泛議題使用客棧發起討論，是連提案都沒讀好就反對的意見。
• 限制（甚至干涉）編者討論自由的所謂「遞進步驟」：自由不是無王管。造成問題的自由就會被限制，正如言論自由並不保障對他人有負面影響的言論。顯然現在的「自由」制度有非常清晰可見的問題，那就該管。

如果Eric君仍然是完全沒有辦法提出實質且能回應反駁的論點，只會鬼打牆重複已經被多次回應也站不住腳的論點或提出空泛無論證的論點，我應按共識方針的明確規定將已多次回應的意見視作已解決，並不再回應。--路西法人 2024年5月15日 (三) 04:36 (UTC)

其实这个方针也可以这样写：在互助客栈条目探讨板发起，且仅影响单一条目或影响多个属相同主题的条目的讨论应被移动至任意受影响条目讨论页或专题布告板进行讨论。

我这样写的原因是认为就算你用多强硬的须，你改变不了仍然会有人使用WP:VPD讨论单一条目的现实。所以你能怎么办呢？如果最终结果一样，都是要去移动讨论串，那是不是还不如从一开始就写移动讨论串。要是以后有人说「你在这里发起讨论违反了方针」是真的听上去有点冲。

但是你们俩在讨论什么，我没看懂。。--0xDeadbeef (留言) 2024年5月15日 (三) 09:34 (UTC)

您這個寫法只能作為「從客棧移走」的依據，而達不到「鼓勵/建議從一開始在適當的地方做適當的事」。--路西法人 2024年5月15日 (三) 09:46 (UTC)

没仔细看上面，但有依据且不建议移回，本身就是鼓励了。以习惯养成的循序渐进和需要观察来说，不应一竿子打死在VPD发起。同0xDEADBEEF的看法。--YFdyh000（留言） 2024年5月15日 (三) 10:01 (UTC)

看來閣下看漏了「從一開始」四個字。我的提案是兩方面，一面處理被不恰當的發起於VPD的討論，一面在規定上寫清楚best practice。Deadbeef版本而言，沒有寫清楚開始要去哪裏發起留言即全部人都要撞一次鐵板才知道哪裏對，這顯然是不理想的，更是對我提案其中一個目標「避免/減少移動討論」相違背。我期望的是看指示的人能明確知道討論一開始在哪裏發起合適，而不是僅依靠有人長期監視客棧每則移走。

當然，我的提案無法杜絕不讀指示的用戶在VPD發起討論（從客棧長期存在類似指示卻無人遵守得知），但起碼寫清楚了指示就有明確的移動理據，而不能被胡亂質疑移動的目的。--路西法人 2024年5月15日 (三) 10:21 (UTC)

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

今早回覆其他用戶時沒看到您的留言。您的版本是「叫你做就做，我不會告訴你為什麼有這個要求」，絕對會產生疑問和異議；我的版本是配有完整理據的規範，「憑什麼」從來都不是在維基百科的有效異議（類同「憑甚麼維基百科限制/讓我創建自關於自己條目」）。規範連帶理據通過的話，「憑什麼」類異議是無效也無需反駁的，而「為什麼」的問題更是不需回應（因方針已經有寫，沒看到不是執行人的問題）。--路西法人 2024年5月19日 (日) 08:59 (UTC)

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

已添加一項錯誤場合發起的討論可被關閉（需指出重新發起討論的合適場所）或移動（需保留討論討論主題及移動目標頁面連結）。--路西法人 2024年5月21日 (二) 00:30 (UTC)

---

已按HK5201314的異議調整條文、我和Sanmosa也已回應其後續疑問，視作意見已解決。Ericliu1912所指出的反對論點均已清晰回應，其除了不斷重複已回應論點也未能對我已經多次作出的反駁作進一步駁論；依共識方針，已獲正當回應的意見應視作意見已解決，後續重複提出該等意見無需再回應。其餘用戶的意見已獲回應。

由於較大幅度調整過條文， 重行公示7日，2024年5月25日 (六) 02:45 (UTC) 結束。--路西法人 2024年5月18日 (六) 02:56 (UTC)

支持提案。不過請問提案的文字準備要放在哪一份方針的哪個段落呢?--CaryCheng（留言） 2024年5月18日 (六) 09:07 (UTC)

我傾向先以實踐為重心。共識方針始終有大量文本的翻譯、內容組織問題需要改善。目前推行的規範可以不用這麼生硬地塞在方針內，而是調整段落文本來反映這個目標和效果。目前先作維護討論秩序的措施實施，往後確認效果後再調整方針文字亦可。如果目前有需要，暫時整段放進方針就行。--路西法人 2024年5月18日 (六) 10:37 (UTC)

了解。支持先以實踐為重心，未來調整文字後再放進方針。--CaryCheng（留言） 2024年5月19日 (日) 15:42 (UTC)

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

不過就事論事，還是要確定「多個屬相同主題的條目」跟「多個主題條目」的差別在哪裡？應該說提案混用了「主題」一詞，加上「受影響」等不同用法，導致很難確定究竟所指為何。並建議給提案各項提供幾個範例，俾編者較好確定範疇。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月18日 (六) 09:51 (UTC)

無法提出新論據回應反駁就拉布大概才是可笑的一方。

提案早在原始提案版本已經提供例子，不知反方是否沒認真讀提案。「多個屬相同主題的條目」即原提案「涉及多個條目的討論」下的「有單一主題條目者」；「多個主題條目」就是「有多個主題條目者」。所謂「主題條目」即最貼近需討論條目的主題條目，例如：

• HK5201314提出的案例就同屬「香港巴士路線（列表）」的主題，在該主題條目的討論頁發起即可（甚或「香港巴士」也可）；
• 上例如會影響更多地區的巴士路線條目，那麼就不是最貼近的主題條目，即可視作多個主題處理（此情況推薦使用專題佈告版討論）；
• 台灣各條目地理及政治內容架構的就涉及多個主題（因國家和地理並不同屬同一主題，且常人可判斷這些也是主題的中心條目），那麼在任何一個（主題）條目或客棧發起並在其他主題條目討論頁發通告即可。

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

混淆至極，難以想像這是設計給一般編者看的政策條文。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月24日 (五) 21:52 (UTC)

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

錯誤地方發起的討論可被關閉或移動，目前無罰則。當然除非是有人蓄意擾亂客棧和討論秩序。--路西法人 2024年5月18日 (六) 13:50 (UTC)

另外我才發現此提案不僅禁止編者在條目探討區發起若干討論，甚至禁止行之有效的「討論參與不足，移動至客棧擴大討論」慣例，只允許在客棧發什麼「討論通告」，那就實在更加離譜。真把條目探討區當作「互助客棧 (消息) (條目)」了啊？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月18日 (六) 14:41 (UTC)

顯然你還是不懂得認真讀提案。除討論過長需要分拆為獨立討論頁、討論在錯誤場合發起等情況，不應在發起討論後移動討論串，以免造成混亂；討論結束後亦應讓討論原地存檔，避免重複在多個頁面存檔後出現討論分支。討論串移動本來就有造成混亂的問題，僅有在無其他辦法取代的情況下才應執行。在客棧發討論通告亦能達到從能見度高的客棧招來更多用戶參與討論的目標，目前也有RFC、FRS的配套，顯然也能達到「擴大討論」的效果；在社群習慣討論不再大量於客棧發起時，「擴大討論」的曝光方式只是與以往不一樣（RFC列表、討論通知），也避免了討論串在客棧堆積；過往習慣追蹤客棧的用戶也能更清晰看到需要關注的議題。移動討論串是毫無必要的操作。至於「慣例」之類說法，我回應過一千遍，也無意重複回應。

在早前針對「客棧能見度高」論點的反駁中，我寫過這麼一段話：況且客棧條目探討板也經常出現近乎沒人參與的討論。以昨天Sanmosa將部分討論串分開前的時刻（topic list）為例：有將近一半的討論並沒有獲得多少人的關注，超過一半以上的討論的參與者人數也不過五個，而這些參與者更不是來自對話題熟悉的用戶而多數是路人。如果在你眼中RFC沒什麼人回覆叫不成熟，那麼客棧缺乏用戶參與的討論串不就充分證明所謂「討論參與不足，移動至客棧擴大討論」並不是「行之有效」嗎？

你把話換個方式說一遍並不會改變你提出爭議來來去去都是我已經充分回應過的論點，反而你的每一則留言都只是展現了你根本沒有去讀提案和我給你的回應，更遑論理解我的論點。--路西法人 2024年5月18日 (六) 17:11 (UTC)

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

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

請留意一下VPD那邊的討論。Sanmosa _人人皆王 2024年5月20日 (一) 11:45 (UTC)

那其實不是討論，只是通告，本意是請那些會看條目探討區的人多來這裡參與討論。但此處討論已經過長且偏於toxic，可以理解社群不甚願意就某些立場發言的原因（至少好幾個人跟我講過討論篇幅太長，他們難以跟進）。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月20日 (一) 11:49 (UTC)

無視方針和討論板長久以來規範的論點站不住腳能被輕易擊破，貴站用戶大概需要先有自知之明。這裏的討論就剩你無限鬼打牆拉布、無視實質規範、連提案都沒讀清楚就來反對，理虧沒法回應質疑就開始抹黑「強推」，不罵你罵誰？--路西法人 2024年5月21日 (二) 01:02 (UTC)

您可是誰反對就罵誰，還順便帶上個「異議無效」的帽子，如此推進討論可不樂活。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月24日 (五) 21:52 (UTC)

(－)反对 👉 影響多個屬相同主題的條目的討論須在主題條目、專題佈告板或任一受影響條目的討論頁發起：我認為影響多個條目的討論可在互助客棧條目探討板發起，同意避免一刀切所帶來的不必要問題，① 未必存在主題條目、專題佈告板，即便存在發起人也未必知道存在相關頁面，② 如果在任一受影響條目的討論頁發起，其他受影響條目的討論頁就沒有討論存檔，而且花多眼亂到底選擇哪一條目討論頁發起。 -- 月都 ※ 2024年5月23日 (四) 15:31 (UTC)

很多條目討論頁都掛有專題模板，找專題不是難事；能找到客棧條目探討板的用戶也顯然會在該處接觸到更多社群頁面的連結，找不到專題佈告板的新手用戶多數也不會找得到互助客棧（對新手而言，客棧條目探討板甚至比專題頁面更難找，因條目討論頁能直接找到專題模板）；找不到主題條目更不是一個問題，直接使用當前受影響條目的討論頁即可。就算用戶找到客棧也找不到這些，在客棧發起了討論後仍可儘早指導其去正確場所發起討論，這是教導用戶更瞭解社群運作。

其他受影響條目的討論頁沒有存檔也從來不是問題，當前客棧中影響多個以上個同主題條目的討論也不會存檔去所有受影響條目的討論頁，這未曾造成問題；提案也指出多處存檔會難以追蹤後續討論和造成平行討論的問題，在任一受影響條目的討論頁發起時也會因應情況盡可能向多個受影響討論頁發討論通告。

「花多眼亂」：顯然你是幾乎沒在參與條目編輯的人才會說出這種話。有話題、爭議要討論，自然是在編輯某一條目時衍伸出的問題，在該條目的討論頁直接發起討論已經是「任一受影響條目」，這不是很直覺的事情嗎？

為什麼能提出如此荒謬的「反對意見」呢？不就只能是因為你參與維基百科但不認真瞭解參與條目編輯會發生什麼事（簡稱不務正業）嗎？--路西法人 2024年5月24日 (五) 01:40 (UTC)

確實，在涉及較少條目而非整個主題的討論中，要「選」一篇條目發起話題是不合理的。已經沒什麼量能批評其他地方，也不相信有什麼用處，不過提案人雖然到處攻擊反對者，甚至聲稱他人「不務正業」，但恐怕只有真的「不務正業」才能研發出這種蔑視社群慣性的制度。今日尚無可多言，來日當有所證明。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月24日 (五) 02:44 (UTC)

我能論證選一篇條目發起話題的合理性，你卻自始至終無法提出要「選」一篇條目發起話題是不合理的的「不合理性」的論證，甚至一而再再而三地迴避回應任何實質反駁論點。

月都實際長時間未有參與任何條目討論，也長期未使用條目探討板，更在其論證中展現其未曾實際閱讀提案也未曾瞭解社群討論的機制，不是不務正業是什麼？反方不受得任何批評，就指控我「攻擊」反對者；反方自己卻自始至終無法提供實質站得住腳的駁論，也充分展現了為了反對提案可以無視多少方針、扭曲「初心」「慣性」「架空」「自由」等詞語，難道作為正方就不能批評反方荒謬且站不住腳的論證？--路西法人 2024年5月24日 (五) 03:10 (UTC)

我已無心做冗長之政策辯論，須知遇到對手「裁判兼球員」的賽局是打不贏的。只可惜互助客棧這樣一種適切本地社群自然發展出來的討論制度，將為官僚追求形式的強迫之舉所毀，最後受害的只會是編者及讀者。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月24日 (五) 21:52 (UTC)

( ✓ )同意：在涉及較少條目而非整個主題的討論中，要「選」一篇條目發起話題可使發起人感到困惑。 -- 月都 ※ 2024年5月25日 (六) 20:09 (UTC)

關於指引。

一、在我看來無非是確實是「徵求意見制度運作約一個月來實績不彰」。Sanmosa在2024-05-11將VPD的六項討論移動到對應討論頁，包括Talk:福建人、Talk:丹巴·冈呼雅格、Talk:丹巴·冈呼雅格、Talk:陳牧馳、Template_talk:Infobox_officeholder#h-模板問題六處，六處無一例外之後都沒有回應。尤其是Talk:福建人，本來討論串是由「編輯爭議」版移動過來，已增加能見度，然後在「互助客棧」得到更多人的參與，然後在討論在條目討論頁中完全得不到回覆。

一之一。且客棧條目探討板也經常出現近乎沒人參與的討論。以昨天Sanmosa將部分討論串分開前的時刻（topic list）為例：有將近一半的討論並沒有獲得多少人的關注，超過一半以上的討論的參與者人數也不過五個，而這些參與者更不是來自對話題熟悉的用戶而多數是路人。確是事實，問題是互助客棧的討論熱情不高，但RFC下條目討論頁較互助客棧更為低。這是相對性的問題。不能證明所謂「討論參與不足，移動至客棧擴大討論非行之有效」。

二、我想提案的重點和RFC不可能是不可分的。所謂「互助客棧」之所以會成為整個中維的集中討論地方，完全是因為其他討論頁、專題討論頁幾乎完全沒有能見度。我想「把RFC拆了我還是要推行」這種想法完全是天馬行空。

三、專題布告板。如大家所知，專題布告板只屬於簽名板，除了極少數專題有活躍之外（ACG等），完全沒有作用。提案方針中寫「應以通知專題布告板」，我只認為是害了一些不知道專題運作制度的人。英維可行制度不一定合於中維。

四、既然「太多人根本連有這個系統也不知道」，那應該首先推廣此制度才是。我想這是制定政策的根本常識才是。應該先去將替代品搞好，然後再去將既有產品、服務取消才是對吧？我想社群最擔憂是這點才是。「條目探討」平均瀏覽次數為400左右，「徵求意見/全部」則只有40。兩者相差一個量綱級，帶到具體「議題」，即使加上FRS帶給的流量，和討論頁本身的可能流量和關注列表等，又可能拉平多少？能見度高不代表能解決爭議，但能見度高往往對於推進議案、爭取共識有相當大的作用。

五、我過去一直都有提出互助客棧過長的問題。也過去一直支持RFC的制度的（參Wikipedia_talk:徵求意見/存檔1#WP:RFC需要兩個bot）。提案中談的問題（Wikipedia_talk:共识#c-LuciferianThomas-20240410103300-Ghren-20240410073200），除了二、三項，我承認舊制度較新制度為佳，然而這些所謂「好處」有沒有大到要社群在短時間內吸引使用呢？完全沒有。壞處存在，但帶來的負面影響也不大，這樣的話操之過急的理由是什麼？

關於條文。

甲、（1c）款：「影響多個主題條目的討論可在任一受影響主題條目的討論頁或互助客棧條目探討板發起，並應在互助客棧及受影響的主題條目的討論頁發送討論通告」。「應」應為「可」。是否發送討論應由編者自由決定。

乙、須與應之別。五大支柱之一WP:5P5給予了突破既有指引的空間、而「應」也給予突破指引的空間，使用「須」、「應」的分別何在，我看上方已有一些解釋，但依然不明確。比如雖然只影響一條條目，但因為影響甚眾，故初期置於「條目討論」區作討論（比如「中華民國」的內容結構），是否有立即回退，「指引」其正確討論方式之必要。RFC 2119之所以定「須」為「必須滿足」，明顯是因為「不滿足」會明顯帶來較大負面後果，乃至危害運作。「僅影響單一條目的討論須在條目討論頁發起」是否帶來足夠大的負面後果呢，您所舉的「陋習」缺乏即時性的危害，影響亦有有限。

總的來說，維基百科是典型由下至上運作的社會，在不涉及違反方針指引的前提下，不帶來重大或即時性的惡果，對於社群陋習應該慢慢因勢利導才是，這不是所謂「懶」，而是社群根本缺乏誘因去改變，在此情況迫使社群做什麼根本不現實。依靠一紙公文解決問題根本不現實。這種問題明明拖一年半載，自然成熟解決。即使解決不了，到時候提出來的迫切性也高了。然而目前反對聲音眾，支持聲音寡，非得要強硬闖關，浪費大量社群資源，實在不無遺憾。我已經可以想像您給什麼說話我聽了，無非是「Stoneball」「非合理意見」「老調重彈不新鮮」之類。我本就應該如Fire Ice所說的不別花這樣多口水的。歎歎！--Ghren🐦🕓 2024年5月24日 (五) 20:42 (UTC)

回：

（一）、（四）：徵求意見制度運作約一個月來實績不彰、太多人根本連有這個系統也不知道：互助客棧條目探討板總長70頁，RFC討論列表一節僅佔1.5頁。這不是「徵求意見制度實績不彰」，而是互助客棧條目探討板的長度完全使RFC討論列表難以被注意。現在的情況跟在一整頁報紙上僅有一個小卡大小的版面說是有公告那樣。RFC根本尚未被給予完整的機會去運作，任何形式去擴大RFC能見度的動作又被抹黑成「推銷」，簡單而言就是反對RFC、不認為RFC有用的用戶實質上無限壓縮RFC的運作空間後說RFC沒人用。閣下說「包括（……）六處[討論]」，卻只給了五個連結，還有兩個是重複的，這不是虛假論述？列出「Talk:福建人、Talk:丹巴·岡呼雅格、Talk:陳牧馳」三個例子，沒有任何一則討論是掛過RFC模板的，拿沒有經過過RFC制度的討論來說RFC沒用是否虛假論述？

（一之一）：問題是互助客棧的討論熱情不高，但RFC下條目討論頁較互助客棧更為低。這是相對性的問題。當然有相對性問題。在70頁的討論篇幅中僅有1.5頁的篇幅去邀請討論，相對性論述下RFC完全沒有被給予跟互助客棧同等證明效度的機會，沒給過機會就不要說沒用。

（二）：此提案沒有RFC完完全全能正常運作，只是有了RFC能更好運作。沒有機械人的幫助，且在客棧不會被70頁的五花八門互不關聯討論佔據下，用戶發送討論通告能很容易被注意到。既然客棧如此「有能見度」，在沒有人海戰術淹沒討論通告的前提下，客棧應當完全能達到引流效果。反觀，有了RFC自動登錄討論列表和發送討論通告的機制，理論上客棧的討論通告能完全吸收原有能見度加上發送邀請個別專題用戶討論的通告，能見度反而會高於客棧本身，當然在沒有人海戰術淹沒討論通告的前提下。

（三）：關於專題佈告板，我確實同意當前狀態下專題佈告板幾乎沒有能見度。追根究底，不是因為「沒有用戶去維護專題」，而是什麼討論都被鼓勵送往客棧討論，而不先與熟悉有關主題的用戶討論，所以才沒有人有動力去維護、組織專題，因為根本沒有專題內先嘗試自行討論的誘因。客棧無限擴大使用範圍是奪走這個基礎誘因的主因。補充一句：當下特定主題涉及大量條目的討論往往都需要大量ping相關專題用戶，實際反映完全有回歸專題的需求，只是所有討論導向客棧的背景下難以鼓勵新用戶第一下就是去參與專題。

（五）：帶來的負面影響也不大：即時負面影響當然不大，但長期負面影響一大堆。同時比對而言，若層遞式討論規範通過，在沒有人海戰術淹沒討論通告的情況下，當前唯一問題「缺乏用戶關注和使用機制」也獲得解決。反方除了「沒人用」以外未曾能提出任何其他新機制會造成長期負面影響的重大問題，拿比較沒有負面影響的新制度跟有一堆重大問題（包括你所同意的第二三點）的舊制度比較，為啥要繼續使用有問題的舊制度？

（甲）：不論是什麼討論，向其他受影響條目/主題的討論頁發送討論通告應是基本討論禮儀。在條目討論頁發起的討論，因主題影響重大需要較多關注則當然應該向客棧發討論通告；在互助客棧發起的討論，需要參與有關條目編輯的用戶關注，自然也應該向有關條目討論頁發送討論通知。「應」已經包含「非強制滿足的條件」而只是「強烈建議」的做法，沒做沒有後果但絕對可以被其他人提醒或要求做，做了自然是最好。

（乙）：「僅影響單一條目的討論須在條目討論頁發起」是否帶來足夠大的負面後果呢，您所舉的「陋習」缺乏即時性的危害，影響亦有有限。最顯而易見的多個即時性危害包括：造成互助客棧討論板過長、影響不大的條目埋在其他巨型討論中無法被關注（所謂互助客棧的部分討論串熱度不高）、損害用戶間先行通過個別討論解決問題的基礎溝通交流。另外，依客棧長年置頂的要求，討論應是先在討論頁發起後無果才轉移至客棧。假設用戶遵守了這一點，那麼在討論頁中已經開展了一段時間的討論再轉移到客棧的討論往往出現平行討論和討論斷層的問題。你沒看到的問題不等於不存在。

誘因是不會憑空變出來的，必須由社群給予誘因才能存在改變的誘因。不願給予誘因去改變的正是「懶」；社群在某些用戶放任有問題制度繼續運行同時壓縮改良制度空間卻期望改變誘因會從天而降才是不切實際、天馬行空的幻想。「反對聲音眾」，卻無法拿出真正無法被回駁的論點，有什麼用？--路西法人 2024年5月25日 (六) 05:38 (UTC)

一）正如您說的，置頂沒有人看；討論指引沒有人看，何以見得之下的討論有人看。自相矛盾。「Talk:陳牧馳」此處是兩個討論，請您留意S君的{{moved from}}模板。「列出「Talk:福建人、Talk:丹巴·岡呼雅格、Talk:陳牧馳」三個例子，沒有任何一則討論是掛過RFC模板的」，乃是事實。既然而此，我修正我的論述。問題是「條目通告不能起了導流作用」。

二）應該說基本上上方路西法人君提出了大量假設、臆斷，社群根本很難去驗證、證明。舉證責任本應在貴方。近者如此處：

在沒有人海戰術淹沒討論通告的前提下，客棧應當完全能達到引流效果。。何以見得編者會閱讀討論通告？此點假設是證明您整串討論串的重要要素，然而您甚至根本沒有簡單的推論。

有了RFC自動登錄討論列表和發送討論通告的機制，理論上客棧的討論通告能完全吸收原有能見度加上發送邀請個別專題用戶討論的通告，能見度反而會高於客棧本身，當然在沒有人海戰術淹沒討論通告的前提下。空話。問題是不能「完全吸收」。導流模板起了的作用要打折扣。「當然在沒有人海戰術淹沒討論通告的前提下」這句的前提是討論少，導流模板就會容易看到。置頂都沒有人看，指望人家看導流模板，是不是有點天方夜談。

而是什麼討論都被鼓勵送往客棧討論，而不先與熟悉有關主題的用戶討論，所以才沒有人有動力去維護、組織專題，因為根本沒有專題內先嘗試自行討論的誘因。客棧無限擴大使用範圍是奪走這個基礎誘因的主因。我完全看不到理論成立的基本理據。日維雖沒有互助客棧，但專題依然是簽名板。說明一連串的推測鏈根本不成立。連沒有人有動力去維護、組織專題都怪互助客棧，是不是有點過了？

遠者有：

「不需要限制誰要使用徵求意見制度」——以貴站習性，沒有好好規範的制度就會被用爛。。個人主觀臆斷。等

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

• 所謂「條目通告不能起了導流作用」，但移動的三則討論連「通告」都不存在，同樣不能以該三則討論論證「討論通告起不了導流作用」。「沒有人看」的原因在於客棧極長篇幅下這些列表和通告並不引人注目；但客棧改為限制用作討論條目討論頁難以滿足的討論後，客棧篇幅大幅縮小，「可以引人注目」的效果顯然會大增。
• 關於「何以見得編者會閱讀討論通告」，目前社群習慣閱讀客棧本身的topic list，在topic list中的討論本身就比隱身在下面的RFC討論列表更好被注意；在篇幅較短的客棧內，每則討論通告的篇幅佔比就會大增，也同樣相對會提高討論通告的能見度。
• 「置頂沒人看所以推斷導流模板沒人看」一說顯然是滑坡，兩者本就無因果關係。置頂沒人看，但討論還是有人看，這就證明問題在於很多人會選擇性失明，光是這則討論中某些用戶的論點對方針的選擇性理解已經能證明。再者，過往討論可見部分討論移交客棧仍然參與度低，這是反映某些不太被重視的話題本來不論在哪裏討論都會存在「參與度低」的問題，話題本身難以吸引流量並不能用以佐證某個制度失效。正如RFC/RFA2024本身是社群關注的議題，那麼就算放得多「偏僻」都會有人來參與；某些飽受爭議的議題也自然會有同樣的情況。在目前的客棧下，不受關注的議題被比較大的議題埋藏；在建議的新制中，討論通告都會在客棧有近乎相同篇幅的曝光度，這時討論是否夠人參與就在於議題本身而非其他因素了。
• 我說的是「客棧是（本地）無法組織專題的主因」，而並沒有說「唯一/必要因素」。我的推論中表明「客棧導致了沒有較小群體討論這個維護專題的誘因」，你未有實際證明這個說法不存在；而你的推論「沒有客棧的站點也是這樣，因此沒有這個因素」中存在否定前件的謬誤。如果本地無客棧，而仍然無法組織專題，那倒是則可將「編者本身缺乏組織專題的動力」認定為無法組織專題的主因。從頭到尾我的推論永遠都是「真的沒有第三方因素影響才確定是本身的問題」，我列出客棧的每一個問題都是儘可能排除被第三方因素影響而引致當前的狀況。反方的推論卻是「就算有第三方因素影響的可能性，都要先歸咎在本身的問題」，但這個問題可能從頭到尾就只是因為第三方因素導致的。
• 「沒有好好規範的制度就會被用爛」，本地大量例子啊。AIV沒好好規範就被濫用作提報非破壞，導致管理員難以處理；客棧沒有好好規範導致目前超出原先設計的使用框架，引發各種問題；RFDA沒好好規範就被有心人濫用以報復自己不同意的管理人員，甚至不用顧對方是否真的違規。這些還不足以證明「本地沒有好好規範的制度就會被用爛」嗎？

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

此提案將限制編者在互助客棧條目探討區發起若干類型之條目相關討論。該分區自二〇一〇年創立至今已十餘年，是本站目前最主要之條目討論機制，此次政策修訂涉及體制全盤變更，茲事體大；又此話題目前僅十五人參與，且長年參與實際編輯事務者可謂更少（如上方LuciferianThomas即指出某些參與討論的維基人實際上鮮少來客棧條目探討區），規模就該等重要之政策修訂討論而言顯然不足。故除在該頁面發送討論通告外，還有進一步開展諮詢之必要。

@20204622hkus、AliceYYin、Aronlee90、Asbtrl361442、August0422、Baomi、BigBullfrog、BlackShadowG、Carrot2333、Chu Tse-tien、Cmsth11126a02、CopperSulfate、Dabao qian、Dakhung、EleniXDD、Factrecordor、Fire-and-Ice、FradonStar、HYHJKJYUJYTTY、Happyseeu、Hat600、Heihaheihaha、Hercoffee、Interaccoonale、Irralpaca、JNO1、Jinxun、Justice3651d、KOKUYO、Kcx36、LHD、Lemonaka、Ma3r、Marvin 2009、Matt Zhuang、MilkyDefer、Milkypine、Miyakoo、Nostalgiacn、Perinbaba、Prince of Erebor、SilverReaper、Sohryu Asuka Langley Not Shikinami、Sprt98、Summerize、T45614631、TGTON、Taydou、The Puki desu：為確保實際參與者之權益在未來政策中獲得充分反映，並彌補此前提案未能有效促進社群參與之遺憾，本人在此不論立場偏好，以一次性（不重複）之正式通知，誠摯邀請近一個月內（正好也差不多是此提案出臺期間）使用過互助客棧條目探討區、且未曾參與上方任何討論的維基人，希望談談普羅大眾參與客棧及一般條目討論的經驗並做比較，俾評估相關制度調整之利害；更歡迎就此提案之內容及可行性直接提供些許意見（包括支持、反對及其他折衷看法均可），相信將能加速促進真正共識形成。另外，本人及此提案其他某些參與者之意見雖鮮明至甚、甚至趨於對立，但相信諸位當可不受上方包含本人在內諸多正反唇槍舌戰影響，自由且不受限制的發言。當然，諸位也可純粹關注話題發展，監督社群協商過程，或者提前準備「適應」之類，總之必然較「一無所知」為好吧。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月24日 (五) 22:37 (UTC)

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

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

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

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

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

Cwek引用WP:IAR作為依據，說「不墨守成規」，卻選擇性無視5P5「方針與指引所蘊含的原則和精神比字面措辭更為重要」的字句。建立共識的過程本身就是一層一層慢慢擴大的，方針將互助客棧放在討論頁之後正是反映這個原則，甚至也有明文表明應該如此。在互助客棧發起討論但未曾有關用戶討論也顯然沒有展示對解決編輯爭議的禮儀。在社群全面使用互助客棧的現況下，所有討論不經邀請有關聯用戶參與，專題無法持續有效運作正是反映互助客棧完全抹殺社群建立較小規模群體自行解決問題的能力。同時，Cwek完全無視無所列出互助客棧的多個重大問題，也無視解決客棧長年存在的問題才是提出限制必須使用有關機制的原因，更無視提案繼續容許用戶在客棧發送討論通知能維持當前條目探討板在沒有大量討論掩蓋的前提下可以存在「各處的討論都能獲得廣泛接觸」的優點，還完全無視在影響廣泛的議題中仍然容許使用客棧進行討論的機制。「因為條目探討板具有廣泛關注」而「不應該限制」本來就完全建基於偽邏輯之上，限制並沒有沒出條目探討板的優勢，且限制是旨在解決客棧本身具有的問題。

簡而言之：僅有在VPD大規模限縮使用的情況下，新機制在完全保留並理由互助客棧曾存在的優勢的，使客棧的流量被善用的同時，能排除互助客棧的缺點，更能鼓勵用戶才得以建立自行解決爭議而不需事事擴大討論的能力。--路西法人 2024年5月25日 (六) 05:59 (UTC)

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

你堅持迴避回應我指出5P5規定IAR是不必定要遵守細項而以方針原則為本，同時將其理解為如果你自己不喜歡就連原則都不需要遵守，乃是扭曲IAR、5P5及共識方針理解，就算你重複提多少次我都還是會將其視作無效論點。

你堅持迴避回應我指出客棧的各種問題，無論你如何包裝，那些問題都是確實存在的，且反方也持續無法真正針對我指出的問題作出回應。鬼打牆並不會使我退縮承認非針對提案回應的反對意見。--路西法人 2024年5月25日 (六) 08:20 (UTC)

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

專題缺乏關注人員在於所有討論都被推到客棧，自然沒人去專題發起討論，更導致沒人去關注專題，問題根源在於客棧設計。我也沒有強迫只能選擇專題討論頁，條目討論頁及（若涉及多個主題）客棧仍可作為選擇之一。這本身只是提案的其中一個選項，你的留言卻扭曲成提案只提供這一個選項，顯然是與提案無關的反對意見，依共識方針注釋一將視作無效意見。--路西法人 2024年5月25日 (六) 08:23 (UTC)

註：此處原有文字，因為Cwek發言持續假定惡意、訴諸動機，誹謗本人基於私心鼓勵偏頗共識。，已由LuciferianThomas(留言)於2024年5月25日 (六) 13:35 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

完全屬於臆測的留言內容，與提案本身內容無關，也非實際對提案本身的點評，依共識方針注釋一將視作無效論點。若再有任何無斷臆測、胡亂扭曲提案本質，將作離題以隱藏留言處理，並請求第三方管理員處理假定惡意（「推銷」、「提案者鼓勵偏差」等）及離題討論。--路西法人 2024年5月25日 (六) 08:28 (UTC)

另，所謂「使用新規則堵截提升討論者範圍」乃是完全展現反方完全沒有在讀提案。提案只是先行要求用戶儘可能自行解決爭議；在自行解決爭議無果後通知「特定專題」跟「互助客棧」是同一步的事情（都是徵詢第三方意見），不會存在「避免無關人士參與」的荒謬說法。若編者無自行解決爭議的能力，需要依靠其他人介入才能解決爭議，顯然只會產生出無法作出有效討論的社群。

另外，共識方針本身就有WP:CON#共识的级别，一來反映社群本身就可以存在不同級別的共識，所謂「不廣泛的共識」也仍是有效的共識；但同時也規限了這些「不廣泛的共識」不能凌駕更廣泛的社群共識（如方針指引、徵求意見和互助客棧所得出的結果等），本來就不會容許更多特定傾向的參與者可以形成對此傾向的把持。能說出這種話僅僅完全表明反方選擇性閱讀方針、選擇性閱讀提案，只抓部分內容包裝成自己不喜歡的版本然後拿來反對。局部理解當然會產生問題，不然我提整個整體提案來幹嘛？反方這種態度不就正正顯示了局部理解方針和提案的問題所在、如何無法作為有效意見採納嗎？--路西法人 2024年5月25日 (六) 08:42 (UTC)

註：此處原有文字，因為Cwek發言持續假定惡意、訴諸動機，誹謗本人基於私心鼓勵偏頗共識。，已由LuciferianThomas(留言)於2024年5月25日 (六) 13:35 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

註：此處原有文字，因為Cwek發言持續假定惡意、訴諸動機，誹謗本人基於私心鼓勵偏頗共識。，已由LuciferianThomas(留言)於2024年5月25日 (六) 14:32 (UTC))刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

(－)反对：據我經驗，就算關於一個單一條目的討論，有時也不是依靠活躍於該條目的人就能解決，不少情況下需要尋求更多人的意見，包括對維基規則熟悉的人，或在其他條目有相關經驗的人，而這些人不會主動出現在個別條目的討論頁。若依靠個別活躍者去@其他人來發表意見，也很可能會只召喚立場相同的人過來，令更熟知維基人事關係的一方獲得優勢。就算共識不一定廣泛，我們應該盡力讓共識廣泛，吸收更多人的經驗，而不是讓個別條目變成活躍者的小圈子。除非設立一個介面顯示近來有哪些條目發起了新討論，才能姑且考慮。另外順帶一提，我反而感到維基人過於喜歡去人家的個人討論頁發起討論，令到一些牽涉個別條目的爭議細節、編輯行為的背後動機，這些來龍去脈有時沒法被其他編輯者注意，或令到後來的編輯者難以追溯當時發生什麼事，例如令我感覺最差的《中年好聲音》在播映期間被全保護三個月一事，在其頁面討論裡就沒留什麼痕跡，整個過程也完全沒有詢問其他有參與編輯但在編輯戰期間沒有活動的用戶，顯得不尊重。雖然這好像是題外話，但也反映到討論的地方越小眾，越少人察知，越易構成危害。我始終主張讓多些人察知的精神，這重要過一些行政問題。--Factrecordor（留言） 2024年5月25日 (六) 11:45 (UTC)

又是一個沒讀提案就來反對的用戶。WP:RFC、WP:FRS和向客棧發討論通告不就是防止有偏見地找人討論的解決方法嗎？又不是只能ping不能招人，只是提供工具下不要移動討論而已。在社群越發成長之時，每一則討論都要「廣泛共識」顯然不可行。--路西法人 2024年5月25日 (六) 11:58 (UTC)

WP:FRS人手有限，只是聊勝於無，幫助不大。WP:RFC似乎原則上是可以的，但我關注的重點是多少人察知，正如被通知來討論的原因，長期以來互助客棧是主要的平台，我這個不新不舊也算有點貢獻的用戶甚至從沒被介紹過WP:RFC這種機制，所以WP:RFC或同類的機制似乎是需要更大的推廣，更多人參與，介面優化之類，再決定全面推行本主題的主張。--Factrecordor（留言） 2024年5月25日 (六) 12:26 (UTC)

我在上方的留言已經提及過為何RFC為何無法全面推行，這裏複製一小段出來：互助客棧條目探討板總長70頁，RFC討論列表一節僅佔1.5頁。這不是「徵求意見制度實績不彰」，而是互助客棧條目探討板的長度完全使RFC討論列表難以被注意。現在的情況跟在一整頁報紙上僅有一個小卡大小的版面說是有公告那樣。RFC根本尚未被給予完整的機會去運作，任何形式去擴大RFC能見度的動作又被抹黑成「推銷」，簡單而言就是反對RFC、不認為RFC有用的用戶實質上無限壓縮RFC的運作空間後說RFC沒人用。--路西法人 2024年5月25日 (六) 12:59 (UTC)

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

效果不好是在於機制被淹沒難以被注意而非機制本身的設計問題，你是哪一隻字看不懂？--路西法人 2024年5月25日 (六) 13:39 (UTC)

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

人沒看到何來有人「自願使用」？被埋沒然後歸咎在新制度之上，跟檢討受害者有何分別？--路西法人 2024年5月25日 (六) 14:29 (UTC)

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

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

僅「建議」就代表繼續放任有問題的舊機制繼續爛下去。反方為了佐證自己的論點，連「這些問題都是你發明出來」這樣的話都說的出來，拒絕真正去理解駁論，將問題歸在提出問題的人身上，顯然開始不講道理了，我也無義務再放任此類留言擾亂此討論串。無法真正回應問題之處而聲稱問題不存在，又無法證明問題實質上不存在的言論將按共識方針註釋所指「並非針對提案的發言」一律視作無效意見處理。--路西法人 2024年5月25日 (六) 13:47 (UTC)

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

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

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

「有人滿意」不等於「問題不存在」；「很噁心但又無奈」更代表需要改。--路西法人 2024年5月25日 (六) 14:34 (UTC)

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

正在組織內容，寫了一個下午了。--路西法人 2024年5月25日 (六) 14:05 (UTC)

統整

由於上方有用戶通知了大量用戶參與討論，此處開一節重新統整提案及上方正反兩方的論點及有關回應，以便新參與用戶能更簡明的瞭解上面近200則留言在吵什麼。

目前社群探討條目及模板內容等的「最高場所」為维基百科:互助客栈/条目探讨討論板，長期都會有大量的討論於該處發起，也是參與討論用戶最多、閱讀流量相對最高的社群討論板塊。經審視，我發現該板的討論串大多數是在該板直接發起而未有充分嘗試在討論頁與有關用戶商討達成共識；也有很大部分都是僅涉及個別條目的討論，根本不至於需要徵求全站用戶意見。該討論板的置頂規則自該板開設至今，一直存在「任何條目或模板的交流應考慮先在其討論頁發表，而若無人加入討論才可在此發起」的規則，顯然沒有被嚴格執行。

有討論板給各編者踴躍參與討論固然是一件好事。過往缺乏配套和措施，在個別條目討論頁發起討論確實難以引起其他用戶注意，越來越多人選擇在互助客棧條目探討板發起討論是可以理解的現象。然而，社群慢慢從「沒人參與才來客棧發起討論」演變成當前「直接在客棧發起討論」的情況。目前編者毫無節制地濫用（使用而未遵守板規）該討論板，以及該討論板本身的機制設計產生了以下問題：

1. 當前制度未能鼓勵用戶在徵求第三方意見前嘗試自行解決爭議。
2. 條目討論頁未被善用，對條目影響相對重大的討論反而不在條目討論頁商討，不知情的用戶瀏覽對應的條目討論頁根本無從得知有討論正在進行，更有機會在討論頁發起平行的討論串。
3. 部分先在條目討論頁發起的討論無法達成共識就移師互助客棧條目探討板徵求第三方意見，在原處之討論卻幾乎從來不會在此時關閉，形成平行討論。
4. 互助客棧並非新用戶「直覺」就知道是討論的場所。條目討論頁往往不會附有互助客棧的連結，新用戶發起或尋找討論最直覺就是在頁頂就有連結的條目討論頁。客棧便利舊用戶，也僅僅會變成舊用戶圍爐，新用戶除非被ping，否則都幾乎不會主動找上客棧。
5. 討論板頁面過長會導致載入及編輯儲存越發緩慢，在社群逐漸發展、需要討論的議題只會越來越多之下，這個問題只會越發惡劣。目前互助客棧條目探討板長度長期大於20萬位元組，過往亦曾發生討論時使用過多模板而無法載入的問題，顯然頁面過長是一個非常需要解決的問題。
6. 互助客棧討論串過多，本身性質比較不受關注的討論會更難被注意到，導致「以為遷移至客棧後能獲得解決」的議題送去客棧後也僅有寥寥數人參與討論，屢次發生討論無疾而終的情形。
7. 目前設計下，互助客棧的討論串可同時被存檔至多個討論頁。
   • 客棧經常發生討論無疾而終後自動存檔的情形。自動存檔後，討論未曾正式關閉，其他用戶看到討論就會以為討論仍然活躍，最終可形成平行討論串。
   • 就算討論已結束後存檔，重複的存檔亦可導致後續需要補充討論時出現平行討論串；分支存檔後的討論亦難以追蹤及維護。
   • 存檔後，難以在互助客棧的「存檔」中（存檔移動至討論頁後客棧僅存檔標題）查找話題有相當的困難，因為根本不知道存檔到哪裏去。
8. 客棧討論串過多時，討論於互助客棧發起，僅關注該單一主題的用戶需要多追蹤一個頁面的討論，每次來互助客棧檢查討論進度也需要找討論串。
9. 客棧無法讓用戶持續追蹤特定感興趣類別的話題，用戶僅能通過不斷查看並人肉篩查去找感興趣的話題。（比對專題討論頁和徵求意見機制）

有鑑於此，我提出了以下規範討論的遞進機制：

1. 為善用社群討論資源，
   1. 僅影響單一條目的討論須在條目討論頁發起；
   2. 影響多個屬相同主題的條目的討論須在主題條目、專題佈告板或任一受影響條目的討論頁發起，並在情況許可下其餘受影響條目的討論頁發送討論通告（若受影響條目過多，應以通知專題佈告板及@提及為主）；
   3. 影響多個主題條目的討論可在任一受影響主題條目的討論頁或互助客棧條目探討板發起，並應在互助客棧及受影響的主題條目的討論頁發送討論通告。
   4. 未有條目的討論可在適當的專題佈告板或互助客棧條目探討板發起。
2. 編者應先盡可能自行透過討論解決爭議，過早徵求第三方意見可能使爭議另一方認為其意見不被尊重。在條目討論頁發起討論時，應發送通知（@提及或用戶討論頁通告）涉爭議的用戶參與討論（如有）；在無法解決時邀請近期編輯有關條目／主題的用戶參與討論。
3. 錯誤場合發起的討論可被關閉（需指出重新發起討論的合適場所）或移動（需保留討論討論主題及移動目標頁面連結）。
4. 經討論頁討論仍無果或下列情況下——
   1. 過往曾討論而未達成共識或需要改變共識的議題；
   2. 討論影響多個條目；
   3. 高風險主題條目的討論，
   編者可往互助客棧發送討論邀請通告及將討論加入徵求意見系統以獲取第三方意見。
5. 在其他頁面發送討論邀請通告時，應在討論串中申報以免造成拉票誤會。會顯示文本的@提及則不需重複申報。
6. 除討論過長需要分拆為獨立討論頁、討論在錯誤場合發起等情況，不應在發起討論後移動討論串，以免造成混亂；討論結束後亦應讓討論原地存檔，避免重複在多個頁面存檔後出現討論分支。
7. 社群可考慮新增機械人任務向受影響討論頁發送討論通告及結論。

除了解決上方提及互助客棧條目探討板的種種核心問題，亦期望建議機制協助完成以下長期目標：

1. 重新建立編者間不需依賴第三方意見，建立自行理解方針指引要求、自行與發生爭議的用戶進行商討解決爭議的基本討論參與能力。
2. 減少互助客棧條目探討板的使用壓力，最大限度解決舊制度問題之餘，繼續善用互助客棧的流量及其他討論機制的優點輔助進行各類型討論。
3. 重新建立編者間自行組織專題協調內容建設及討論的能力。

以下綜合記錄反方提出的論點及有關回應（已按意見修訂提案的意見不列入此處）：

1. 建議機制依賴徵求意見，而徵求意見成效不彰——分兩部分回應：
   • 徵求意見在建議機制中僅是作為輔佐工具使用。沒有徵求意見協助推廣個別討論不代表社群應該毫無節制地將討論都塞進互助客棧。在條目討論頁等合適場所發起討論需要徵求外部意見時，仍可向互助客棧發送討論邀請通告，而並不需要重新在互助客棧發起或將討論移動至互助客棧。
   • 「徵求意見成效不彰」跟「徵求意見未能彰顯成效」是完全不同的概念。前者表示機制本身缺陷導致效果不好，後者表示機制因外部因素而效果不好。條目探討方面，目前徵求意見引起其他用戶關注的方法僅有在互助客棧的置頂通告及那一節的討論列表。置頂通告沒人關注或跟從是預期的結果，該板置頂模板存在了十數年的規則也是完全被無視。討論列表置於互助客棧的topic list之下，用戶往往在topic list找完主題就跳過討論列表，自然容易被忽略。更何況，互助客棧條目探討板（下筆時版本）70頁A4的篇幅，徵求意見列表僅佔1.5頁。這些都反映徵求意見本身都還沒獲得足夠機會完整展現效果，根本不可能逕下判斷說徵求意見機制效果不好。另外，有反方Ericliu1912的「善意」編輯損毀機械人閱讀WP:FRS的頁面格式，導致FRS停止運作將近半個月（且無人反映），當然無法展現效果。
2. 架空互助客棧——根據定義，架空是「比喻暗中受到排擠而失去實權」。此反對論點暗示了互助客棧的作用是被不公平地排擠了，然而我能輕易列出會對編者造成實際影響的眾多問題，有問題而被排除就顯然不是被「不公平」地排擠，而是因出現問題而淘汰。
3. 目前客棧還沒有非常明顯的負面影響——負面影響一直存在，版面過長導致載入困難或出現模板限制等都是非常明確的體現。其餘負面效果也當然存在，認真觀察不同討論的後續就能看到這些負面影響。只會逛客棧不逛條目討論頁的用戶當然看不到。
4. 違背互助客棧條目探討板設立初心——條目探討板設立之初已經存在討論須先在討論頁發起一段時間無人參與才能轉移的規則，這也是條目探討板的「設立初心」，目前互助客棧的使用情況才是真正違背該板設立初心的體現。
5. 不應限制/強制編者選擇在何處發起討論的自由——「自由」不代表「無政府」，也不代表可以造成傷害。目前無規範下，用戶無法遵守討論板規則而正確使用各討論板，那自然就要規範（WP:NOTANARCHY）。
6. 維基百科不是官僚體系或避免說明氾濫：理想情況下確實不需要如此明確的規則去規範，但社群目前缺乏自制能力下才必須如此。共識方針本來就已經包含「先在討論頁討論再在客棧發起討論」的有關條文，改變社群陋習後就不再需要如此明確的限制了。
7. 徵求意見制度應被視作互助客棧的「雅座」，不應強制分流——徵求意見本來就不是用來「分流」用，而是從源頭鼓勵用戶在討論頁發起討論後不要再移動。所謂「分流」僅會有移動討論的負面後果。
8. 討論發起人未必知道哪個主題條目、專題討論頁合適——新機制本來就容許在當下發生爭議的討論頁或（若涉及多個不同主題的條目）互助客棧，「主題條目」的定義也並不嚴謹，與有關條目的最有關聯的主條目的討論頁都能作為主持討論的場所，沒可能「找不到」。固然，目前專題的活躍度極低，這個期望編者們在更新制度，讓互助客棧不再被濫用積累過多討論時，編者們自然就會慢慢重新組織專題。
9. 機制鼓勵有同樣傾向的人士把持討論——機制設計讓編者ping人，拉票方針的規定依然有效，如果有用戶為了偏移討論共識而只拉特定傾向的用戶參與討論，仍然違反拉票方針。徵求意見、客棧發送討論邀請則無此憂慮。

另外補充為何上方討論的態度會變得如此差劣：Ericliu1912及Cwek等反方用戶的多次發言反映未真正閱讀、瞭解提案內容就提出反對，選擇性扭曲提案內容之餘，還持續拒絕回應對其反對意見的駁論，鬼打牆重複已被回應的觀點試圖拉布，同時無限扭曲、無視各處方針及規範。Ericliu1912在我要求下一直無法提出實質駁論，就開始指控我「球員兼裁判」Cwek亦開始造謠我推動此議案的動機和目標，完全無意認真討論。我謹此嚴正譴責兩名反方用戶為了闡述其觀點，無所不用其極地扭曲方針及提案、對我人格抹黑的行為。

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

目標宏大，然非一蹴可幾。只聞客棧罪大惡極問題多，條目討論頁問題豈少？且上揭問題兩者皆有者甚矣，尤其涉及討論程序部分，如難道換到條目討論頁就能有效關閉討論？這當然不可能，但既可歸咎於客棧罄竹難書，則何樂而不為？本人認為，這才真的是所謂「只會逛客棧不逛條目討論頁的用戶當然看不到」的東西，甚至可說是官僚式的「為解方找問題」了，此提案許多聲稱均是如此。改革管道繁多，舉凡存檔及討論機制調整等，可解決前述問題者亦不鮮見，偏選擇走此等險路，不顧既有類似之失敗結果（遠在此提案以前，成效即頗不彰；近期如Sanmosa君嘗試活用徵求意見制度之發展，則尚有待觀察），又不給社群另以折衷測試額外評估之機會，空口說白話承諾理想願景的「支票」誰都會開。包裹提案條文未臻清晰，強推作為頻出，自行定性詆毀意見、掃清異議障礙均在所不惜，也讓許多人退卻自行備案與分部詳細磋商的契機及興趣，此自不必多言；而妄想以政治手段全面鎮壓斥之以鼻而須矯正之所謂「陋習」，而非謹慎溫和而有敬意地加強引導、扭轉十餘年來社群自然形成之討論慣性，或自可收得一切順利無波瀾之死寂表象，然隱約不可見之損害必成於其下。對新手而言，鍛鍊熟悉寫作及溝通技巧，更需要老手議事相助——這正是互助客棧的職能，反而不應該鼓勵他們一開始直接去條目討論頁參戰。又新手若來互助客棧求助區求助，自然也就知道有條目探討區，得以踏出熟稔社群的第一步。本人已經不是新手，無欲多加揣測新手心理，但集中討論在此方面優勢極為顯著，甚至及於其他有經驗編者。

本人尊重編者儘可能想怎麼討論改進維基百科條目之自由，也欽佩願意在此話題中嘗試推動提案修正的朋友。從來沒人覺得限制凝聚共識的人數門檻、公意形成要件、改善討論關閉程序是壞事（實際上包含徵求意見在內，多數條目討論也存在同樣嚴重的問題），甚至積極分流討論更無妨，但只要有道理地就條目內容達成共識，憑什麼限制編者要在哪裡開啟討論或禁止在哪裡發表什麼類型的議題？憑什麼用一紙方針條文阻止編者自己找到合適的辦法改善條目？又兩三個人自己能解決的事，要求一開始就聚眾喧嘩做什麼？這種過度僵化的規定根本沒有必要，也沒有意義。由此衍生的其餘假想實際上都只是窒礙難行的枷鎖罷了。是放任自由討論還是箝制限縮討論傷害大？本人見過無數人抱怨互助客棧不夠好用，也有人認為可以多加善用條目討論頁、更適當移動或存檔討論等，但從來沒有人覺得應該據此禁止在互助客棧討論某幾種條目相關話題。提案人當然很明白「推薦」與「強制」之區別，但明確決定要走錯的路，這正是現階段此提案不應該通過的原因。近來無力就此等冗長討論之多加辯駁是事實，不過在恐怖氣氛下鋪陳論述有什麼用？以為沒試過？自從討論在此荒郊野外之處莫名其妙「續命」延長然後「絲滑」付諸公示之際，本人就已喪失繼續辯論下去的動能。換作誰面對這種話題恐怕都沒能力應付，上面也有人指出過了。「球員兼裁判」之說法，一點都不過分。其實這本來是個供正反各自充分陳述意見，開放社群討論協商，然後分節擬訂題目、付諸社群投票公決就能解決的議題，但只怕最後仍是一路碾壓，「七日無合理正當異議，公示通過」，太平無事。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月25日 (六) 15:15 (UTC)

• 上揭問題兩者皆有者甚矣，如何「皆有」？
  1. 過早提出徵求意見自然會該被其他編者打回，但客棧本就有此規而無人執行，你作為管理員對此不是協助執行而是視若無睹，更強詞奪理合理化有關行為。
  2. 此案正是旨在善用條目討論頁，顯然不存在此問題。
  3. 此案正是防止了移動討論而造成的平行討論問題。
  4. 不需我贅述也知道條目討論頁不會有這個問題。
  5. 討論頁多數情況下僅會有一則討論持續進行，除非持續討論很久，否則都很難發生討論頁過長的情況。
  6. 已結束討論可原地存檔，討論串不會被「淹沒」；不太受關注的討論反而得益於客棧長度縮短而更能被注意到。當然，仍然是無人關注的議題不論放哪裏都強迫不來。
  7. 此案設計正是解決分支存檔的問題。
  8. 討論沒移過，自然只需追蹤該討論所在的討論頁。
  9. RFC有提供追蹤特定主題討論，顯然解決了此問題。
  我有能力論述客棧的問題，請問你在哪裏有論述過「兩者皆有」的問題，以讓社群考量？如無，是否又是空口無憑，不提供論證的反對意見？我提出改革，論證改革要解決的問題的責任自然在我；你提出反對，論證改革存在的問題的責任自然在你，但你還是堅持不做。
• 改革管道繁多，凡存檔及討論機制調整等，可解決前述問題者亦不鮮見，如何「不鮮見」？類似之失敗結果，什麼的類似的失敗結果？Sanmosa移動的部分討論串連RFC都沒掛，何來「活用徵求意見制度」？是否又是空口無憑？
• 又不給社群另以折衷測試額外評估之機會，原話奉還給多次實質損害或阻攔各新制測試機會的你。
• 包裹提案條文未臻清晰：此處條文本來就不需要清晰，可選的位置就是寫得相對模糊，以讓在除了已經論證不合適的場所外任何真正合適的空間都能發起討論。
• 自行定性詆毀意見、掃清異議障礙均在所不惜，你和Cwek一來就人格抹黑，且持續未能作出實質論證，反過來還給你「自行定性詆毀提案、為了阻擋議案通過而不斷扭曲方針和提案均在所不惜」？
• 妄想以政治手段全面箝制、鎮壓斥之以鼻所謂須矯正之「陋習」，而非謹慎溫和而有敬意地加強引導、扭轉十餘年來社群自然形成之討論慣性，謹慎溫和的任何舉動都能被反方冠上「推銷」污名、多次以手段實質性負面影響任何溫和的引導舉動，外加社群本就有在不恰當的時候忽視規則的事實，否則何須嚴格管控？
• 對新手而言，鍛鍊熟悉寫作及溝通技巧，更需要老手議事相助，這從來不是「互助客棧（條目探討板）的職能」，這是「所有維基老手的職責」，不論在哪裏發起的討論都應該協助新手。
• 反而不應該鼓勵他們一開始直接去條目討論頁參戰，這句更是可笑之極。討論頁的討論就叫「戰」，有名字你叫的「互煮客棧」就沒有更「戰」？那豈不是更不應該鼓勵他們一開始就直接去互煮？
• 又新手若來互助客棧求助區求助，自然也就知道有條目探討區，認真一看VPH就知道區互助客棧求助板的用戶多數是因操作受限而求助，而非參與條目討論；以你的同樣邏輯，新手若是編輯甚至只是閱讀條目，都能看到頁頂「討論」二字，自然也就知道有條目討論頁。
• 再者，把新手引導至互助客棧條目探討板，你是想害死他們？連最基本的方針指引能力都缺乏的新手，引導他到眼花繚亂的場所參與編輯本就不合適；不知就裏的新手看到自己有興趣的話題插個嘴，但不熟悉方針指引，是送他們過去討罵？在客棧參與討論的用戶，多多少少都對方針指引有一定的熟悉度，新手一來就越級挑戰客棧很合理？
• 只要能在合理合法的條件下就條目內容達成共識，憑什麼限制編者要在哪裏開啟討論或禁止在哪裏發表什麼類型的議題？憑什麼用方針阻止編者自己找到合適的辦法改善條目？就憑客棧確實存在的問題，造成問題就該被限制。編者自己認為「合適的辦法」不等於問題不存在。想當然，你就會想以同一句說我認為合適的辦法不等於問題不存在，然而你指出實質的問題所在了嗎？
• 又兩三個人自己能解決的事，要求一開始就聚眾喧嘩做什麼？提案正是要用戶兩三個人自己能解決的事就自己解決，要求不要一開始就聚眾喧嘩，你這不是反而佐證有通過有關要求的需要？
• 從來沒有人覺得應該據此禁止在互助客棧討論某幾種條目相關話題，沒人提出就代表以後都不能提出？什麼道理？
• 明確決定要走錯的路，當前客棧運作不遵從反方口中的「初心」，這是已經走錯的路，反方還是堅持要繼續走；我的提案連運作都沒運作，路都沒上，何以看見是「走錯的路」？你是有穿越未來的能力？你一直堅稱我所為是「詆毀意見」，但你自己一直無法作出完整論述，就已經直接判斷是「錯的路」，何以不是「詆毀」？

每次我都費盡心機以儘可能詳細的方式分析你不論有多荒謬的說法，而你每次卻都以空泛無論證的論述唬弄過去，還好意思說你自己「無力」繼續說下去？--路西法人 2024年5月25日 (六) 18:57 (UTC)

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

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

（有關IAR）「忽略所有規則」並不意味着所有行為都有正當性。在過往沒有任何配套下，忽略有關規則是「尚可理解」但絕非「應被接受」；新制能提供改善配套下仍忽略有關規則顯然缺乏正當性。

（二）現在問題不在於用戶想不想用，而是客棧從來就不應該（置頂規則）不能再如此使用。

（三）移動討論除了有平行討論的問題，還有流失原先留言論點的問題；整串遷移更是讓不熟悉運作的用戶摸不着頭腦。新制雖說要將在不合適場所發起的討論移動，但我更傾向於將不合時機在客棧發起的討論儘早關閉並指導合適的討論區；如果討論已經開始，也應通知所有已參與用戶討論串已被移動。另，在討論頁發起且無重複存檔的討論，就算是停止了討論也是能原串直接重新開啟（各方論點完整可以被繼承）。

（四）既然互助客棧是需要「引導」的，那正是證明互助客棧並不是適合基礎條目討論的場所，而是後來才參與較廣泛主題討論的合適場所。

（六）「應該意識到」，期望新手「應該意識到」嗎？

（七）在客棧保留標題，是期望用戶背討論標題關鍵字嗎？更何況討論標題並不必然包含需要搜的字。僅有標題不是明顯比在各討論頁原處存檔直接能搜討論內容更好？另，討論通告也會有簡單的介紹內容（類似RFC的主題句），不是比寥寥數個字的標題更好搜？

（八）你都能說出「（關心需要廣泛性討論）互助客棧」，請問互助客棧現在僅僅被用作探討「需要廣泛討論的話題」嗎？顯然不是。關注特定專題這一點是RFC賦予的便捷之處，互助客棧一天繼續掩埋RFC列表，用戶不但不能關注客棧「需要廣泛性討論」的話題，也無法關注「特定專題」（因不多人知道用RFC），癥結點不是正正在於客棧目前的濫用狀況嗎？

如果這個提案者與RFC、FRS的關係沒有這麼明顯的話，或者有些編輯不會這麼介意「必須」這種強硬規則措辭。所以是論證你們說話是對人不對事咯？

傾向「建議」、「推薦」的力度，我也已經論證過「推薦」是沒人會去遵從的，單單是繼續容許任何的漏洞都會繼續擴大互助客棧的缺點，直到再一次爆破為止。--路西法人 2024年5月25日 (六) 18:57 (UTC)

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

您說的對，其實真的沒有規則阻止我在不將此案納入方針下照樣做這些動作以解決客棧問題。有關「建議」，我也已經論證過十萬次「建議」是沒人會去遵從的，目前使用RFC已經是「建議」，有用嗎？--路西法人 2024年5月25日 (六) 18:57 (UTC)

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

70頁的互助客棧裡，RFC的討論列表僅佔1.5頁，多數客棧的參與者更是在RFC之上的客棧話題列表直接點章節標題跳過該處討論列表，「應者寥寥」的原因不顯而易見嗎？RFC並不是因為自身設計而「失敗」，而是因為現有制度壓擠而未曾實際以full capacity運作作測試。這部分不能說「不思進取」，而是「連能進取都未必知道」。

至於將FRS放在顯眼處，客棧的討論規則也是在置頂模板的顯眼處、頁面過長建議使用RFC的通告也是在置頂的顯眼處，但顯然仍然沒幾個人會去注意，光是放在「顯眼處」顯然是行不通也不足夠的。--路西法人 2024年5月25日 (六) 18:57 (UTC)

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

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

RFC的核心在於用戶瀏覽不同類別的討論列表找到自己想要討論的話題，FRS只是附加的協助。當RFC核心的討論列表被淹沒，RFC僅剩下FRS的通知，當然是不夠人參與。另外，可以觀察到：有些討論很常連涉及有關條目的編者都沒通知過就直接轉客棧或RFC，這正正也是建議機制要求用戶先通知有關編者的原因。補充一點：我之所以說Ericliu1912不斷使手段壓縮RFC測試機會正是因為他對RFC相關內容做的動作很多都是不斷縮小、隱藏有關內容，比如在客棧頁頂模板試圖隱藏RFC討論列表使RFC列表更容易被忽略。即使不是他的原意，他的小動作確實有壓縮RFC空間的效果，然後再來論述RFC效果不好，顯然不可理喻。--路西法人 2024年5月26日 (日) 04:40 (UTC)

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

究竟你有沒有認真讀提案和論點？目前的討論都放在客棧，新手無從參與，當然難以鼓勵新人加入討論，當然「活人人數本來就夠嗆」「完犢子」；每天卻不乏用戶在條目討論頁發起話題討論，顯然證明條目討論頁對新手老手都是最直覺的討論場所，新手也容易加入討論並從討論慢慢往社群其他討論發展和理解。--路西法人 2024年5月26日 (日) 04:46 (UTC)

(！)意見：我相信在哪裏發起討論，包括發起人在內的社群自有公論；提案要每個頁面點擊一次才能參與條目討論。 -- 月都 ※ 2024年5月25日 (六) 20:09 (UTC)

你是沒編輯條目多久了？難道參與討論的時候就不需要先閱讀條目內容是什麼？本來就是要點開看條目的，問題在哪？新制下不論從條目往討論區或從討論區往條目或從客棧瀏覽討論列表去討論區都只是點一次，舊制下從條目去客棧討論才是跳級的事情吧？更何況，很多用戶都是在客棧頁頂的討論列表點章節標題下去討論，這也是「點擊一次」啊，有何分別？--路西法人 2024年5月26日 (日) 04:43 (UTC)

WP:太長不看；相對而言大概也有「太多連結不點」吧。不過我也是支持不試試看是要怎麼知道效果如何那邊的，本維都有個無限試行的RELIST了，這怎麼不也來試行一下。（雖然我個人是懷疑會點進VPD的人應該都有預期要看長頁面了，再多按好幾次連結是否只是徒增無謂的操作次數）--WiTo🐤💬 2024年5月26日 (日) 06:00 (UTC)

會點進VPD的人應該都有預期要看長頁面了是否反映客棧對新手和僅追蹤單一討論的用戶不友善？另，如上方所述，參與討論的時候就不需要先閱讀條目內容是什麼？正常參與討論的人本來就是要點幾次去看看條目內容如何、爭議版本是什麼，在VPD討論並不代表這些動作就會消失不見（當然，不讀條目就討論的人是另一種問題）。若討論在客棧以外的頁面發起，多點一次連結能防止客棧出現討論過多造成的問題，那麼如何能叫做「無謂」？--路西法人 2024年5月26日 (日) 08:01 (UTC)

共識同時考慮支持者多少和意見是否合適兩者。問題是整串討論串我只能找到「路西法人」君一人實際支持而已，和一兩票的無論述、無參與式的支持。這違反共識應採納多數人的意見，並和重要少數的意見作出適當妥協。一项。我建议阁下最基本的是找第三方管理试著调停，判断共识。谢谢。--Ghren🐦🕑 2024年5月28日 (二) 06:59 (UTC)

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

貴方真的很愛選擇性摘錄方針，就算再違背方針背後的原則都要選擇性摘錄。共識方針表明「共識應當考慮到所有正當合理的意見」，請問反方存在極大量邏輯謬誤的滑坡論證叫做「正當合理意見」嗎？共識方針源自英文維基百科，原文A consensus decision takes into account all of the proper concerns raised. Ideally, it arrives with an absence of objections, but often we must settle for as wide an agreement as can be reached. When there is no wide agreement, consensus-building involves adapting the proposal to bring in dissenters without losing those who accepted the initial proposal. 哪裏有提及過「採納多數人意見」？更何況，討論不是點人頭，維基百科也不是民主體制，所謂「少數服從多數」本來就是本站對共識的超譯，這一點UjuUjuiMandan在他的RFA中回應問題時的論述共識根本和「多數」「少數」無關，只和「反對意見有沒有被考慮、有沒有向反對意見妥協」有關說的非常清晰也十分合理。

在這則討論當中，反方提出的論據大多空泛無實質論證，僅有少數論述還能叫做有論證過（雖然存在非常顯然的邏輯謬誤）；反方的反對因素我也有非常積極的考量，並在提案中提供對應措施去解決反對意見中提及新制可能面對的問題，在我提案部分有遺漏的地方也適時採納部分反方意見修訂提案。相反而言，反方除了給我強加標籤抹黑之外，在我多番提出客棧存在的問題後，一直到25號才終於有用戶正面回應我列出客棧的問題。該用戶回應認同部分問題存在，其餘的表述也有反向證明客棧存在問題。

至於所謂「無其他人實質支持此提案」，這顯然是因為正方同意提案自然不會有什麼打意見，反方不同意提案才會有大篇幅留言回應，以此來認定那些是「非實質」的支持顯然並不合理。有明確支持提案的用戶有冥王歐西里斯、CaryCheng、Ma3r；與Sanmosa的來回討論也在進一步修訂條文後獲得其「不反對」、WiTo也指出可以試行（上面已經論述過此提案本身就是方針原則的執行，有問題則應改善新制，而非一棒打回原先的問題，所以「試行」除了「安慰反方」外無意義）。Kethyga提出可以參考的項目也大概同意提案的推行。認為應該只是「建議」而非「強制」的用戶意見（0xDeadbeef、微腫頭龍、桐生ここ）則顯然可理解作認同理念而僅不認同執行方式，不是「支持」也不是「完全反對」。提出反對意見也就你Ghren、Ericliu1912、Cwek、HK5201314（有按其提出的情況調整提案，異議可視作已解決)、月都（整個論述跟實際情況毫不相符而不考量）和Factrecordor（僅是因RFC「未成熟」），這個情況下要把「反對意見」視作「多數」更是難以置信。

我當然能理解用戶對強制的限制有所疑慮，例如「真的有需要時會被過度限制」。我在上面的表述有說過，強制性的措施在於儘可能改變本站編者會造成問題的「習慣」，未來在重新全面審視共識方針錯誤翻譯、違反核心原則的條文時，以最佳做法（而非強制措施）的形式重新融入方針（如明確共識需要逐層建立的原則），而不再需要強制性措施。

所以真的不用再出來搬弄方針來營造提案和用戶意見缺乏任何效力的假象，反方真的不需要也不能因為無法以沒有明顯謬誤的邏輯回應駁論就開始玩程序戰拉布。--路西法人 2024年5月28日 (二) 10:24 (UTC)

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

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

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

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

我作為提案人，當然有責任指出並回駁反方論述不符合邏輯之處。反方多名用戶一直沒有辦法嚴密地論證其邏輯，甚至提出的觀點一則比一則多邏輯謬誤、選擇性摘錄並扭曲提案條文和方針原則等荒誕議事行為。每一次我都以盡所能及縝密的邏輯去分析其觀點中存在的謬誤之處才會將意見視作「非正當合理意見」；反方不予回應、辯駁，然後就徑自給我冠上「強推討論」、指控我「球員兼裁判」等污名。「合理」，詞解「合乎道理或事理」，該等反方用戶的論證能夠被輕易挑出邏輯問題，甚至連多條重大方針都能扭曲理解，顯然不可能「合乎道理或事理」而構成「正當合理」的意見。

你所指由於這些問題的複雜性和模糊性，好像難像形式邏輯的命題那樣，通過純粹的嚴密邏輯推理來做出判斷和說服，這一點說得對，但還有一點需要延伸。雖然確實無法非常全面地針對問題的每一個向度進行嚴密的邏輯推理，但針對每一個用戶提出的每一個觀點則能被檢驗邏輯，這也是我正在做的。如果我的提案中存在邏輯錯誤，例如早前其中一位反方用戶指出我原先提案一來就ping其他未涉事用戶與我提案要求逐步遞進討論有所牴觸，我也非常樂意接受意見並修正。邏輯有錯就認、邏輯有錯就改，而不是像該等反對用戶辯不過邏輯就開始給我冠惡名。--路西法人 2024年5月28日 (二) 15:55 (UTC)

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

(！)意見

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