維基百科討論:共識

頁面內容不支援其他語言。
維基百科，自由的百科全書

共識建立的遞進步驟[編輯]

是否應該修改互助客棧及達成共識的流程，規範討論必須先在條目討論頁發起，如有必要才發起徵求意見或互助客棧討論，並限縮互助客棧的使用範圍？臺灣杉在此發言 (會客室) 2024年5月29日 (三) 12:37 (UTC)[回覆]

依據RFC的規範進行摘要。臺灣杉在此發言 (會客室) 2024年5月29日 (三) 12:37 (UTC)[回覆]

第一階段討論[編輯]

推行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)[回覆]
不要總是習慣將未發生的事情就交給明天的社群，你不會知道社群陸續退步的有多嚴重。現在放寬鬆，未來再收緊，還是會再出現更多問題。有需要改善的點再來談「需要改善」，不然一切只是空談。--路西法人 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)[回覆]
  1. 提案第二及第三點矛盾：已修訂用詞，確實遺漏。
  2. RFC部分不用「可」：條文本身並未表示「僅」或什麼情況「不可」，若有人如此超譯則顯然應無視。但亦已稍微修改用詞用句。
  3. 「損失流量」：此提案仍然存在讓用戶在廣邀意見的時候往客棧發討論通告邀請討論，而客棧也會長期掛着討論連結，不見得在清空客棧積壓後會有非常嚴重的流量損失（尤其是目前客棧流量顯然也不比RFC多很多）。點段落標題跟點進討論頁都是一步的事。
  4. 討論不活躍、無共識本就隨時可以重啟，但以完全站不住腳、未曾能完整回應我反駁的所謂「反對」論點來以「社群不採納」結案就絕對不可能。我推提案每次都是正面回應問題，反方就「側側膊」裝作看不到我對其論點的反駁，甚至將過往至今顯然仍然對此案有重大意義而目前制度無法做到的規則指引等訴諸無用、過時，談何我「強推」議案？
