维基百科讨论:共识

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

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

理論上，這應該更普及推廣至所有討論。目前觀察到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)[回复]

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

原标题为：統整

原标题为：第三階段討論

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

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

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

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

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

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

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效果不好，顯然不可理喻。--路