維基百科討論:共識/討論頁及共識方針試行案/原始討論存檔

本頁是以往討論的存檔。請勿編輯本頁。若您想發起新討論或重啟現有討論，請在當前討論頁進行。

討論1：共識建立的遞進步驟

最新留言：1 個月前351則留言29個人參與討論

本主題或以下段落文字，複製自Wikipedia_talk:共識#重要：涉及限制互助客棧條目探討區討論之政策修訂。執行人：臺灣杉在此發言 (會客室) 2024年10月5日 (六) 06:38 (UTC)。

以下討論是徵求意見的存檔紀錄，請勿修改。本次討論所達成的總結如下：

公示通過，試行方案即日起施行，相關後續討論請到WP:CON/TRIAL及WT:CON/TRIAL進行。臺灣杉在此發言 (會客室) 2024年6月26日 (三) 03:58 (UTC)

如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

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

#第三次公示。臺灣杉在此發言 (會客室) 2024年6月18日 (二) 15:34 (UTC)

第一階段討論

原標題為：原始提案

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

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

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

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

不認為應該限制編者的發言自由，設立此強制規定並無必要。方針上僅建議即可。--桐生ここ★[討論] 2024年4月9日 (二) 23:05 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我贊同Eric Liu這一說法。我並不覺得徵求意見系統目前有濫用情況，所以不需要限制誰要使用徵求意見制度。個人不太了解客棧條目探討區的實況，不過看起來要求單一條目的探討強制挪到討論頁不妨是個好方案。--0xDeadbeef (留言) 2024年4月8日 (一) 12:44 (UTC)

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

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

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

如果RFC沒有被濫用，為什麼要給提RFC加上前提呢？--0xDeadbeef (留言) 2024年4月9日 (二) 13:31 (UTC)

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

原諒我不能理解。我沒見過RFC被濫用，我也想象不出來RFC被濫用。我個人的意見是害怕這會有WP:CREEP的問題。也許你維人太少，導致沒什麼可聊的話題被掛上RFC之後也沒人管，也許你維人太多，你一句我一句導致VPD討論太多。若存在有人只討論一個條目又不在條目的talk頁面發起討論的問題的話，應當處理這樣的問題。如果存在VPD討論太長而影響到閱讀，則確實應該想辦法把一些本不應該在上面的討論挪走。我目前還是沒時間去了解具體問題是什麼。0xDeadbeef (留言) 2024年4月9日 (二) 16:15 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(！)意見有個想法，這個RFC是否可以和相關專題聯動，比如討論1，或許關注單個條目和討論頁的少，但是相對來說關注香港專題的應該大有人在，關聯到專題模板可能會讓更多編輯或讀者關注到。另外對應（優良）條目評審也可以考慮加入RFC中。

在en:Wikipedia:WikiProject Biography/Article alerts專題條目動態中支持Requests for comments，可以在條目動態中直接跳轉到條目頁面對應的rfc頁。比如en:Talk:Ariana_Grande#RFC:_LEAD_IMAGE就出現在上面的傳記條目動態裡面。這個可能要問下@Shizhao

另外維基數據和英維分別有d:Template:Ping project與en:Template:Mass notification，可以ping到相關專題的參與者，也是個不錯的方法。--Kethyga（留言） 2024年4月9日 (二) 01:03 (UTC)

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

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

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

還是認為以自願為原則，用RFC還是客棧，要視項目討論者的意願，而不是依靠兄台你賣力地推銷。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月9日 (二) 02:26 (UTC)

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

壞處只是你的主觀認為，你現在的做法純屬強制推銷，愛用RFC的可以在RFC推進討論，不愛用或者不需要用到小心討論可以維持在客棧進行。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月9日 (二) 05:33 (UTC)

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

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

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

客棧的en來源（Village pump）如果放到Google上搜索就可以發現就是一家酒吧，這也可能就是它的典故來源，其叫什麼名字不是重點，其重點就是它的定性：社群的一個通用討論區。所以為什麼需要廣泛討論的內容更適宜放到這邊上，當然考慮到社群紛爭太多，會偶發性導致頁面膨脹，導致某些用戶體驗不佳，所以RFC可以充當分流的單獨「雅座」。但如果濫用「雅座」的話，甚至強求分流到「雅座」的話，無論怎麼解釋，都看上去在架空某些東西。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月9日 (二) 05:39 (UTC)

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

不同範圍的共識在哪裡確立並不應該限定其出處，從極小範圍的條目討論頁，限定特定編輯主題的專題討論頁，到更廣泛影響的大型討論頁，包括客棧，或者RFC。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月9日 (二) 05:42 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

WP:共識#形成共識的誤區和錯誤：

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

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

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

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

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

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

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

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

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

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

感謝你花時間寫下這些。同我上面的回覆的一些意見，我覺得這個alternative比較更合適一點。--0xDeadbeef (留言) 2024年4月9日 (二) 16:17 (UTC)

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

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

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

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

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

對，因為你需要推銷你的「產品」，所以才不為餘力地要求社群必須按照你的想法盡力地使用RFC而無形間地架空客棧，但現時來看，社群認為應該需要用RFC自然會選RFC，不需要的話就還是在客棧等其他討論頁面解決，你不喜歡客棧的討論氛圍，但也不能將你的「美學」強加於社群。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月10日 (三) 00:42 (UTC)

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

因為你也僅僅基於你認為影響到你的觀感（諸如頁面加載，或斥之陋習），然後反覆推銷RFC，甚至現階段變本加厲地認為應該強制地以確定共識的討論位置，借着稱可以利用RFC和回饋提醒機制來推銷自己的RFC。以上不需要我的詳細，因為這就是你現在所做的。客棧的現象（或者以你的觀所以認為，稱之為陋習）我不認為是陋習，或者我更願意稱之為一種慣例。我的最終觀點依然認為：共識的確立位置不應該強行地確定其確立的位置，無論是在客棧、各範圍的討論頁、還是RFC，我認為現在RFC在客棧的目錄列出已經足夠彰顯其作用，社群愛用RFC就去RFC解決，愛用客棧則在客棧解決，貴您愛用RFC就用你愛的RFC去討論，現階段的做法我認為已經足夠。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月10日 (三) 06:04 (UTC)

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

回應：

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

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

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

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

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

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

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

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

因為社群的慣性的確是將各種廣泛性的問題放在客棧解決，而你斥之為陋習，就算你沒直接聲明需要「架空客棧」，但搞出一個RFC機制來分散討論，甚至還期望強制設立共識確立位置的規定來限制客棧或者推廣RFC的使用，但這些做法怎樣看都是不滿於RFC的利用不足而嘗試架空客棧。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月10日 (三) 06:09 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一次公示（已停止）

以下討論是徵求意見的存檔紀錄，請勿修改。本次討論所達成的總結如下：

停止公示，進行後續討論。臺灣杉在此發言 (會客室) 2024年6月19日 (三) 11:09 (UTC)

如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

原標題為：公示版本

原標題為：第二階段討論

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

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

即新增規範如下：

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

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

在以下情況下，編者可[..]將討論加入徵求意見系統以獲取第三方意見：我的疑問是這一句話是否代表如果以下情況下不適用的話是不是就不能用RFC系統了？--0xDeadbeef (留言) 2024年5月11日 (六) 03:28 (UTC)

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

例如

以前討論過但無法形成共識的
以前討論過、也形成共識的，但共識貌似已經改變了（或需要試圖改變）的討論
從一開始便能知道影響較大、應當有很多人來參與的討論，例如這裡？

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

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

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

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

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

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

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

(！)意見：關於您剛才提到的第三條，可以針對該分類含有的條目數量來判斷（例如若分類中的條目數量大於100條，可直接將討論通告發送至互助客棧）。--WiiUf ——青龍出世，傲視蒼穹 2024年6月13日 (四) 10:45 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

.

可以這樣改

.

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

.

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

.

可以這樣改

.

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

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

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

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

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

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

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

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

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

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

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

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

回應：

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

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

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

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

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

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

感謝通知，我希望提案人先不要急着公示通過，讓我們先看看新的方針條款，謝謝。--桐生ここ★[討論] 2024年5月19日 (日) 08:40 (UTC)

沒有細讀上面的討論。我唯一害怕的是這其實是一個XY問題，而可能是工具規律下造成的WP:CREEP。我仍然不反對這個提案，但是如果說最大的問題是有人不在正確的地方開討論，我覺得更好點的切入點應該是鼓勵他人移動討論，所以最需要改的應該是明確指出哪裡是讀者應當開啟討論串的地方。英維的區別就是英維有一群知道自己在做什麼的編輯，能在討論早期的時候便給你指出來在哪裡討論才是最正確的。當然，之前通過移動戰已經看到這方面還沒出現共識，我的想法是條目討論除了很重要的事情不要在客棧上（事實上英維沒有討論條目的客棧）。0xDeadbeef (留言) 2024年5月14日 (二) 10:20 (UTC)

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

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

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

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

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

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

其實這個方針也可以這樣寫：在互助客棧條目探討板發起，且僅影響單一條目或影響多個屬相同主題的條目的討論應被移動至任意受影響條目討論頁或專題布告板進行討論。

我這樣寫的原因是認為就算你用多強硬的須，你改變不了仍然會有人使用WP:VPD討論單一條目的現實。所以你能怎麼辦呢？如果最終結果一樣，都是要去移動討論串，那是不是還不如從一開始就寫移動討論串。要是以後有人說「你在這裡發起討論違反了方針」是真的聽上去有點沖。

但是你們倆在討論什麼，我沒看懂。。--0xDeadbeef (留言) 2024年5月15日 (三) 09:34 (UTC)

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

沒仔細看上面，但有依據且不建議移回，本身就是鼓勵了。以習慣養成的循序漸進和需要觀察來說，不應一竿子打死在VPD發起。同0xDEADBEEF的看法。--YF dyh000（留言） 2024年5月15日 (三) 10:01 (UTC)

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

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

沒有寫清楚開始要去哪裡發起留言但是其實我本意就是分開寫，一部分寫可以移動討論，另一部分寫討論最好哪裡發起。practically，這和僅影響單一條目的討論須在條目討論頁發起的方針在實行上是沒有區別的，只是移動討論這一行為的依據不同：若方針里側重在於移動發起位置不理想的討論串，則在移動的時候可說「方針說要移動討論，所以要移動討論」。若使用你的版本，則在移動的時候要說「因為方針要求你必須在這裡發起討論，所以我必須移動你的討論串」。這兩個的區別就在於後者容易遇到人的異議「憑什麼限制我發起討論串的地方？」而前者則更難有人反駁（因為本來移動到正確的地方沒什麼人有異議吧）。--0xDeadbeef (留言) 2024年5月18日 (六) 14:25 (UTC)

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

叫你做就做，我不會告訴你為什麼有這個要求顯然不是。我上面的是在指實行時的論證而不是寫方針的論證。若問題是客棧討論太多，移動討論串是更明顯的解決辦法。我的版本也完全可以加入為善用社群討論資源更完整。我的版本主要是基於助推的一種實行方式。多的就沒什麼可說的，我沒時間。--0xDeadbeef (留言) 2024年5月19日 (日) 14:54 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

想請問如果我違反了上述條文，直接在客棧發起討論而不在討論頁發起討論會被採取措施或被懲罰嗎？可能上面的一連串討論有提到，但我不是很想讀完。--微腫頭龍（留言） 2024年5月18日 (六) 13:12 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

關於指引。

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

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

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

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

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

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

關於條文。

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

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

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

回：

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

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

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

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

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

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

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

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

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

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

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

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

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

遠者有：

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

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

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

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

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