過往社群缺乏充足配套，以客棧為討論集中地尚可理解；現在配套充足提案從頭到尾都只是在目前本地配套更完善的背景下，將客棧置頂長久以來都存在且仍有重大意義的限制付諸更明確具體的實行；反方卻從頭到尾拒絕考量當初的規則未被遵守而造成今天的問題。反方打不倒「任何條目或模板的交流應考慮先在其討論頁發表」這條自客棧設立存在至今的置頂要求的意義就甭想阻攔此提案以某種形式實現。我無任歡迎社群用戶參與討論並指出此遞進制度的缺陷所在（如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)[回覆]
  • 您上面邏輯推理論據引用的UjuUjuiMandan在他的RFA中回應問題時的論述，是其回應在下的對四個參選人提出的同樣的問題時有爭議的表述。UjuUjuiMandan和我在討論將結束時都認識到我們的觀點仍然分歧而且無法說服對方，並表明各自仍然保留各自的看法。
  • 針對他上面關於人數的觀點，在下認同這樣的表述： 總的來說，雖然正確與否不應僅僅基於人數多少，但在實際操作中，民主和社會契約的原則導致了多數決的做法。這是一種平衡個體權利和集體利益的方法，儘管它並不完美，但在許多情況下被認為是最公平的解決方案。詳細解釋在下面：Wikipedia_talk:共識#少數人的選擇是否應該在無法通過討論來說服多數的反對者情況被採用？--Gluo88（留言） 2024年5月28日 (二) 19:32 (UTC)[回覆]
    背景：UjuUjuiMandan論述是針對我的問題的回應。 我向四個參選人提了同樣問題。按照我的理解， 四個參選人中只有UjuUjuiMandan 認為共識根本和「多數」「少數」無關 。
    1. Wikipedia:何謂共識#不是多數表決"51%的人傾向的選擇通常並不足以形成共識，而只有少數人支持的選擇更基本不可能是共識"。
    2. 所以我提出：避免採用只有少數人支持的方案。如果一個方案沒有得到大多數人的認可，那麼它可能不是最佳選擇，因為它可能無法代表大多數人的利益。
    3. UjuUjuiMandan 不同意上面觀點， 認為一件事對還是不對和人數多少沒關係，主要看論述 。 但在下覺得UjuUjuiMandan的觀點不符合： 上面引用的Wikipedia:何謂共識#不是多數表決中的表述。
      • 我的回應為： 關於「主要看論述」， 雙方對同一論述可以有相反看法。總的來說，雖然正確與否不應僅僅基於人數多少，但在實際操作中，民主和社會契約的原則導致了多數決的做法。這是一種平衡個體權利和集體利益的方法，儘管它並不完美，但在許多情況下被認為是最公平的解決方案。
    4. 按我的理解，另外三個參選人認可我的觀點。 我不認為UjuUjuiMandan觀點在社群中有共識， 我不認可用「共識根本和「多數」「少數」無關」的這個論述做為邏輯推理的合理依據
    --Gluo88（留言） 2024年5月29日 (三) 01:43 (UTC)[回覆]
    Wikipedia:何謂共識#不是多數表決不是方針，就算其觀點不符合該論述也完全沒有問題。本身「不是多數表決」這一點建基於「雙方理據都各有道理」，WP:共識方針本身就要求考慮「正當合理」意見。在反方意見被邏輯論證質疑是否正當合理時，反方無法反論證自己的邏輯正確，無法證明自己邏輯正確的論述都站不住腳，不可能是「正當合理」的意見。「不認為UjuUjuiMandan觀點在社群中有共識」，沒有共識不代表該點並非方針本身的核心觀點和原則，正如上方的用戶即便再不同意方針或某些規則，都不能否定那些是方針的一部分。WP:5P5指出「方針與指引所蘊含的原則和精神比字面措辭更為重要」，而「多數意見」則自始至終都不是共識的核心原則（參見英文維基百科原版方針），方針中重複出現的「正當合理意見」才是。就算「未曾經過共識檢驗」，也不代表原則不存在。所謂「民主和社會契約的原則導致了多數決的做法」則根本不可能是在維基百科的合理觀點，維基百科不是民主體制，自然無需「跟從」民主制的多數決（尤其是多數決本來就存在多數暴力的問題，不論觀點是否合理，人多就贏，這顯然不合理）。--路西法人 2024年5月29日 (三) 02:18 (UTC)[回覆]
    1. 維基百科不是民主體制表述：「維基百科不是民主體制或任何政治體制的實驗。這裏尋求共識的主要方法是討論，而不是投票」， 強調不是單純投票。
    2. 共識一定遵守了民主的原則，因為它涉及到集體討論和決策，這是民主的基本組成部分。共識強調了參與、包容和多樣性的意見，這些都是民主價值觀的核心。共識決策是民主決策中，加上集體討論和決策和一致同意（有時可能略有變通，可另討論）。
    3. 民主不一定遵守了共識討論、參與、一致同意原則。
    4. 共識主要是一致同意，少數人可以否決多數人的提議。 目的是避免多數決本來就存在多數對少數暴力的問題（尤其是多數決本來就存在多數暴力的問題，不論觀點是否合理，人多就贏，這顯然不合理） 。
    5. 共識決策中中，不論各方觀點是否合理， 更不容許少數人觀點和提議強加於多數人。
    --Gluo88（留言） 2024年5月29日 (三) 02:40 (UTC)[回覆]
    你說的最後一點「不論各方觀點是否合理」的說法已經跟共識方針的原則有所牴觸。不再回應不顧觀點是否合理而提出沒有共識的觀點。--路西法人 2024年5月29日 (三) 02:43 (UTC)[回覆]
    1. 有不同看法是正常的。我認為，「不論各方觀點是否合理， 更不容許少數人觀點和提議強加於多數人」是符合「共識方針的原則」。
    2. 我們可以請社群研討，發表意見， 也可查查可信來源的論述。
    --Gluo88（留言） 2024年5月29日 (三) 03:22 (UTC)[回覆]
    「不論各方觀點是否合理」顯然完全違背共識方針，不是你「認不認為」就行。--路西法人 2024年5月29日 (三) 09:16 (UTC)[回覆]
    1. 閣下只取了「不論各方觀點是否合理」。
    2. 我認為，「不論各方觀點是否合理， 更不容許少數人觀點和提議強加於多數人」是符合「共識方針的原則」 。 要點為： 更不容許少數人觀點和提議強加於多數人。
    3. 在下理解共識表述為，共識不是只是數人頭而不討論不妥協。 理想的共識是一致同意，判斷一致同意就需要數人頭，確信包含了所有人頭。所以在討論和妥協工作後，判斷共識時需要數人頭。
    4. 我們可以在客棧公開討論。 也可以到英維公開討論。
    --Gluo88（留言） 2024年5月29日 (三) 11:15 (UTC)[回覆]
