维基百科讨论:互助客栈


大幅增添[石油峰值]的內容

{{翻譯自|en|Peak oil}}--ThomasYehYeh留言2023年4月19日 (三) 04:10 (UTC)回复

只展示模板名称及所调用的参数而非模板本身。--EvesiestaDie Gedanken sind frei! 2023年5月13日 (六) 10:47 (UTC)回复

本页面格式问题

本页格式自“Wikipedia:互助客栈/技术#吾改Module:High-use前欲論之”开始有不正确的缩进,个人猜测有Lint错误导致未闭合的标签影响到后方的其他章节,烦请各位技术帝协助查看更正,多谢!--EvesiestaDie Gedanken sind frei! 2023年5月13日 (六) 10:40 (UTC)回复

Wikipedia:互助客栈/方针有辦法先存檔嗎?

快爆了。--窝法乙烷 儿法梦碎 2023年7月26日 (三) 14:25 (UTC)回复

@Milkypine:最近應該有一批討論會存檔。—— Eric Liu 創造は生命(留言留名學生會 2023年7月28日 (五) 05:37 (UTC)回复

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

續上個月存在初步共識的討論(Wikipedia_talk:請求評論#引入WP:回馈请求服务与WP:请求评论),再次提出引入WP:請求評論機制。目前,我經已開始開發負責運行請求評論的機械人(Wikipedia:机器人/申请/LuciferianBot/5),並有初步成功的測試結果。WP:回饋請求服務尚未引入,英維也暫時沒了這個服務,似乎也並不至於必須即時引入。@參與上次討論的用戶@0xDeadbeefGhrenEricliu191294rainHehuaS8321414魔琴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)回复
@HehuaSanmosa:取代一事,第一步一定是完全廢除條目探討板(理由已前述,若有疑慮可至上面回應),同時可以不再將方針板訂為唯一可以修訂方針指引的有效場所,並要求討論要麼在相關方針指引頁發送通知(包括發起討論、公示等),或者直接在相關方針指引頁討論,鼓勵編者在合適的場所提出,而避免在難以追蹤、集合數十個不相關話題的互助客棧討論訂立和修訂方針。方針板大概不會被完全取代,始終必須有一個場所給人問方針相關的問題。--西 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)回复
@其餘參與提案討論的用戶@94rainHehuaSanmosaS8321414落花有意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:RFCWP: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)回复
返回到项目页面“互助客栈”。