為確保實際參與者之權益在未來政策中獲得充分反映，並彌補此前提案未能有效促進社群參與之遺憾，本人在此不論立場偏好，以一次性（不重複）之正式通知，誠摯邀請近一個月內（正好也差不多是此提案出臺期間）使用過互助客棧條目探討區、且未曾參與上方任何討論的維基人，希望談談普羅大眾參與客棧及一般條目討論的經驗並做比較，俾評估相關制度調整之利害；更歡迎就此提案之內容及可行性直接提供些許意見（包括支持、反對及其他折衷看法均可），相信將能加速促進真正共識形成。另外，本人及此提案其他某些參與者之意見雖鮮明至甚、甚至趨於對立，但相信諸位當可不受上方包含本人在內諸多正反唇槍舌戰影響，自由且不受限制的發言。當然，諸位也可純粹關注話題發展，監督社群協商過程，或者提前準備「適應」之類，總之必然較「一無所知」為好吧。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年5月24日 (五) 22:37 (UTC)

（技術限制得分成兩批，不過倒也可由此見條目探討區還是很活躍的）—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年5月24日 (五) 22:37 (UTC)

(＋)支持，如果我理解得沒錯的話：（以條目討論為例）如果條目討論無果，不再去客棧發起討論，而是通知客棧的人（或者類似的效果）來條目討論。既然 Ping 到我，我說說個人體驗：我一般不去客棧，只是在條目討論無果（討論人數也很少，可能就兩個）時，才去客棧發起討論，這樣確實能讓更多人參與（可能十幾二十個）。所以我覺得，如果像我理解的這樣，還是很好的：既能吸引更多人參與，又不用去監視客棧。--Ma3r（鐵塔） 2024年5月25日 (六) 08:57 (UTC)

(－)反對，無論提案者如何「故意無視」或者「否定」其他不同意者的意見，或者出於推銷自己維護的討論提醒機制，我認為關於條目編寫問題的共識，不應該限制其討論的位置或者使用的工具方式，更應該考慮其他可能涉及的或者期望的參與範圍大小，也就是，即使針對單一條目的討論範圍，也不應該其只在或者先在其討論頁進行討論頁，我認為條目探討版是現在我們社群最具廣泛接觸性的討論場合之一，可以作為更廣泛的共識確認和接觸場所，不應該只依賴於討論提醒機制。可以鼓勵使用，但不應該限制必須使用這套機制。所以第1點的「必須性」並不「必須」，應該傾向建議了，同樣第3點同理。無論提案者想拖多久，說得多「動聽」的理由，只要提案者不對這種強制性的要求作出改變，或者如此粗暴干涉過往的討論慣例，我對此仍保持反對意見，並以WP:IAR為依據。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 00:59 (UTC)

總體來說——如果對某個條目方面的問題（範圍從單一條目頁面、特定專題或者主題（沒有對應專題跨專題的情況），到對於整個項目的條目都有涉及的情況）：如果希望能得到整個社群的留意、或者針對特定專題的條目類別的對應專題觀察上缺乏活躍，可以選擇條目探討版來討論；如果針對特定專題的條目類別的對應專題觀察上足夠活躍並能局限於專題內的討論，可以選擇在專題下的討論頁來討論；如果只局限於特定單一條目，且參與者都能或者同意只在可控的討論場所範圍進行討論的話，可以選擇在單一條目頁面上討論。條目涉及範圍越廣，就越可以和應該提升討論場所的層級（從單一條目討論頁、專題討論頁、到條目探討版等更大範圍的討論版塊（如果有））。而且，上面這些做法，並不強制依賴或者需要討論提醒機制。

反而，我認為應該控制討論層級的隨意調整，提升層級可以適當放鬆，但下降層級要限制（例如需要儘可能所有參與者同意的情況下），避免頻繁移動討論層級。這一點我認為更具實際意義。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 01:17 (UTC)

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

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

我的觀點依然是根據條目的問題所需要的覆蓋性或者共識廣泛程度，而選擇相應的討論層面，而不是單靠規則（並且使用「應」這樣強硬的規則式語氣）來限制如何達成共識。無論你說的多冠冕堂皇，我依然指出你所說的「問題」僅僅你自己創造的問題，並且為自己創造的問題創造自己的所謂的答案，包括所謂的加載問題。所以我對IAR在這方面的理解是如上面所說的，而不是死規矩地先在指定的地方討論問題，並且配合使用那個討論提醒功能，或者隨意地以不符合規則地關閉或者移動討論。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 06:18 (UTC)

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

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

「專題無法運作」本身也存在專題缺乏關注參與人員的表象（或者說，由於我們社群活躍強度太低了，必然導致一些專題無法存在足夠活躍的參與，或者足夠活躍的討論），而不是原因，不應該以此作為強迫將對應專題的條目問題討論應該圧回對於專題的討論頁，還是上面所說，如果涉及的需要參閱範圍過大，可以一步優先在範圍更廣的條目探討版處理，也一定程度上令關注或參與不活躍的專題對應條目也可以得到更多的關注場所。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 06:25 (UTC)

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

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

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

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

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

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

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

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

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

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

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

作為RFC機制的引進者，難道不應該正視存在有編輯對這些機制的負面意見？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 13:05 (UTC)

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

或者「被埋沒」不就是其必然遇到的問題？如果所有乃至大部分編輯自願使用，那就不會被埋沒，甚至也不需要這樣強推強制改變？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 14:04 (UTC)

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

如果特定條目內容在有限討論位置的範圍內沒有充足或者預期沒法有充足的討論時，自然會考慮將其放到更廣泛的討論地方，也就是條目探討版。而且可以看出，現時仍然存在編輯不認同或者不了解RFC、FRS，所以不應該以強制要求讓這些編輯去關注這些機制，應該使用寬鬆的「建議」性去推薦使用，不想使用這些機制的編輯完全可以按照已有的討論慣例做法去完成條目內容的討論與共識的達成。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 13:03 (UTC)

對於RFC的提案者如此強推態度，我能接受的考慮也就是：對於討論時間過長（或者預期過長）（長度的判斷：可能超過兩周，因為從條目探討版來看，一部分已經不活躍的討論，基本持續兩周以內就似乎能解決）的情況下，應該建議使用RFC另頁討論，避免過度擠占頁面（解決頁面加載問題）；保留「正在廣泛徵求意見的議題」在條目探討，作為FRS在更廣泛的場合的提醒引導；使用RFC另頁討論的，應該保留指引路徑在條目探討版，作為提醒引導。——2024年5月25日 (六) 13:18 (UTC)--此條未正確簽名的留言由Cwek（討論｜貢獻）於2024年5月25日 (六) 13:18 (UTC)加入。

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

看到這個議題已經爭論許久了，能不能幹脆在客棧列明使用條目討論頁和互助客棧的好處及壞處，然後由社群投票決定是否強制規定須在討論頁發起討論？現在正反雙方再辯經下去沒完沒了，議題觀點來來去去就那些且雙方誰也不服對方。而且如果強制通過但後續大部分人不願遵守也沒用啊。先聲明，我對這個提案的初衷和想法十分認同，互助客棧也確實有許多毛病，但好像不是所有人很在意這些毛病。--微腫頭龍（留言） 2024年5月25日 (六) 14:02 (UTC)

正正是這個問題，如果仍然有相當一部分編輯不認為這套方案好用，就算提案者強推，依據過往好用的討論方式繼續（也就是IAR的「如果有規則妨礙您恰當地改進或維護維基百科」，這種強制方式阻礙了這些不滿意這套機制去「改進或維護維基百科」），他們也會忽略這套規則，畢竟原來的方法一樣能達成條目討論的共識。「僅「建議」就代表繼續放任有問題的舊機制繼續爛下去。」不就是提案者認為的「問題」？說了這麼久不是仍有一批編輯不滿意這些方式（即使你否認這些意見）？應該採取寬鬆的方式，或者按照現時對RFC、FRS在條目探討版的使用，各走羅馬路，作為對比，讓編輯們自己選擇好的方式。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 14:17 (UTC)

或者如所說，這套機制看着爛（屎山那種），但有編輯們願意用，或者不在意，能維持下來：很噁心但又無奈。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 14:24 (UTC)

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

「有人滿意」、「有人不在意」就給了這個提案的「非必須」性，如果將這些措施的強度傾向「建議」、「推薦」的力度，或者可以避免這個討論這麼對立（至少我也闊佬懶理，你也不用語氣強硬；也可能我也會掂量着什麼程度的條目討論放到什麼程度的範圍，根本用不到這些規則）。還是上面那句：各走羅馬路，作為對比，讓編輯們自己選擇好的方式。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 15:08 (UTC)

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

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

第二階段討論

原標題為：重新統整提案及參與者意見

原標題為：統整

原標題為：第三階段討論

LuciferianThomas版本

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「該討論板的置頂規則自該板開設至今，一直存在「任何條目或模板的交流應考慮先在其討論頁發表，而若無人加入討論才可在此發起」的規則，顯然沒有被嚴格執行。」或者就是IAR的體現：「如果有規則妨礙您恰當地改進或維護維基百科」，或者編輯認為「若無人加入討論」特定範圍的討論頁（針對特定條目或者特定專題（可能是缺乏活躍的專題）），他是不是可以直接提升到條目探討版去處理？關於問題點：點1、只是闡述現狀，沒意見。點2、前面說了，如果相應的討論參與者本身就不想用？點3、討論版的「存檔問題」（完成討論應該即時存檔（頁）），或者部分討論參與者急眼了會沒留意條目探討的討論，應該指導位置繼續討論，另外也存在部分過了良久的討論（可能超過一個月）已經停止討論後，仍有編輯試圖接續，而不是重開新討論（並可以提及前討論）。點4，當新用戶接觸編輯熟悉的話，互助客棧遲早是需要了解的地方，而且部分規則也提到互助客棧的存在。老用戶也應該適當做出引導。點5，加載問題是一定程度存在，但可以藉助RFC等機制解決，而且觀察來看，一部分討論能在2周內討論靜默，或者可以進入存檔處理。點6，單一個討論過長的情況，無論何種方式都有可能存在編輯因為冗長而不願意繼續討論情況。點7，與點3 「存檔問題」類似，而且應該意識到這樣的移動討論可能已經完結（可能變成無法達成共識），而不應該接續；而且正確使用saveto的話，現時自動存檔是能保留原來在條目探討的標題和討論對應的頁面（看不出這算是問題或者缺點）。點8，與編輯的習慣有關，存在只關注「（關心需要廣泛性討論）互助客棧+關心的特定專題+關心的特定條目（+不使用討論單獨監視）」，如果不關心相應版塊的，可以不監視對應。點9，不反對意見。提案者雖然提出對於這些問題，的確存在一定的合理性，甚至提案者表達出強烈的「希望社群參與者自己先自行在有限小範圍內解決條目規範問題」，但似乎也不完全是必要必須地改掉的，也就是如前面討論的存在編輯提到「但好像不是所有人很在意這些毛病。」。如果這個提案者與RFC、FRS的關係沒有這麼明顯的話，或者有些編輯不會這麼介意「必須」這種強硬規則措辭。如果將這些措施的強度傾向「建議」、「推薦」的力度，或者可以避免這個討論這麼對立，並且給這些機制一個展現的機會（至少現在放在方針、條目探討版應該足夠不埋沒，對於願意關注的人來說），各走羅馬路，作為對比，在滿足現時討論需要和規範的情況，讓編輯們自己選擇好的方式。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 15:33 (UTC)

（準備休息，並且不想再為這種應該是可選的規則浪費精力，後續不再回應，只能說大路朝天，各走羅馬路）我期望的讓步就是（前面的）「對於討論時間過長的情況下，應該建議使用RFC另頁討論，避免過度擠占頁面（解決頁面加載問題）；保留「正在廣泛徵求意見的議題」在條目探討，作為FRS在更廣泛的場合的提醒引導；使用RFC另頁討論的，應該保留指引路徑在條目探討版，作為提醒引導」，最終的規則應該偏向「建議」、「推薦」而不是通過「必須」搞規則「革命」。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月25日 (六) 15:33 (UTC)

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

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

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

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

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

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

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

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

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