WP:太長不看；我承認上述的討論，我可能沒有詳細完整的看完，在目前的理解下，我不贊成此一提案。我參與過維基百科一段時間，我同意我在有條目相關問題時應該要先在討論頁討論，若有問題還可以用WP:RFC徵求更多人的意見。若還是無法解決，再提報到互助客戶的條目研討。（我跳過維基專題，因為我覺得以現況來說，大部份在維基專題上的討論效果不大。）但這對於剛接觸維基百科的新手而言，難度高了一些。而且可能在條目討論頁、維基專題討論頁提出後，就沒有下文了（這部份透過WP:RFC可能會有些改善，但效果還不明確）。--Wolfch (留言) 2024年5月29日 (三) 04:08 (UTC)[回覆]
想請問「難度高」而言，如何定義「難度高」？哪一些操作比較「難」？另外上方也論述過，對新用戶而言，最直觀能找到的是條目的討論頁，而互助客棧條目探討板往往是用戶遇到過濾器等問題才會找到客棧的求助板，繼而才找到客棧的條目探討板，找客棧條目探討板顯然不是一件容易的事情。對於兩個新用戶之間的討論而言，大概本身就不懂得找客棧烙人討論，不懂得使用RFC也應該可以理解的。
另外，請真的讀一下#第三階段討論所整理的論點。我的整理中指出了此提案除了處理原則性問題外，還有處理了客棧被濫用的問題。您不贊成這個流程，那麼對於客棧目前被過度使用的看法是什麼？目前對於客棧眾多問題沒有全面改制以外的選項，在該等考量下你認為客棧的有關問題是否應被解決？--路西法人 2024年5月29日 (三) 08:27 (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)[回覆]
社群討論中應確保每一方提出的意見都能經受邏輯檢驗。這不僅是為了保證討論的質量，也是為了確保決策的合理性和公正性。如果一方指出反方的觀點中存在邏輯漏洞，而反方無法有效回應，那麼這應被視為反方論點的一個重大缺陷，而非單純的「選擇不參與」或「沉默」。在邏輯討論中，沉默更常被視為默認其論點存在問題，這並不是一種合理的爭辯策略，反而只表明反方難以辯駁其論點中的邏輯漏洞。即便反方表達未被說服，但這並不能改變其論點中存在邏輯漏洞的事實。邏輯錯誤的存在是客觀的，無論個人主觀上是否接受，事實仍然擺在那裏。在共識體制下，討論的目的是通過論證來達成共識。這意味着每個觀點都需要經過嚴格的邏輯檢驗，並且能夠經受住質疑和反駁。只有這樣，才能確保討論的結果是合理且公正的。因此，如果反方的觀點存在邏輯漏洞且無法有效論證，那麼這些觀點就不能被認為是「正當合理的意見」。--路西法人 2024年5月29日 (三) 01:40 (UTC)[回覆]
  1. 如果正方已經說服反方或者社群：「反方的觀點存在邏輯漏洞且無法有效論證」， 那麼這些觀點就當然不能被認為是「正當合理的意見」。
  2. 如果只是正方自己認為：「反方的觀點存在邏輯漏洞且無法有效論證」， 是否這些觀點也不能被認為是「正當合理的意見」？
