跳转到内容

维基百科讨论:互助客栈/存档3

页面内容不支持其他语言。
维基百科,自由的百科全书

編輯請求 2021-03-18

请求已处理

將「投訴管理員不當處理站務」的標題改回原本的「投訴蟲蟲飛不當處理站務」。是蟲蟲飛把標題上的「蟲蟲飛」抹去,改成「管理員」--温大善人留言2021年3月18日 (四) 00:27 (UTC)

已改回[1]。—-Outlookxp留言2021年3月18日 (四) 01:54 (UTC)

編輯請求 2021-05-02

编辑请求 2021-05-04

请求已拒绝

请协助建立页面:「Wikipedia:长期小作品」,将之与 en 的“Wikipedia:Permastub”链接在一起(跨语言链接),并将“Template:Wikipedia essays”中的「* {{Link-en|Wikipedia:元素小作品|Wikipedia:Permastub|元素小作品}}」一行改为「* {{Link-en|Wikipedia:长期小作品|Wikipedia:Permastub|长期小作品}}」,谢谢。

我是非确认用户,没有权限做这些编辑,本想试试那个内容翻译功能,结果它告诉我服务器连接不上(

WuzgXY留言2021年5月3日 (一) 16:18 (UTC)

*更正:最后一项改为「* [[Wikipedia:长期小作品|长期小作品]]」。

我受自动登出漏洞影响不能编辑原文本,只能在手机版视图再加一条评论了(

WuzgXY留言) 2021年5月3日 (一) 16:18 (UTC) WuzgXY留言2021年5月4日 (二) 00:21 (UTC)

未見建立的必要。SANMOSA Σουέζ 2021年5月9日 (日) 01:16 (UTC)

我认为有建立的必要。原文的 perma 显然不是「元素」的含义,这是一点需修正的错误;另外我作为非确认用户想对原文作翻译,不得不请求确认用户建立此页面,还希望能再考虑一下。WuzgXY留言2021年5月9日 (日) 07:09 (UTC)

你可以直接在Template:Wikipedia essays更改譯名,而且你理論上也可以直接建立Draft:長期小作品頁面並翻譯完成後後請求移動。SANMOSA Σουέζ 2021年5月10日 (一) 03:10 (UTC)
好的,感谢回复。但前者由于 https://zh.wikipedia.org/wiki/User:SteepPeak/Guide/Autologout 无法实现,后者涉及到创建页面,我个人尚未找到 2017 版编辑器创建页面的方法,因此也受此漏洞限制,我个人不能完成此项编辑。我已经将翻译后的文本上传至 https://paste.ubuntu.com/p/7y54Yk6DJX (文中的带协议外[内?]链可能格式有误),如能帮忙建立,感激不尽。WuzgXY留言2021年5月12日 (三) 15:11 (UTC)
@WuzgXY你能不能先嘗試用流動版編輯器(在手提電話上的browser編輯)?SANMOSA Σουέζ 2021年5月18日 (二) 02:43 (UTC)
已添加Draft:長期小作品,并已修改好 [[Template:Wikipedia essays]],正等待草稿审核。很抱歉添麻烦了,本来能自己解决的WuzgXY留言2021年5月19日 (三) 11:06 (UTC)
提請人已自行解決。SANMOSA Σουέζ 2021年5月22日 (六) 03:13 (UTC)

編輯請求 2021-06-01

方针区的存档问题

现在方针区已经太大了,我已经多次遇见不能在移动设备上查阅方针区的事情,是否有一些已经讨论完的事项能及时存档,或者移至其他的名字空间进行进一步讨论?--LightyearsTalk·Sign#维猫报 2021年5月15日 (六) 10:08 (UTC)

建议多弄点儿→“方针一区”、“方针二区”、“方针三区”。[開玩笑的]--安忆Talk 2021年5月15日 (六) 10:12 (UTC)
未尝不可[開玩笑的]--LightyearsTalk·Sign#维猫报 2021年5月15日 (六) 13:12 (UTC)
方针核心方针热门入方针必刷方针动画,方针番剧,方针音乐……方针小黑屋...[開玩笑的]--ClayM300(留言讨论🧐) 2021年5月15日 (六) 13:16 (UTC)
也不要給到B站的連結,,,-- Sunny00217  2021年5月23日 (日) 14:24 (UTC)
之前誰好像說過可以啟用集中討論制度啥的。—— Eric Liu 創造は生命(留言留名學生會 2021年5月15日 (六) 15:10 (UTC)
(?)疑問:現在方針區還好,我也用手機,沒發現甚麼問題,怎麼不能查閱?--蟲蟲飛♡♡→♡℃留言 2021年5月15日 (六) 15:20 (UTC)
@虫虫飞:我不是很清楚,不过您在香港我在深圳,我需要跨越虚拟混凝土或者用镜像站,这或许是区别之一。--LightyearsTalk·Sign#维猫报 2021年5月15日 (六) 15:22 (UTC)
建議試一下用手機時點選桌面電腦模式,手機的模式,有很多功能都不支援。--蟲蟲飛♡♡→♡℃留言 2021年5月15日 (六) 15:31 (UTC)
是桌面电脑模式,不排除是我的手机问题,但方针区的及时存档和分流也应提上日程了。--LightyearsTalk·Sign#维猫报 2021年5月16日 (日) 07:37 (UTC)
就是单纯的大,页面内容多到浏览器渲染起来很慢。当然和链路也有关,VPN会有一个中转的过程,会比在香港直连新加坡服务器慢一点,反代站的话还要有解包处理再打包的过程,还要比VPN慢得多。--安忆Talk 2021年5月16日 (日) 08:00 (UTC)
(?)疑問:能否使用类似Wikipedia:互助客栈/方针/Example的页面来储存每个讨论,然后只在Wikipedia:互助客栈/方针上使用{{Wikipedia:互助客栈/方针/Example}}这样的语句来显示讨论?或者只在主页面上保留一个前往讨论的链接,而讨论本身放在子页面进行?--Yining Chen留言|签名2021年5月17日 (一) 13:13 (UTC)
方針區的問題嚴重嗎?還是個別型號手機的問題?因為最近維基也有各種形式的問題,像我自己輸入「:」「{}」經常有亂碼,要複制黏貼才可以,其他人好像都沒有這個問題。前些時候,vip的小工具,也只有我不能用,但最近突然又沒事了。--蟲蟲飛♡♡→♡℃留言 2021年5月17日 (一) 13:55 (UTC)
这样感觉和现有的存档机制不太协调。有一部分是设备和网络的原因,但最主要的原因其实还是页面太大了。现在就进行着很多个大型提案,完全可以分离一下。--安忆Talk 2021年5月17日 (一) 14:11 (UTC)
我觉得可以利用WP:RFCWP:CD之类的方式处理。比如将讨论时间过长的讨论转移到相应的对话页或者建立单独的RFC页面继续讨论,减小单个页面的压力。有时候页面那么大,讨论内容各种各样,阅读的心情都没有了,更别说积极讨论了--百無一用是書生 () 2021年5月18日 (二) 01:38 (UTC)
我用PC,在方针版用回复功能经常显示 服务器未在预期时间内相应,但其实我的回复已经发布出去了,我觉得和页面大也有关系。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月17日 (一) 15:28 (UTC)
我這邊沒這個問題,其他大陸用戶也遇到相同問題嗎?如果用“quickedit”會否改善?--蟲蟲飛♡♡→♡℃留言 2021年5月17日 (一) 22:36 (UTC)
+1,大的页面经常出“编辑冲突”的错误,有的可能自动解决,有的不会。--ClayM300(留言讨论🧐) 2021年5月18日 (二) 08:41 (UTC)
+1,遇到过。回复功能不会有编辑冲突,可视化也比较方便。--安忆Talk 2021年5月17日 (一) 23:55 (UTC)
前两天我用回复功能编辑冲突好几次....--百無一用是書生 () 2021年5月18日 (二) 01:32 (UTC)
回覆功能會通過API回傳整個頁面內容,時常編輯有保存,但顯示連線逾時。--Xiplus#Talk 2021年5月20日 (四) 08:40 (UTC)
半开玩笑的说,不妨在讨论部分引入Discuz,或者其他的BBS系统。虽然编辑冲突仍然存在,但是这样至少可以缓解讨论页的问题。——ClayM300(留言讨论🧐) 2021年5月18日 (二) 08:44 (UTC)
或者默认折叠所有的讨论,只有在主动点击查看的时候再加载内容。——ClayM300(留言讨论🧐) 2021年5月18日 (二) 08:44 (UTC)
电脑端加载缓慢的内容不见得手机端会更容易加载,有一次因为打开的标签页太多,Chrome直接崩溃了。我上一次遇到因为内存不足导致PC端浏览器崩溃的事情是还是在10年前。——ClayM300(留言讨论🧐) 2021年5月18日 (二) 08:48 (UTC)
好像没这功能(指Ajax请求段落文字),就算是用Minerva,也只有图片是懒加载…MediaWiki正常的“折叠”只是视觉上的,实际还是得把全文拉回来才行。--安忆Talk 2021年5月18日 (二) 09:00 (UTC)
@AnYiLin:參考Wikipedia_talk:模板限制#模板限制後半討論,認為可以從minecraft wiki引入{{LoadBox}}與{{LoadPage}}模板過來。(mcwiki:MediaWiki:Gadget-site.js、另見mcwiki:Category:Ajax载入页面)。參與者只要在有興趣的議題按下 [閱讀更多..] 之類的按鈕或連結即可(像Facebook那樣,顯示個貼文摘要)。-- 五歲抬☎️·☘️2021年5月18日 (二) 09:25 (UTC)
但無論哪種做法,勢必都會需要重新調整目前的客棧原始碼結構。-- 五歲抬☎️·☘️2021年5月18日 (二) 09:29 (UTC)
趕快將無法通過的討論存檔掉就行。--Temp3600留言2021年5月18日 (二) 14:43 (UTC)
同意Temp3600的建議,「趕快將無法通過的討論存檔掉就行。」現在就是太多鸭子测试一望而知無法通過的提案,這些提案提早存檔,不但方便閱讀,而且避免大家浪費時間在無法通過的提案上,例如有些新手方針還沒看,就走來改方針,這類提案都可以提早存檔。--蟲蟲飛♡♡→♡℃留言 2021年5月19日 (三) 02:39 (UTC)
我一台能跑GPU实时光线追踪的Mac,开方针区网页滚动页面都要白上半秒钟才有内容渲染出来,方针区真的太大了。短时间内涌现大量议题讨论也是可能的事情,我建议尽快分流一些大的话题到集中讨论那里去。 --Milky·Defer 2021年5月18日 (二) 16:35 (UTC)
你确认是你的电脑垃圾吗?我的,使用桌面网页版,Chrome,系统锁定显卡为mx150,都没有这种情况。如果你说在手机上使用手机网页版或者桌面网页版显示加载有延迟,这我倒见过。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年5月19日 (三) 03:11 (UTC)
@cwek:我認為是方針區成千上萬個DOM節點造成的。 請注意DOM節點的運算,預設是在CPU,算完才會開始渲染。-- 五歲抬☎️·☘️2021年5月20日 (四) 08:37 (UTC)
有本地缓存(例如图片、脚本),重新加载也就是6秒左右。也没有滚动时有明显色块撕裂的情况。可能和机器渲染效率有关,但方针现在的规模还没有达到加载缓慢的问题(像是模板扩展溢出的基本上十几秒)。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年5月20日 (四) 09:27 (UTC)
DOM處理是在CPU,當DOM節點過多時,很難保證CPU能在Frame update前完整更新DOM節點資料給GPU。-- 五歲抬☎️·☘️2021年5月20日 (四) 10:05 (UTC)
和显卡有什么关系吗…网页里也没有WebGL、CSS动画等“图形内容”。即使浏览器开硬件加速也不会用GPU算document啊(解析DOM、执行JS等),要是单纯的DOM节点巨多也没关系,主要是还有很多JS在增改它(在DOMContentLoaded的前后,这堆脚本还是各管各的,没多少协调性可言),整体就慢下来了。onload的时间会变得很长。--安忆Talk 2021年5月20日 (四) 10:11 (UTC)
但長度過長造成困擾也是事實。其他條目照樣有JS在增改它,但大部分的條目沒有客棧方針區這樣的LAG狀況,就說明客棧方針區真的太長。建議拆分,可用子頁面模式+嵌入包含時用Lua腳本讓他只顯示摘要或有限內容,展開完整內容則從minecraft wiki引入{{LoadBox}}與{{LoadPage}}模板(見留言#A2569875 2021年5月18日 (二) 09:25 (UTC))。-- 五歲抬☎️·☘️2021年5月21日 (五) 04:59 (UTC)
我的意思是想说“DOM巨多的同时,又被长时间计算和增改,所以才更慢(相比单纯DOM巨多)”…--安忆Talk 2021年5月21日 (五) 05:16 (UTC)
  • 把討論內容分流到其他頁面,很影響社群閱讀討論,而且現在的問題不是很嚴重,我這邊就完全沒有問題。如果是個別用戶的裝置問題,不認為把討論切割和搬到另一頁面就能解決問題。現在方針區的主要問題是太多沒意義的提案,很多都是“為改而改”,甚至有新手沒看方針,就走來改方針,只要訂立一些規則,約束一下不合理的提案,已經可以把方針區的提案大大減少。--蟲蟲飛♡♡→♡℃留言 2021年5月21日 (五) 10:24 (UTC)
    因为您离服务器很近…不受传输速率(浪费在跨境中转上)所影响。现在方针区不算脚本、样式表、媒体资源等,一个网页(即/)就将近300K(别看数字比较小,但这和下载文件不一样,浏览器还要并发一些其他的资源,同时解析处理它们,上面说过了),换算起来就是十五六万字,大到能出书。--安忆Talk 2021年5月21日 (五) 10:36 (UTC)
User:Temp3600的建議很好,其實不用太複雜,像用戶討論頁那樣,弄一個存檔小工具,方便大家把一些顯然沒共識的提案儘快存檔,不但可以解決提案所提及的問題,而且可以避免浪費社羣時間在討論沒意義的提案上。--蟲蟲飛♡♡→♡℃留言 2021年5月21日 (五) 13:35 (UTC)
理论上Bluedeck的Easy Archive已经足够了,问题是这岂不是谁想存档点一下就好,打编辑战从未如此方便。--痛心疾首 2021年5月22日 (六) 09:23 (UTC)
建議訂立一些存檔規則,違規回退存檔的可以舉報。--蟲蟲飛♡♡→♡℃留言 2021年5月23日 (日) 05:04 (UTC)
直接POINT處理就好何必定新方針-- Sunny00217  2021年5月23日 (日) 14:29 (UTC)
我看了下方針區發現有一些提案似乎正處於等待處理的狀況,例如專題命名空間有關新增偽命名空間的提議似乎在等人寫機器人,設計一個制度解決部分速刪模板掛不上去的頁面的刪除問題在等著更新Twinkle。像這種與其說在討論不如說更像是等待性質的提案,是不是可以另外增設類似Wikipedia:互助客棧/方針/等待區將這些等待處理的提案放進去,這應該可以減少一定程度的內容。另外我對於蟲蟲飛說的「沒共識沒必要浪費時間討論的提案」感到疑惑,目前方針區有哪些提案是屬於這種性質,能不能提供幾個實例?假設將這些沒必要浪費時間討論的提案進行存檔後,能不能改善目前方針區內容過大導致有些手機無法查閱的問題?--Poontele留言2021年5月26日 (三) 01:33 (UTC)
可以根據常識判斷,如果提案出現大量反對票,那提案人就不好強行通過,要麼就撤回提案,要麼就根據反對意見弄一個新的修訂案。如果還是出現大量反對,提案人堅持下去也沒意義。--蟲蟲飛♡♡→♡℃留言 2021年5月26日 (三) 02:35 (UTC)

編輯請求 2021-06-13

请求已处理上扬斯克的雪 2021年6月13日 (日) 09:05 (UTC)

hi,各位,我想要翻译条目,然后发现了Wikipedia:翻译请求,但是,我想“为了保持鸡巴整洁,请勿在此填写完成度。”应该并不合适,我不知道维基百科对这个内容的态度是什么,然后我注意到WP:联络我们,然后我到这里来了。--JohnFrankStar留言2021年6月13日 (日) 04:14 (UTC) 还有,请问为什么“WP”也可以链接到Wikipedia?

編輯請求 2021-06-28

请求已拒绝-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

您好,我已在「中華民國中古車出口建設研究協會」編輯"英文"板本:

https://zh.wikipedia.org/w/index.php?title=Special:%E5%86%85%E5%AE%B9%E7%BF%BB%E8%AF%91&page=%E4%B8%AD%E8%8F%AF%E6%B0%91%E5%9C%8B%E4%B8%AD%E5%8F%A4%E8%BB%8A%E5%87%BA%E5%8F%A3%E5%BB%BA%E8%A8%AD%E7%A0%94%E7%A9%B6%E5%8D%94%E6%9C%83&from=zh&to=en#suggestions

請求協助後續發佈,謝謝~--ucc留言2021年6月28日 (一) 02:49 (UTC)

invalid-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

有三個網址希望補充一下一些重要資訊

https://zh.m.wikipedia.org/wiki/B.1.617譜系 https://zh.m.wikipedia.org/wiki/B.1.1.7譜系 https://zh.m.wikipedia.org/wiki/B.1.351谱系 希望補充項目: 主要症狀 重症率 致死率

如果知道主要症狀或許就能夠提高染疫者的警覺 Geni0809048212留言2021年6月30日 (三) 07:29 (UTC)

編輯請求 2021-07-08

请求已拒绝-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

請求開放建立振宇五金股份有限公司條目。--Sam2468083留言2021年7月8日 (四) 03:55 (UTC)

invalid-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

編輯請求 2021-07-12

请求已拒绝-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

請管理員協助將以下意見移至「有關台鐵EMU500型電聯車與台鐵EMU600型電聯車改造中的資訊有必要留嗎?」一節,感謝。

invalid-- Sunny00217  2021年7月15日 (四) 03:10 (UTC)

編輯請求 2021-07-22

请求已拒绝:无内容。--东风留言2021年7月26日 (一) 16:13 (UTC)

修改部分頁面內容--Villager8787留言2021年7月22日 (四) 07:10 (UTC)villager

編輯請求 2021-07-23

请求已拒绝。--东风留言2021年7月26日 (一) 16:15 (UTC)

您好。 因為我原來的條目「兒童文學作家張友漁」被刪除,我不曉得為何被刪除。 刪除後,張友漁的網頁搜尋結果,本人也就是張友漁是女性,照片卻被置換成大陸同名同姓已故男性張友漁作家。 請問,我該如何將張友漁(作家)這條目,修改成兒童文學作家張友漁, 以便與大陸已故作家張友漁做出區別。 照片被誤植、錯置,讓人非常憂鬱。 懇求這裡的高手幫忙,謝謝。--Jeeptaiwan留言2021年7月23日 (五) 07:28 (UTC)jeeptaiwan張友漁

@Jeeptaiwan您可前往WP:DRV申请复核,此处并非恰当的求助位置。--东风留言2021年7月26日 (一) 16:15 (UTC)

(節刪)

註:此處原有文字,因為和互助客棧關係不明確的留言,已由Wolfch (留言)於2021年8月4日 (三) 22:27 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。

關於Wikipedia talk:互助客栈

建議將Wikipedia_talk:互助客栈(或是包含其子頁面)以標題黑名單半保護,並自訂提示導到WP:VPH。看起來是有新手搞不懂(可能還不是少數)要去哪裡求助,造成困擾。-- Sunny00217  2021年7月15日 (四) 03:15 (UTC)

可是客棧各頁面都被那群(節刪)LTA搞臭到半保護n個月(條目探討14天而且我發言不久即將到期(LTA一定不死心然後該頁被大概率補上3個月),方針1個月到8月6日,求助57天到8月18日,消息技術和本頁直接到十月)(至於跟維基百科無關問題的WP:ASK則是一週到本月19日),把新手都擋之門外,那些不友善的頁面對新手來說就跟不存在無異,還是要讓他們去IRC還是找管理員還比較有可行性。-- Matt Zhuang表示有事按「此」留言 2021年7月15日 (四) 03:51 (UTC)
更新:不出所料,條目探討保護一結束又有LTA用Open Proxy破壞而再度被半保護到十月。-- Matt Zhuang表示有事按「此」留言 2021年7月16日 (五) 08:48 (UTC)
或者临时将在Wikipedia:互助客栈编辑提醒,加上其他渠道的联系方式,例如IRC、telegram等,方便转走沟通。不过某位虫虫飞黑的孜孜不倦确实令人“叹为观止”。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月16日 (五) 02:22 (UTC)
@Cwek完成。--Txkk留言2021年7月24日 (六) 06:51 (UTC)
求助版不該被保護的!-- Sunny00217  2021年7月16日 (五) 13:35 (UTC)
或者你去说服虫飞飞辞职或者说服那位整天喊虫飞飞辞职的那位收手呗。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月24日 (六) 07:00 (UTC)
在求助版发“求助,为什么我编辑不了求助版” 囧rz…… --Yining Chen留言|签名2021年7月25日 (日) 02:44 (UTC)
求助,因为无法求助。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月25日 (日) 05:04 (UTC)
Wikipedia:回退、封禁、不理會,不是保護吧 囧rz……-- Sunny00217  2021年7月27日 (二) 02:37 (UTC)
如果不保护的话,就会变成猫捉猫鼠的游戏吧。干脆保护长久一些,他愿意“等待只因渴求”那就无计了。(摊手)——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月27日 (二) 02:54 (UTC)

LTA:QCHM

受制于千村狐免及其傀儡实施的长期破坏,使得互助客栈知识问答的讨论受到严重影响。永无止境的半保护抹杀了IP用户的言论自由。所以,如何在不半保护客栈和知识问答的情况下防止千村狐免继续扰乱或人身攻击?过滤器还是标题黑名单?

以下是千村狐免的常用内容:

  • 虫飞到鼻孔里怎么办?
  • 虫子和车子什么关系?
  • 所谓《讣告》(節刪)

--爬行数码1903 2021年8月2日 (一) 05:20 (UTC)

过滤器一直都有,但效果逐步不太好。(LTA也说过这个用户有一定的技术基础)——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年8月2日 (一) 05:40 (UTC)
最佳解决方案:在方针里写明禁止非自动确认用户编辑WP:VPWP:RD[開玩笑的]--Yining Chen留言|签名2021年8月7日 (六) 04:29 (UTC)

延長互助客棧的存檔時間

希望將互助客棧,只少是方針的存檔時間改為10天。因為WP:7days要求7天無發言但又8天存檔,結果經常要人打撈,不然很容易錯過議題,被存檔,不利討論。ghren🐦吱吱吱...🔊 2021年11月8日 (一) 16:07 (UTC)

現在不就是 10 天存檔嗎?T: Village pump page header:「10月29日之後沒有新回應的議題會移動至相應的討論頁或存檔。」
7 日無發言。公示 7 日。公示開始,編輯一次,說一聲。公示結束,再編輯一次,總結。然後 10 日後存檔。所以最快也是 24 日後才存檔。 — 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2021年11月8日 (一) 16:32 (UTC)

公示7日,將WP:VPP的存檔時間延至10天。ghren🐦吱吱吱...🔊 2021年11月17日 (三) 11:08 (UTC)

十日了。--路西法人 2021年11月25日 (四) 18:16 (UTC)
我去請求更改了。--ghren🐦吱吱吱...🔊 2021年11月26日 (五) 08:47 (UTC)

为什么WP:VPA重定向至此?


总感觉A和“求助”不怎么搭调啊?总感觉A对应article,即条目,照理来说应该重定向到Wikipedia:互助客栈/条目探讨才对啊?--Liuxinyu970226留言2021年12月10日 (五) 01:12 (UTC)

ask?桐生ここ[讨论] 2021年12月10日 (五) 01:23 (UTC)

如果这样,那岂不是Wikipedia:知识问答更沾边?!--Liuxinyu970226留言2021年12月10日 (五) 04:41 (UTC)
Village pump,VP。--安忆Talk 2021年12月10日 (五) 07:09 (UTC)
Assistance. -Mys_721tx留言2021年12月10日 (五) 07:12 (UTC)

请求协助存档

我打算帮助这里存档一年前(更近期也可以)的存档(我有开小工具),不知道各位有意见吗?如果没有请@我。另外如果有其他页面积存需要存档也可以一并向我说明。--Evesiesta 2022年8月21日 (日) 14:32 (UTC)

Wen WanYi

Wikit2022留言) 2022年9月25日 (日) 03:12 (UTC)于文晚一,我尝试编辑,它有显着的参考 qnd 做中文翻译,但 contect 说上个月翻译不好,我不知道该怎么办。我需要帮助做中文翻译Wikit2022留言2022年9月25日 (日) 03:12 (UTC)

WP:共识與WP:移動請求協調等

由於有人認爲在頁面及其討論頁發起的移動請求,在被轉入互助客棧後屬於提案,按Wikipedia:共识#互助客栈的公示/免除公示程序及公告等步驟處理,不適用Wikipedia:移動請求:“一般來說,移动請求將在提出請求七天後依據其討論頁之討論結果處理”,因此提出以下問題:

  • 1. 被轉入客棧的移動請求經逾七日討論並達成共識,可否據此共識移動?應否遵循客棧提案的公示/免除公示及公告等步驟?

如以上問題一否一應,衍生以下問題:

  • 2. 被轉入客棧的移動請求經逾七日討論並達成共識,處理此請求的管理人員是否有權不經公示/免除公示及公告等步驟,據此共識直接移動?
  • 3. 經客棧逾七日討論、達成共識但未經公示/免除公示等步驟的移動請求,經機器人自動存檔轉出客棧後,可否免於客棧提案通過程序,據移動共識直接移動?
  • 4. 經客棧逾七日討論、達成共識但未經公示/免除公示等步驟的移動請求,經請求者、管理人員或其他人手動存檔轉出客棧後,三者分別可否免於客棧提案通過程序,據移動共識直接移動?
  • 5. 若不轉移移動請求的討論,僅在客棧設置鏈接以導向相關移動請求的討論,其他情形不變,第1、2問答案為何?會否改變?

無關移動請求,亦有客棧提案通過相關問題:

  • 6. “提案”為何?
  • 7. 如在客棧中有條目等頁面編輯提議,提議者或其他人可否在此提議停留在客棧期間,不經公示/免除公示等步驟,實施與此提議一致或近似的編輯?如否,此提議自動或手動存檔轉出客棧後,又可否如此為之?
  • 8. 如在客棧中有條目等頁面編輯提議經多日討論後達成共識,提議者或其他人可否在此提議停留在客棧期間,不經公示/免除公示等步驟,實施與此提議一致或近似的編輯?如否,此提議自動或手動存檔轉出客棧後,又可否如此為之?
  • 9. 如在客棧中有求助性請求,可否不經公示/免除公示等步驟,滿足其請求?如否,達成共識後,又可否如此為之?

此外,Wikipedia:共识#互助客栈有極重大漏洞:

  • 10. 只規定客棧提案的公示通過、免去公示通過、微小修訂通過的條件;未規定無定語或狀語的“通過”本身的條件,或前述三者是客棧提案通過的唯三管道。即法理上任何人可不經公示/免除公示/微小修訂規定在客棧宣佈通過任何提案,包括方針指引修訂。(也許有人説確實如此,以上問題全部白問了;或許也有人説前者説法游戲維基規則,該方針實質上暗示“若要通過,理應公示,除非例外”。)

--Gohan 2023年1月20日 (五) 09:03 (UTC)

這是為什麼我在一個月前提出修訂WP:共識,涉及共識的必須明確表達意見,當進入公示程序時,管理員需插手確認有沒有問題,這樣的做法可以解決上述問題。--唔好阻住我愛國留言2023年1月20日 (五) 17:16 (UTC)
先決問題是上述請求需不需要公示,此前又有多大比例確實公示。--Gohan 2023年1月21日 (六) 01:40 (UTC)

互助客栈的编辑提示

目前,互助客栈所有子页均使用相同的编辑提示,其中包含一个推荐的讨论格式。但这个讨论格式不适用所有子页,也有新手向我表示在求助版提问时对编辑提示感到困惑。很明显,“问题背景、我的观点、我的解决方案、比较条文”完全不适用于消息、求助版,在条目探讨和其他版也只有部分话题适用。考虑到互助客栈属于高流量页面,且目前使用组提示套用至所有子页,若要一页一提示会需要大改引用关系,所以在这里发起讨论。最基础地,至少应该要在消息和求助版移除这个讨论格式,条目探讨和其他版也应该考虑移除掉。希望得到大家的意见。--Tiger留言2023年1月23日 (一) 15:14 (UTC)

本來就只有方針版有這個提示,是有人自作聰明改的。--Xiplus#Talk 2023年1月24日 (二) 03:14 (UTC)
都幾年前的事了 囧rz……--SunAfterRain 2023年1月25日 (三) 05:45 (UTC)
支持,又有多少人在方针版用这个格式呢 ——魔琴 留言 贡献 新手2023计划 ] 2023年1月24日 (二) 13:45 (UTC)
咱覺得直接把那段限定在方針版才能看到就好了吧--SunAfterRain 2023年1月25日 (三) 05:45 (UTC)
現在編輯提示沒有存檔提示了。--Gohan 2023年1月31日 (二) 06:07 (UTC)

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

{{翻譯自|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)
感觉“征求意见”更顺口,大量文书标题使用,也有栏目使用[2]。“意见征集”[3]等也可以,征集更像非定向。主名称不确定,但都可以作为别名。--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)

本页上方那个存档是否做成折叠的

已经有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)

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

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

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