(！)意見雖然EricLiu通知的是沒參與本頁面討論的用戶，不過我一直有看討論，沒想到越吵越烈。還是建議別弄得像立法院一樣，維基百科是很直接行動的，很多事情是在實際運作中解決，而不是辯論解決。我個人認為這種事情從實際上講只能是「建議」。有用戶提到頁面長、加載速度慢，但實際上頁面內容長期以來都是文本為主，加載速度往往是受到MediaWiki為有個人設置的註冊用戶渲染而非直接使用緩存、用戶個人js過多（例如用來編輯特定頁面或命名空間的js因缺乏設置在任何頁面都加載一遍）等影響。btw上面有些用戶的js加起來可能比互助客棧還長。——暁月凜奈 (留言) 2024年5月25日 (六) 16:14 (UTC)

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

@LuciferianThomas：那個機器人停止運作半個月都無人反映問題，說明絕大部分用戶完全不在乎那個機器人的通知以至於這麼長時間沒有受到通知都沒察覺。我個人也放過幾次rfc，但基本應者寥寥，但一丟到客棧就有一堆討論了。這是否說明目前社群還未能夠適應新的機制，或者說是「不思進取」、「甘於現狀」？我覺得如此倒不好強逼所有人都到討論頁討論，否則恐怕會引起巨大反彈。還有，我覺得Wikipedia:回饋請求服務的訂閱人數目前不太夠，需要考慮怎麼推廣，可能可以把訂閱的鏈接放在客棧或其他較為顯眼處？感謝閣下細心整理討論，不過看樣子閣下的提議是不會被多數人接受了。--微腫頭龍（留言） 2024年5月25日 (六) 17:09 (UTC)

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

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

RFC的討論列表占的篇幅短只是一點，有許多人收到機器人發的通知後都沒有前來討論。雖說參與與否是個人自由，但如果嘗試數次都無人積極響應可能會令rfc使用者懷疑，究竟有沒有人在乎那個機器人的通知，還是說大家都是直接點掉通知欄的小藍點然後當作沒事發生了。因此我覺得社群現在的心態顯然還沒做好準備接受這套新機制，十多年的老頑疾確實很難一夜之間改過來。

那個RFC放得地方其實完全不顯眼，因為大家都是直接跳到感興趣的章節里的。我覺得放在目錄的上方可能效果會更好，雖然會有點怪。--微腫頭龍（留言） 2024年5月26日 (日) 01:11 (UTC)

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

中維活人人數本來就夠嗆，經常是丟一個問題結果半天沒人理，再限制討論單一條目那更完犢子。--BigBullfrog（𓆏） 2024年5月25日 (六) 19:08 (UTC)

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

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

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

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

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

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

確實，目前看來只有路西法君一人支持該提案。我本人雖認同他的初衷，但反對強制推行。--微腫頭龍（留言） 2024年5月28日 (二) 07:04 (UTC)

我也是同感 -「我本人雖認同他的初衷，但反對強制推行」--Gluo88（留言） 2024年5月30日 (四) 04:40 (UTC)

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

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

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

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

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

甚至本來是部分支持、不反對階段性推動，卻因為提案人堅持不讓步、要立刻施行一些現階段根本不經濟的作法，搞得只能全盤反對，避免砸掉討論體系。近日本人會考慮另行草擬較溫和的版本提出，應可爭取社群更多支持。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年5月29日 (三) 17:22 (UTC)

社群合理的決策程序問題重要性可能比提案本身影響更大。如果他仍然把所有反對意見全部僅按著自己的意願而定性為非「正當合理意見」，是否很難看出是能按共識方針的本意處理提案？
不知您和其他管理員團隊成員，是否能先協助按共識方針的本意解決社群合理的決策程序問題？
也請社群發表意見，是否應該先協助按共識方針的本意解決社群合理的決策程序問題？是否可以不故其他人的反對，一直堅持將所有反對意見全部僅按著自己的意願而定性為非「正當合理意見」？ --Gluo88（留言） 2024年5月30日 (四) 04:38 (UTC)

延伸內容

摺疊用戶持續扭曲方針理解發表的擾亂發言--路西法人 2024年5月29日 (三) 15:28 (UTC)

您上面邏輯推理論據引用的UjuUjuiMandan在他的RFA中回應問題時的論述，是其回應在下的對四個參選人提出的同樣的問題時有爭議的表述。UjuUjuiMandan和我在討論將結束時都認識到我們的觀點仍然分歧而且無法說服對方，並表明各自仍然保留各自的看法。
針對他上面關於人數的觀點，在下認同這樣的表述：總的來說，雖然正確與否不應僅僅基於人數多少，但在實際操作中，民主和社會契約的原則導致了多數決的做法。這是一種平衡個體權利和集體利益的方法，儘管它並不完美，但在許多情況下被認為是最公平的解決方案。詳細解釋在下面：Wikipedia_talk:共識#少數人的選擇是否應該在無法通過討論來說服多數的反對者情況被採用？--Gluo88（留言） 2024年5月28日 (二) 19:32 (UTC)
背景：UjuUjuiMandan論述是針對我的問題的回應。我向四個參選人提了同樣問題。按照我的理解，四個參選人中只有UjuUjuiMandan 認為共識根本和「多數」「少數」無關。
1. Wikipedia:何謂共識#不是多數表決"51%的人傾向的選擇通常並不足以形成共識，而只有少數人支持的選擇更基本不可能是共識"。
2. 所以我提出：避免採用只有少數人支持的方案。如果一個方案沒有得到大多數人的認可，那麼它可能不是最佳選擇，因為它可能無法代表大多數人的利益。
3. UjuUjuiMandan 不同意上面觀點，認為一件事對還是不對和人數多少沒關係，主要看論述。但在下覺得UjuUjuiMandan的觀點不符合：上面引用的Wikipedia:何謂共識#不是多數表決中的表述。
  - 我的回應為：關於「主要看論述」，雙方對同一論述可以有相反看法。總的來說，雖然正確與否不應僅僅基於人數多少，但在實際操作中，民主和社會契約的原則導致了多數決的做法。這是一種平衡個體權利和集體利益的方法，儘管它並不完美，但在許多情況下被認為是最公平的解決方案。
4. 按我的理解，另外三個參選人認可我的觀點。我不認為UjuUjuiMandan觀點在社群中有共識，我不認可用「共識根本和「多數」「少數」無關」的這個論述做為邏輯推理的合理依據

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

Wikipedia:何謂共識#不是多數表決不是方針，就算其觀點不符合該論述也完全沒有問題。本身「不是多數表決」這一點建基於「雙方理據都各有道理」，WP:共識方針本身就要求考慮「正當合理」意見。在反方意見被邏輯論證質疑是否正當合理時，反方無法反論證自己的邏輯正確，無法證明自己邏輯正確的論述都站不住腳，不可能是「正當合理」的意見。「不認為UjuUjuiMandan觀點在社群中有共識」，沒有共識不代表該點並非方針本身的核心觀點和原則，正如上方的用戶即便再不同意方針或某些規則，都不能否定那些是方針的一部分。WP:5P5指出「方針與指引所蘊含的原則和精神比字面措辭更為重要」，而「多數意見」則自始至終都不是共識的核心原則（參見英文維基百科原版方針），方針中重複出現的「正當合理意見」才是。就算「未曾經過共識檢驗」，也不代表原則不存在。所謂「民主和社會契約的原則導致了多數決的做法」則根本不可能是在維基百科的合理觀點，維基百科不是民主體制，自然無需「跟從」民主制的多數決（尤其是多數決本來就存在多數暴力的問題，不論觀點是否合理，人多就贏，這顯然不合理）。--路西法人 2024年5月29日 (三) 02:18 (UTC)

維基百科不是民主體制表述：「維基百科不是民主體制或任何政治體制的實驗。這裡尋求共識的主要方法是討論，而不是投票」，強調不是單純投票。
共識一定遵守了民主的原則，因為它涉及到集體討論和決策，這是民主的基本組成部分。共識強調了參與、包容和多樣性的意見，這些都是民主價值觀的核心。共識決策是民主決策中，加上集體討論和決策和一致同意（有時可能略有變通，可另討論）。
民主不一定遵守了共識討論、參與、一致同意原則。
共識主要是一致同意，少數人可以否決多數人的提議。目的是避免多數決本來就存在多數對少數暴力的問題（尤其是多數決本來就存在多數暴力的問題，不論觀點是否合理，人多就贏，這顯然不合理）。
共識決策中中，不論各方觀點是否合理，更不容許少數人觀點和提議強加於多數人。

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

你說的最後一點「不論各方觀點是否合理」的說法已經跟共識方針的原則有所牴觸。不再回應不顧觀點是否合理而提出沒有共識的觀點。--路西法人 2024年5月29日 (三) 02:43 (UTC)

有不同看法是正常的。我認為，「不論各方觀點是否合理，更不容許少數人觀點和提議強加於多數人」是符合「共識方針的原則」。
我們可以請社群研討，發表意見，也可查查可信來源的論述。

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

「不論各方觀點是否合理」顯然完全違背共識方針，不是你「認不認為」就行。--路西法人 2024年5月29日 (三) 09:16 (UTC)

閣下只取了「不論各方觀點是否合理」。
我認為，「不論各方觀點是否合理，更不容許少數人觀點和提議強加於多數人」是符合「共識方針的原則」。要點為： 更不容許少數人觀點和提議強加於多數人。
在下理解共識表述為，共識不是只是數人頭而不討論不妥協。理想的共識是一致同意，判斷一致同意就需要數人頭，確信包含了所有人頭。所以在討論和妥協工作後，判斷共識時需要數人頭。
我們可以在客棧公開討論。也可以到英維公開討論。

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

將不再回應明顯扭曲方針理解，「不論觀點是否合理都應算進去」和「共識是數人頭」這兩種不合理的說法顯然任何一個有認真參與過社群討論而非空口說白話的用戶都會指出這個說法有非常嚴重的問題。面對我WP:RFC/RFA2024總結多數共識的時候，不同意我的用戶就懂得拋出「共識不是數人頭」等說法，現在他們就開始來數人頭了，就噤聲假裝看不到，雙標到一個極致。我將摺疊以上明顯與方針有所牴觸的討論，若再有繼續扭曲方針即提報請求處理。--路西法人 2024年5月29日 (三) 15:24 (UTC)

雖然本來真的不想再回覆，但補充英維在指引中對共識的詮釋協助佐證「不合邏輯的意見值得考量」與方針原則明顯牴觸，讓眾人看看這些說法有多荒謬。

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

此處非常明確寫明「存在邏輯謬誤的觀點多數不會被考量」（discount詞解：to decide that something or someone is not worth considering or giving attention，譯「不值得考量」）。--路西法人 2024年5月29日 (三) 16:07 (UTC)

您提到：「面對我WP:RFC/RFA2024總結多數共識的時候，不同意我的用戶就懂得拋出「共識不是數人頭」等說法，現在他們就開始來數人頭了，就噤聲假裝看不到，雙標到一個極致。」
- 「就噤聲假裝看不到」「雙標到一個極致」是否假定我應該看到，並而應該支持您正確理解了共識的識別需要數人頭？
- 「就噤聲假裝看不到」「雙標到一個極致」是否是假定動機，違反了假定善意？摺疊理由是否是假定動機，違反了假定善意？
閣下按自己理解，摺疊反對者的發言，而不是由社群中立者的理解，然後繼續回應。這是否得當？請社群發表意見。--Gluo88（留言） 2024年5月29日 (三) 17:09 (UTC)

@Gluo88：你上面這樣分章節然後置頂發言，別人就算要恢復發言，也不知道之後怎麼排版。請反縮排2024年5月29日 (三) 17:01 (UTC)的發言並改放底下，然後把「下面」改成「上面」之類。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年5月29日 (三) 17:31 (UTC)

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

