跳至內容

維基百科討論:互助客棧

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

捷徑

引入WP:請求評論取代互助客棧方針板及條目探討板功能

本主題或以下段落文字，移動自WP:VPP。執行者：路西法人 2024年2月16日 (五) 08:51 (UTC)。[回覆]

續上個月存在初步共識的討論（Wikipedia_talk:請求評論#引入WP:回饋請求服務與WP:請求評論），再次提出引入WP:請求評論機制。目前，我經已開始開發負責運行請求評論的機器人（Wikipedia:機器人/申請/LuciferianBot/5），並有初步成功的測試結果。WP:回饋請求服務尚未引入，英維也暫時沒了這個服務，似乎也並不至於必須即時引入。@參與上次討論的用戶@0xDeadbeef、Ghren、Ericliu1912、94rain、Hehua、S8321414、魔琴、Taeas：--路西法人 2024年2月5日 (一) 16:35 (UTC)[回覆]

提案內容

中文維基百科目前使用互助客棧作方針指引修訂及條目探討，運作多年算是運行得不錯，但有重大的缺陷需要正視：

  1. 互助客棧方針及條目探討二板塊常年存在過長問題（大於100KB），常有載入緩慢或留言儲存緩慢的問題；
  2. 用戶無法長期追蹤特定方針指引／特定頁面的修訂討論，因為無法自動選擇性訂閱特定討論主題；
  3. 條目探討板的討論往往是條目討論頁遷移過來，難以追蹤。

以上兩個問題均能通過RFC系統解決：

  1. 將討論回歸至各條目及方針指引頁面討論頁，不再會輕易造成過長討論頁面。
  2. 回歸討論頁後用戶可簡單通過監視頁面（或請求評論列表頁面）即能達到追蹤討論的效果。

請求評論曾被指「效果不佳」、「難以引導用戶參與」，但最近一次試行證明，在未有廣發通知的情況下，討論參與度並不亞於客棧的各提案。若往後配合WP:回饋請求服務，自然能更加鼓勵關注及參與討論。另外，中維設有公告欄，亦是公告社群邀請參與討論的方式，改用請求評論並不會削弱公告欄廣邀意見的效果。

由此，在技術問題已經開始解決的背景下，我謹此提出正式引入WP:請求評論，逐步取代互助客棧方針板（即本頁）及條目探討板的功能。請求評論的討論方式與現存在互助客棧及集中討論的方式無異。建議互助客棧方針板在請求評論引入後，轉型為就方針指引修訂及訂立提出初步概念及討論的場所；而條目探討板則全面廢除，在用戶有需要請求更多人意見時使用RFC召集意見，避免遷移討論。若有共識採納，亦需修訂共識方針相關規定，將RFC納入接受的場所之中。 --路西法人 2024年2月5日 (一) 16:35 (UTC)[回覆]

討論

請踴躍發表意見。--路西法人 2024年2月5日 (一) 16:35 (UTC)[回覆]

(～)補充：目前互聯群中有機器人定期自動推送公告欄的公告事項，RFC亦可考慮新增類似功能，向互聯群自動推送討論主題，以增加討論曝光度。--路西法人 2024年2月5日 (一) 16:37 (UTC)[回覆]
支持。其實我覺得即使沒有RFC/回饋請求服務機器人也可以這麼做：討論可以仍然在互助客棧發起，當討論較長時，可以直接移動到RFC下的獨立頁面 / 方針或條目討論頁，然後互助客棧保留一個"討論通知"並且暫不存檔。公示了也可以在客棧通知下。--及時雨 留言 2024年2月5日 (一) 16:49 (UTC)[回覆]
現在不是討論過長的問題，而是同時存在十幾個議案，每個都不一定過長，但合起來就很多。更何況「移動」討論的部分才是最可能流失討論者的情況，從一開頭就在別處會比較好。--路西法人 2024年2月5日 (一) 17:07 (UTC)[回覆]
因為互助客棧方針板將「轉型為就方針指引修訂及訂立提出初步概念及討論的場所」，所以感覺還是不能做到一開始就在對應討論頁，需要移來移去？--及時雨 留言 2024年2月5日 (一) 17:44 (UTC)[回覆]
方針板所謂「初步概念及討論」，是指用來提出方針指引相關的問題（若，真正討論訂立、修訂方針則不在此處理。若自問題延伸出方針提案，那麼最好以「發展出方針修訂／訂立提案」總結原討論，並在對應討論頁發起新討論。請求評論的主要目的是更方便追蹤特定話題，如果在客棧提出議案則難以讓監視方針頁面及討論頁的用戶追蹤話題變化。
最重要的一點：不要再用機器人剪貼移動討論存檔，這導致難以追查留言修改、deltalk等情況。客棧討論不應再存檔至原始討論頁，而是以原是討論頁發送討論通知時提供連結取代。--路西法人 2024年2月6日 (二) 02:44 (UTC)[回覆]
是要直接替代全部職能？還是先以分拆冗長討論為主？基本上我認為互助客棧話題與條目討論頁請求評論可以並行，前者本來是一種集中討論，而後者則是提升條目討論頁討論熱度的管道之一，沒有一定要誰取代誰的問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月5日 (一) 19:15 (UTC)[回覆]
我認為條目探討板功能應完全由RFC取代。40個完全不相關的主題集中討論毫無意義，追蹤條目及其討論頁的編者實則完全無從追蹤客棧的討論。既然目前實則要求先在條目探討頁試圖解決爭議再上升客棧討論，那麼即存在必然之討論轉移，除了難以追蹤討論變化外更容易造成參與者流失。故應修改規定，條目探討頁無法處理，不再轉移至客棧討論，而是原地發起RFC邀請其他編者參與。
方針板可另議。--路西法人 2024年2月6日 (二) 02:49 (UTC)[回覆]
支持引入，但取代一事仍有疑慮，應當在試用中進行決定。--在下荷花，請多指教（歡迎簽到） 2024年2月5日 (一) 23:57 (UTC)[回覆]
@Ericliu1912：他的原話是「逐步取代」，因此做法自然是逐步逐步來，但具體怎樣逐步逐步來他沒有明說。個人認為先以分拆冗長討論為主確實是合適的第一步棋。@Hehua：但其實我們已經試用過一次了。Sanmosa Défendre jusqu'à la mort 2024年2月6日 (二) 00:46 (UTC)[回覆]
這個當然是沒問題的，我的意思是在未來的使用中進行檢討。--在下荷花，請多指教（歡迎簽到） 2024年2月6日 (二) 05:55 (UTC)[回覆]
我並不反對以評論請求制度分拆既有話題中較長的討論，甚至可以立即推動。但通常要等討論持續加長以後才能判斷是否分拆的。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月7日 (三) 00:44 (UTC)[回覆]
由於現行WP:共識#提案討論及公示時間的規定（7DAYS）是只有在互助客棧的提案才需要遵守如此規定，因此有必要考量是否需要要求RFC的提案同樣遵守7DAYS規定，或是索性直接廢除該從一開始就不該存在的規定。我個人會傾向於僅保留「正當合理的意見」的定義，其餘一概廢除。Sanmosa Défendre jusqu'à la mort 2024年2月6日 (二) 00:55 (UTC)[回覆]
@Hehua、Sanmosa：取代一事，第一步一定是完全廢除條目探討板（理由已前述，若有疑慮可至上面回應），同時可以不再將方針板訂為唯一可以修訂方針指引的有效場所，並要求討論要麼在相關方針指引頁發送通知（包括發起討論、公示等），或者直接在相關方針指引頁討論，鼓勵編者在合適的場所提出，而避免在難以追蹤、集合數十個不相關話題的互助客棧討論訂立和修訂方針。方針板大概不會被完全取代，始終必須有一個場所給人問方針相關的問題。--路西法人 2024年2月6日 (二) 02:54 (UTC)[回覆]
支持。--在下荷花，請多指教（歡迎簽到） 2024年2月6日 (二) 05:56 (UTC)[回覆]
不反對這個做法。Sanmosa 起視四境　而秦兵又至矣 2024年2月6日 (二) 09:51 (UTC)[回覆]
想問一下目前相關機器人的運作方式？--冥王歐西里斯（留言） 2024年2月6日 (二) 01:20 (UTC)[回覆]
請參閱維基百科:機器人/申請/LuciferianBot/5說明。--路西法人 2024年2月6日 (二) 02:55 (UTC)[回覆]
稍微看了一下機器人的運作效果，不反對正式引入WP:RFC（可能需要修訂Wikipedia:共識#徵求外部意見以形成共識一節），同時廢除互助客棧的條目探討子板面，至於方針板屆時應該改說明就可以了。--冥王歐西里斯（留言） 2024年2月6日 (二) 03:07 (UTC)[回覆]
不支持過度依賴RFC，只有涉及可能需要長時間的長篇討論的話，才有需要一個專門的討論頁面，也就是類似RFC的方式來解決。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月6日 (二) 12:54 (UTC)[回覆]
原因？討論談論據，沒論據就只能當您這是個人觀點而非討論的論據。--路西法人 2024年2月6日 (二) 14:11 (UTC)[回覆]
同意Cwek的觀點（註：此句為釐清回覆性質添加）。實際上集中討論也有不同於分散於各該條目討論頁的好處，編者不需要再同時反覆來回查閱多個討論頁，尤其是部分涉及許多條目的討論。所以縱使禁止直接在條目探討區提案，至少仍應保留其彙整集中討論的門戶作用。當然，目前大多數編者的習慣仍應是追蹤互助客棧討論，為此監視一眾條目討論頁及個別話題者應屬極少數。另外提案人可能忽略的一個重點是也有人根本不監視任何頁面，而是定時查閱互助客棧討論（這種作法仍然是相當有效的）。嘗試在短時間內以制度強制改變編者習慣並不實際。故就僅涉及單一條目的討論而言，雖然可以考慮在未來推行回歸以條目討論頁為基礎，但仍需要有較長時的過渡期。是以現階段個人亦不支持直接廢除條目探討區（及其討論功能）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月6日 (二) 14:18 (UTC)[回覆]
若技術上可行，應該考慮先鼓勵改成嵌套條目討論章節，這樣既可以保留互助客棧集中討論的特性，並保留個別情況直接使用互助客棧頁面的彈性，也應當可以避免提案人所說討論搬移的情形。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月6日 (二) 14:27 (UTC)[回覆]
逐點回應：
  • 編者不需要再同時反覆來回查閱多個討論頁並不準確，首先理論上若條目探討區所有討論都是按規則發起，理應全部都要先在條目討論頁討論過，這時理論上所有參與討論的負責任用戶都必須翻閱過往討論才能瞭解前文後理，客棧等集中討論模式實際並無解決這個問題（反而產生了缺失原始討論的問題，因多數討論都不會整串移動）。更何況，負責任的編者更是需要翻查條目的過往其他討論，實際上仍然有來回翻查的需要，條目探討區的存在反而變相導致編者不會特地去翻查過往討論。
  • 同時，在同一頁反覆來回查閱完全不關聯的主題實則上並不具備效率，在長長的客棧中等候載入才能點章節連結，還要很常走過頭翻到其他不相關的討論，實則上更是降低了討論效率。
  • 條目探討區並非直接刪除，而是廢止不再作討論之用，實質操作可如閣下所言禁止提案。條目探討區可添加嵌入如維基百科:請求評論/全部的請求評論列表，自動追蹤討論，而不再需要人手發通告。
  • 部分涉及許多條目的討論應改以開請求評論子頁面討論。涉及多個條目不是垃圾場般推到客棧同時進行毫不相關的討論的原因。
  • 有人根本不監視任何頁面，而是定時查閱互助客棧討論，請求評論仍有討論列表，「點去章節」只是變了「點去討論頁」，根本沒分別，顯然不是「客棧優勝於RFC」的問題。
  • 嵌套整串討論在早前不知道什麼時候已證會產生很多問題（見T:集中討論重定向編輯歷史）。
