维基百科讨论:共识

共識建立的遞進步驟

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

公示通過，試行方案即日起施行，相關後續討論請到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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

回應：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一次公示（已停止）

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

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

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

---

原标题为：公示版本

原标题为：第二階段討論

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

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

即新增規範如下：

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

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

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

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

例如

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

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

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

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

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

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

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

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

(！)意見：關於您剛才提到的第三條，可以針對該分類含有的條目數量來判斷（例如若分類中的條目數量大於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，也不見得能找到成百上千個用戶。Sanmosa _{全方貧工之聯合} 2024年5月11日 (六) 15:07 (UTC)

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

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

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

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

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

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

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

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

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

回應：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

關於指引。

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

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

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

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

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

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

關於條文。

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

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

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

回：

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

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

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

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

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

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

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

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

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

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

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

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

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

遠者有：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

第二階段討論

原标题为：重新統整提案及參與者意見

原标题为：統整

原标题为：第三階段討論

LuciferianThomas版本

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我也是同感 -“我本人虽认同他的初衷，但反对强制推行”--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)

1. 社群合理的决策程序问题重要性可能比提案本身影响更大。如果他仍然把所有反对意见全部仅按著自己的意愿而定性为非“正当合理意见”，是否很难看出是能按共识方针的本意处理提案？
2. 不知您和其他管理员团队成员，是否能先协助按共识方针的本意解决社群合理的决策程序问题？
3. 也请社群发表意见，是否应该先协助按共识方针的本意解决社群合理的决策程序问题？ 是否可以不故其他人的反对，一直坚持将所有反对意见全部仅按著自己的意愿而定性为非“正当合理意见”？ --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 认为共识根本和“多数”“少数”无关 。 Wikipedia:何谓共识#不是多数表决"51%的人倾向的选择通常并不足以形成共识，而只有少数人支持的选择更基本不可能是共识"。 所以我提出：避免采用只有少数人支持的方案。如果一个方案没有得到大多数人的认可，那么它可能不是最佳选择，因为它可能无法代表大多数人的利益。 UjuUjuiMandan 不同意上面观点， 认为一件事对还是不对和人数多少没关系，主要看论述 。 但在下觉得UjuUjuiMandan的观点不符合： 上面引用的Wikipedia:何谓共识#不是多数表决中的表述。 我的回应为： 关于“主要看论述”， 双方对同一论述可以有相反看法。总的来说，虽然正确与否不应仅仅基于人数多少，但在实际操作中，民主和社会契约的原则导致了多数决的做法。这是一种平衡个体权利和集体利益的方法，尽管它并不完美，但在许多情况下被认为是最公平的解决方案。 按我的理解，另外三个参选人认可我的观点。 我不认为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)

1. 您提到：“面對我WP:RFC/RFA2024總結多數共識的時候，不同意我的用戶就懂得拋出「共識不是數人頭」等說法，現在他們就開始來數人頭了，就噤聲假裝看不到，雙標到一個極致。”
   • “就噤聲假裝看不到”“雙標到一個極致”是否假定我应该看到， 并而应该支持您正确理解了共识的识别需要數人頭？
   • “就噤聲假裝看不到”“雙標到一個極致”是否是假定动机， 违反了假定善意？ 折叠理由是否是假定动机， 违反了假定善意？
2. 阁下按自己理解，折叠反对者的发言，而不是由社群中立者的理解， 然后继续回应。 这是否得当？ 请社群发表意见。--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)

桐生ここ版本

原标题为：桐生版本

建议简单一点：

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

这样就可以了。--桐生ここ★[讨论] 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口中所謂「落實此原則便足以解決現存多數問題」又是毫無論證，甚至連提供了的九個問題都沒能指出解決了哪一項，只留「解決了問題」一句話但實際沒有反映如何解決問題的議事方式實在不負責任。就九個問題的分析：