--Gluo88（留言） 2024年5月29日 (三) 02:01 (UTC)[回覆]
邏輯是客觀的，只要能指出邏輯的漏洞，就不是「個人的認為」而是「論述事實」。--路西法人 2024年5月29日 (三) 02:07 (UTC)[回覆]
  1. 同意「邏輯是客觀的」。
  2. 「邏輯是客觀的」能從邏輯上推導出： 「只要能指出邏輯的漏洞，就不是「個人的認為」而是「論述事實」」嗎？ 請社群其他人參與評判？
  3. 指出邏輯的漏洞，可能是漏洞也可能不是。
--Gluo88（留言） 2024年5月29日 (三) 02:53 (UTC)[回覆]

少數人的選擇是否應該在無法通過討論來說服多數的反對者情況被採用？[編輯]

(？)疑問 少數人的選擇是否應該在無法通過討論來說服多數的反對者情況被採用？

前面討論中LuciferianThomas閣下認為：「更何況，討論不是點人頭，維基百科也不是民主體制，所謂「少數服從多數」本來就是本站對共識的超譯，這一點UjuUjuiMandan在他的RFA中回應問題時的論述共識根本和「多數」「少數」無關，只和「反對意見有沒有被考慮、有沒有向反對意見妥協」有關說的非常清晰也十分合理」。

  1. 不知LuciferianThomas是否認同 Wikipedia:何謂共識#不是多數表決"51%的人傾向的選擇通常並不足以形成共識，而只有少數人支持的選擇更基本不可能是共識"？ 少數人的選擇更不能在無法通過討論來說服多數的反對者情況下， 被強行採用。？
  2. 如果LuciferianThomas仍然堅持採用UjuUjuiMandan上面觀點為有效的邏輯推理依據，社群是否先需要討論產生共識以便修改Wikipedia:何謂共識#不是多數表決中「少數人支持的選擇更基本不可能是共識」的表述，並且添加認可少數人支持的選擇可以是共識表述？--Gluo88（留言） 2024年5月28日 (二) 19:13 (UTC)[回覆]
那一段方針的表述當然要修，但「UUM版觀點未被社群廣泛審視」沒有共識不代表沒有道理。WP:5P5指出「方針與指引所蘊含的原則和精神比字面措辭更為重要」（即WP:規則只是原則），當前WP:共識方針的條文跟核心方針WP:NOT（WP:NOTDEMOCRACY）有所牴觸，NOT顯然比共識方針的層級更高。加上比較共識方針兩站條文差距，英維版本的WP:CON與WP:NOT無牴觸，也顯示本地當前條文的詮釋並非方針本身的原則和精神。「多數人」不代表可以沒有邏輯沒有討論然後亂來，因為人數多而在討論中越過邏輯的基本需求則會造成更大的問題。「多數人」並不能代表他們的意見就「合乎道理」，不合理的意見就算多少人都是不應該被考量的。極端例子：一則討論有20名用戶發言，15名用戶留下反對時沒有解釋或解釋中存在不能接受的謬誤，此時雖然反對方為多數，但不代表反對方的不合理意見應被考量在「多數」之內，因「考量所有正當合理意見」本身是共識的基本要求。--路西法人 2024年5月29日 (三) 02:03 (UTC)[回覆]
  1. 社群對"當前WP:共識方針的條文跟核心方針WP:NOT（WP:NOTDEMOCRACY）有所牴觸"是否有共識？ 如果沒有，很難認同用此理據做邏輯推導。
  2. 同意「沒有共識不代表沒有道理」。但是，一般來說，多數人的選擇（如3/4）有道理的概率比很少數人的選擇（如LuciferianThomas的選擇-參選者1/4））要大。
  3. 雖然正確與否不應僅僅基於人數多少，但在實際操作中，民主和社會契約的原則導致了多數決的做法。這是一種平衡個體權利和集體利益的方法，儘管它並不完美，但在許多情況下被認為是最公平的解決方案。
  4. 共識決策中，不論各方觀點是否合理， 更不容許少數人觀點和提議強加於多數人。