以上。--路西法人 2024年2月6日 (二) 14:39 (UTC)[回覆]
目前涉及較多條目的話題，基本沒有所謂「垃圾場般推到客棧同時進行毫不相關的討論」，多半是緊密相連的幾個條目。例如上次華僑相關討論，明明討論內容實際上都是一個議題，但有人偏要一個獨立條目拆出一個討論話題，這當然不比整體討論再同時存檔至三、四個頁面要好。此等狀況是實際存在而非孤例的，也是符合編者討論慣性的。我想具體怎麼處理這種話題，社群可以詳細討論（例如用機器人同步討論至其他條目的討論頁之類），但我想應該沒有必要為了推進制度「踩一捧一」，開頭就「垃圾不離嘴」貶抑他人討論習慣，一竿子打翻一船人吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月6日 (二) 15:42 (UTC)[回覆]
「垃圾場般推到客棧同時進行毫不相關的討論」寫的是「同時進行毫不相關的討論」，不是「涉及多個條目的討論毫不相關」，而是「涉及多個條目的討論與客棧其他議題不相關。客棧的實踐方式確實是「什麼都可以過來開」，客棧確實是垃圾場般運作，只是送來的是五花八門、互不相關的討論，而不是垃圾而已。--路西法人 2024年2月6日 (二) 16:01 (UTC)[回覆]
另外還存在一種話題，就是不針對特定條目，而是比較廣泛存在的現象發起的討論。這之中固然有部分情況可以歸類於維基專題（也就與條目討論頁類似），但也有不強調特定主題而不適合硬性歸類者。強行為這些討論指定發起標的條目討論頁是非常不合理的。我想提案人沒有注意到的是，互助客棧並不只是「個別條目討論的集成」，而實較之更加複雜得多。個人認為，激進地廢除直接討論功能、以評論請求制度取而代之看似理想（至少理論上還挺自洽），但與互助客棧現實運作情況則略有脫節之虞。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月6日 (二) 16:09 (UTC)[回覆]
（編輯衝突）—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月6日 (二) 16:10 (UTC)[回覆]
就廣泛現象的討論，則顯然適合另開啟獨立的請求評論頁，從來未曾要求發起討論必須在對應討論頁而不能另開請求評論頁，這一點在我2239的留言[錨點失效]也有提到（應改以開請求評論子頁面討論）。請不要選擇性閱讀。--路西法人 2024年2月6日 (二) 16:16 (UTC)[回覆]
請求評論獨立頁面應只適用於較長篇幅而有個別討論需要的話題。為了保持頁面列表「純潔性」而動輒設立單獨子頁面，不僅效果甚差，實際上也是毫無必要。現在這樣運作的提案方式，本身有什麼問題（注意：這與頁面載入等技術問題無關）？這是典型的「沒壞別修」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月7日 (三) 00:44 (UTC)[回覆]
現在這樣運作的提案方式，本身有什麼問題，提案及其他回覆中已詳述技術問題以外的其他原因（需翻查過往討論、無法主從特定議題等），加上技術上的問題，顯然不是沒壞。請求評論獨立頁面應只適用於較長篇幅而有個別討論需要的話題又是一個觀點而沒論證原因，為何涉及多個條目而討論篇幅未必長的就不能開請求評論頁？為何就必須跟其他話題堆在同一個「集中討論」的客棧？--路西法人 2024年2月7日 (三) 06:11 (UTC)[回覆]
一、唯一認同引進相關制度的理由，只有部分頁面確實存在話題堆積的問題，這也是眾所皆知了。但閣下顯然過度誇大互助客棧頁面載入及瀏覽相關章節時間所產生的負面效應。不然章節及頁面導言的目次及topic list是設計來做什麼的？凡是知道怎麼利用這些工具的人，都不會輕易為上述問題所困擾。何況只要等待一個長頁面載入，與改成在不同頁面之間反覆橫跳耗費的總時間加起來對照，也不見得會比較好。是哪一種方式討論效率比較差，還很難說呢。
二、實際上，包括互助客棧在內，幾乎所有站務頁面都是如此運作，以一個或多個主題為核心，聚集所有相關討論。除了討論總長度，我不認為互助客棧方針區與條目探討區及其他一部分站務頁面在討論格式上有決定性區別。真要說的話，互助客棧消息區消息之間、求助區求助各該話題之間，或者檔案存廢討論各討論之類，差不多也都是互不相關，但歸根究底，客棧頁面（及多數站務集成頁面）本來就是如此設計的——在宗旨是討論「條目、模板、主題相關」事項的頁面提出「條目、模板、主題相關」的話題，這本身並沒有問題；互助客棧其他區塊及大多數站務頁面同理。我想不應該為了宣稱評論請求制度的「優越」，反過來批評這樣的討論形式叫做「垃圾場」。我認為這是不公道的。退一步說，就算這麼多頁面的運作方式真的都像垃圾場，那也沒關係吧？憑什麼社群討論頁面不能以垃圾場的形式運作？
三、「『點去章節』只是變了『點去討論頁』，根本沒分別」並不符合事實，實際上光所需步驟就多了一倍，而且會隨欲參與的討論話題數量等距增加。互助客棧（及多數站務頁面）聚集相關討論的一個好處在於，編者在瀏覽自己本欲參與主要討論的同時，也有很大機會「順便」就其他話題發言（如果實際參與過任何社群討論，就知道這有多麼容易），結果就是得以有效擴大社群在許多討論的參與（或許也可以視為「維基兔子洞」的縮小版？XD）。我不知道這是不是當初頁面設計所預期的情況（或許維基討論系統本來就有這樣的特點），但其效果則是明顯可見。不要小看編者討論的慣性；制度是設計給人類，而不是給一群「討論機器人」用的。強制分拆請求評論回各條目或方針與指引頁面，甚至於禁止直接在客棧提案（條目探討而言），將客觀上大幅增加參與討論的成本，削減編者在主要討論以外針對更多話題發表寶貴意見之動機。道理很簡單，若要參與十個來自各條目或政策話題的討論，卻要在不同頁面之間來回點擊數十次，我想至少相當數量的編者衡量機會成本，肯定將放棄參與許多本有討論潛力的話題，只專注於自己最偏好的幾個主題。就增加話題平均bias程度而言，這是不是利大於弊呢？
四、我非常懷疑多少人有「自動追蹤所有特定話題相關討論」的需求。許多編者大概不會為了參與單一話題的討論，就希望自動訂閱所有類似話題。無論條目探討或方針，大概都是如此。當然，必須指出，這方面需求也並不是不存在，所以就引進評論請求制度、增進條目討論頁討論熱度本身而言，個人並沒有特別反對的理由。甚至先推動分拆既有冗長討論以為測試，評估該制度在本地運作效果如何，亦無不可，反而還挺歡迎的。但是在未有實證研究佐證相關正面效果且有完全替代作用的情況下，不嘗試推動該制度與既有互助客棧頁面並存「良性競爭」，而是企圖直接取而代之，則恐怕操之過急。從過往實際參與討論的經驗，我完全認為兩種提案方式各有利弊，不應該逕行獨尊其中一種。無論如何，在徹底推行如此巨大的變革之前，社群也應當完全有權利以試行的形式觀察相關制度運作情況。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月7日 (三) 00:44 (UTC)[回覆]
回：
  1. 以我相當不錯的網速在客棧方針板儲存一次留言需要10秒以上的時間，不同於在其他板塊不足3秒就完成儲存，即顯然為緩慢載入；我網速已經算不錯，對網速更慢的人來說顯然會更加吃力。再者，超長頁面亦會存在點選章節標題後瀏覽器跳錯位置的問題，這是我僅在互助客棧發現的問題，其他討論頁均不存在，這顯然已經展現客棧已經長到會導致技術問題。
  2. 幾乎所有站務頁面都是如此運作，並沒看到如此。AIV的共通點是全部都是破壞提報、RFPP全部都是保護提報，範圍定義明確；而我長久詬病的AFD、DRV格式正是如客棧般容易導致過長且相關業務範圍過廣，導致難以查找過往記錄。VPD各討論的唯一共同點是「需要其他用戶注意／提供意見的條目」，這個業務範圍顯然已經過廣。並不是請求評論制度優越，而是目前客棧、AFD等制度是真的垃圾。VPO、VPN、VPT等板塊我尚能理解是沒有其他位置可以放的討論所以集中處理，VPP、VPD顯然是有其他更合理的位置放討論，根本就不應該需要集中討論的主題。
  3. 社群頁面本來就按照業務有分列不同板塊，本來就是在找尋不同板塊的路途上跳來跳去的。更何況，條目也是每一個主題放在不同標題之下，也是需要點來點去的，編輯多個條目的用戶本來就習慣在監視清單跳來跳去。如果「跳來跳去」是如此不方便，要不要弄一個頁面是集中全站所有業務來「提高用戶參與度」？所以「跳來跳去」會成問題一點本來就是站務精才會有的問題。要做什麼就該去那個地方，不應該因為不方便而不去做。不方便就不做的就是陋習，不值得鼓勵。
  4. 閣下說我非常懷疑多少人有「自動追蹤所有特定話題相關討論」的需求，卻遺忘了維基百科最大的重點是編輯條目的人。這些人監視自己編輯或有興趣的條目的同時，必然會自動追蹤了對應的討論頁（這是MediaWiki設計）。多數編者都會有參與自己有興趣的條目的討論的需求，但互助客棧的設計顯然沒有推動到這一點。
  5. 再者，我說過十萬遍：分拆討論才是萬惡之源，理論上應該什麼話題都直接在對應的討論頁（或者開全新的請求評論集中討論頁）處理，這樣才不會出現討論流失。閣下非常清楚這一點，卻要求先行推動「分拆討論」，這顯然無助檢視請求評論效果的同時，會反向營造請求評論不好用的非建設性效果。我完全無法理解為什麼閣下這麼愛提出毫無建設性、反而對議案存在反效果的建議，這裏是如此，ArbCom討論亦是如此。這不是制度間的「良性競爭」，而是以手段去偽造公平競爭，然後偽證一方無效；更何況平行運行兩個不相容的制度根本無助任何編者參與。