WP:太長不看；我承認上述的討論，我可能沒有詳細完整的看完，在目前的理解下，我不贊成此一提案。我參與過維基百科一段時間，我同意我在有條目相關問題時應該要先在討論頁討論，若有問題還可以用WP:RFC徵求更多人的意見。若還是無法解決，再提報到互助客戶的條目研討。（我跳過維基專題，因為我覺得以現況來說，大部份在維基專題上的討論效果不大。）但這對於剛接觸維基百科的新手而言，難度高了一些。而且可能在條目討論頁、維基專題討論頁提出後，就沒有下文了（這部份透過WP:RFC可能會有些改善，但效果還不明確）。--Wolfch (留言) 2024年5月29日 (三) 04:08 (UTC)

想請問「難度高」而言，如何定義「難度高」？哪一些操作比較「難」？另外上方也論述過，對新用戶而言，最直觀能找到的是條目的討論頁，而互助客棧條目探討板往往是用戶遇到過濾器等問題才會找到客棧的求助板，繼而才找到客棧的條目探討板，找客棧條目探討板顯然不是一件容易的事情。對於兩個新用戶之間的討論而言，大概本身就不懂得找客棧烙人討論，不懂得使用RFC也應該可以理解的。

另外，請真的讀一下#第三階段討論所整理的論點。我的整理中指出了此提案除了處理原則性問題外，還有處理了客棧被濫用的問題。您不贊成這個流程，那麼對於客棧目前被過度使用的看法是什麼？目前對於客棧眾多問題沒有全面改制以外的選項，在該等考量下你認為客棧的有關問題是否應被解決？--路西法人 2024年5月29日 (三) 08:27 (UTC)

閣下，我覺得就上面討論而言，反對提案的人真的很多，或許你也可以說他們都沒有實質理據，不過這種東西不是應該符合大家的意願嗎？要說制定規範條目的方針應該有實質理據，但這種東西就像修改一個圖標，你可以說你作為設計師的專業觀點認為很好看，大家只說一句新版圖標不喜歡就是沒有實質理據所以無效嗎？--桐生ここ★[討論] 2024年5月31日 (五) 19:33 (UTC)

界面圖標的主要作用是美觀和實用性，實用性的探討顯然是客觀討論，而爭論設計美觀與否是主觀、談感覺的，這種情況下單純的「不喜歡」當然可以作為實質理據。方針及機制的主要元素是邏輯、功能和理據，邏輯、理據是客觀的證據，討論制定規範當然要講求邏輯、功能和理據；方針和機制並無「主觀」判斷的因素，「主觀」的「不喜歡」自然就不能作為一個實質的反對理據。--路西法人 2024年6月6日 (四) 05:21 (UTC)

註：此處原有文字，因為用戶Gluo88已因有關擾亂性扭曲方針的發言被封鎖，已由路西法人於2024年5月30日 (四) 12:50 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

(＋)支持：我的支持意見應該是被龐大的討論洗掉了，只好再次投票表達意見，支持U:LuciferianThomas的最新提案。--CaryCheng（留言） 2024年6月3日 (一) 08:27 (UTC)

桐生ここ版本

原標題為：桐生版本

建議簡單一點：

為善用社群討論資源，僅影響單一條目的討論應先在條目討論頁發起，未先在條目討論頁發起的討論將被移動；
影響多個條目的討論可在相關討論頁或互助客棧條目探討板發起。

這樣就可以了。--桐生ここ★[討論] 2024年5月31日 (五) 19:53 (UTC)

另外真的應該考慮Taiwania Justo所說的，發起一個意見調查，問問大家喜歡在集中一個地方討論然後存檔到各個討論頁，還是分散在各個討論頁，解決不了問題再到客棧。這基本上就是一個UI設計問題，而不是適用於條目內容的原則性問題，沒有什麼有效無效理據，只是問大家喜歡哪一種。客棧本身也只是一個UI，當初的設計者也不一定就會制定條目探討這個版塊，討論頁也只是一個UI，如果開發者沒有設計出討論頁功能，現在大家都是在客棧討論了。--桐生ここ★[討論] 2024年5月31日 (五) 20:08 (UTC)

另外回饋請求這個東西很好，我覺得應該允許客棧的討論使用中，甚至應該允許存廢覆核、存廢討論、評GA/FA、乃至除權爭議和ANM、AN3等。--桐生ここ★[討論] 2024年5月31日 (五) 20:16 (UTC)

本來就應該是這樣。落實此原則便足以解決現存多數問題。另應確定討論轉移機制，如當年條目探討區建立時，好像粗淺訂了個一週沒什麼人參與就可移步客棧的規定。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月1日 (六) 07:53 (UTC)

補個(＋)支持，這樣顯眼一些（ —— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月10日 (一) 18:59 (UTC)

所謂「簡單一點」就是完全沒了「編者應先盡可能自行透過討論解決爭議」的最基本要求，也沒了如何善用討論資源的指導。這兩個是修改規則的最重要原因，兩樣都消失了那跟沒修沒分別。Ericliu口中所謂「落實此原則便足以解決現存多數問題」又是毫無論證，甚至連提供了的九個問題都沒能指出解決了哪一項，只留「解決了問題」一句話但實際沒有反映如何解決問題的議事方式實在不負責任。就九個問題的分析：

當前制度未能鼓勵用戶在徵求第三方意見前嘗試自行解決爭議——桐生版本僅局部解決了這個問題，但仍有很多情況都未能推動改善討論習慣。桐生版本沒有要求用戶先行跟涉爭議的用戶自行展開討論、沒有要求二人商議無果邀請其他編輯該條目的編者參與討論，沒寫的顯然社群多數都不會做。影響同一主題下的條目的討論根本不應該容許直接在條目探討板發起，而是應採用能鼓勵編者先行與編輯相同專題的用戶商討協調如何在社群方針指引框架下編輯，同主題跟單一條目的情況都存在「應該先進行的更下層討論」，同主題但多個條目的討論沒有實際理由能支撐一開始就跑去客棧發起的選擇。
跟條目有關的討論無法在討論頁中找到——幾乎沒解決，多數「相對重大」的討論的問題仍然存在（尤其是桐生版本沒要求在適當的討論頁發送討論通告，更是無法解決
客棧再開討論形成平行討論——完全沒解決，不限制從討論頁轉移討論至客棧則仍然會繼續有這個問題，仍需要用戶額外巡查確保原處討論已經關閉（反觀從客棧移到討論頁多數會整串移走或關閉）
互助客棧並非新用戶「直覺」就知道是討論的場所——無對應措施解決，新用戶仍然難以參與任何在客棧的討論。
客棧過長——拿「分流」的說法來說，個別條目的討論反而比較多是相對較短的討論串，反而影響條目眾多的條目才是討論會比較長的話題（更容易引起爭議），桐生版本解決客棧過長問題的效果非常有限。
互助客棧討論串過多，本身性質比較不受關注的討論會更難被注意到——無對應措施解決。
V
- 客棧討論結束在多處自動存檔形成平行討論——無對應措施解決。
- 難以在客棧查找討論存檔——無對應措施解決，存檔仍然存回討論頁，無法搜尋在客棧進行過什麼討論。
討論串過多，想參與討論的用戶每次都要在字海中找話題——無對應措施解決。
客棧無法讓用戶持續追蹤特定感興趣類別的話題——無對應措施解決，但這個開放在客棧使用RFC機制已經能解決。

請問「解決」了什麼問題？還是又是未經實際分析而自由心證的結論？我推的是能解決問題的提案，桐生閣下建議的是解決0個問題的提案，那請問這個提案有什麼作用？很老實那句，上述部分問題（2、4、6、8、9）能直接通過開放在客棧使用〔RFC機制及討論通告〕去輔助儘可能解決，但既然都用到RFC，那倒不如直接在條目討論頁發起討論還實際，還能解決剩餘的問題？--路西法人 2024年6月1日 (六) 08:31 (UTC)

關於新手的問題，我覺得新手確實會直觀地認為討論頁為討論該條目的地方，大部分也確實會先於討論頁發起討論。但是我相信他們肯定不知道有rfc之類的東西，所以他們發起的討論我覺得大概率也不會有人注意到吧。閣下的方案有辦法解決這個問題嗎？--微腫頭龍（留言） 2024年6月1日 (六) 08:45 (UTC)

就我觀察，兩個新手之間的爭議不外乎直接在條目打編輯戰開幹和兩個人在討論頁吵起來。監視最近修改作為反破壞的工作甚至比客棧更多人長期監視，老手們不難發現新人在吵架或打編輯戰。老手發現編輯戰並提報保護的同時，就能引導用戶在條目討論頁發起討論。這時候，很多老手都會協調兩名用戶瞭解方針指引規範，也能作為適時協助請求擴大討論。就算這名老手就算該用戶本身無意參與討論，也等於留了一個「老手聯絡人」，解決不了ping他也是可以。（DiscussionTools在本地預設啟用，ping用戶有界面輔助輸入@號）這是循序漸進教導新手的體現。

再者，可統一在新手最直觀切入社群討論的討論頁增加編輯提示（Template:Editnotices/Namespace/Talk），亦能作為長期懸掛討論頁規則（Template:Talk header，甚至在MediaWiki:Talkpageheader加入該模板），該處已有「遇到爭議時請尋求解決方法」的連結供用戶查找RFC或客棧等方法。（倒是才發現RFC沒寫進去WP:DR，不過這個新增在該指引大概不會遇到爭議）--路西法人 2024年6月1日 (六) 09:10 (UTC)

前面早就提過該類討論占客棧大宗，數量及篇幅都是。減少此類話題，正好將客棧留給大型討論，可為適當分工。桐生的版本實際上兼顧了討論頁善用及編者發起討論的自由，本人認為切實可行。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月10日 (一) 19:03 (UTC)

能自己話打自己話的人真的非你莫屬。你的說法是「單一條目討論數量及篇幅『占客棧大宗』所以適合『分流』」，（其他類型討論）歸類「大型討論」；但「大型討論」卻不是「篇幅佔多數」，反而留在客棧，卻不是應被「分流」的對象，由得「大型討論」繼續製造客棧一直存在的問題？空口一句「實際兼顧了討論頁善用」，卻迴避回應種種仍然存在的客棧問題，「實際」去哪裏？來來去去都是同一句「編者發起討論的自由」，卻不管任何前設，實際變成「不管種種問題，編者的選擇發起討論場所自由都應該受到保障，就算造成客棧種種問題也不該被限制」，這跟「不管編者寫的內容是什麼，編者的編輯自由都應該受到保障，就算內容不恰當也不該被限制」有何分別？--路西法人 2024年6月11日 (二) 05:06 (UTC)

所以反方是沒辦法提出站得住腳又不跟方針牴觸的反對意見了嗎？我花心機去儘可能完善我的提案，確保我的發言儘可能沒有錯誤和漏洞，反方還是要用「不喜歡」這種共識方針本來就不接納的意見作為反對論點嗎？沒有的話我24小時後就重新公示了。--路西法人 2024年6月10日 (一) 16:17 (UTC)

所以所謂「站得住腳又不跟方針牴觸」仍是由提案人自行認定與否？也不知道「不喜歡」是怎麼歸類出來的意見。即便有大規模提及，社群多數成員仍然沒興趣推進如此程度的提案（實際上大概是沒意願捲入死纏爛打冗長辯論，前面幾位也已經表明了），根本不代表提案具備足以實施的共識。何況制度是死的、人是活的，每個人編輯體驗不同，偏好的討論管道、遭遇的事件也不同，本來就沒有某種一以貫之的道理；這又不是條目，本人認為縱使真是單純「不喜歡」某種使用者設計，也完全可以成為反對理由（遑論並非如此，某些互助客棧有的問題討論頁可也不缺），提案人自行認定何者屬於所謂「有效意見」的弊病再度浮現。共識方針也指出，就算一致認為要作出改變，但不代表（一定）要作出改變。此提案並非無人支持，但顯然不足夠，這時本來應該做的是吸納眾多新意見、適當調整提案範圍及實施細節，儘可能爭取社群最大支持；但提案人僅是做些無關緊要的微調（貶斥他人意見、宣告他人意見無效給自己「讓道」的時間或許還更多），就屢次再三堅持公示，是根本無視此提案尚沒有共識的現實。本人認為，應就LuciferianThomas版本及桐生ここ版本提交徵求意見，付諸社群以安全投票公決。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月10日 (一) 18:25 (UTC)