1. 當前制度未能鼓勵用戶在徵求第三方意見前嘗試自行解決爭議——桐生版本僅局部解決了這個問題，但仍有很多情況都未能推動改善討論習慣。桐生版本沒有要求用戶先行跟涉爭議的用戶自行展開討論、沒有要求二人商議無果邀請其他編輯該條目的編者參與討論，沒寫的顯然社群多數都不會做。影響同一主題下的條目的討論根本不應該容許直接在條目探討板發起，而是應採用能鼓勵編者先行與編輯相同專題的用戶商討協調如何在社群方針指引框架下編輯，同主題跟單一條目的情況都存在「應該先進行的更下層討論」，同主題但多個條目的討論沒有實際理由能支撐一開始就跑去客棧發起的選擇。
2. 跟條目有關的討論無法在討論頁中找到——幾乎沒解決，多數「相對重大」的討論的問題仍然存在（尤其是桐生版本沒要求在適當的討論頁發送討論通告，更是無法解決
3. 客棧再開討論形成平行討論——完全沒解決，不限制從討論頁轉移討論至客棧則仍然會繼續有這個問題，仍需要用戶額外巡查確保原處討論已經關閉（反觀從客棧移到討論頁多數會整串移走或關閉）
4. 互助客棧並非新用戶「直覺」就知道是討論的場所——無對應措施解決，新用戶仍然難以參與任何在客棧的討論。
5. 客棧過長——拿「分流」的說法來說，個別條目的討論反而比較多是相對較短的討論串，反而影響條目眾多的條目才是討論會比較長的話題（更容易引起爭議），桐生版本解決客棧過長問題的效果非常有限。
6. 互助客棧討論串過多，本身性質比較不受關注的討論會更難被注意到——無對應措施解決。
7. V
   • 客棧討論結束在多處自動存檔形成平行討論——無對應措施解決。
   • 難以在客棧查找討論存檔——無對應措施解決，存檔仍然存回討論頁，無法搜尋在客棧進行過什麼討論。
8. 討論串過多，想參與討論的用戶每次都要在字海中找話題——無對應措施解決。
9. 客棧無法讓用戶持續追蹤特定感興趣類別的話題——無對應措施解決，但這個開放在客棧使用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. 為善用社群討論資源，
   1. 僅影響單一條目的討論須在條目討論頁發起；
   2. 影響多個屬相同主題的條目的討論須在主題條目、專題佈告板或任一受影響條目的討論頁發起，並在情況許可下其餘受影響條目的討論頁發送討論通告（若受影響條目過多，應以通知專題佈告板及@提及為主）；
   3. 影響多個主題條目的討論可在任一受影響主題條目的討論頁或互助客棧條目探討板發起，並應在互助客棧及受影響的主題條目的討論頁發送討論通告。
   4. 未有條目的討論可在適當的專題佈告板或互助客棧條目探討板發起。
2. 編者應先盡可能自行透過討論解決爭議，過早徵求第三方意見可能使爭議另一方認為其意見不被尊重。在條目討論頁發起討論時，應發送通知（@提及或用戶討論頁通告）涉爭議的用戶參與討論（如有）；在無法解決時邀請近期編輯有關條目／主題的用戶參與討論。
3. 錯誤場合發起的討論可被關閉（需指出重新發起討論的合適場所）或移動（需保留討論討論主題及移動目標頁面連結）。
4. 經討論頁討論仍無果或下列情況下——
   1. 過往曾討論而未達成共識或需要改變共識的議題；
   2. 討論影響多個條目；
   3. 高風險主題條目的討論，
   編者可往互助客棧發送討論邀請通告及將討論加入徵求意見系統以獲取第三方意見。
5. 在其他頁面發送討論邀請通告時，應在討論串中申報以免造成拉票誤會。會顯示文本的@提及則不需重複申報。
6. 除討論過長需要分拆為獨立討論頁、討論在錯誤場合發起等情況，不應在發起討論後移動討論串，以免造成混亂；討論結束後亦應讓討論原地存檔，避免重複在多個頁面存檔後出現討論分支。
7. 社群可考慮新增機械人任務向受影響討論頁發送討論通告及結論。

由於反對提案的用戶一直未能提出能被邏輯、方針指引及共識方針本身的基本原則合理支撐的論點回應提案，存在邏輯謬誤的論點本來就是客觀認定的「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)

1. 若有人聲稱擁有條目控制權，新機制下仍能在客棧發討論通告（這次可以寫明「有人聲稱對主題/條目擁有控制權，請求協助」這類），仍然是可以在客棧求助；再不是，掛個RFC請求協助也是可以吧。新制只是把社群用戶帶回原有討論串參與，而避免討論出現分支造成混亂。（註：未來有仲裁委員會，若社群無法解決用戶聲稱控制權，那麼就可以提報仲裁處理）
2. 「經討論頁討論仍無果或下列情況」，無人參與實質上是你發起了討論頁討論而無果，這時確實可以往客棧發討論邀請和開展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 为此+1了。--Liuxinyu970226（留言） 2024年6月18日 (二) 08:29 (UTC)

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