--路西法人 2024年2月7日 (三) 01:47 (UTC)[回覆]
回覆收到了，但不認同，而且認為上述宣稱有很大商榷空間。其他的等過年完再詳細說。我也想好好過年放個假的。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月7日 (三) 02:51 (UTC)[回覆]
我不知道評論請求本來是否打算針對冗長之條目及政策討論而言？畢竟提案一開始就指出互助客棧討論過度冗長為一大理由，那我想多數人預期該制度對於較長討論特別有效，也應該不差錯。怎麼會是反過來「營造請求評論不好用」呢？顯然並不會是這個意思。那我就不太理解閣下反對先行以此制度分拆部分較長討論來試驗評論請求制度效果的理由了。如果這樣提議就會招致「毫無建設性」、「存在反效果」的批評，那若全面在所有形式相關討論實施該制度，社群就大概更要有疑慮了吧？還是說此制度實際上對分流篇幅較小的討論比較有效？個人確實搞不懂。或許是措辭有模稜兩可之處，導致誤會。
有一個前提需要注意：依據實際觀察經驗，目前條目探討區的討論，反而實際多次搬移者較少，而多是直接在互助客棧發起，爾後再存檔至討論頁；尤其是涉及多個條目者，自然傾向一次在客棧提案討論，而不是在多個條目同時發起話題。此一現象的本質或有可批評之處，但基本上我不認為「討論流失」是用評論請求全面推翻目前互助客棧運作形式的主要理由。至於如何照顧監視條目者，我想在不涉及評論請求的情況下，有一個明顯更簡單且有效的解方，那就是直接在條目討論頁寄發通知；這個方法過往也有其他人用過，符合本地社群實際運作情況，而且或許還更方便（半）自動化；只要偵測存檔至模板填入哪些對應討論頁，就可以用機器人或人工自動寄發通知。如果再搭配評論請求制度，提升條目討論頁本身既有討論的熱度，相信將能充分發揮互補作用。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月11日 (日) 15:44 (UTC)[回覆]
至於目前相當一部分話題直接在互助客棧而非條目討論頁發起的「問題」，若既有情況如此，則或許我們更應該先檢討這樣的規定是否符合設計初衷，還是已經脫離社群實踐共識而需要修訂了？又例如同時承認兩種方式的效果是不是比較照顧傾向使用不同提案方式的編者？諸如此類建設性問題，大概都比反過來直接批評這種「劣跡」要得體一些。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月7日 (三) 01:06 (UTC)[回覆]
為什麼垃圾就不能被批評？同時承認多種制度反倒造成更多規則漏洞，根本就不是建設性，而是給予機會編者更懶更不願意去遵守合理的規定。不要自以為是地覺得提出偽公允觀點就是「公平」「良性競爭」，實則帶來更多反效果。--路西法人 2024年2月7日 (三) 01:50 (UTC)[回覆]
只能說這多半是價值觀及理念上差異，你談你的理論，我講我的經驗，大家各自暢言，匯聚意見，把多一點可能性攤開來，自然能夠促進提案完善；就算無法盡善盡美、讓所有人滿意，至少也能說有好好交流過了。我想閣下並沒有在此必要上綱上線給他人安個什麼「偽公允」的帽子，不然以後都別討論或認真寫論述，也不用假裝請社群「踴躍發表意見」（引開頭語），互相拆臺就得了。這樣無禮的作為才是真正的自以為是。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月7日 (三) 02:56 (UTC)[回覆]
發表意見的基礎在於推論和反駁，但閣下發言屢屢漏洞百出，我指出閣下發言的漏洞、批評閣下推論有問題、批評閣下的「觀點」看似公允實則反效果居多、批評制度的腐爛，卻又成了我上綱上線、我不接受意見。--路西法人 2024年2月7日 (三) 04:13 (UTC)[回覆]
我（大概）也沒說過自己的觀點是（最）「公允」的，所以所謂「偽公允」議題應純屬虛構。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月11日 (日) 15:51 (UTC)[回覆]
口說「公平競爭」卻說自己期望的做法不是公允，這不就自打嘴巴了嗎？不公允的建議如何公平競爭？--路西法人 2024年2月11日 (日) 16:04 (UTC)[回覆]
或者可以這樣說，我的想法是與其直接作廢，不如把條目探討區改造成提案人所說的一種「請求評論列表頁面」，這樣就不用再生造一個頁面出來。當然具體怎麼改可以再商量。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月6日 (二) 14:42 (UTC)[回覆]
條目探討區既然不再作討論之用，實則即是廢除。導向新制格式與廢除不衝突，WP:VPD廢除後掛{{historical}}同時提供導向RFC列表兩件事可以同時發生，正如WP:HAM也可以提供連結按帳號查詢存檔至SPI的用戶查核記錄一樣。--路西法人 2024年2月6日 (二) 14:48 (UTC)[回覆]
完全可以沿用頁面本身。傀儡調查分立頁面的原因，主要是因為性質產生重大變化，且中間有數次更迭。相關列表顯然從頭到尾都是要用作彙整條目相關討論用的，所以若沒有打算保留原頁面之作用，則不需要新開一個頁面。我覺得我們單純在這個議題上不存在衝突。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月6日 (二) 15:25 (UTC)[回覆]
維基百科:請求評論/全部並非僅收錄條目相關討論，顯然不適合整個放在廢除後的VPD；同時我從來沒說過要開一個新頁面去放條目相關的討論列表，從來都是在說在VPD直接放置非維基百科專案相關的列表，完全不理解閣下是在「不需要新開一個頁面」是在說什麼。--路西法人 2024年2月6日 (二) 16:06 (UTC)[回覆]
既然如此，那就好啦！—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月6日 (二) 16:10 (UTC)[回覆]
必須注意，閣下眼中的「RFC」只是社群目前使用請求評論系統的冰山一角，並非所有RFC都需要專門設置一個頁面去處理RFC，而是可以直接在討論頁掛RFC模板邀請其他用戶參與，閣下所言的「類似RFC的方式」根本就不是這個提案要提的「RFC」。--路西法人 2024年2月6日 (二) 14:21 (UTC)[回覆]
首先感謝LuciferianThomas的在理論和技術上的貢獻。(＋)支持當前提案。另外請提案人適時起草修訂WP:RFC。並請注意最近一次試行使用的是集中討論而非請求評論，具體到某個主體下的討論效果還未有實踐。考慮到有些編輯不經常參與站務討論，建議在提案通過後，給活躍用戶發消息。
主題破碎，海涵。--落花有意12138 2024年2月6日 (二) 16:14 (UTC)[回覆]
必須注意請求評論和集中討論並非互斥的措施，請求評論容許共識框架下的任何討論方式，集中討論是其中之一。「集中討論而非請求評論」並不準確，RFC/RFA2024是「集中討論模式的請求評論」，只是因為RFC尚未正式啟用而未使用有關RFC模板而已。--路西法人 2024年2月6日 (二) 16:20 (UTC)[回覆]
您說的對，我這裡的意思是RFA2024是全站的討論，區別於特定主題之下的討論，理應更多人討論。所以需要試行查看後者的討論效果。
另外其他發言內容我默認您看到了。--落花有意12138 2024年2月8日 (四) 16:27 (UTC)[回覆]
如果要建立話題索引，介面大概可以沿用目前topic list的樣子？看起來還不錯。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月7日 (三) 01:06 (UTC)[回覆]
大致同意，客棧反而是經常監視關注的地方，也考慮到部分議題可能長期討論下去可能變長而不便閱讀和推進討論的問題。所以我還是維持意見：小討論可以保留在條目探討、方針版上，但如果有可能討論長期大幅增長或有必要長時間討論的，可以用RFC解決，並保留一個路徑在客棧版上鏈去，而不是破除傳統做法。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月7日 (三) 05:45 (UTC)[回覆]
請閣下回應我所指，「將進行中討論分拆至其他討論頁導致流量及參與度下降核心問題，而當（大多數）討論本身就在適當的討論頁發起才不會存在這個問題」。另外，仍未見閣下論證觀點，「傳統做法」不等於「必然適合繼續運行下去」，所謂「傳統做法」似乎只是有壞仍不修的藉口。--路西法人 2024年2月8日 (四) 16:08 (UTC)[回覆]
這不是為了論證，而是一個觀點，我就這麼認為，也不要求你去認同這個觀點。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月10日 (六) 10:46 (UTC)[回覆]
那麼就當您這是觀點而非反對（議案特定部分）的意見了。反對意見需要論述，觀點確實不需。--路西法人 2024年2月11日 (日) 00:33 (UTC)[回覆]
建議深思，避免到時候被當成公示時排除「有效意見」考量的藉口。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月11日 (日) 06:52 (UTC)[回覆]
不對提案進行實則性點評的意見、並非正當合理的意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」與「相關意見」。此為共識方針條文，不是排除有效意見「藉口」而是「正當理由」。--路西法人 2024年2月11日 (日) 09:25 (UTC)[回覆]
「引進評論請求」跟「互助客棧轉型」基本是兩個互不妨礙的議題。那既然沒人反對前者，那應該已經可以開始提出制度運作細節，準備部署相關技術了。畢竟目前評論請求在本地幾無有效運用，這也是客觀事實，所以我想無論是要支持還是反對用這個社群相對陌生的討論形式來改革互助客棧，都需要引進本地實際運作以後才知道具體效果究竟如何。目前參與討論者意見所云「試用」大致如此，而這與提案人所說的「逐步取代」也應該不相違才是。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月11日 (日) 06:49 (UTC)[回覆]
我唯一可以給的讓步是在客棧方針板及條目探討板大字置頂建議改用請求評論制、嵌入請求評論的討論列表等，否則無鼓勵自然沒人用，完全無法比對效果。建議的大字置頂通告如下：