考慮到在此情況下先前大規模邀請討論效果不彰完全可以預期，本人並另外主張，應該先從事意見調查（同樣也是使用安全投票），讓社群不必陷於長篇大論之泥沼中，即可提供有益意見。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月10日 (一) 18:30 (UTC)

反方能自行認定自己意見在合理有效，而不作任何邏輯論證；而我認定反方意見無效基於種種邏輯推論、論證。所謂「死纏爛打」「冗長辯論」豈不是反方用戶堅持無法給出符合邏輯、符合方針指引原則的任何論證？所謂反方「沒意願死纏爛打」，還是是根本從頭到尾自己說法站不住腳，不斷得用更多的偽邏輯偽論證，一個大話掩蓋另一個大話，最後辯不過就歸根對方死纏爛打？我給反方認定論據不符合「合理有效」都還需要大量論證，反方至今都無法論證我的邏輯依據、方針指引依據存在任何錯誤，然後就可以給我冠上「自行認定」「死纏爛打」？豈不是反方自己「自行認定」自己的論據合理有效，而不接受我指出反方說法中的種種荒謬邏輯謬誤？--路西法人 2024年6月11日 (二) 04:57 (UTC)

更好笑的是，Eric君你指出方針中「就算一致認為要作出改變，不代表一定要作出改變」，這個從來都不是共識方針的原則，甚至只是過往修訂方針時未經任何討論、無人提出過增加這一點的偷渡增訂，英文原版也未曾有此道理；菲菇修訂共識方針時，也極度強調雖然共識也看重多數意見，但觀點合理性所佔的權重，要大於其支持者多寡的權重（至於如何判斷合理，我覺得能否說服對方觀點陣營的部分人，或者至少能說服不涉事的其他編者，是一個重要因素）。反方的觀點無方針指引支持、不符合方針指引原則、甚至存在大量邏輯謬誤，這些都是客觀上的不合理而不是單純我認定；而我指出客棧存在的問題等也獲部分反方用戶接納。

當年制定當今共識方針，已經有用戶針對「自認合理」的論證表示擔憂。反方除了空口說「不認為存在這些問題」和迴避回應以外，未曾實際推出我的論證存在不合理；反而是反方一直對自己已被指出大量邏輯謬誤的論點是「自認合理」，更是完全佐證了反方觀念上就存在問題的情況。

當初Reke和菲菇分別表達過這樣的說法：

合理的意見即使當下是少數，也可以在不斷推廣後形成多數，從而寫入共識之中不是嗎？
所以，我覺得如果真正是共識過程的話，合理的意見要比不合理的意見更加容易被採納，哪怕在表面上只有少數的支持者。

這不就完全反映「合理的意見」比「多數意見」更重要嗎？--路西法人 2024年6月11日 (二) 05:24 (UTC)

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

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

由於反對提案的用戶一直未能提出能被邏輯、方針指引及共識方針本身的基本原則合理支撐的論點回應提案，存在邏輯謬誤的論點本來就是客觀認定的「invalid arguments」（某大學資源、人文作家、GPT輔助解釋、另一大學資源）。共識方針自制定時的討論也非常明確「觀點合理性所佔的權重，要大於其支持者多寡的權重」的原則，這一點不論是本地方針還是英文原版方針都有指明。由此，此討論中已考量並回應和按需處理合理有效意見（邏輯通順且不與方針指引的基礎原則牴觸），符合共識方針要求「考慮所有正當合理的意見」。

綜上，在已無有效異議的背景下，重新將此提案付諸 公示7日。--路西法人 2024年6月12日 (三) 04:26 (UTC)

(＋)傾向支持。--WiiUf ——青龍出世，傲視蒼穹 2024年6月13日 (四) 10:50 (UTC)

我想請問你的根本鼓勵用戶在徵求第三方意見前嘗試自行解決爭議到底有沒有想過如何成立？你跟EL吵了幾個月請問有解決爭議嗎？你們雙方一路各說各話，你是認為你的意見已經得到另一方尊重？我怎麼看不出來？EL也這麼想嗎？

所謂自行解決爭議的本質是一方服軟讓步，這個就是現實不用質疑。如果按你的走法，像我這種不喜歡跟瘋狗吵架的人是不是連把問題提交給社群的機會都等不到？是不是意味着以後只要誰敢於吵樂於吵善於吵，他的觀點就可以凌駕維基百科？--。->>Vocal&Guitar->>_留言 2024年6月13日 (四) 23:53 (UTC)

這裏寫的是「嘗試」自行解決爭議。若經過一段時間，或短時間而非常密集的討論後仍無果，那就上一級徵求其他人意見，然後再徵求廣泛意見。未來若能成功設置仲裁委員會，或許可以制裁堅持己見但無合理依據支撐論點的用戶。沒有說必須其中一方讓步才能找更多人討論，讓步了反而是不需要再向上的情況。所以如果你認為對方理據不妥而無法讓步，經過交涉嘗試後即能找其他用戶參與。--路西法人 2024年6月14日 (五) 00:46 (UTC)

中文維基百科願意開煮的不都是堅持己見但無合理依據支撐論點的用戶，跟他們嘗試自行解決爭議不就等於上門約架？說難聽點如果都像你一樣一通紅字粗字甩出來，誰還有毅力繼續煮下去？正常人遇到傻子會讓步，遇到瘋子會讓步，你是期待這樣解決問題嗎？你維的現狀是即便客棧有第三方介入的情況下也需要很長時間收拾，以後一對一，一對朋黨，朋黨對朋黨，這樣會令社群更好嗎？我不懷疑這套體系，但這套體系在華人社會死路一條。--。->>Vocal&Guitar->>_留言 2024年6月14日 (五) 22:53 (UTC)

事實上站內條目討論大多數都不存在這樣的人，多數討論都可以通過先跟當事用戶溝通而解決。真的比較大爭議、難以解決的問題，連嘗試都沒有嘗試過，怎麽知道對方不是只是不清楚問題所在而產生的爭議，而根本說一聲就可以解決？

至於紅字粗字，若非對方有明顯扭曲方針、錯誤邏輯，仍然堅持己見，大概也沒必要紅字粗字強調。社群討論與條目討論不同，在條目討論頁的基礎討論若失效（對方拒絕接受方針及邏輯論述），可以在找上一級的用戶參與。條目的內容規範各方面站務討論的行為規範更完整，除了中立性永遠存在爭議外，其他方針都甚少會有人可以有個人的理解，所以幾乎可以預見除了某些如高風險主題外，絕大多數討論都不太會出現這個問題。--路西法人 2024年6月15日 (六) 00:01 (UTC)

(！)抗議：對此公示，我感到非常遺憾，若通過，對此規定之有效性表示(？)異議。--桐生ここ★[討論] 2024年6月14日 (五) 13:32 (UTC)

過往的反方意見言之無物，與方針相悖、與邏輯牴觸，百多則留言沒幾則比得上Ohtashinichiro上方兩則留言內明確指出心中疑慮（與善戰之人吵難以有好結局的問題）。--路西法人 2024年6月15日 (六) 00:14 (UTC)

1.針對WP:OWN，方針提及如有人聲稱擁有某個條目的控制權、主導權（如「黑色怪物」於港鐵相關條目的編輯），編輯者可到條目探討區與其他編輯者反映。閣下的條文成立後，這個反映機制是不是失效了？

.

如果您發現自己與其他貢獻者陷入編輯戰時，為何不靜下心來？暫休息一段時間可化解糾紛，待一兩個星期後再來重新檢視。又或者，如果某人聲稱「擁有」某個條目，您可以在相關討論頁提出，或通過維基百科:互助客棧/條目探討等管道向其他貢獻者反映。

.

2.假設我在條目討論區ping了5個近期相關編輯者參與討論，唯五日後仍沒有人發言（這個狀況英維時常發生）。在閣下的提案中，不能因此在討論發起六日後把討論邀請掛在條目討論區，對嗎？--唔好阻住我愛國（留言） 2024年6月14日 (五) 17:44 (UTC)

若有人聲稱擁有條目控制權，新機制下仍能在客棧發討論通告（這次可以寫明「有人聲稱對主題/條目擁有控制權，請求協助」這類），仍然是可以在客棧求助；再不是，掛個RFC請求協助也是可以吧。新制只是把社群用戶帶回原有討論串參與，而避免討論出現分支造成混亂。（註：未來有仲裁委員會，若社群無法解決用戶聲稱控制權，那麼就可以提報仲裁處理）
「經討論頁討論仍無果或下列情況」，無人參與實質上是你發起了討論頁討論而無果，這時確實可以往客棧發討論邀請和開展RFC等等。

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

1. 應擴大至方針指引要求條目探討區處理的議案，而非單一WP:OWN。

2. 我開始望到有bug了。只要我ping正在放維基假期的編輯者／長期離線編輯者(如2000年於該條目類別活躍的且現退休的編輯者)/當刻被封鎖的編輯者（黑色怪物曾經嘗試並成功）/不在討論區發言的編輯者/到該類別編輯量極少且冷門的條目發起討論（如我到任一2000年的日本動畫條目發出討論，關於整體日本動畫條目），並等待數天。即可以「無人參與實質上是你發起了討論頁討論而無果」為由到條目探討區發起討論。--唔好阻住我愛國（留言） 2024年6月15日 (六) 15:16 (UTC)

我覺得「近期」這個詞已經寫得很明白了，而且如果有這個問題，依照常識也可以處理。臺灣杉在此發言 (會客室) 2024年6月16日 (日) 15:03 (UTC)

探討案例1：A編輯者大幅度變更B條目後於個人頁宣布放自己一個維基假期，在B條目，最後編輯條目的編輯者是A君且最近的編輯均由他發起。

探討案例2: C編輯者用工餘時間編寫了D系列條目，最近一年也沒有任何其他編輯者進行更新。有一天，C編輯者因犯了3RR而被管理員封鎖3個月。在C君被封鎖當天，E編輯者提出要大輻度變更D系列條目。--唔好阻住我愛國（留言） 2024年6月16日 (日) 15:16 (UTC)

上述案例我覺得在程序合規下，直接發互助客棧也沒什麼不可以，之後如果其他編者認為「宜」進入RFC，自然就會處理了。臺灣杉在此發言 (會客室) 2024年6月16日 (日) 16:20 (UTC)

面對如此蠻橫之舉，本人只有建議維基人繼續預設在互助客棧發布所有條目相關討論（其他類型因仍不受限就不必提），這樣一來可以確保仍獲得些許互助客棧既有之流量及編者有效參與，最大程度避免遭此等不合理之規定損及條目改善機會及自身權益，二來縱使爾後話題遭移動，尚能在一段時間內留下討論頁連結，相當於引流，往後訪問互助客棧的維基人看到標題，也知道該去哪裡討論，即不用再回頭發一次討論通告。此外，不知道或不確定要在哪裡發起討論的維基人，更仍歡迎在客棧上發布話題，這樣就不用擔心沒有人幫忙處理。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月15日 (六) 18:18 (UTC)

另外我也呼籲所有反對此種逆施之維基人，保留不滿意見，往後縱使此提案遭強行推動，實際造成編者不便後，纔有回退之可能。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月17日 (一) 05:01 (UTC)

@Ericliu1912什麼時候閣下可以收回條目探討區通告裡，以下自相衝突的兩點，什麼時候我才能支持閣下的其他主張：

“

二、禁止在互助客棧條目探討區發起「影響多個屬相同主題的條目的討論」，也禁止此等討論移動至客棧，只能發送討論通告；

三、在互助客棧條目探討區發起「影響多個屬相同主題的條目的討論」時，應當在主題條目發送討論通告。