因提案影響既有權益甚大,卻未曾通知日常使用互助客棧的多數編者,故在此特別予以公告提醒,請編者注意並踴躍參與相關討論。—— 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及討論參與者@GakmoBluedeckJasonzhuocn來發表意見(纔發現連同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)

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

通過:
公示期間無合理異議。Sanmosa 熱烈慶賀「關注度」正名「收錄標準 2025年1月24日 (五) 01:23 (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)
@LuciferianThomasEricliu1912Sanmosa 新朝雅政 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)
@SanmosaLuciferianThomas:两位如何看待这个讨论(注意彼讨论并非修改方针指引,恰恰是根据现存指引取消一些模板中的斜体格式)?--自由雨日🌧️留言贡献 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)
就本節原始討論的議題而言,我個人認為若是要修正既有方針指引,或是提議將既有頁面升格為方針指引,最好還是都在該方針指引的討論頁提出,並透過RFC機制邀請社群討論,至於方針板仍可提供全新提出的方針指引討論,(如果可行的話)並將方針板頂部的RFC嵌入改為僅嵌入Wikipedia:徵求意見/維基百科方針與指引Wikipedia:徵求意見/維基百科提議以及Wikipedia:徵求意見/維基百科格式與命名,如此狀況應該會好上不少。--冥王歐西里斯留言2024年11月9日 (六) 12:39 (UTC)
@Ericliu1912行,現在VPP的長度又突破30萬了,問題主要出在留言數近或逾50的討論串,其中一個還是你發起的。如果不盡早處理的話,那問題遲早會惡化成我一開始開這討論串時的情況。難不成每次VPP長度過長,我就得來這裏開個新討論串嗎?Sanmosa 新朝雅政 2024年11月29日 (五) 15:45 (UTC)
基本上我的意見是涉及單一方針或指引討論有基本進展或累積一定長度者,均得移往各該政策討論頁。如果這樣還不夠,再看看要加上什麼。—— Eric Liu 創造は生命(留言留名學生會 2024年11月29日 (五) 17:46 (UTC)
然而「搬運」這個操作真的不能省卻嗎?Sanmosa 新朝雅政 2024年11月30日 (六) 01:05 (UTC)
@Ericliu1912行,現在又破40萬了,現在該如何處理?Sanmosa 蘭絮 2025年1月7日 (二) 04:00 (UTC)
或许应像条目探讨那样规定,仅涉及单一方针的讨论需在方针讨论页发起?--自由雨日🌧️❄️ 2025年1月7日 (二) 05:52 (UTC)
關注度那討論快結束了。另外亦可規定僅涉及單一方針或指引者須先在自身討論頁發起話題,若實無進展再考慮移往客棧之類。—— Eric Liu 創造は生命(留言留名學生會 2025年1月7日 (二) 06:32 (UTC)
那這不就是我一開始提的案嗎?那你當時説的話[錨點失效]又有甚麽意義?Sanmosa 蘭絮 2025年1月8日 (三) 13:12 (UTC)
任何提案都是看情況。—— Eric Liu 創造は生命(留言留名學生會 2025年1月8日 (三) 18:03 (UTC)
另外考慮到相關制度施行後實情,建議明文允許一段長時間無討論(至少長於既有客棧討論存檔回討論頁者)時得逕移往客棧。—— Eric Liu 創造は生命(留言留名學生會 2025年1月8日 (三) 20:09 (UTC)
不建議這樣做,這只會導致一個stale的討論被不斷移來移去,我甚至認為應該要限制這種做法。這也是我從實例中得出的結果。Sanmosa 蘭絮 2025年1月10日 (五) 08:25 (UTC)
過往討論很少「移來移去」。而且現行制度其實相當於把一個政策討論「自然結束」的期限從近兩週(存檔回討論頁)拉長到一個月(徵求意見模板撤除),前者應該優先。你公示的過程本身也很能說明徵求意見的問題,整整七天都沒人回。我對這種程序結果是否能真正得致共識感到憂慮。—— Eric Liu 創造は生命(留言留名學生會 2025年1月17日 (五) 14:27 (UTC)
然而你恰好就做了把stale的討論移來移去的事情。Sanmosa 熱烈慶賀「關注度」正名「收錄標準 2025年1月19日 (日) 08:23 (UTC)
移回客棧一次不叫「移來移去」,頂多你又移回討論頁纔算。—— Eric Liu 創造は生命(留言留名學生會 2025年1月19日 (日) 10:56 (UTC)
這是甚麽話,一開始是我移至討論頁,然後你又將stale了的討論移回VPP,而導致客棧長度又破20萬,後來更是又破40萬了。你這種説法未免有些顛倒黑白了。Sanmosa 熱烈慶賀「關注度」正名「收錄標準 2025年1月19日 (日) 13:52 (UTC)
或者反向規定政策先在客棧討論一段時間(曝光)後再移回討論頁,這也是一種辦法。—— Eric Liu 創造は生命(留言留名學生會 2025年1月17日 (五) 14:28 (UTC)
不能這樣做,VPP已經過長了。Sanmosa 熱烈慶賀「關注度」正名「收錄標準 2025年1月19日 (日) 08:22 (UTC)
如果要在較長篇幅跟沒討論間,我寧願選前者。何況這本也不是永遠狀態。—— Eric Liu 創造は生命(留言留名學生會 2025年1月19日 (日) 10:56 (UTC)
然而最近一次VPP過長是你造成的,你覺得這不是問題不代表這就真的不是問題,VPP過長早在去年10月已經被視為問題了,上面的留言(1[錨點失效]2[錨點失效])就能證明這點。説真的,我在嘗試搬運討論串以縮減VPP長度後知道你又移回部分討論導致VPP長度再度破20萬時,我是很沮喪的,這相當於我白移動討論串了,於是我就選擇擺爛了,結果VPP的長度又破40萬了,這直接影響了我使用VPP,因此我也不得不停止擺爛,繼續推進此案。要不是我今天再搬運了部分討論串,我相信VPP長度破20萬不成為永遠持續的狀態也很難。Sanmosa 熱烈慶賀「關注度」正名「收錄標準 2025年1月19日 (日) 13:54 (UTC)
方才參照了有關條目內容的討論的發起的規定寫了這個版本。與有關條目內容的討論的發起的規定的主要分別在於有關中文維基百科規則的討論只要不是在VPP進行的都得走RFC,這與有關條目內容的討論不在VPD進行也被限制使用RFC的情況不同。Sanmosa 蘭絮 2025年1月10日 (五) 08:42 (UTC)
WP:共识#一般公示基本規定,現公示此版提案7日。Sanmosa 熱烈慶賀「關注度」正名「收錄標準 2025年1月17日 (五) 01:23 (UTC)

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

能否折叠一下存档

指本页面header中从2003年列到2024年的存档部分。--Fire Ice 2024年10月22日 (二) 15:49 (UTC)

@Fire-and-Ice可以,但互助客棧的其他存檔要嗎?--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨2024年10月22日 (二) 16:40 (UTC)
我认为都需要折叠。--Fire Ice 2024年10月22日 (二) 16:42 (UTC)
全部完成。--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨2024年10月22日 (二) 16:52 (UTC)
知識問答被遺忘了。--Miyakoo留言2024年10月31日 (四) 15:35 (UTC)
照着WP:互助客棧/其他/檔案館改了下。--Miyakoo留言2024年10月31日 (四) 16:00 (UTC)
更新了客棧其他板的存檔摺疊方式,看看會不會比直接整個摺疊更好(?--西 2024年10月23日 (三) 00:42 (UTC)
@LuciferianThomas感覺不錯,可以套用到客棧其他各區(都留下二〇二一年至今討論即可)。—— Eric Liu 創造は生命(留言留名學生會 2024年10月24日 (四) 08:50 (UTC)