由於客棧板過長導致載入及儲存過慢等問題，用戶可以改用請求評論系統請求更廣泛意見；〔影響一整個主題的討論／關於現有方針指引的探討〕則在此發文。〔請建立新的請求評論子頁面討論影響多條方針的修訂案。〕

同時在共識方針關於互助客棧的章節添加通告：
應2024年X月社群共識，使用請求評論系統的討論亦執行以下規定。方針將於稍後修訂。
不同意在完全無鼓勵的情況下直接引入請求評論，用戶難以接觸新系統的情況下，一來難測試新系統的效果，二來會自動給予「請求評論效果不佳」的結果。望能同意以上第一階段鼓勵轉移的妥協安排。--路西法人 2024年2月11日 (日) 09:22 (UTC)[回覆]
既然如此，您也應該意識到在這種情況下直接廢除互助客棧既有討論制度不太可行了吧。個人當然沒理由不支持用評論請求分流討論緩解互助客棧壓力——而不是直接取代——甚至可以考慮在相關方針與指引明文寫出「先在條目討論頁提出討論，（迴響不大的話）進而提出評論請求，（涉及較廣泛條目或確有其他必要時）最後才是在客棧提案」的「三步驟」建議。當然，還是希望能提出評論請求在條目討論頁的執行細節，現在看起來似乎還比較不明瞭（尤其跟回饋請求服務好像還有一點混淆？我感覺評論請求在本地實際上比較接近前者的角色）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月11日 (日) 15:17 (UTC)[回覆]
我並不認為不應該廢除客棧，只是閣下一直堅持，而我也說過是分階段，那麼階段可以改，以讓議案推進，但最終目標仍沒改變。不要猜度我的思想，妥協不等於放棄。--路西法人 2024年2月11日 (日) 15:27 (UTC)[回覆]
請求評論單純就是掛個模板，讓機器人自動載入需要邀請廣泛意見的討論而已，並無特別的執行細節。回饋請求純粹是RFC的延伸部分，透過機器人發訊息隨機邀請用戶參與關注了的主題的討論而已，並非RFC的必然構成部分。--路西法人 2024年2月11日 (日) 15:29 (UTC)[回覆]
您可以不放棄革命，我也不非要「獨尊」舊制度，但總是不應該拿客棧當實驗場。我始終相信不用以推倒互助客棧為起手式，也能妥善運用評論請求。至於其效果是否有好到可取彼而代之，就得讓社群評斷。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月11日 (日) 15:44 (UTC)[回覆]
貴站問題在於愛造輪子，將別人運行得非常成功的制度不必要地左改右改，出錯的位置卻也總是與別人不同的部分。「Village pump」、「客棧」如其名，只是設計來非正式議事的地方，貴站卻越改越偏，變成「議事廳」的款式，「互助」更是無稽之談。閣下對著「互助客棧」這個標題，在這麼不正式的場所卻用來正式議事，沒覺得過怪嗎？究竟現行的真的是「舊制度」，還是「走偏不成原樣的老制度」？--路西法人 2024年2月11日 (日) 16:20 (UTC)[回覆]
@其餘參與提案討論的用戶@94rain、Hehua、Sanmosa、S8321414、落花有意12138：：是否同意首階段採上述折衷方案（見此留言[錨點失效]）？若無異議，請問各參與用戶（及@Ericliu1912君），是否同意讓此折衷方案按Wikipedia:共識#非方針指引相關提案簡易規定免除公示並於達到簡易規定條件的三日後執行？--路西法人 2024年2月12日 (一) 13:09 (UTC)[回覆]
不反對。Sanmosa 起視四境　而秦兵又至矣 2024年2月12日 (一) 13:11 (UTC)[回覆]
覺得可以。--Borschts™ 歡迎外帶一碗羅宋湯 2024年2月12日 (一) 16:37 (UTC)[回覆]
同意。--在下荷花，請多指教（歡迎簽到） 2024年2月13日 (二) 00:16 (UTC)[回覆]
不反對。--冥王歐西里斯（留言） 2024年2月14日 (三) 23:31 (UTC)[回覆]
首先聲明，我未仔細閱讀上面的討論，故僅就提案內容發表意見。我認為，所謂三大缺陷，至少對我而言均不存在。一、我嘗試載入條目探討頁面，結果5秒左右（估測）能完全載入，這一速度可以接受，並且可以在同一頁面閱讀和發表對多個議題的意見，較為便利。（但是，如果只關注一項議題，則浪費了載入其他議題的時間。）二、維基百科的回覆功能，點擊訂閱即可訂閱二級標題下的更新，並不麻煩。三、使用move from，move to等模板，似乎也沒有難於追蹤的問題。不過，雖然如此，我並不反對，乃至支持推廣RFC機制，如果真能鼓勵討論的話。Fire Ice 2024年2月11日 (日) 17:11 (UTC)[回覆]
較為便利：這個便利建基於什麼都混在一起，如我上面所說，要「便利」的話，不如所有專案頁面都集合在同一頁面下？顯然「便利」不是一個合理的解釋原因。
點擊訂閱即可訂閱二級標題下的更新：本來就不是指追蹤單一話題，而是單一主題下的所有話題。如果一個人要追蹤「可供查證」相關方針討論，則必須手動前往客棧查看有沒有相關話題再訂閱，而RFC（回歸討論頁）就只要監視頁面（自動監視對應討論頁）即可追蹤所有相關方針討論。
使用move from，move to等模板，似乎也沒有難於追蹤的問題，喪失所有編輯歷史，難以查找留言編輯、刪除記錄，甚或是否曾被偽造都難以查證，始終客棧有十數萬編輯。
以上回覆。--路西法人 2024年2月11日 (日) 17:32 (UTC)[回覆]
初步的議題分類（方針、條目探討等），將每個頁面的話題限制在幾十個，因此初步分類有合理性。至於追蹤方針討論，只能說可能有人有這種需求，要關心某一方針的每次討論。--Fire Ice 2024年2月12日 (一) 01:28 (UTC)[回覆]
方針只是討論的範疇之一。互助客棧只能提供監視兩個頁面，且包含大量讀者未必感興趣的話題；WP:RFC光是機器人支持分類的主題就14個範疇，別說追蹤個別條目、方針，追蹤整個主題的討論都還行；客棧就難以提供不重複、不冗餘的討論索引。我不認為一個頁面有「幾十個」討論算是合理，尤其是各討論之間實則近乎無任何關聯之時更是不合理，跟把AFD和AIV合併在一起沒什麼分別。--路西法人 2024年2月12日 (一) 02:29 (UTC)[回覆]