”

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

第三階段討論

原標題為：公示後關閉討論文字敘述

Taiwania Justo初次版本

由於本次討論各方對於其持有的論點有所堅持，而且參與各方無論是誰關閉，可能仍然會有不服情況。本人作為參與討論程度較低的編輯者，依據WP:ACD的精神，由我本人在公示後進行關閉，並做出以下結論：「公示通過，但由於各方存在激烈爭論，而且對於討論中的各方觀點需要長時間的觀察及分析才能得知，因此無法評估此次共識是否廣泛。建議爭論各方在公示通過後，就實施的真實情形，滾動討論並達成更廣泛的共識。」

如有任何問題，請提出。如果本人不適格擔任關閉者，請與本次討論無關的管理員進行關閉。臺灣杉在此發言 (會客室) 2024年6月16日 (日) 15:39 (UTC)

感謝閣下願意站出來主持。某些用戶主張未經實現就以顯然可以用其他原因解釋的現象來佐證提議機制無效或不合理的想法顯然就已經說不過去。如同AFD relisting，持續討論有助找出機制問題所在，我完全同意並也曾多次主張在正式推行機制後持續檢視問題並予以解決。由於此提案是推動廣大編者回歸討論基礎本質（在多數情況下先與涉及爭議的編者交涉，而非毫無疑問越過對方），實際也不適宜再次fallback至客棧機制（鑑於其本身就非系統給予的預設做法），應儘可能通過推動用戶活躍回歸討論頁參與討論。--路西法人 2024年6月17日 (一) 02:03 (UTC)

這麼多(？)異議，恐怕難以通過啊--WiiUf ——青龍出世，傲視蒼穹 2024年6月17日 (一) 07:18 (UTC)

根本不難通過，根據現行公示規則，在公示期間所有合理疑問於提出後已獲提案人解決，而解決後3天內沒有進一步追問，即可通過公示。而且基於共識不是點票，即使有大量人反對或支持也沒有用，因只按提案內容是否合理而行。換句話說，這句是可以刪除「，但由於各方存在激烈爭論，而且對於討論中的各方觀點需要長時間的觀察及分析才能得知，因此無法評估此次共識是否廣泛。建議爭論各方在公示通過後，就實施的真實情形，滾動討論並達成更廣泛的共識」。

唯公示結束日肯定不是6月19日星期三，因為提案人還未解決所有問題。--唔好阻住我愛國（留言） 2024年6月17日 (一) 11:00 (UTC)

如果這樣強行通過的話，(－)反對。--WiiUf ——青龍出世，傲視蒼穹 2024年6月17日 (一) 11:02 (UTC)

如果閣下對這個公示程序有什麼不滿，另請閣下提出修改。--唔好阻住我愛國（留言） 2024年6月17日 (一) 11:26 (UTC)

(＆)建議按照@Taiwania Justo的提案先試行一個月，如果能高效地解決條目探討區討論過多的的問題，那恐怕就沒多少(？)異議了。--WiiUf ——青龍出世，傲視蒼穹 2024年6月17日 (一) 11:51 (UTC)

「只按」提案內容是否合理而行？那就算提案完全合理，會有人樂意實行？--WiiUf ——青龍出世，傲視蒼穹 2024年6月17日 (一) 11:04 (UTC)

以我的意見，如果改成「試行」一個月之後，依據成效來進行討論，我想反彈不會那麼大，如果提案人願意的話。臺灣杉在此發言 (會客室) 2024年6月17日 (一) 11:11 (UTC)

這樣還可以，(＋)傾向支持。--WiiUf ——青龍出世，傲視蒼穹 2024年6月17日 (一) 11:13 (UTC)

其實現在提案人已偷步試行。你可以測試那些已偷步試行的例子是否具成效。--唔好阻住我愛國（留言） 2024年6月17日 (一) 11:25 (UTC)

其實也沒別的方法了吧？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月18日 (二) 02:59 (UTC)

WiiUf版本

此次討論並未能取得廣泛共識，各方均堅持自己的觀點。綜合各方意見，我提出以下方案：

「公示將於此討論結束後試行30日，並在試行結束後根據公示的有效性及真實情形進行進一步討論，決定是否通過此公示。」

如有任何問題，請提出。如果本人不適格擔任關閉者，請與本次討論無關的管理員進行關閉。

—WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 07:19 (UTC)

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

這個可以。--唔好阻住我愛國（留言） 2024年6月18日 (二) 11:13 (UTC)

再次討論合法性問題

@Taiwania Justo、WiiUf：有鑒於WP:共識#什麼是共識有特別説明「重大修改更應獲得絕大多數的同意」，因此我想先確認路西法人的提案到底是否屬於「重大修改」，以及是否「獲得絕大多數的同意」。如果路西法人的提案屬於「重大修改」，但並未「獲得絕大多數的同意」的話，那這個提案無論如何都不能被認定為通過，否則這就相當於提案在不存在共識的情況下（實際上）通過。我所指的「（提案）不能被認定為通過」意指完全不執行或停止執行提案提到的任何措施。San mo sa _{Snipe–Clam Grapple} 2024年6月18日 (二) 13:17 (UTC)

「獲得絕大多數的同意」是絕對沒有的，但是是否屬於「重大修改」還需要進一步討論。我(＋)傾向支持認為這是重大修改。--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 13:58 (UTC)

就這兩方面來回應。

是不是重大修改：依照目前討論的激烈程度，重大修改應該合理吧。
是否是大多數人同意：那就要回到共識到底是單純的數人頭，還是考慮各個觀點的合理性。依照英語維基百科和中文維基百科的共識頁面精神，以及目前我正在翻譯的WP:ACD，都建立於「合理」的權重。依據目前的討論來看，路君的論述合理比重比較高，可以看作主要的合理論據；而反方論點邏輯上確實有瑕疵，但所擔心的點無非是影響新手或特定領域的編輯者可能因為不熟悉「先在討論頁討論再進行其他管道」的優先程序而求助無門。這兩方以人數來看，確實相當，但在論點合理性方面，路君的合理性較高。不過，反方意見的擔憂處也必須納入考慮。

因此，今天我在思考的是，如果不熟悉，那就來真的「試行」，除了測試接受度，也讓該提案有一次嘗試的機會，期限30日或一個月為限。目前這個試行共識看起來接受度算高，應可成為本案的共識。以上。臺灣杉在此發言 (會客室) 2024年6月18日 (二) 14:04 (UTC)

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

由於實踐才是真理，看似完善的論述，不一定行得通。但既然如此堅持非要「測試」看看，那也就罷了。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月22日 (六) 05:34 (UTC)

第三次公示

經過24小時場外溝通和我介入以後的情況，目前對於「試行」的提案獲得大多數認同；但在場外溝通時，@LuciferianThomas提出因為WP:FRS的推廣及教育工作需要長時間去推動，最少需要半年的時間，這個部分我也認同（就目前中維的參與者活躍情形不如英維，需要長時間溝通實屬合理）。因此，這裡改以「試行」模式做為最終公示方案：

下列方案以「試行」方式執行半年，從公示完成之日起算。
第3個月，必須於特定頁面進行期中報告，重點要放在是否有提升討論頁的使用頻率與參與程度。
試行結束時發表最終報告，並進行討論是否接納成為正式方針與/或是否進行修改。
公示後30天內需要討論報告的呈現方式及指標。
試行期間，違反者儘量以教育為手段，不得採用封禁等禁制使用者參與編輯維基百科的方式。

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

以上試行方案即日起 公示7日，2024年6月25日 (二) 15:20 (UTC) 結束。臺灣杉在此發言 (會客室) 2024年6月18日 (二) 15:20 (UTC)

不論試行前後，都不得使用封鎖或禁制處理違反此等條款的用戶，除非能證明用戶是蓄意為之（WP:POINT，例如「我就是要這樣啊」）。--路西法人 2024年6月19日 (三) 00:45 (UTC)

@Taiwania Justo:

請提供「經過24小時場外溝通和我介入以後的情況，目前對於「試行」的提案獲得大多數認同」的證明，謝謝！--唔好阻住我愛國（留言） 2024年6月19日 (三) 13:23 (UTC)

原因：「維基外的討論。我們不鼓勵編者在其他網站、論壇、聊天工具、電子郵件或其他本專案外的地方討論。這些討論在「維基內」決定共識時是不予考慮的，並在它們被揭發後會引發猜疑和不信任情緒。儘管我們需要在維基外討論少數問題以顧及隱私，但絕大多數維基百科相關的事項都應在維基百科上討論，這樣它們將對所有參與者可見。」--唔好阻住我愛國（留言） 2024年6月19日 (三) 13:24 (UTC)

「試行」依據在關閉公示版本討論的部分可見，沒有在場外討論的因素；場外討論主要是試行的方案，如上所述。--臺灣杉在此發言 (會客室) 2024年6月20日 (四) 03:52 (UTC)

我不認為這是在維基以外地方討論的合理理由。--唔好阻住我愛國（留言） 2024年6月20日 (四) 10:56 (UTC)

目前場外溝通的只有提案人和Eric Liu，沒有其他人，溝通的結果也如實在此說明供大家公評，程序部分已經完備。--臺灣杉在此發言 (會客室) 2024年6月20日 (四) 13:52 (UTC)

而且該條例不是「禁止」這樣做，而是「避免」這樣做，部分溝通還是要有即時性才能完成，只不過做出的結果還是要拿回來維基百科做說明供大家討論，程序才能完備。--臺灣杉在此發言 (會客室) 2024年6月20日 (四) 13:55 (UTC)

我相信有不少人也關注，是什麼論點促使路西法人妥協？

另外，「場外溝通的只有提案人和Eric Liu，沒有其他人」，請問閣下是如何得知他們的討論結果？--唔好阻住我愛國（留言） 2024年6月21日 (五) 11:16 (UTC)

我分別和他們進行溝通，主要說服論點就是不能太激進，如果以「試行」方式，反彈聲浪會比較小，而且我分別將#公示後關閉討論文字敘述的結果跟他們進行說明，他們雖然可能還有不同意見，但至少大致都認為「試行」方案可行。--臺灣杉在此發言 (會客室) 2024年6月21日 (五) 14:20 (UTC)

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

不只是所謂「溝通」，還有根本制度性問題。但事到如今，都無所謂了。甚至只是改為「試行」都讓我感到驚訝。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月19日 (三) 16:36 (UTC)

(？)疑問-在下以為，在互助客棧討論不是不行，但應先在、或同時在條目討論頁發起討論為宜。在下有些疑惑：設置這一新規定，可能有哪些副作用？會否過度限制溝通？會否讓維基用戶疑惑而卻步？Wetrace歡迎參與WP人權專題 2024年6月19日 (三) 17:31 (UTC)

我是覺得提案人很理想，但問題在於「不習慣」。既然如此，一個不習慣的方式突然要變成「正式方針」並且要「強力執行」，一定會有很大的反彈。因此這裡改成「試行」也是基於儘早讓編輯者習慣的一個重要手段。前幾天我私底下和@Ericliu1912討論的時候，我有提出目前還有其他的配套措施正在引進當中，例如WP:DRN是目前可能的方案，實際上就是條目探討的複雜版，對於編輯者內容爭議進行引導的模式也做得非常完善。我是打算在試行期間完善化DRN，到時候看試行效果再做爭議解決指引的修正，甚而解決條目探討一直以來的過長問題。臺灣杉在此發言 (會客室) 2024年6月20日 (四) 04:02 (UTC)

我也正在準備重新翻譯WP:DR，如果您有意推行DRN，那麼我把DRN寫進方針重修提案中吧。--路西法人 2024年6月20日 (四) 04:50 (UTC)

若「禁止發起若干討論」是一種短期措施，旨在樹立分流之慣例，到來日不必禁止之時即可解除，那倒是還好；但此提案的目標既然是「永遠禁止」，那就不能迴避客棧以外某些討論方式之固有缺陷。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月21日 (五) 06:10 (UTC)