再次討論合法性問題

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

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

就這兩方面來回應。

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

以上試行方案即日起 公示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）的执行可能出现如下问题：

1. 如果当事方或第三方中任意一方采用条款（4）启动页面外讨论，那么页面外讨论的共识引入页面内可能基于两种原因受阻：
   1. 反对方基于条款（4）“经讨论页讨论仍无果”判定标准不明确拒绝承认页面外共识或反向指控提请方违反本方针。
   2. 基于条款（4）发起的页面讨论与基于条款（1）发起的页面内讨论间效力关系不明，究竟是页面外讨论的共识效力“更高”还是页面内讨论的共识效力“更高”缺乏方针背书。
2. 有些长期编辑战的当事方往往是新手，而新手并不熟知或者没有兴趣去熟知条款（4）相关内容，如果不增加强制性动机，则很难触发条款（4）；
3. 条款（4）本身就是一种需要让社群注意到长期编辑战的方式，如果不更改触发机制，则成了“为何需要先有一部分人注意到再让社群其他人知道，如此给予那部分先注意到的人一些不应有的裁量权”。

题外话，之前的法论功主题貌似就属于“长期编辑战”这一范畴，而且并没有人尝试去互助客栈引入共识，反而是互相提报WP:VIP和WP:AN3。--Sinet（讨论） 2024年6月24日 (一) 11:11 (UTC)

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

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

試行專門討論頁