折衷方案（見此留言[錨點失效]）已獲三名用戶同意按非方針指引公示規則處理，如無其他異議將於2024年2月16日 (五) 00:16 (UTC)後生效執行。--路西法人 2024年2月13日 (二) 04:09 (UTC)[回覆]

( π )題外話：「請求評論」翻譯腔太重，可否改爲「××諮詢／徵詢××」之類的地道説法？避免再像這個名稱引人誤入歧途、（基本）不服務過客的地方被稱爲「客棧」（旅客服務設施）一般積重難返、殘留20年。雖然此前並不迫切，但要設立恆常制度，以改名為宜。--— Gohan 2024年2月13日 (二) 08:16 (UTC)[回覆]
「意見徵求」？臺灣及大陸等地都有在用。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月13日 (二) 08:27 (UTC)[回覆]
感覺「徵求意見」更順口，大量文書標題使用，也有欄目使用[1]。「意見徵集」[2]等也可以，徵集更像非定向。主名稱不確定，但都可以作為別名。--YFdyh000（留言） 2024年2月13日 (二) 09:02 (UTC)[回覆]
可以在正文中使用，如「評論請求是維基百科社群徵求意見的一種手段」之類。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月13日 (二) 14:31 (UTC)[回覆]
不反對。--— Gohan 2024年2月14日 (三) 04:35 (UTC)[回覆]
既然系統取名自RFC備忘錄，那麼翻譯也最好參考該備忘錄。該條目來源1提供了數個翻譯選擇，其中就有請求評論。如此，既然「請求評論」本身足夠準確地說明了系統的功用，且有來源支持這個翻譯方法，我不認為有改變目前名稱的需要。最少也不像客棧那樣，不是互助也不是客棧。--路西法人 2024年2月13日 (二) 09:01 (UTC)[回覆]
該備忘錄紙面上有中文名稱嗎？在來源1中也有出現「意見徵求」。--— Gohan 2024年2月14日 (三) 04:45 (UTC)[回覆]
看似沒有中文版。既然目前翻譯正確也沒歧義，那麼自然沒需要改。--路西法人 2024年2月14日 (三) 04:51 (UTC)[回覆]
互助客棧名稱是歷史遺留，求助等版塊是互助的，不感覺是什麼問題。沒有將爭論等完全分流是管理問題。--YFdyh000（留言） 2024年2月13日 (二) 09:04 (UTC)[回覆]
大字通告應該明確什麼「應該」在此討論，什麼「可以」請求評論。建議改成：由於客棧板過長導致載入及儲存過慢等問題，用戶可以改用請求評論系統請求更廣泛意見；但關於現有方針指引的不涉及修訂的探討則應在此發文。影響多條方針的修訂案建議創建新的請求評論子頁面討論。
另外，這個修訂案相當於引入了請求評論機制，所以建議稍後根據實際進一步修訂WP:RFC和WP:DR。--落花有意12138 2024年2月13日 (二) 11:57 (UTC)[回覆]
可。--路西法人 2024年2月13日 (二) 12:22 (UTC)[回覆]
個人認為應該確立實施細節（及操作方法）才正式引流，不然編者被引流去了也不知道怎麼做。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月13日 (二) 14:31 (UTC)[回覆]
WP:RFC本來就有操作指南，這一點從來就不是問題；落花有意建議的調整僅是改了「應」「可」等優先次序，全部都不是絕對性用詞，也只是強烈建議、沒做到時可作提醒的做法，實施細節基本已定。--路西法人 2024年2月14日 (三) 00:01 (UTC)[回覆]
對僅部分編輯同意或者提案者只挑選認同意見後就強行推進提案的做法感到詫異，我依然保持認為應該保留客棧簡易的提案討論方式，RFC用於預期需要長期或詳細討論的提案；如果希望無論大小，提案都應該用RFC解決的話，應該保留在客棧上帶出簡易的討論連結指引來引導編輯前往參與討論。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月14日 (三) 02:16 (UTC)[回覆]
後者「提供連結導向」本來就在上方我與Ericliu的辯論中已指出是取代客棧二板塊後會做的事情；閣下持續未能就觀點提出推論和理據，卻逕稱我挑選意見、強行推行。對於閣下沒讀討論就發言、不就自己觀點提出理據而強行要他人接受您的觀點等不負責任的討論操守感到詫異。--路西法人 2024年2月14日 (三) 03:46 (UTC)[回覆]
目前他應該是接受了折衷意見，只打算要在互助客棧頁面置頂說明而已（吧）。希望不是我眼花了。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月14日 (三) 14:39 (UTC)[回覆]
我上次查閱的時候還有若干未本地化的內容，既然已經清理完畢，就沒什麼問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年2月14日 (三) 14:42 (UTC)[回覆]