同意以上觀點，如果半年之後效果有出來以及配套措施建成，可以考慮放寬或是停止這個條款。這也是「試行」的另一個層面的意義。--臺灣杉在此發言 (會客室) 2024年6月21日 (五) 10:43 (UTC)

其實我也看過英語維基百科的共識方針（以下Chatgpt翻譯並經過潤飾）：

當僅通過編輯無法達成共識時，形成共識的過程會變得更為明確：編輯者會在相關的討論頁上開設一個新章節，嘗試通過討論來解決爭議，並使用基於方針、來源和常識的理由；他們還可以提出替代解決方案或妥協方案，以滿足所有人的關切。最終的結果可能是一個無法完全滿足所有人的協議，但代表了整體小組的共識。在維基百科上，共識是一個持續的過程；通常接受一個不完美的妥協——理解到頁面會逐步改進——比試圖立即實施一個特定的偏好版本更好。

當編輯者特別難以達成共識時，有幾個流程可以幫助建立共識（如第三方意見、爭議解決布告板、徵求意見），甚至有一些更極端的流程會採取權威措施結束爭議（如管理員干預、仲裁）。然而，請記住，管理員主要關注方針和編輯行為，不會權威地決定內容問題。他們可能會因干擾共識過程的行為（如編輯戰、濫用多個帳號或缺乏禮貌）而封禁編輯。他們也可能會決定某些編輯是否符合方針，但通常不會超出這些行動。

其實根本上在英語維基百科也沒有特別出現「應」怎樣，「須」怎樣的文字敘述。我是希望試行半年或是三個月之後，可以換成這種比較溫和的文字描述。臺灣杉在此發言 (會客室) 2024年6月21日 (五) 14:32 (UTC)

實際上以後若編者能自然形成什麼程度重要的議題適合伊始即在客棧討論的共識，且其行之有效，那自然要好於用行政手段強制規範。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月22日 (六) 05:34 (UTC)

@Taiwania Justo(？)疑問：第4條是不是在說，某些情況下不能將討論加入徵求意見系統？似乎有些議題並非從爭議開始，而是從對意見的徵求開始；在低瀏覽量條目討論頁發起的這種議題，要是不加入徵求意見系統，可能一年都不會有人看到。--CuSO₄ · 龍年大吉 2024年6月22日 (六) 19:25 (UTC)

這個情況下，編者應先嘗試提及近期參與過該條目編輯的用戶討論（因沒有特定的爭議對象）。真的沒人能提及的情況下就等同討論無果的情況而可以開RFC了吧。--路西法人 2024年6月23日 (日) 00:51 (UTC)

這樣的話，既然已經有RFC系統了，那在下並不反對上述提案。--CuSO₄ · 龍年大吉 2024年6月23日 (日) 14:05 (UTC)

「若有人聲稱擁有條目控制權，新機制下仍能在客棧發討論通告（這次可以寫明「有人聲稱對主題/條目擁有控制權，請求協助」這類），仍然是可以在客棧求助；再不是，掛個RFC請求協助也是可以吧。新制只是把社群用戶帶回原有討論串參與，而避免討論出現分支造成混亂。（註：未來有仲裁委員會，若社群無法解決用戶聲稱控制權，那麼就可以提報仲裁處理）」

.

這個還未解決。--唔好阻住我愛國（留言） 2024年6月23日 (日) 08:02 (UTC)

這個部分不是「條目內容」的問題，而是「使用者行為」的問題，在仲裁委員會還沒有建立的情形下，直接在WP:互助客棧/其他處理就好。--臺灣杉在此發言 (會客室) 2024年6月23日 (日) 10:40 (UTC)

該方針明文指向這裏解決，請二位檢視一下還有什麼方針指引明文指向條目探討區解決問題，一併進行修改。--唔好阻住我愛國（留言） 2024年6月23日 (日) 10:54 (UTC)

剛看完英語維基百科對於條目所有權的規範，的確是先在討論頁討論，不行才必須進行爭議解決程序。這個部分等公示完成進行試行之後，一併進行修正，在此之前條目所有權問題仍然照舊，不知@LuciferianThomas意下如何。--臺灣杉在此發言 (會客室) 2024年6月23日 (日) 11:19 (UTC)

本地將條目所有權當作行為問題處理也沒有什麼問題，應考慮在條目探討中無視聲稱條目所有權的說法以外，同步開啟對有關聲稱的行為爭議解決。--路西法人 2024年6月24日 (一) 02:00 (UTC)

(！)意見：未參加先前討論，但條款（4）中「編者可往互助客棧發送討論邀請通告及將討論加入徵求意見系統以獲取第三方意見。」與條款（1）中的強制規定顯然有衝突，如果條款（1）中的討論長期無法達成共識（具體為a.b.兩項中限制討論的情況），但卻沒有強制編者採用條款（4）在互助客棧發起第三方討論引入共識，則可能導致部分條目長期出於編輯戰狀態，亦導致本方針效力下降。如果希望本方針可以切實解決部分長期衝突，則條款（4）應當變為條款（1）的強制性補充條款（也即，如果條款（1）所發起的討論不能夠達成共識，條款（4）應當被強制啟用；或者將條款（4）改為須在互助客棧發起討論引入相關共識），並且增加判定論仍無果的方法（比如增加具體的時間判定）。--Sinet（討論） 2024年6月23日 (日) 16:12 (UTC)

任何人都能執行條款四。我確信如果社群已經注意到特定主題長期編輯戰，必然有人會就有關議題發起徵求意見，基本上不太可能出現「長期編輯戰，而雙方及第三方都不發起徵求意見」的情況。--路西法人 2024年6月24日 (一) 02:02 (UTC)

還是建議修改，否則按照原條款（4）的執行可能出現如下問題：

如果當事方或第三方中任意一方採用條款（4）啟動頁面外討論，那麼頁面外討論的共識引入頁面內可能基於兩種原因受阻：
1. 反對方基於條款（4）「經討論頁討論仍無果」判定標準不明確拒絕承認頁面外共識或反向指控提請方違反本方針。
2. 基於條款（4）發起的頁面討論與基於條款（1）發起的頁面內討論間效力關係不明，究竟是頁面外討論的共識效力「更高」還是頁面內討論的共識效力「更高」缺乏方針背書。
有些長期編輯戰的當事方往往是新手，而新手並不熟知或者沒有興趣去熟知條款（4）相關內容，如果不增加強制性動機，則很難觸發條款（4）；
條款（4）本身就是一種需要讓社群注意到長期編輯戰的方式，如果不更改觸發機制，則成了「為何需要先有一部分人注意到再讓社群其他人知道，如此給予那部分先注意到的人一些不應有的裁量權」。

題外話，之前的法論功主題貌似就屬於「長期編輯戰」這一範疇，而且並沒有人嘗試去互助客棧引入共識，反而是互相提報WP:VIP和WP:AN3。--Sinet（討論） 2024年6月24日 (一) 11:11 (UTC)

1. 在新規範下，不應存在「頁面外共識」（條文六：不應移動討論串，平行討論亦是移動討論的一種），討論仍然會繼續在該討論串進行，只是邀請了更多人參與。
2. 同上，不再存在「頁面外討論」。
新手不熟知條款，新增強制性也不會使他們忽然就知道這條條款。新規範的目的之一是讓老手教導用戶正確使用維基百科的討論機制，而有爭議、新手討論或編輯戰，很多時候都能在RecentChanges中被發現。
長期編輯戰光是在RFPP或管理員佈告板等已經能引起社群注意，條款四並非「讓社群發現編輯戰」，我上一則留言的說法是順序相反的「社群發現後執行條款四」。另，就算是局部共識也是有效共識，而後來的人仍然可以通過新共識去推翻舊共識，「先注意到」的人並不會「達成共識後就不能再改」，這個並不叫「裁量權」。

而你說FLG沒人去客棧引入共識就完全反映您沒關注客棧。光是Talk:法輪功未存檔的討論已經有五串是移動或存檔自互助客棧。你的通篇留言僅僅反映你沒有查證事實、沒有認真讀我的留言。--路西法人 2024年6月25日 (二) 02:08 (UTC)

試行專門討論頁

WP:CON/TRIAL。臺灣杉在此發言 (會客室) 2024年6月23日 (日) 06:46 (UTC)

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

討論2：重要：涉及限制互助客棧條目探討區討論之政策修訂

最新留言：1 個月前18則留言9個人參與討論

本主題或以下段落文字，複製自Wikipedia_talk:共識#重要：涉及限制互助客棧條目探討區討論之政策修訂。執行人：臺灣杉在此發言 (會客室) 2024年10月5日 (六) 06:37 (UTC)。

本主題或以下段落文字，移動自Wikipedia:互助客棧/條目探討。執行者：Jimmy-bot（留言） 2024年5月31日 (五) 08:14 (UTC)。

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

近月有若干修訂共識方針提案，將限制編者在互助客棧條目探討區發起討論，大略意涵如下：

一、禁止在互助客棧條目探討區發起「僅影響單一條目的討論」（也就是涉及單一條目的討論，例如討論「最大政黨列表」條目之原創研究問題等），也禁止將此等討論移動至客棧，只能發送討論通告；

二、禁止在互助客棧條目探討區發起「影響多個屬相同主題的條目的討論」（也就是涉及多於一篇類似領域條目的討論，例如討論「中華民國」及「臺灣」條目之架構等），也禁止此等討論移動至客棧，只能發送討論通告；

三、在互助客棧條目探討區發起「影響多個屬相同主題的條目的討論」時，應當在主題條目發送討論通告（但我不確定這是什麼意思）。

因提案影響既有權益甚大，卻未曾通知日常使用互助客棧的多數編者，故在此特別予以公告提醒，請編者注意並踴躍參與相關討論。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年5月18日 (六) 10:01 (UTC)

以下則純粹是個人意見：提案若獲得通過，代表目前客棧條目探討區超過三分之二提案都將遭到取締，只能改置所謂「討論通告」，根本形同廢除；至於討論通告究竟有多少用處，請參見目前徵求意見制度成效，本人實際參與條目相關話題的經驗是從冷清到平淡左右。互助客棧有許多顯性及隱性功能及作用是單一討論頁所難以取代者，我認為此提案未考慮客棧實際運作情況，縱然移植外來制度，企圖以行政手段改變流行習慣，為所謂「確保各討論頁獲得善用」（提案理由）箝制編者選擇討論管道之自由，損害運用客棧頁面討論之公益，是錯誤的形式主義及官僚主義政策（完整論述在討論頁）。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年5月18日 (六) 10:01 (UTC)

老實說我覺得這麼做會嚴重分流潛在的討論參與者。就比如我來說，我會偶爾逛一下互助客棧、看看大家的討論、有興趣就發表意見，沒有就離開。但是那些用rfc的我幾乎不會點進去看，除非有人ping我。不過路西法君的話也在理，全部都擠到互助客棧確實造成頁面過大、難找diff之類的問題，如果社群能接受這些缺點我覺得倒也不必強推一定要到討論頁討論。因為不是針對該條文的意見我就發在這裡了。--微腫頭龍（留言） 2024年5月18日 (六) 11:26 (UTC)

反對此提案。這屬於是徹底與本討論區的初心（詳「維基百科:互助客棧/條目探討/存檔/2010年10月#建議維基客棧增開「/條目」分棧」）相違背。我認為現狀至少令人勉強滿意，沒有改動的必要。—— 　桁霽　 ↹　晚來天欲雪，能飲一杯無　　 2024年5月18日 (六) 23:33 (UTC)