--Gluo88（留言） 2024年5月29日 (三) 02:49 (UTC)[回覆]
我覺得共識雖然不是數人頭，但也不能完全不顧人頭數吧？假設一個有20個人參與的討論，其中有18個提出反對但使用的都是有邏輯漏洞的理由（不包括狀況外的），那我覺得剩下的那2個即便理由再合理再完美也已經無法反應共識了。但如果當中只有15個人反對或更少，那他們的不合理意見確實可以被忽略。總結一下，我認為共識雖不是民主投票，但若反方的比例高到一定數量（比如以80%為界限），正方的理由再完美也不能被視為共識了。以上例子只是假設，不是在說本次討論，只是發表一下我對共識的見解。--微腫頭龍（留言） 2024年5月29日 (三) 03:03 (UTC)[回覆]
在下理解共識表述為，共識不是只是數人頭而不討論不妥協。 理想的共識是一致同意，判斷一致同意就需要數人頭，確信包含了所有人頭。所以在討論和妥協工作後，判斷共識時需要數人頭。 共識的核心是靠說服和協調，如果論述不能說服人，甚至僅有少數人同意， 論述者則應該努力改善論述以及妥協，來產生一致同意的理想共識， 少數人的選擇更不能被強行採用。--Gluo88（留言） 2024年5月29日 (三) 03:14 (UTC)[回覆]

對共識理解的探討[編輯]

看到社群對共識理解有分歧，希望能通過討論，幫助解決社群共識解讀中的分歧。 最近在網上查找和研習有關資料，整理出下面論述， 要點如下：

  1. 共識通常是通過討論、協商和達成一致來形成的。在民主制度中，人們有權發表意見，而決策通常應該反映大多數人的意願。因此，共識在某種程度上與民主原則一致。
  2. 民主原則強調每個人的平等權利，但並不一定要求每個人都達成共識。在民主決策中，多數人的意見通常被視為代表集體意願的一種方式。
  3. 共識隱含民主的原則，因為它涉及到集體討論和決策，這是民主的基本組成部分。共識強調了參與、包容和多樣性的意見，這些都是民主價值觀的核心。
  4. 然而，民主不一定隱含共識。民主制度允許多樣性和不同意見的存在，決策可以通過多數票而非全體一致來實現。在民主過程中，可以通過投票來解決分歧，而不是必須達到完全的共識。
  5. 因此，共識是民主的一種理想狀態，但民主本身並不要求每個決策都必須達到共識。民主更多地關注如何平衡不同利益和觀點，以及如何通過公正的過程來做出決策。

--Gluo88（留言） 2024年5月28日 (二) 22:06 (UTC)[回覆]

然而維基百科不是民主體制。--路西法人 2024年5月29日 (三) 02:08 (UTC)[回覆]
  1. 共識是民主體制的一種， 而且是加強版的民主。 因為它涉及到集體討論和決策，這是民主的基本組成部分。共識強調了參與、包容和多樣性的意見，這些都是民主價值觀的核心。共識決策是民主決策中，加上集體討論和決策和一致同意（有時可能略有變通，可另討論）
  2. 然而維基百科不是民主體制 表述為投票不能代替討論。 「參見：Wikipedia:投票不能代替討論。 維基百科不是民主體制或任何政治體制的實驗。這裏尋求共識的主要方法是討論，而不是投票。」
  3. Wikipedia:何謂共識("51%的人傾向的選擇通常並不足以形成共識，而只有少數人支持的選擇更基本不可能是共識")--Gluo88（留言） 2024年5月29日 (三) 02:45 (UTC)[回覆]
取自 "https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:共识&oldid=82834044"