已執行折衷方案。望社群能學會「對的地方做對的事」。--路西法人 2024年2月16日 (五) 00:56 (UTC)[回覆]

@Ericliu1912：請協助複檢執行效果是否符合閣下現階段期望。--路西法人 2024年2月16日 (五) 02:52 (UTC)[回覆]

本頁上方那個存檔是否做成摺疊的

本主題或以下段落文字，移動自Wikipedia:互助客棧/技術。執行者：Jimmy-bot（留言） 2024年3月26日 (二) 16:14 (UTC)。[回覆]

已經有20個年度了，是否考慮摺疊或者省略一部分早年的年份，在另一頁（如Wikipedia:互助客棧/技術/檔案館）展示全部存檔頁面？（互助客棧其他頁同。） --達師 - 370 - 608 2024年3月16日 (六) 05:59 (UTC)[回覆]

我直接試著改了，參考Wikipedia:當前的破壞/存檔，您看可不可以。--Cookai餅塊🍪（💬留言） 2024年3月16日 (六) 06:57 (UTC)[回覆]
客棧的都改好了。--Cookai餅塊🍪（💬留言） 2024年3月16日 (六) 11:16 (UTC)[回覆]

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

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

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

一、禁止在互助客棧條目探討區發起「僅影響單一條目的討論」（也就是涉及單一條目的討論，例如討論「最大政黨列表」條目之原創研究問題[錨點失效]等），也禁止將此等討論移動至客棧，只能發送討論通告；
二、禁止在互助客棧條目探討區發起「影響多個屬相同主題的條目的討論」（也就是涉及多於一篇類似領域條目的討論，例如討論「中華民國」及「臺灣」條目之架構[錨點失效]等），也禁止此等討論移動至客棧，只能發送討論通告；
三、在互助客棧條目探討區發起「影響多個屬相同主題的條目的討論」時，應當在主題條目發送討論通告（但我不確定這是什麼意思）。

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