原來當時就有討論了，正反意見還與今日相去不遠。不過依據過往經驗，您單純在這裡講是沒有用的 :( —— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年5月19日 (日) 11:18 (UTC)

互助客棧條目討論區同樣自創立至今都有任何條目或模板的交流應考慮先在其討論頁發表，而若無人加入討論才可在此發起。（後半句直至RFC啟用前都仍然存在）的要求，本討論區自設立之初更是有跟當今提案意義完全相同的要求（任何條目或模版的問題、疑慮、懷疑、參考文獻、有關文章的論戰或者評論應該先在相關的條目討論頁提出來並在討論段落加上{{indiscussion}}模板，最近7天在條目對話頁上的討論會出現在討論索引，而若無人加入該討論才在此發起，若否則可能被移動回{{Moveto}}原條目討論頁，討論頁指導方針亦在此適用。），現在全部討論塞在這裏才是真正「徹底與本討論區的初心相違背」的體現。貴站用戶選擇性「初心」的操作真的很難看。--路西法人 2024年5月21日 (二) 00:39 (UTC)

你說得對，路西法人，我選擇性初心的操作真的很難看，太難看了。問題是我也不是沒有用過條目討論頁，被搭理的情況微乎其微。—— 　桁霽　 ↹　晚來天欲雪，能飲一杯無　　 2024年5月21日 (二) 03:09 (UTC)

樓上王桁霽君說的的確是，在討論頁發起討論很大概率不被理會。我前幾天在Talk:1954年克里米亞轉交事件和Talk:蘇阿戰爭掛了rfc至今無人參與討論，可見社群有多麼不重視rfc。（Talk:1954年克里米亞轉交事件的那些討論是在掛rfc前討論的）。另外，最近@LuciferianThomas的機器人好像沒發討論邀請，難怪沒人參與。請不要告訴我去ping人，因為有時候我不知要ping誰。--微腫頭龍（留言） 2024年5月21日 (二) 03:25 (UTC)

依據我目前正在公示的版本，以Talk:蘇阿戰爭為例，你應直接先跟作出爭議編輯的用戶交涉（就ping他一個），然後無法達成共識就ping過往參與編輯有關主題和條目的用戶，從頁面歷史中都ping一下就已經是了。仍沒人參與再請求外部意見。

另外，「不被理會」始終在於客棧目前仍然是有大量話題，#正在廣泛徵求意見的議題一節自然難以引起注意；機械人壞了是因為User:Ericliu1912非常善心地手癢破壞了機械人自動閱讀列表的格式@Special:Diff/82499812。--路西法人 2024年5月21日 (二) 03:57 (UTC)

再者，共識方針本來就有當無法透過討論頁討論時[…]，維基百科還有幾套既定的流程去徵詢外部編者的意見。共識本來就是從小討論慢慢展開到大討論，「徵詢外部編者的意見」的前提是「當無法透過討論頁討論時」。現在配備了更多機制供在原始討論頁討論，但現況顯然是「沒有充分嘗試」而非「無法」。--路西法人 2024年5月21日 (二) 00:53 (UTC)

大概的看法和一些實際操作來看：一般情況，只針對特定條目或者模板的單一頁面的討論問題，應該是先在討論頁討論解決，在無法在單一頁面達成討論共識（可能需要更大範圍的共識討論）甚至範圍擴大的情況時，才拉到條目探討版處理。也存在預期需要更大範圍共識討論（或者認為對應討論頁關注程度偏小而尋求更矚目的關注）的情況下，就出出現一步拉到條目探討版而非先在對應討論頁討論的情況。現有的調整意味着以明文的方式限制後一種情況，但這可能與實際操作上存在矛盾，所以雖然過往的規則上是希望循序漸進，但實際上存在這樣的跳島路徑。至於是否為了保證現在為先單一討論頁進行討論同時為了保證引起關注而利用（或者從提案者的角度來看，更像是推廣自己的成品）討論提醒機制的情況，我認為還是尊重現有的做法，當然愛循規蹈矩的和愛用那東西的，隨便。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月21日 (二) 02:41 (UTC)

WP:IAR，法則僅僅是原則而非死例。就條目討論共識，我還是不認為限制位置或者使用工具的方式。我認為條目探討版還是可以作為更高可見度的條目內容探討或討論的主要板塊。該願意在這裡討論的還是這樣做，願意用RFC或者討論提醒的就讓他們去吧。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月20日 (一) 00:48 (UTC)

我贊同"只聞客棧罪大惡極問題多，條目討論頁問題豈少"。現實中就有類似的制度，為了讓上級部門減負、提高解決重大問題的能力，所以就禁止下級人員直接到上級部門處理事務，那就是歷朝歷代的逐級上訪制度，結果在基層解決不了的事情到最後也是爛尾，反而起到了正當化「基層問題」的作用。我承認從條目討論頁開始，一級級擴大討論是一種最佳實踐，但是現實告訴我們，最佳實踐的強制化、法條化最終只會得到適得其反的結果。現實就是沒有多少人把條目的討論頁當一會事，甚至不少編者都沒有自動訂閱自己創建頁面的討論頁，也沒有多少爭端是在討論頁就得到解決。再給出現實中相反的實踐，蘋果CEO庫克對於任何用戶的來信向來有求必應，這也不見得他會因為這種做法降低效率。

最後再講講這些條款的預設前提，第一客棧討論的內容一定要比一般討論頁來得「高級」，第二討論的重要性只能由影響條目的數量決定；第一個前提我完全覺得這就是官僚做派，所以維基百科最大的流量入口之一只能討論國家大事不能討論民間疾苦，所謂的站務就一定比普通人之間的討論更為重要、更為高貴；而第二個前提我也難以苟同，再這麼長的討論串中我也難以確定規則的制定者到底是為了什麼才給出這種規定，這又是有哪種理論支持這種觀點，如何證明維基百科訪問量最大的「中華民國」條目的討論比涉及100個低流量條目的小修改要低級一些，我覺得這種判定方法難言科學。--Cat on Mars 2024年5月31日 (五) 16:48 (UTC)

我覺得CatOnMars說的很好！如果限制在客棧發言就是相當於逐級上訪制度。--桐生ここ★[討論] 2024年5月31日 (五) 20:02 (UTC)

逐項回覆：

層遞討論與逐級上訪制度比較：逐級制度是A找B（AB嘗試解決問題）、不行再找C（AC嘗試解決問題），其中B和C作為較「高級」的人員可能存在官僚或濫權，更會有人試圖阻止A向上聲請；層遞討論是A加B然後再加C，而ABC都是平等的用戶，無所謂「上下級」觀念，無人能阻擋其他人再向聲請其他人參與。顯然是不可比擬的情況。你所說逐級上訪制度，在基層解決不了的事情到最後也是爛尾，起到了正當化「基層問題」；認真分析一下上方用戶討論，卻會發現反對削減互助客棧的用戶存在「沒給基層討論解決問題的機會，正當化『基層討論存在問題』，然後以此阻礙全面鼓勵基層討論嘗試解決問題的機會」，社群的情況顯然與逐級上方制度是完全相反的。
討論頁的重要性：一來社群的機制設計本身不鼓勵使用討論頁，自然沒人當討論頁一回事；二來用戶只要有監視自己創建的內容空間頁面，連帶的討論頁也是會自動監視；三來「沒有多少爭端是在討論頁就得到解決」完全是倖存者偏差的觀念，解決了的問題根本輪不到社群廣泛注意到。
蘋果CEO庫克的例子：庫克對於任何用戶的來信都是有求必應是一件好事，但若所有人事無大小（一切蘋果相關的問題）都直接找他，他的處理管道不就會出現擁塞，導致難以及時分配資源跟進從而機制失效了嗎？現在的客棧不正是「原先是一件好事，但現在因被過度使用而是失效」嗎？維基百科依賴社群的自我管理和協作，而非集中化的高層決策。這種模式下，討論頁提供了一個基層參與和解決問題的平台，這是其運作方式的基礎。
條款的前提：同上。另，就算是「100個低流量條目的小修改」，我仍然是鼓勵在條目討論頁開啟討論。給我真的全面推這個議案，我是情願不再讓用戶在客棧發起任何討論，而僅用作引流，只是現在被反方用戶弄得必須給這個選項而已。我的理念是所有討論都是平等的，沒有一條條目討論比其他「重要」，而僅應有討論本身是否具爭議性、話題性或「影響力」而由編者決定是否參與。也如同我上面反駁桐生最新提案及Ericliu回應的留言中提及，「影響廣泛的討論本身就是導致客棧過長的主要食糧，這些需要分流分拆到其他地方討論；影響較低的討論很多本身就不至於需要整體社群關注（甚至在客棧也不多人參與），直接在討論頁使用徵求意見或許已能滿足該類討論需求。」長的不適合放在客棧（會過長），短的也不需要放在客棧（現在有同等效力的替代工具，客棧給予曝光引流即可），這個才是以上提案條款的前提。

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

原始RFC搬移者的回應

作為原始RFC翻譯者，看完最近的討論之後，有些話要說。

以個人立場，我是同意互助客棧必須要做一定程度的減壓，所以才會嘗試引入其他機制，只不過當時不知道如何建置機器人而已。
如果觀察到英語維基百科和中文維基百科的首頁配置，可以發現到中維有「互助客棧」的連結，而英維沒有。這就可能導致中維的新手使用者直接點入互助客棧而不是中英維都有的「社群入口」。其實英維的設計我覺得更好，必須要凸顯「社群入口」當作新手獲取維基百科社群資源的第一站，而不是互助客棧。
我不知道集中式討論是不是我們獨有的特性，所以特別偏愛單一頁面就能夠解決所有問題，這個可以再好好討論，甚至可以做一下意見調查。例如：
您喜歡的是互助客棧集中討論，還是先在條目討論頁討論，如有需要才去互助客棧討論？

您認為為何條目討論頁很好用/難用？

目前中文維基百科開始引入了「徵求意見」、「請求回饋系統」等相應措施，您是否已經開始使用？

如果有使用，您認為是否有效解決互助客棧的問題？如果沒有使用，請問您的考量點為何？

您認為中文維基社群要如何行動，才能改善條目討論頁功能不足的問題？

大概是這樣。臺灣杉在此發言 (會客室) 2024年5月31日 (五) 14:23 (UTC)

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

討論3：重要：涉及限制互助客棧條目探討區討論之政策修訂（續）

最新留言：1 個月前8則留言7個人參與討論

本主題或以下段落文字，複製自Wikipedia_talk:共識#重要：涉及限制互助客棧條目探討區討論之政策修訂（續）。執行人：臺灣杉在此發言 (會客室) 2024年10月5日 (六) 06:40 (UTC)。

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

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

近月有修訂共識方針之提案，將限制編者在互助客棧條目探討區發起討論，大略意涵如下：

一、禁止在互助客棧條目探討區發起「僅影響單一條目的討論」，也禁止將此等討論移動至客棧，只能發送討論通告；

二、禁止在互助客棧條目探討區發起「影響多個屬相同主題的條目的討論」，也禁止此等討論移動至客棧，只能發送討論通告；

三、在互助客棧條目探討區發起「影響多個主題條目的討論」時，應當在主題條目發送討論通告。

因提案已重行公示，且涉及目前此頁面多數討論，故再一次予以公告提醒，請編者注意並踴躍參與相關討論。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月12日 (三) 18:25 (UTC)

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

根據原提案，三應該是指「影響多個不同主題的條目的討論」，和二沒有衝突。--Wolfch (留言) 2024年6月13日 (四) 09:20 (UTC)

按所謂「重行公示」版本調整了內容。但我還是有看沒有懂，相信以後其他編者也將如此。行文都這副樣子，未來強行執行之效果恐怕是一言難盡！—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月17日 (一) 06:34 (UTC)

(－)反對二和三，因為自相矛盾，恐存選擇性執行之漏洞，Wolfch的和二沒有衝突說法恐怕語焉不詳。--Liuxinyu970226（留言） 2024年6月17日 (一) 06:23 (UTC)

不知道會怎樣。但是我相信LuciferianThomas肯定會持之以恆並忠誠地守着這個版塊來將不符合他的理念的討論移到他認為合適的地方，並持續地推廣那套機制。

——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月26日 (三) 07:54 (UTC)

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。