WP:CON/TRIAL。臺灣杉在此發言 (會客室) 2024年6月23日 (日) 06:46 (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翻譯者，看完最近的討論之後，有些話要說。

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

   您喜歡的是互助客棧集中討論，還是先在條目討論頁討論，如有需要才去互助客棧討論？

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

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

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

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

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

---

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

提案改成個人化頁面

我很快看了一下目前的提案，沒有一個是我喜歡或想用的。我認為問題有兩方面，一方面是探討區內容太多，一方面是希望有足夠的人參與討論。這種問題其他網站其實解決過，例如新聞網站會讓用戶選擇他感興趣的新聞類型，用戶只會看到自己感興趣的新聞。例如我選擇只看羽球新聞，我的頁面就不會顯示籃球或足球新聞。所以我的提案是把探討區改成個人化頁面，用戶只會看到自己感興趣的分類，提交的問題必需分類。至於分類是根據現有的主題還是別的分法，大家可以集思廣益。--歡顏展卷（留言） 2024年6月16日 (日) 14:30 (UTC)

您可以參考一下Template:RFC list footer。這個部分可能就是您所說的一種體現。此外，透過WP:FRS也能實現只關注某些領域討論的功能。--臺灣杉在此發言 (會客室) 2024年6月16日 (日) 16:27 (UTC)

既然大方向是強化討論頁作用，又不應忽視客棧既有之優點，那很有必要考慮研發能彙整嵌入整個話題的「客棧子頁面」機制（進一步分拆條目探討區），而不是像現在徵求意見祇看得到首句，恐怕很多人就因此懶得點，效果差也是可以預期。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月16日 (日) 22:33 (UTC)

這個方向（條目探討分領域）沒有問題，但是完整顯示討論部分，我的建議是嵌入的話題除了顯示首句之外，其餘部分全部摺疊，這樣除了版面較簡潔，還能夠減少點擊次數。不過我覺得這是後話了，先看看路兄方案實施後一個月的情況再做考量吧。臺灣杉在此發言 (會客室) 2024年6月17日 (一) 06:40 (UTC)

我根本就不覺得上面那提案「討論替代率」有多高，就是考慮到人性。人性是不可量化的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月17日 (一) 04:58 (UTC)

也可以把条目探讨区按主题划分为几个类别，这样也能解决--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 11:47 (UTC)

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

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

---

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

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

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

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

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

三是笔误？是第二项所禁止的。--YFdyh000（留言） 2024年6月13日 (四) 06:10 (UTC)

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

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

(－)反对二和三，因为自相矛盾，恐存选择性执行之漏洞，Wolfch的和二没有冲突说法恐怕语焉不详。--Liuxinyu970226（留言） 2024年6月17日 (一) 06:23 (UTC)

不知道会怎样。但是我相信LuciferianThomas肯定会持之以恒并忠诚地守着这个版块来将不符合他的理念的讨论移到他认为合适的地方，并持续地推广那套机制。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月26日 (三) 07:54 (UTC)

---

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

提議清楚定義何謂「正當合理的回應」

根據WP:共識的公示條文：

---

另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。

---

假設提問者在提案討論提出一個具建設性的問題給提案人，而提案人為了希望該提案盡快獲得通過，以解決當前指引的漏洞，故提案人選擇坐在電腦前，當提問者提出意見後，提案人秒回提問者的意見。3天後，提問者並無進一步回應。

根據上述條文，應視為該意見已解決且不需再回覆。

可是，在7天後（即回答問題後10日），也是公示期結束前一天，提問者認為提案者的回應不正當合理，於是強行終止公示。

---

個人認為這是一個拉布的行為，嚴重影響共識形成。

---

1.首先，何謂「正當合理的回應」？誰有權在3日限時以外可以judge這個回應？

2.其次，理論上，共識應解決所有合理的問題，唯提問者在提案者回答後3日不回應相關答案，算不算已解決相關問題。

3.如果這裡有4名編輯者參與討論，當提案者回答提問者（這裏已有2人）問題後，其餘2位編輯者也發表與提案者類近回答及補充。4日後，提問者可不可以認為提案者的回應不正當合理而當提案者的回應不算數？

---

以上！（希望在條文中清楚定義何謂「正當合理的回應」，可以是其他編輯者投票或第三方管理員進行判定，以避免因此而造成拉布的理由。）--唔好阻住我愛國（留言） 2024年6月25日 (二) 11:20 (UTC)

不要墨守成规，以讨论而非流程时限去判定。

是否已解决，提问者最有发言权，视为已解决是一种假定（类似自动评价），当事人始终有权在公示前后再度表态，不能以流程堵嘴说来晚了、已视为已解决，且“共识可以改变”。

问答是否正当，参与讨论者均可表态与附议，不清晰可以直接问。

恶意拉锯请考虑游戏维基规则的警告、举报，可附注之前回应或者更广泛的意见。但执意推进不成熟的提案同理。--YFdyh000（留言） 2024年6月25日 (二) 14:24 (UTC)

「提問者最有發言權」，難道我可以在問題被回答後十個月後提出該回答是否合理？--唔好阻住我愛國（留言） 2024年6月26日 (三) 12:01 (UTC)

视作新问题？是否打破之前共识，倾向按常识个案讨论处理。视作已解决不代表失去未来资格，可能要看是否应当解决。--YFdyh000（留言） 2024年6月26日 (三) 16:14 (UTC)

顯然是祇能個案判斷。雖然本人一向認為近來若干討論有擴大解釋的不良傾向。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月26日 (三) 04:16 (UTC)

離題的當然就不可能是正當合理意見。若有違基本邏輯，能被指出邏輯漏洞甚至是邏輯謬誤的意見，客觀及字面意思上不符合「正當合理」，因存在邏輯謬誤的論點本來就是客觀認定的「invalid arguments」（某大學資源、人文作家、GPT輔助解釋、另一大學資源）。若並無明顯違反邏輯或存在邏輯謬誤，則以是否與其他方針指引牴觸為考量因素，確實與其他方針指引相違背的不可能視作有效意見考量。另外，共識方針也指明過往已獲回應，而並未提出新觀點，僅僅重複過往觀點的留言不需重複回應。其餘絕大多數情況都是正當合理的意見。--路西法人 2024年6月26日 (三) 08:01 (UTC)

「共識方針也指明過往已獲回應，而並未提出新觀點，僅僅重複過往觀點的留言不需重複回應。」：

甲人：我認為論點A是十分重要 —> 1日後—> 乙人：基於論點A，這是見解B ；丙、丁、戍人：見解B所言正解—> 3日後 —> 開始公示 —>6日後—> 甲人：我認為你沒有回答問題，見解B的論點完全不合理，所以我還是認為論點A是十分重要，於是強行終止公示。

——

換算是閣下的共識議案，我套用這個邏輯找閣下提案的不足，閣下肯定會覺得非常不滿。--唔好阻住我愛國（留言） 2024年6月26日 (三) 11:49 (UTC)

因為這個邏輯，本人的提案已被拉鋸足足2個月（討論及完善條文僅使用1個月），而對手是管理員，根本無從入手解決問題。--唔好阻住我愛國（留言） 2024年6月26日 (三) 11:57 (UTC)

單單說「沒有回答問題」而沒有論證則同樣為無效，除非能夠論證如何沒有回應問題，否則都不能說對方的回應不合理。--路西法人 2024年6月27日 (四) 06:54 (UTC)

條文沒有這樣寫…

而且隔這麽久先質疑回應的正當性會不會有問題？--唔好阻住我愛國（留言） 2024年6月27日 (四) 11:20 (UTC)

如果重複為了拖延提案而選在公示將近結束前才發表反對意見，就是遊戲共識形成過程的行為。況且，缺乏論證的觀點本來就不屬於可供參考的意見，缺乏論證或論證明顯有誤的「沒有回答問題」也同樣不會是有效的程序質疑。--路西法人 2024年6月28日 (五) 02:42 (UTC)

比較想不用頗主觀性的遊戲維基規則，如管理員參與了戰爭，一切最終決定權還是管理員。

—-

打算這樣改

另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應（如編輯者欲質疑相關回應是否正當合理，必須於問題被回應後3天內提出，並詳細說明該回應有什麼不足），且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。--唔好阻住我愛國（留言） 2024年6月28日 (五) 03:34 (UTC)

不認為有必要限制必須在三天內提出，但確實有必要規定述明有何不足。--路西法人 2024年6月28日 (五) 09:41 (UTC)

但應同時避免無限期等待或最後一刻先發表重復的意見。--唔好阻住我愛國（留言） 2024年6月28日 (五) 14:14 (UTC)

這是當然，但這樣寫就會變得相當模糊，還不如直接將其視作玩弄社群建立共識的程序處理更好。--路西法人 2024年7月3日 (三) 01:48 (UTC)

另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應（如編輯者欲質疑相關回應是否正當合理，必須於問題被回應後儘快提出，並就每一不足論點詳細說明該論點的不足之處及提出可接受的建議。），且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。

我相信管理員在調查破壞者是否玩弄社群時會參考破壞者的貢獻記錄，看看是否達到「儘快」要求。--唔好阻住我愛國（留言） 2024年7月3日 (三) 15:14 (UTC)

@Ericliu1912@Factrecordor@LuciferianThomas@YFdyh000:三日後無反對意見的話就開始公示這個版本。--唔好阻住我愛國（留言） 2024年7月12日 (五) 11:05 (UTC)

您不能只要求「質疑者」詳細說明該論點的不足，還要提出可接受的建議這樣子。「提案者」和「質疑者」兩者的責任並不相稱。而且「可接受的建議」也太主觀，也不合適。質疑者沒有必要教提案人如何寫好方針好嗎。--Ghren🐦🕛 2024年7月12日 (五) 16:52 (UTC)

遊戲維基社群也屬於主觀規條。

正如路西法人道「 缺乏論證的觀點本來就不屬於可供參考的意見」，不能單單一句「我不同意這個回覆」而影響整個討論。--唔好阻住我愛國（留言） 2024年7月13日 (六) 01:18 (UTC)

請問Ghren在說天秤兩邊重量不成比例，導致共筆版本傾斜於提案方的問題嗎？即使想釐清正當合理的狀況，但要其他人質疑來決定正當合理與否，此舉潛在默認了沒有受到質疑的回應。 -- 月都 ※ 2024年7月14日 (日) 16:10 (UTC)

• 上方兩名用戶都將「質疑者」定性為「反對提案的人」，但這個條文寫的是「編輯者」，同樣可以套用於「正方質疑反方提出的回應」，正方的質疑同樣需要詳細論證論點的不足。
• 「可接受的建議」確實過於主觀。
• 上方用戶指出質疑者沒有必要教提案人如何寫好方針好嗎，同樣可以還一句「提案人沒必要教反方如何提出真正有力的論述」。現在很多時候是反方恃着自己是反方，然後不論自己意見是否合理，就硬打說提案有反對意見不應通過；演變成「反方說自己的反對意見有效就行，不論正方怎樣有力的反駁、反方自己的意見如何無力，反方的反對意見依然自稱有效」，和「反方不同意自己意見被認定非正當合理或已被回應，但同時卻在認定正方的回應並非正當合理，令自己的意見維持有效」。現在的釐清顯然是將天秤從偏向反對方拉回中間而已。

--路西法人 2024年7月17日 (三) 04:47 (UTC)

「可接受的建議」—>「改善建議」

這個可以嗎？--唔好阻住我愛國（留言） 2024年7月17日 (三) 10:20 (UTC)

不太行。指出對方說法有問題後並無原因要協助修正對方的說法。指出對方錯誤後推翻其提案/意見難以構成「改善建議」，但確實仍能合理推翻對方意見。--路西法人 2024年7月18日 (四) 08:32 (UTC)

「，並就每一不足論點詳細說明該論點的不足之處及提出可接受的建議。」—>「，並就每一不足論點詳細說明該論點的不足之處。」--唔好阻住我愛國（留言） 2024年7月18日 (四) 10:34 (UTC)

Version 2:

另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應（如編輯者欲質疑相關回應是否正當合理，必須於問題被回應後儘快提出，並就每一不足論點詳細說明該論點的不足之處。），且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。

--唔好阻住我愛國（留言） 2024年7月20日 (六) 06:41 (UTC)

不行，不一定要詳細才能指出對方不足，有時簡短的兩三句話就已經足夠說明不足之處。相對的，詳細也不一定可以說明不足之處，如果論點本身有錯，再詳細也沒有用。--素菓霖 2024年7月23日 (二) 05:42 (UTC)

同。說一百句但言之無物也沒用，指出對方說法邏輯謬誤三五句也可以足以駁回對方論點。--路西法人 2024年7月23日 (二) 09:15 (UTC)

「詳細」：沒有列明字數，但不相信一句就能反駁，你們的對我的反駁也至少兩句啦。--唔好阻住我愛國（留言） 2024年7月23日 (二) 15:06 (UTC)

這是模糊與否的問題（--路西法人 2024年7月24日 (三) 02:36 (UTC)

但如果是玩規程問題或模糊表達，當然與「詳細說明」有很大落差。--唔好阻住我愛國（留言） 2024年7月25日 (四) 13:52 (UTC)

我們在編輯某些條目，察覺一些方針需要制訂或修改，卻不一定常涉足所有受該方針影響的範疇，先反思影響範圍，再看看哪些用戶經常活躍於箇中話題，邀請討論，所有潛在疑問可能在兩三星期內就能被大家想出來了，可以集中解決。若不這樣做，往往有個人偶爾路過，又放下一個疑問，自然無休無止。就算你曾經順利通過提案，也只是你的一時幸運，而你的幸運不一定是維基之福。--Factrecordor（留言） 2024年6月26日 (三) 13:01 (UTC)

「偶爾路過，又放下一個疑問」，這個絕對支持，唯該路人是不是應該負起責任，主動跟進自己問過的疑問，如有需要，應儘他能力以最快時間進行追問，避免社群其他成員無限的等待，這對提案者絕對是一個折磨。--唔好阻住我愛國（留言） 2024年6月26日 (三) 13:13 (UTC)

我反而認為追問是提案者（或者任何主持討論者）的責任。問了沒人答，所等待的是要回答的人，而不是提問者。這不是現實生活的上班（那種情況下提問者不追問會影響他的工作進度以至績效考核）。而且很多情況下，路過提問的潛在訊息是：提案不通過對者是最有益的（不然他也不用提問，由得提案通過吧）--派翠可夫 (留言按此) 2024年7月31日 (三) 03:18 (UTC)

@Patrickov:重點是：提問者問完，提案者馬上回答，隔了一個公示週期，提問者先質疑相關回答的有效性並同時強行中止公示。而非「問了沒人答」。--唔好阻住我愛國（留言） 2024年7月31日 (三) 11:18 (UTC)

那不叫「偶爾路過」而是「找碴」吧。不過有意阻止公示的拉布行為可否當擾亂處理？--派翠可夫 (留言按此) 2024年7月31日 (三) 16:37 (UTC)

理論上應該如此，然而提案人聲稱這樣做的人包括一個管理員，我真的不知道究竟管理員是否實際上能夠受這條規則約束。Sanmosa _蚌埠 2024年7月31日 (三) 22:44 (UTC)

管理員參與了爭論就當然要避嫌，找另一個管理員甚至行政員去主持公道，如果那個管理員玩太大就提案解任他--派翠可夫 (留言按此) 2024年8月1日 (四) 02:56 (UTC)

根據什麼要求解任？

• 「遊戲維基社群」？畢竟他浪費了社群時間，但事實上沒有這個規矩。
• 「WP:遊戲維基規則」？例子清單中並沒有關於規程的內容/限制。

——

討論應該專心討論事件，而非玩弄規程問題。這裏不是台灣立法院及2019年前的香港立法會。如果有規例強制要求當有編輯者提出規程問題，第三方管理員需要介入調停及仲裁，那我會撤回「正當合理回應」提案。--唔好阻住我愛國（留言） 2024年8月1日 (四) 11:06 (UTC)

以下兩個是這種行為有可能符合的解任條件：

• 一再發生的、嚴重違反社群共識及禮儀。
• 在編輯戰或衝突中，使用管理員權力，沒有主動迴避。

當然那下面立刻列明了甚麼程度才能觸發解任，但至少條件是存在的。--派翠可夫 (留言按此) 2024年8月1日 (四) 12:45 (UTC)

然而最為微妙的地方在於那位管理員還自己把解任條件狹隘地詮釋，以至於解任條件反而變得對提請解任管理員者不利，這種條件會導致即使大部分解任請求本身是合理的，被提請解任的管理員依然可以向行政員請求宣告解任請求無效。Sanmosa _蚌埠 2024年8月1日 (四) 15:02 (UTC)

請求了也不一定批准吧，這話有點暗示中文維基的行政員跟這位管理員同一思維--派翠可夫 (留言按此) 2024年8月1日 (四) 15:15 (UTC)

一方面是部分行政員確實與那位管理員同一思維（從他們的留言可見）；另一方面是行政員通常信任（in general）管理員多於一般用戶，甚至就算社羣的主流意見並不支持（in general）某管理員的見解，行政員通常還是會支持（in general）該管理員。Sanmosa _蚌埠 2024年8月2日 (五) 08:49 (UTC)

我認為一個比較合理的做法可能會是禁止任何人（包括但不限於管理人員）在未取得提案人的首肯的情況下中止公示（顯然不可能獲得任何人支持的提案除外），畢竟現行規則並沒有規定公示期的長度上限。Sanmosa _蚌埠 2024年8月1日 (四) 15:10 (UTC)

「未取得提案人或第三方管理員」會較為合適；而且不應「的首肯的情況下中止公示」，應「任何規程問題」，畢竟這裏不應玩弄程序戰，包括強行中止有共識公示或通過未得到共識的提案。--唔好阻住我愛國（留言） 2024年8月1日 (四) 15:53 (UTC)

我這樣說是因為現行規則並沒有規定公示期的長度上限，在這種情況下提案人（或公示人，我發現我漏了）應該擁有首肯中止公示的專有權利，否則我擔憂這會創造一個第三方管理員加入戰團的bug。此外，我說的話是「現行規則並沒有規定公示期的長度上限」，也就是如果一個提案暫時未能得到共識，那提案人（或公示人）可以選擇延長公示期以進一步凝聚共識，但這並不影響強行通過未能得到共識的提案屬違規行為的事實。Sanmosa _蚌埠 2024年8月2日 (五) 08:45 (UTC)

如果在條文中要求第三方管理員不能在裁決前、後及在裁決留言內就相關事件表達意見，僅執行裁決，如表達意見，相關裁決作廢。

這樣應該可以制止「戰團的bug」。--唔好阻住我愛國（留言） 2024年8月2日 (五) 10:39 (UTC)

不好意思，忘了回覆，但是一個第三方管理員如果存心要加入戰團的話，他會無視並曲解如此規定，並阻止任何人提出這點，這事情之前已經發生過不止一次了。Sanmosa _{DC·恭賀樊振东奧運奪金} 2024年8月9日 (五) 00:33 (UTC)

@Sanmosa：當這個「第三方管理員」加入戰團，他就不再是「第三方」了（不過這樣推下去有點問題：我好像在《李天命的思考藝術》見過這種論述……） -- 派翠可夫 (留言按此) 2024年8月14日 (三) 08:07 (UTC)

對，然而社羣無法識別這種情形，而此前的情況是相關管理員就此混淆視聽，以試圖使社羣誤以為他沒有加入戰團。Sanmosa _{DC·恭賀樊振东奧運奪金} 2024年8月14日 (三) 08:13 (UTC)