以下則純粹是個人意見：提案若獲得通過，代表目前客棧條目探討區超過三分之二提案都將遭到取締，只能改置所謂「討論通告」，根本形同廢除；至於討論通告究竟有多少用處，請參見目前徵求意見制度成效，本人實際參與條目相關話題的經驗是從冷清到平淡左右。互助客棧有許多顯性及隱性功能及作用是單一討論頁所難以取代者，我認為此提案未考慮客棧實際運作情況，縱然移植外來制度，企圖以行政手段改變流行習慣，為所謂「確保各討論頁獲得善用」（提案理由）箝制編者選擇討論管道之自由，損害運用客棧頁面討論之公益，是錯誤的形式主義及官僚主義政策（完整論述在討論頁）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月18日 (六) 10:01 (UTC)[回覆]
老實說我覺得這麼做會嚴重分流潛在的討論參與者。就比如我來說，我會偶爾逛一下互助客棧、看看大家的討論、有興趣就發表意見，沒有就離開。但是那些用rfc的我幾乎不會點進去看，除非有人ping我。不過路西法君的話也在理，全部都擠到互助客棧確實造成頁面過大、難找diff之類的問題，如果社群能接受這些缺點我覺得倒也不必強推一定要到討論頁討論。因為不是針對該條文的意見我就發在這裡了。--微腫頭龍（留言） 2024年5月18日 (六) 11:26 (UTC)[回覆]
反對此提案。這屬於是徹底與本討論區的初心（詳「維基百科:互助客棧/條目探討/存檔/2010年10月#建議維基客棧增開「/條目」分棧」）相違背。我認為現狀至少令人勉強滿意，沒有改動的必要。—— 　桁霽　 ↹　晚來天欲雪，能飲一杯無　　 2024年5月18日 (六) 23:33 (UTC)[回覆]
@王桁霽：原來當時就有討論了，正反意見還與今日相去不遠。不過依據過往經驗，您單純在這裡講是沒有用的 :( —— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月19日 (日) 11:18 (UTC)[回覆]
互助客棧條目討論區同樣自創立至今都有任何條目或模板的交流應考慮先在其討論頁發表，而若無人加入討論才可在此發起。（後半句直至RFC啟用前都仍然存在）的要求，本討論區自設立之初更是有跟當今提案意義完全相同的要求（任何條目或模版的問題、疑慮、懷疑、參考文獻、有關文章的論戰或者評論應該先在相關的條目討論頁提出來並在討論段落加上{{indiscussion}}模板，最近7天在條目對話頁上的討論會出現在討論索引，而若無人加入該討論才在此發起，若否則可能被移動回{{Moveto}}原條目討論頁，討論頁指導方針亦在此適用。），現在全部討論塞在這裏才是真正「徹底與本討論區的初心相違背」的體現。貴站用戶選擇性「初心」的操作真的很難看。--路西法人 2024年5月21日 (二) 00:39 (UTC)[回覆]
你說得對，路西法人，我選擇性初心的操作真的很難看，太難看了。問題是我也不是沒有用過條目討論頁，被搭理的情況微乎其微。—— 　桁霽　 ↹　晚來天欲雪，能飲一杯無　　 2024年5月21日 (二) 03:09 (UTC)[回覆]
樓上王桁霽君說的的確是，在討論頁發起討論很大概率不被理會。我前幾天在Talk:1954年克里米亞轉交事件和Talk:蘇阿戰爭掛了rfc至今無人參與討論，可見社群有多麼不重視rfc。（Talk:1954年克里米亞轉交事件的那些討論是在掛rfc前討論的）。另外，最近@LuciferianThomas的機器人好像沒發討論邀請，難怪沒人參與。請不要告訴我去ping人，因為有時候我不知要ping誰。--微腫頭龍（留言） 2024年5月21日 (二) 03:25 (UTC)[回覆]
依據我目前正在公示的版本，以Talk:蘇阿戰爭為例，你應直接先跟作出爭議編輯的用戶交涉（就ping他一個），然後無法達成共識就ping過往參與編輯有關主題和條目的用戶，從頁面歷史中都ping一下就已經是了。仍沒人參與再請求外部意見。
另外，「不被理會」始終在於客棧目前仍然是有大量話題，#正在廣泛徵求意見的議題[錨點失效]一節自然難以引起注意；機器人壞了是因為User:Ericliu1912非常善心地手癢破壞了機器人自動閱讀列表的格式@Special:Diff/82499812。--路西法人 2024年5月21日 (二) 03:57 (UTC)[回覆]
再者，共識方針本來就有當無法透過討論頁討論時[…]，維基百科還有幾套既定的流程去徵詢外部編者的意見。共識本來就是從小討論慢慢展開到大討論，「徵詢外部編者的意見」的前提是「當無法透過討論頁討論時」。現在配備了更多機制供在原始討論頁討論，但現況顯然是「沒有充分嘗試」而非「無法」。--路西法人 2024年5月21日 (二) 00:53 (UTC)[回覆]
大概的看法和一些實際操作來看：一般情況，只針對特定條目或者模板的單一頁面的討論問題，應該是先在討論頁討論解決，在無法在單一頁面達成討論共識（可能需要更大範圍的共識討論）甚至範圍擴大的情況時，才拉到條目探討版處理。也存在預期需要更大範圍共識討論（或者認為對應討論頁關注程度偏小而尋求更矚目的關注）的情況下，就出出現一步拉到條目探討版而非先在對應討論頁討論的情況。現有的調整意味著以明文的方式限制後一種情況，但這可能與實際操作上存在矛盾，所以雖然過往的規則上是希望循序漸進，但實際上存在這樣的跳島路徑。至於是否為了保證現在為先單一討論頁進行討論同時為了保證引起關注而利用（或者從提案者的角度來看，更像是推廣自己的成品）討論提醒機制的情況，我認為還是尊重現有的做法，當然愛循規蹈矩的和愛用那東西的，隨便。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月21日 (二) 02:41 (UTC)[回覆]
WP:IAR，法則僅僅是原則而非死例。就條目討論共識，我還是不認為限制位置或者使用工具的方式。我認為條目探討版還是可以作為更高可見度的條目內容探討或討論的主要板塊。該願意在這裡討論的還是這樣做，願意用RFC或者討論提醒的就讓他們去吧。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月20日 (一) 00:48 (UTC)[回覆]

互助客棧（或是任何討論）存檔到空的討論頁需改為加上Template:Talk header

例如這個部分，當機器人存檔到一個空討論頁時，會自動加上存檔模板。但問題是有時目標本身就是一個正常的討論頁，加上存檔模板不合常理。因此希望這個機制改一下，正常頁面就改成用{{Talk header}}加註，存檔頁面才是存檔模板。臺灣杉在此發言 (會客室) 2024年6月18日 (二) 04:20 (UTC)[回覆]

副知@Jimmy Xu。臺灣杉在此發言 (會客室) 2024年6月18日 (二) 04:21 (UTC)[回覆]
沒必要必須加上Talk header模板吧,如果都要加的話，不如善加利用MediaWiki:Talkpageheader--百無一用是書生 (☎) 2024年6月18日 (二) 07:33 (UTC)[回覆]
@Shizhao：我剛剛看了看歷史版本（順便恢復了），以前一段期間（二〇一三年左右）曾預設有Talk header，乃爾後經社群討論停用。您當時還有參加討論XD —— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 20:03 (UTC)[回覆]
不如直接邀請當年放模板的@Liangent及討論參與者@Gakmo、Bluedeck、Jasonzhuocn來發表意見（纔發現連同Makecat全是管理員啊）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 20:06 (UTC)[回覆]
都加有違該模板的文檔。--YFdyh000（留言） 2024年6月18日 (二) 12:49 (UTC)[回覆]
@Taiwania Justo：其實應該改成要加上專題模板，條目可以沒有Talk header（甚至大部分沒必要「割雞用牛刀」），但多半要有歸屬專題。機器人可考慮檢測是否有WikiProject banner shell，若無則顯示錯誤訊息，請使用者加上以後纔會自動存檔。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 15:20 (UTC)[回覆]
都可以，只要能解決存檔目標頁面的判斷就行。臺灣杉在此發言 (會客室) 2024年6月18日 (二) 17:34 (UTC)[回覆]
我甚至忘記存檔到空討論頁會加上那個公告！其實主空間應該都是不需要的。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 19:59 (UTC)[回覆]
機器人檢測WikiProject banner shell沒必要--百無一用是書生 (☎) 2024年6月19日 (三) 02:57 (UTC)[回覆]

有關互助客棧方針版的長度壓力問題

此前，互助客棧方針版的長度一度逾60萬位元組，在我搬運了若干已結束或stale了的討論後才降到40多萬，然而這個長度還是比起其他互助客棧的版塊來得長（互助客棧其他版的長度現在是20多萬位元組，條目探討版是10多萬，消息、技術與求助版不超過10萬），而且在頁面載入與編輯上也產生了一些問題（我在電腦嘗試載入或編輯頁面的話，頁面完全載入所需的時間顯著地延長了）。有鑒於此前曾有討論提議以WP:徵求意見機制取代互助客棧方針版的機能，我認為現在是合適的時機來提出這件事情。Sanmosa 新朝雅政 2024年10月23日 (三) 00:30 (UTC)[回覆]

就著我對互助客棧條目探討版在討論遞進機制開始試行後的情況的觀察，在依照WP:共識/討論頁及共識方針試行案#試行條文第1a及1b條搬運部分討論串後，互助客棧條目探討版的運行狀況大致良好。考慮到大部分的方針指引提案一般只涉及或主要涉及一個方針指引頁面，我認為這個情況與WP:共識/討論頁及共識方針試行案#試行條文第1a及1b條所述的情況是類似的，因此我認為可以考慮對只涉及或主要涉及一個方針指引頁面的方針指引提案實行同樣的要求，以較大程度上減輕互助客棧方針版的長度壓力。當然，有鑒於部分方針指引提案會同時主要涉及多個方針指引頁面，又或是部分提議新立方針指引的提案起初並無對應的條文頁面（與WP:共識/討論頁及共識方針試行案#試行條文第1c及1d條所述的情況類似），因此我並不尋求直接廢除互助客棧方針版，我認為互助客棧方針版在現階段還是存在保留的必要性的。Sanmosa 新朝雅政 2024年10月23日 (三) 00:39 (UTC)[回覆]
@LuciferianThomas、Ericliu1912。Sanmosa 新朝雅政 2024年10月23日 (三) 00:43 (UTC)[回覆]
我認為相對條目探討板而言，方針板還是有部分存在的必要，比如探討設置新方針或機制（但未有任何預備條文）的情況還是要有一個地方討論。其餘小修訂既然已經有bulletin負責公告，那我不覺得一些不大不小的修訂有什麼維持在客棧方針板討論的必要。--路西法人 2024年10月23日 (三) 01:18 (UTC)[回覆]
是的，所以我有特別説明我並不尋求直接廢除互助客棧方針版。Sanmosa 新朝雅政 2024年10月23日 (三) 01:46 (UTC)[回覆]
我現在都不敢點開互助客棧/方針，通常會讓瀏覽器無響應10s以上 囧rz……--自由雨日🌧️（留言｜貢獻） 2024年10月23日 (三) 04:41 (UTC)[回覆]
幾周前，那些大討論存檔前，我用手機測試了一下。以這個版本為例（⚠️慎入！Firefox F12模式情報: 完成: 18.72 秒；DOMContentLoaded: 10.96 秒；load: 13.48 秒）；用【歷史版本→編輯原始碼→預覽】來看，後台計算就要CPU 使用時間: 4.577 秒；實際使用時間；5.756 秒。用手機點下互助客棧實測要心中默數12秒才會開始出現內容(但不至於瀏覽器無響應，其他功能仍可操作)，測試地點台電大樓站、5G網路、450Mb/s。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年10月26日 (六) 23:28 (UTC)[回覆]
其實此前情況更嚴重的是WT:COVID-19條目共識，在我處理前長度超過90萬位元組，我甚至連搬運已結束討論到存檔頁也出現困難。Sanmosa 新朝雅政 2024年10月23日 (三) 05:03 (UTC)[回覆]
如果你知道這幾個月以來付諸「徵求意見」的方針相關話題討論多麼冷清而慘不忍睹，就不應該認為提出捨本逐末的所謂「取代」方案是有益社群的上策。本站政策討論的複雜乃屬天然，長度是一時問題，不是持久問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月23日 (三) 05:32 (UTC)[回覆]
我嘗試抽驗了2024年各月末的VPP長度，除了2月末、3月末與4月末外，沒有一個月末的VPP長度是少於20萬位元組的，9月末的時候VPP長度甚至還將近90萬位元組了。而且，唯獨VPP會動輒出現長度逾20萬位元組的情況，VPD與VPO是頂多偶然如此，但VPP的情況是經常發生。如果將近半年也算是「一時」的話，那我不相信社羣有如此好的忍耐能力。説真的，要不是這個問題持續將近半年，我也不用特地為此提這個案，頁面的載入問題實在令我非常痛苦。Sanmosa 新朝雅政 2024年10月23日 (三) 08:30 (UTC)[回覆]
某管理員長期對於您站設備持故步自封的態度，為了合理化所謂「天然」的雜亂無章且造成極嚴重困擾的機制，肆意抹黑任何試圖解決問題的新機制。這些人從來不考究問題是否長期存在，不考量別人是否跟他一樣擁有良好的設備和網絡能順利載入不合理長度的社群討論板塊。這般不食人間煙火，只站在他自己的道德制高點的人的這種發言根本不用理會。--路西法人 2024年10月23日 (三) 17:13 (UTC)[回覆]
在社群反映存在實際問題時，作為管理員的不嘗試協助社群解決問題，反而事事添堵還說你說的問題根本不存在，這不是解決提出問題的人是什麼（--路西法人 2024年10月23日 (三) 17:15 (UTC)[回覆]
看似解決了一個問題，結果恐怕製造更多問題。此問題本無一方案完美，社群乃於多個方案中選擇缺點最少者，故本人就某特定方案提出商榷意見，其來有自。至於閣下就社群若干事務實際運作觀察是否全面，或你我在此議題向來之歧見等，則自是毋庸再論。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月24日 (四) 08:36 (UTC)[回覆]
另查閱存檔，我收回對長度屬一時問題之發言，確實社群長年以來受此問題困擾甚多，本人判斷不周。但此議題茲事體大，當詳加檢討如何處理，而本人認為現有所謂徵求意見制度運作至少相對不彰，不能當作唯一手段，有必要多管齊下。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月24日 (四) 08:45 (UTC)[回覆]
就拿WT:命名常規#調整地名命名常規的規定來説吧，我當時沒ping自由雨日，但他還是參與討論了，由此可見RFC在規則討論方面的情況應該沒有你説得那麽悲觀的。至於如何提升討論的參與度，我認為可以鼓勵開展討論者ping一些相關的用戶，這樣應該比較能夠產生一些有用的意見。Sanmosa 新朝雅政 2024年10月24日 (四) 14:10 (UTC)[回覆]
本來MediaWiki系統的監視功能、討論追蹤功能等都能讓編者追蹤自己感興趣的頁面的討論。只是不是很多人愛善用內設功能，硬要以「便利」這個理由來製造更多混亂：這些人的主張是本末倒置地不使用設計的討論頁面，卻去認為「互助客棧是天造地設」，還反指讓討論回歸討論頁是「本末倒置」，連「本」是什麼都沒分清楚。
發起討論通知有關編者（不論是通過@ping通知、RFC/FRS還是公告欄）是基本討論禮儀，連這個觀念都不建立好，如何期望您維人能建立良好的討論價值？顯然通知相關用戶並非「可以鼓勵」而是「需要」。--路西法人 2024年10月25日 (五) 02:15 (UTC)[回覆]
我説的是走RFC機制以外另外再ping一次，這樣做有reinsurance的效果。另外我認為用戶不使用討論追蹤功能其實是可以理解的，對於不時就有新留言的討論來説，開了討論追蹤功能以後其實還挺擾民的，這是我自己的使用經驗，自從那次以後我就沒再開過討論追蹤功能了。Sanmosa 新朝雅政 2024年10月25日 (五) 02:43 (UTC)[回覆]
此正所以相關制度施行有必要諮詢更廣泛社群意見之故。蓋社群以人為本，各人體驗不同，故自以為面面俱到者，恐適得其反。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月26日 (六) 09:11 (UTC)[回覆]
我知道你應該不是在説我，但你把我也打進你說的那類人裏總歸是不合適的。Sanmosa 新朝雅政 2024年10月26日 (六) 13:12 (UTC)[回覆]
@Sanmosa、LuciferianThomas：兩位如何看待這個討論（注意彼討論並非修改方針指引，恰恰是根據現存指引取消一些模板中的斜體格式）？--自由雨日🌧️（留言｜貢獻） 2024年10月23日 (三) 17:34 (UTC)[回覆]
這樣説吧，又不是只有RFC才冷清，我看VPT與VPA也挺冷清的，就更別説VPN了，你直接go ahead就是了，畢竟他的意見只是「總是覺得」而已。Sanmosa 新朝雅政 2024年10月23日 (三) 23:34 (UTC)[回覆]
補提了一些意見（ —— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月24日 (四) 09:07 (UTC)[回覆]
或者像近來某些話題，在客棧提出討論一段時間，再移步回各該方針與指引頁面繼續討論，也是一種解方。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月24日 (四) 08:36 (UTC)[回覆]
重點是認定話題一般討論到什麼程度纔應移往他處？往年反映多是社群就特定政策議題激辯過長，以致拖累整個客棧頁面，而非全部議題都有必要另起爐灶。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月24日 (四) 08:57 (UTC)[回覆]
以一個一般留言長度約200至300位元組來計算的話，那我認為長度逾1.5萬位元組的討論就應該搬運，留言總數逾30個的也應該搬運。Sanmosa 新朝雅政 2024年10月24日 (四) 14:18 (UTC)[回覆]
考慮到徵求意見本質是擴大參與或關注，或可以話題發言人數為初步基準，有一定人數即可遷回各該政策討論頁。但涉及超過一個方針與指引者，則建議一概不遷移，直至討論結束自動存檔為止。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月24日 (四) 17:30 (UTC)[回覆]
VPP現時還是比較少同時討論多於一個規則的討論串的，但如果真的有這麼一個討論串，而且還真的非常長，我認為該討論串仍然無可避免地必須被搬運。Sanmosa 新朝雅政 2024年10月25日 (五) 00:46 (UTC)[回覆]
另外，我想了一下，以發言人數為基準可能比較容易誤中副車，現在的情況是有些討論串長度非常長，有些討論串長度則偏短，但兩個討論串的討論人數有可能相當，比如VPP裏公佈管理人員任免案投票人數的提案與引入ONUS的提案（這個討論串我搬運了）都有13人發言，但兩者的長度可以説不是一個量級。Sanmosa 新朝雅政 2024年10月25日 (五) 08:49 (UTC)[回覆]
長度判斷或較主觀。不過大可簡約規定「過長討論可予遷移」之類即可，俾編者靈活決定空間。多元議題方面，可先擱置，觀察長討論遷移情況，再做打算。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月26日 (六) 09:11 (UTC)[回覆]
不行，這方面的規定不能模糊，中文維基百科的社羣現在都快淪落到連甚麽叫「過長討論」也能吵一通的地步了。討論長度真的不行的話，用留言總數來判斷應該也是好的。Sanmosa 新朝雅政 2024年10月26日 (六) 13:11 (UTC)[回覆]
如果你的意見是要有「硬基礎」，那鑑於強制規定應代表最低容許標準，我認為這種基礎情況的移動初始門檻應儘量拉高，減少誤判機率。若屆時實際運用發現不足，再逐步調降。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月26日 (六) 13:27 (UTC)[回覆]
留言總數逾30個其實也算高了，這也是我從VPP的情況看出來的結果。Sanmosa 新朝雅政 2024年10月27日 (日) 01:46 (UTC)[回覆]
或者也可以改成所有方針與指引至少討論一定期間，此後若滿足人數或發言等某些要件，即可移回各該討論頁繼續討論。本來條目探討區也應該要是這樣比較好，但無奈提議不受待見。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月28日 (一) 12:39 (UTC)[回覆]
另亦可提早自動存檔期限（本人曾有提議，惟尚未有下文），儘早結束難有共識之討論。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月24日 (四) 08:37 (UTC)[回覆]
我記得OA2021後首次修訂7DAYS時還有人説應該延後自動存檔期限，這點不太好處理。Sanmosa 新朝雅政 2024年10月24日 (四) 14:11 (UTC)[回覆]
就實務上來說，現在最應該做的是趕緊處理那一大篇電視格式手冊討論，看是要移動回指引討論頁還是什麼的都行。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月26日 (六) 21:36 (UTC)[回覆]
那個提案正在公示當中，恐怕是不能動的。Sanmosa 新朝雅政 2024年10月27日 (日) 01:48 (UTC)[回覆]
總之要趕快解決，那個話題即便已經存檔大部分，現在也還占了客棧篇幅至少三分之一⋯⋯ —— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月28日 (一) 12:37 (UTC)[回覆]
我也想儘快解決，畢竟也維持了差不多一年，但奈何有編輯者玩程序問題（包括擠牙膏式提問+冷待回覆以拖延公示+離題討論），故另提出剪布方案避免這個情況發生，奈何該提案反應不大。--唔好阻住我愛國（留言） 2024年10月28日 (一) 15:56 (UTC)[回覆]
其實我可以以討論為持超過30日+足夠共識做公示，但某管理員堅持要7日無新發言才可做7日公示。--唔好阻住我愛國（留言） 2024年10月28日 (一) 15:59 (UTC)[回覆]
另外，整個討論已有點吃力，基本上這是一個比英維相同連結的格式手冊還要詳儘得多好多，如果是需要由0開始寫一個只有較小空間可以鑽空子的格式手冊中的一個分段，需要超過500個回覆統整，那合理嗎？
英維只用了「」English licensed」一詞+維基百科不是」就能讓編者知道編輯目標，到這裏還要按例子解釋每一句的定義及目標，最後本提案由一小段變成一大分段才能平息疑問。--唔好阻住我愛國（留言） 2024年10月28日 (一) 16:17 (UTC)[回覆]
現已將版本十以前討論全部存檔。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年10月30日 (三) 06:46 (UTC)[回覆]
取自「https://wikicn.playgoteam.workers.dev/w/index.php?title=Wikipedia_talk:互助客栈&oldid=84856297」