维基百科讨论:合并请求
![]() |
本页面曾被多次送交存废讨论。
若要再次提交存废讨论,请先参考下列过往讨论记录: |
关于重复条目的处理程序?
编辑目前乍看之下有点难以理解,有以下几个问题:
- 讨论要有什么样的结果才能付诸执行?
- 投票制?多数决制?票数门槛?
- 如何处理有所回应(例如赞成意见)却没有继续讨论的重复条目申请?
- 谁有权进行条目合并?发起者?管理员?
- “发起讨论->没有回应->没有执行”─是否有这类状况的处理方案?
-DarkRanger 2007年9月4日 (二) 18:47 (UTC)
- 没有人来讨论这个问题吗?现在需要处理的条目积压的越来越多了.SH1019♁Team Radio 2009年1月3日 (六) 16:04 (UTC)
- 偶尔会有人去零星地清一点积压的工作的,但减少的速度远不及新增的快,而且去做清理工作的人,都得面对前面DarkRanger早于2007年9月所提出的问题。更惨的是关心这问题的管理员少(不是没有,不过少^^"),阻挠这工作的白目多,我的合并经常被白目回退(参考楼下的另一项讨论即知)--210.6.97.84 2009年5月9日 (六) 10:28 (UTC)
- 慢慢来,不急着立刻全部完成,我预估我这次清理Category:需要合并的条目出来的东西,需要花上三个月以上来清理吧。如果你进行的合并工作被回退,我也会尽量帮忙和其他人沟通的。-Alberth2-汪汪 2009年5月9日 (六) 12:32 (UTC)
- “如果你进行的合并工作被回退,我也会尽量帮忙和其他人沟通的”←刚才专题选粹服务条目正正又发生这种情况了,看来还是又得麻烦您走一趟当说客了^^"
- 其实我过去也不是没尝试过以沟通解决事情,但成效总是像昨天发生的那件事那样,也许我真的不适宜跟人沟通...-_-210.6.97.127 2009年5月29日 (五) 14:59 (UTC)
移动
编辑有没有哪位能界定一下“Wikipedia:重复条目”、“Category:需要合并的条目”和“Wikipedia:移动请求”三个页面的分工有什么不同?
事缘当我动手合并河南郡、三川郡、迦帕多家教父、加帕多家教父时,却被退回了。
查上述两对条目实为积压已久的“Category:需要合并的条目”,前者(三川郡及河南尹)的合并,更是已在“Wikipedia:重复条目”页面经过长足的讨论而达到共识后才进行的。三川郡及河南尹的合并于2009年1月25日08:54被某用户退回,而该用户的再前一项改动则发生于2009年1月25日08:53,足见该用户在进行退回前,对该两条目的合并的前因后果,不可能有超过一分钟的阅读时间去理解。再查该退回合并的用户的其他“用户贡献”,发现该用户实素有盲目退回的习惯。
然而,当我检举该用户的盲回退回时,又被劝喻说“条目不能手动移动,要由管理员处理。”
我见“Category:需要合并的条目”页面只是挂上“本页面是一个积压的工作,需要老练的用户关注”,并没有说非由管理员处理不可。
结果,要做的没人做,大量积压,去做的被人退回,退回者自己又不做。
如果我每次对前两个页面的条目进行合并,都必须被退回且必须送交“Wikipedia:移动请求”页面处理的话,那么干脆只保留“Wikipedia:移动请求”好了,前两个页面要来干嘛?--210.6.97.145 2009年2月7日 (六) 06:11 (UTC)
- 确实常常有人混淆,不过移动请求和重复条目是完全不同的。移动请求是只有一个条目及内容,当无法移动到新名称时,才需要到移动请求提出;此外,现在也会处理被以剪下贴上移动的条目的编辑历史。由于某些情况下的移动只有管理员可以处理,因此移动请求必须由管理员处理,如果被积压确实是管理员该设法处理。而重复条目则是同时存有两个先后建立的条目,但可能后来被发现其实是可以合并为单一条目,因此要将两个的内容合并,并将其中一个改为重定向页;这种工作其实就不需要管理员的权限就可以进行,任何熟悉维基百科的人都可以处理,只是问题常常在于要如何决定将哪个条目改为重定向页?取得合并的共识也是处理重复条目最难的部分,也因次重复条目会更容易被积压。—Alberth2-汪汪 2009年2月7日 (六) 06:59 (UTC)
- 谢谢回复,那么,套用到河南郡、三川郡、迦帕多家教父、加帕多家教父这几个案例时,应该如何处理才对?我确实是在“Category:需要合并的条目”找到的,也确实被退回了,而该退回动作也被肯定了,是不是又该交由“Wikipedia:移动请求”处理?--210.6.97.145 2009年2月7日 (六) 07:42 (UTC)
- 有时候可能只是误会,或许其他人没注意到该页面已经有合并的讨论及共识,这时候建议可以直接去回退者的对话页提出说明、沟通,应该有助于解决争议。另外,也建议在合并同时善用编辑摘要,让他人知道为何自己要做此修改。因为这些动作并不是在进行条目的移动,因此也不需要到移动请求提出。—Alberth2-汪汪 2009年2月7日 (六) 07:52 (UTC)
- 想问一下,直接手动重定向岂不是让被A条目的原编辑历史停止了?原编辑者的功夫岂不是白费?这种情况不是不应该手动重定向而是由管理员移动再合并编辑历史吗?--91.142.12.62 (留言) 2009年2月7日 (六) 07:58 (UTC)
- 可以参考Wikipedia:合并和移动页面#如何合并页面,在合并两页面时,编辑历史的合并并非是必须的;目前的作法是认为有此需求的话,可以在合并完成后再至移动请求提出,但提出前此两条目必须先将内容整合完成,才能方便管理员进行编辑历史的合并。不过个人并不建议所有合并的条目都将编辑历史合并,因为会产生让编辑历史混乱的问题,可以参考我在Wikipedia:互助客栈/方针/存档/2009年2月#重复条目之编辑历史是否须合并?提出的讨论,如果有任何建议方式也欢迎一起提出。—Alberth2-汪汪 2009年2月7日 (六) 08:19 (UTC)
- 想问一下,直接手动重定向岂不是让被A条目的原编辑历史停止了?原编辑者的功夫岂不是白费?这种情况不是不应该手动重定向而是由管理员移动再合并编辑历史吗?--91.142.12.62 (留言) 2009年2月7日 (六) 07:58 (UTC)
- 有时候可能只是误会,或许其他人没注意到该页面已经有合并的讨论及共识,这时候建议可以直接去回退者的对话页提出说明、沟通,应该有助于解决争议。另外,也建议在合并同时善用编辑摘要,让他人知道为何自己要做此修改。因为这些动作并不是在进行条目的移动,因此也不需要到移动请求提出。—Alberth2-汪汪 2009年2月7日 (六) 07:52 (UTC)
Wikipedia:重复条目/存档/2008年中为什么还有未解决便存档的请求?
遇到内容雷同的两个条目究竟是不是应当到Wikipedia:重复条目提出?我发现我在那里提出的请求,结果无非是(一)没有管理员搭理便被存档;(二)被IP用户或管理员手动合并页面,而且这种手动合并的行为似乎也被其他管理员们所默许。于是,遇到铝热剂和铝热法两个应当合并的条目后,我将铝热剂手动合并到铝热法,并在将 Talk:铝热剂 转移至 Talk:铝热法 后,将其提交快速删除。然而该提删页却被管理员挂上了hangon模板,并被提到了Wikipedia:移动请求,要求“合并编辑历史”,致使两者编辑历史混在一起,甚至出现了我将“铝热法”重定向到“铝热法”的记录,我的编辑被回退,并被恢复,最后的页面历史成了这样。难道管理员认为这样互相交错、混乱不堪的编辑历史才是正确的?铝热剂 只有一个主要贡献用户,其内容也大多与 铝热法 相同,手动合并时编辑摘要中已有记录,如果想要看合并前的页面历史,完全可以去相应的页面历史页中看,两者互不影响,然而合并后页面历史中只有页面移动的记录,并没有合并的记录,管理员们却非要使编辑历史变得凌乱,让看页面编辑历史的人一头雾水。如此双重标准,实在令人费解。—Choij (留言) 2009年2月7日 (六) 09:37 (UTC)
- 你提出的疑问可以分两点来说明:
- 其实Wikipedia:重复条目并不是要由管理员来处理的工作,因为这项工作并不需要管理员的权限,是任何人都可以处理的;而重复条目的合并,确实也就是“手动”将两条目的内容集中在一个上,再将另一个改为重定向。至于未被处理就被存档,你举的例子那就是我的疏忽了......。
- 完成合并后,是否需要将原本的两条目编辑历史跟着合并,这目前尚未有一致的共识,个人也是与你一样认为一般状况下不要合并比较好,因为会让编辑历史交错,难以阅读(可以参考上方“重复条目之编辑历史是否须合并?”一节之讨论);但是还是有许多人认为为了保留两条目所有贡献者的纪录,应该合并。所以才会有人提出将两编辑历史合并的请求,并获得其他管理员的认同并执行。这个议题确实需要更多人一起讨论,寻找一个两全的解决方案。
- —Alberth2-汪汪 2009年2月7日 (六) 13:43 (UTC)
关于合并的讨论
编辑建议所有讨论都到相关条目之讨论页进行,以方便所有关切该条目的用户参予及了解;对于关切Wikipedia:重复条目的用户,如果希望监看列表中所有页面及其相关讨论页的话,可以利用这个连结:http://zh.wikipedia.org/w/index.php?title=Special:链出更改&limit=100&target=Wikipedia:重复条目 —Alberth2-汪汪 2009年5月8日 (五) 10:26 (UTC)
是“合并”还是“二择其一”?
编辑请大家关注,218.250.11.179基本上只是消除了尤纳斯·卡斯劳斯卡斯条目的内容,而不是将之跟尤纳斯·卡兹劳斯卡斯条目“合并”,其中,连出生日期的差异都没有考证--210.6.97.75 (留言) 2009年5月14日 (四) 12:25 (UTC)
- 恩,这确实是疏忽......,感谢你的发现......—Alberth2-汪汪 2009年5月14日 (四) 13:07 (UTC)
- 上海碧云良千足球俱乐部也发生了类似情况--210.6.97.129 2009年5月30日 (六) 12:53 (UTC)
- 上海碧云良千足球俱乐部也发生了类似情况--210.6.97.129 2009年5月30日 (六) 12:53 (UTC)
同样的情况,又发生在内搭裤、紧身裤、无底袜条目了
内搭裤和紧身裤两个条目原有的讯息,在这次和这次都全被删掉了(并不是内容合并),并且重定向到无底袜条目。
问题是,目前无底袜条目的内容,不可等同en:Leggings条目所描述的东西,也不可能涵盖、取代、指称这些图片的东西(这些图片来自被后来无底袜条目抹煞了的内容),因此全盘抹煞这个和这个条目的原本内容,有点粗暴--210.6.97.203 2009年8月31日 (一) 07:33 (UTC)
东区体育会和东区足球队
编辑观看编辑历史,这两个条目好像已曾经被合并过,如果是这样的话,即使用我们现在动手合并,会不会再被马上退回,引发编辑战?(羊城条目也是) btw,能否就伊莱恩条目的页面存废讨论给点意见?--210.6.97.246 2009年5月28日 (四) 08:23 (UTC)
- Talk:羊城里并没有明确的共识,所以在未有共识之下合并,被回退其实不意外。至于东区体育会和东区足球队,在他们的讨论页上问问好了—Alberth2-汪汪 2009年5月28日 (四) 08:49 (UTC)
- 说的也是,那还是别沾手好了...
- 唉,所以说,有时不是不想帮忙清理积压工作,无奈顺得哥情失嫂意...-_- 210.6.97.246 2009年5月28日 (四) 09:10 (UTC)
好好墓
编辑“好好墓”实非“妇好墓”的别称,而是个纯粹字误。大家可以先详阅妇好墓条目,看看“妇好”所指的是什么,再用“好好墓”做关键字搜寻一下,即知所言非虚。
因此,“好好墓”宜删除,而非用作“妇好墓”的重定向页,尚祈亮察。
btw,Wikipedia:页面存废讨论/记录/2009/06/21中,曹国雄条目的存废记录虽被Jimmy Xu君注上已删除字样,但条目目前其实还没被删除。--210.6.97.182 2009年7月1日 (三) 03:54 (UTC)
- 好好墓改为重定向算是讨论出的共识,虽然共识的内容不一定正确,如果要删除可能需要再提一次存废讨论。而曹国雄确实已经被删除,但是原创者不死心又重新建立了一次,同时又被其他用户改善了内容,故已不适用于快速删除的标准。—Alberth2-汪汪 2009年7月1日 (三) 04:02 (UTC)
- 好好墓是错误的名称,重定向只会招来人们的笑话。--58.152.239.160 (留言) 2009年7月1日 (三) 04:04 (UTC)
有合必有分
编辑既有了把重复条目合并的讨论页面,想问问,维基有没有把条目分割的专门讨论页面?口罩条目就好像有这个需要了。
btw,“叶调”和“葉調”的情况,应该交去建议合并还是交去移动请求才对?--210.6.97.234 2009年7月5日 (日) 09:17 (UTC)
- 这要合并编辑历史,目前是在移动请求中处理。至于分割?目前好像只有Category:需要分割的条目—Alberth2-汪汪 2009年7月5日 (日) 15:30 (UTC)
- 如果我只是简单地把“叶调”重定向到“葉調”,这可以吗?--210.6.97.254 2009年7月6日 (一) 04:23 (UTC)
- 看起来应该是没问题,另外就是记得在编辑摘要中说明编辑原因吧~~—Alberth2-汪汪 2009年7月6日 (一) 05:18 (UTC)
- 如果我只是简单地把“叶调”重定向到“葉調”,这可以吗?--210.6.97.254 2009年7月6日 (一) 04:23 (UTC)
- 那么我就这么办好了 ^_^ --210.6.97.120 2009年7月6日 (一) 11:28 (UTC)
还没合并就删除
编辑- 人脸识别软件(讨论) → 人脸识别:由User:210.6.97.11建议合并之条目。—Alberth2-汪汪 2009年8月5日 (三) 03:07 (UTC)
- 嘉诺撤圣家书院(讨论) → 嘉诺撒圣家书院:由User:210.6.97.11建议合并之条目。—Alberth2-汪汪 2009年8月5日 (三) 03:07 (UTC)
↑怎么嘉诺撤圣家书院和人脸识别软件还没合并就删除了?--202.155.238.68 (留言) 2009年8月11日 (二) 11:07 (UTC)
- 抱歉,执行删除时忘了补上理由。人脸识别技术的原内容非虚无空洞,实在有点像教人如何坐椅一样。这样的内容合并至另一条条目,无疑只会降低那一条条目的质素。故本人决删除并不予合并。与有反对,欢迎提出。—J.Wong 2009年8月12日 (三) 10:10 (UTC)
- 人脸识别技术是这情况,不过嘉诺撤圣家书院呢?--210.6.97.103 2009年8月13日 (四) 08:59 (UTC)
- 后者内容包含前者,故直接删除。—Wcam (留言) 2009年8月14日 (五) 04:08 (UTC)
- 人脸识别技术是这情况,不过嘉诺撤圣家书院呢?--210.6.97.103 2009年8月13日 (四) 08:59 (UTC)
这个存废讨论中,有用户提出:“合并后重定向”应去WP:合并请求进行讨论,而非在存废讨论进行。而WP:AFD中也有“如果您可以改善条目,请不要犹豫。同时,你可以选择:重定向、重命名、与其他条目合并、回退、或索性加入清理、小小作品限期改善模版。”,故此类合并讨论确实不应在存废讨论进行。然而:
- 在4月7日的存废讨论记录中有非常多的可以“合并后重定向”的讨论,之前的存废讨论亦没有明确的拒绝合并讨论进入的情况。
- WP:合并请求中的讨论不了了之者居多,很多被提出合并的条目几个月后仍然保持原状,该页面似乎少有人关注。
- 提交存废讨论的入口允许提交合并请求,而未指明合并后是否要删除原页面。(存废讨论中的{{合并}}意义不明)
因此提出以下方案:
- 所有不涉及删除页面的讨论都不要提交到存废讨论(例如“合并后重定向”就不需要删除页面)
- 在WP:AFD和Twinkle中增加合并页面的引导。(TW中目前是挂合并模板,然后在讨论页讨论,不了了之的也很多)
或:
- 允许合并讨论进入AFD
我个人认为后一种方案可行度较高:条目讨论页与合并请求的讨论难以引起关注,全放在互助客栈讨论也不现实。希望社群能在此得到共识,明确存废讨论的适用范围。--Tiger(留言)DDL是第一生产力 2017年4月8日 (六) 00:03 (UTC)
- (!)意见虽然tw工具里提删里面有合并...,除了内容一样我会手动合并,如内容不同自己亦不熟该领域就会丢讨论例如音乐名词。-Zest2017年4月8日
- (!)意见:反对把合并讨论放进存废讨论,不能为了所谓获得关注就把不相关的内容都放到存废讨论中来。合并问题放在条目讨论页足矣,没人反对的话提议合并者就可以合并。放到存废讨论中有时执行者会莫名其妙地把本该保留重定向的被合并页也删除了,或者把不该合并编辑历史的页面合并编辑历史,造成更多混乱。英文维基就不会把合并讨论放到存废讨论中来。--Pengyanan(留言) 2017年4月8日 (六) 04:56 (UTC)
- 提议者手动合并的话,编辑历史会分散两地,形成WP:剪贴移动。若是放在存废讨论,则可以让管理员来做,而把编辑历史合并--Liaon98 我是废物 2017年4月10日 (一) 04:54 (UTC)
- (:)回应:如果是两个独立编辑的条目,那么就该采用剪切粘贴方式进行合并(见Wikipedia:合并和移动页面),本来就不该合并页面编辑历史,英文维基只对“以剪切粘贴方式移动条目”这一种情况合并页面编辑历史。对两个独立编辑的条目,如果也合并页面编辑历史,只会使新条目的页面编辑历史混乱不堪,让后人查看页面编辑历史版本比较时感到困惑,不明白前人为何如此修改。我是非常反对这种合并页面编辑历史的的做法的,希望中文维基在这一点上能学习英文维基的经验(参见en:Wikipedia:Requests for history merge)。--Pengyanan(留言) 2017年4月12日 (三) 00:28 (UTC)
- 大部分在存废讨论的合并,很多时候是提出删除,然后最后意见是合并....--百無一用是書生 (☎) 2017年4月10日 (一) 04:04 (UTC)
- (!)意见 存废讨论中的合并,应视为解决删除以外的选择。--Nivekin※请留言 2017年4月10日 (一) 06:00 (UTC)
- 个人认为结论是合并的话,应以转介的认识交给合并请求重新处理,就如关注度一样。—AT 2017年4月10日 (一) 06:03 (UTC)
- (:)回应 其实如结案的管理员不动手作合拼的话,其他的非管理员编辑是无法完全地合并编辑历史的;“以转介的认识交给合并请求重新处理”,其实现况即是不了了之,根本没有任何一位管理员负责。--Nivekin※请留言 2017年4月10日 (一) 07:37 (UTC)
- 现实问题是对于自己不熟悉的领域,经常不知道该如何合并。所以交给管理员来合并不是办法啊。或者任何人合并完内容后,以模板或其他形式通知管理员帮助合并历史,可能会比较容易一些(其实看英文wiki,也是会有常年挂着合并模板的页面....)--百無一用是書生 (☎) 2017年4月10日 (一) 07:51 (UTC)
- 比较喜欢楼上的意见,有可操作性。不过有这样的模版吗? --砜中嘌呤的白磷萃取 打谱 2017年4月11日 (二) 03:14 (UTC)
- (!)意见:中文维基目前经常滥用合并页面编辑历史。Wikipedia:合并和移动页面里面说的很清楚,合并应采用剪切粘贴方式,并在编辑摘要中加以注明,但为什么目前中文维基普遍在合并时也合并页面历史?英文维基只是对“以剪切粘贴方式移动条目”这一种情况才合并页面编辑历史,而在合并独立编辑的条目时采用剪切粘贴的方式,但中文维基却经常在合并两个本来是独立编辑的条目时,也合并页面编辑历史,这样反而使页面编辑历史混乱不堪,后人在看页面历史时,会觉得不知所云。甚至当A条目内容是B条目的一个章节,在把A条目合并进B条目后,中文维基居然有时也把A的页面编辑历史合并进B,这就更错到离谱。希望中文维基能学习一下英文维基的经验(参见en:Wikipedia:Requests for history merge),在合并两个独立编辑的条目时以剪切粘贴方式进行,不要再合并页面编辑历史。--Pengyanan(留言) 2017年4月12日 (三) 00:17 (UTC)
- 规则应该看它背后的原则,而不是只看着英文维基上的规则文字来论述。保留编辑历史原因是为了让贡献者的授权保留住,比编辑历史乱成一团更重要。但你可以从别的角度反对,例如合并后,讨论页有“合并自XX条目”的模板,是否这个模板就有代表贡献者授权来自这个XX条目的编辑历史,而不需要把编辑历史搬过来之类的。而不是单纯的说英文维基这样做就这样,我想英文维基应该也有过类似的讨论当是。--Liaon98 我是废物 2017年4月12日 (三) 09:03 (UTC)
- (:)回应,我一直在论证原则,而不是只看英文维基上的规则文字,实际上英文维基根本没说为什么合并两个独立编辑的条目时不能合并页面编辑历史,论证内容都是我自己的理解。您可能没有仔细区分“保留”编辑历史和“合并”编辑历史这两个概念。以剪切粘贴方式合并也能“保留”编辑历史,被合并条目编辑者的贡献依然都“保留”着,并没有抹杀任何编辑者的贡献(只要不把条目整个删除,编辑历史都是“保留”的),Wikipedia:合并和移动页面也明确规定以剪切粘贴方式合并条目。“合并”编辑历史只是为了让编辑历史清晰体现编辑脉络,方便后来者清晰了解前人编辑的来龙去脉,因此“合并”编辑历史只应是为了纠正“以剪切粘贴方式移动条目”这种情况。对两个独立编辑的条目,以剪切粘贴方式合并,通过挂合并模板、页面讨论页讨论、在编辑摘要中注明等方式,后人更能清楚了解编辑脉络,而如果把两个独立编辑的条目的编辑历史也合并,则反而会让后人无法理解前人的编辑脉络。--Pengyanan(留言) 2017年4月12日 (三) 10:15 (UTC)
- 编辑历史不仅仅是要看整个编辑脉络,还有包含这个内容是由哪个贡献者授权的,以符合CC协定,这是维基媒体一直很重视的版权问题;这也是为什么剪贴移动被禁止的主因;WP:在维基百科内复制内容也有提到这些。所以我才说问题是在如果只留一个模板说是合并于何处,这是否有符合CC授权。另外有些情况,甚至原本合并的条目都被删掉的,连编辑历史都不留的--Liaon98 我是废物 2017年4月12日 (三) 12:14 (UTC)
- (:)回应:请您注意区分“移动”和“合并”这两个不同的概念,用剪切粘贴方式“移动”条目是禁止的,但用剪切粘贴方式“合并”条目是合理的(见Wikipedia:合并和移动页面),Wikipedia:在维基百科内复制内容也只是要求复制时在编辑摘要中注明,而不是合并页面编辑历史。对“合并页面内容”来说,在编辑摘要中注明、加合并模板已经足以表明内容是由哪些贡献者授权的;而“合并编辑历史”,只是为了便于查看编辑脉络,因此只应该用于纠正“以剪切粘贴方式移动条目”这种情况。合并页面内容,必须要手动把两个页面的内容真正融合在一起,这是无法通过合并页面编辑历史来实现的,保留被合并条目的独立性,才能方便人们查看两个条目是如何合并的(内容出自被合并条目的最后版本),而如果把两个条目的编辑历史也合并了,则反而让人很难找到合并的内容来自哪里(两个条目的各自编辑历史都混到一起去了)。另外,删除被合并的条目也是不合理的(应该保留重定向),而把合并讨论提交到页面存废讨论中来,就容易造成删除被合并条目这种错误的做法,我在本讨论一开始也指出了这一点,并据此反对把合并讨论放进页面存废讨论中来。--Pengyanan(留言) 2017年4月12日 (三) 12:31 (UTC)
- (!)意见同Pengyanan,据我一向来的理解,合并条目时应将被重定向的页面历史原地保留,只需在编辑注释中注明原文来自哪个重定向页,一来可以保持重定向页的历史原貌,二来万一有天翻案必须重新分开时,只需简单回退即可。(这点在物种条目,次异名变有效名的情况随时发生)。记得某管理员说过,合并编辑历史很容易,可是要重新分开就困难了,所以尽可能不合并编辑历史。只有违规的剪贴移动(然后有后来者在不知情的情况下继续编辑),造成编辑史断裂,才需动用管理员的“合并编辑历史”权限。——♠白布¤飘扬§§ 2017年4月23日 (日) 00:40 (UTC)
- 编辑历史不仅仅是要看整个编辑脉络,还有包含这个内容是由哪个贡献者授权的,以符合CC协定,这是维基媒体一直很重视的版权问题;这也是为什么剪贴移动被禁止的主因;WP:在维基百科内复制内容也有提到这些。所以我才说问题是在如果只留一个模板说是合并于何处,这是否有符合CC授权。另外有些情况,甚至原本合并的条目都被删掉的,连编辑历史都不留的--Liaon98 我是废物 2017年4月12日 (三) 12:14 (UTC)
- (:)回应,我一直在论证原则,而不是只看英文维基上的规则文字,实际上英文维基根本没说为什么合并两个独立编辑的条目时不能合并页面编辑历史,论证内容都是我自己的理解。您可能没有仔细区分“保留”编辑历史和“合并”编辑历史这两个概念。以剪切粘贴方式合并也能“保留”编辑历史,被合并条目编辑者的贡献依然都“保留”着,并没有抹杀任何编辑者的贡献(只要不把条目整个删除,编辑历史都是“保留”的),Wikipedia:合并和移动页面也明确规定以剪切粘贴方式合并条目。“合并”编辑历史只是为了让编辑历史清晰体现编辑脉络,方便后来者清晰了解前人编辑的来龙去脉,因此“合并”编辑历史只应是为了纠正“以剪切粘贴方式移动条目”这种情况。对两个独立编辑的条目,以剪切粘贴方式合并,通过挂合并模板、页面讨论页讨论、在编辑摘要中注明等方式,后人更能清楚了解编辑脉络,而如果把两个独立编辑的条目的编辑历史也合并,则反而会让后人无法理解前人的编辑脉络。--Pengyanan(留言) 2017年4月12日 (三) 10:15 (UTC)
- 规则应该看它背后的原则,而不是只看着英文维基上的规则文字来论述。保留编辑历史原因是为了让贡献者的授权保留住,比编辑历史乱成一团更重要。但你可以从别的角度反对,例如合并后,讨论页有“合并自XX条目”的模板,是否这个模板就有代表贡献者授权来自这个XX条目的编辑历史,而不需要把编辑历史搬过来之类的。而不是单纯的说英文维基这样做就这样,我想英文维基应该也有过类似的讨论当是。--Liaon98 我是废物 2017年4月12日 (三) 09:03 (UTC)
- 现实问题是对于自己不熟悉的领域,经常不知道该如何合并。所以交给管理员来合并不是办法啊。或者任何人合并完内容后,以模板或其他形式通知管理员帮助合并历史,可能会比较容易一些(其实看英文wiki,也是会有常年挂着合并模板的页面....)--百無一用是書生 (☎) 2017年4月10日 (一) 07:51 (UTC)
- (:)回应 其实如结案的管理员不动手作合拼的话,其他的非管理员编辑是无法完全地合并编辑历史的;“以转介的认识交给合并请求重新处理”,其实现况即是不了了之,根本没有任何一位管理员负责。--Nivekin※请留言 2017年4月10日 (一) 07:37 (UTC)
合并讨论要在哪里发起
编辑目前{{subst:mergefrom/auto|另外的条目}}、{{subst:mergeto/auto|另外的条目}}将讨论连结到talk:留下的条目,而维基百科:合并请求#说明说新增请求时,讨论要连结至Talk:合并走的条目,是否予以统一?--Towatw(留言) 2017年6月9日 (五) 08:00 (UTC)
合并历史是否有相关指导?
编辑经过搜索,似乎没有在Wikipedia名字空间看到有关合并历史的说明,只有一个空章节。请问:
- 合并历史须满足怎样的条件才可进行?
- 何种情况需要合并历史?
--Tiger(留言) 2017年8月7日 (一) 01:14 (UTC)
- 有英文版本,连结在“翻译中”的模板中,可参考英语版。--AndyAndyAndyAlbert(留言) 2017年8月7日 (一) 07:02 (UTC)
合并条目
编辑此讨论是关于是否将合并请求合并至存废讨论,源于我曾经把一些在存废讨论提交的合并请求转至WP:PM。希望大家能多多给予意见。— 卍・〇・卐 2018年3月5日 (一) 10:43 (UTC)
背景
编辑建议让讨论在存废讨论那边进行7天,管理员结案后再转交到合并请求。现在合并请求那里没有经过讨论的请求,除非一目了然,否则很难处理。而存废讨论关闭后,很少会有人来参与讨论了。--Tiger(留言) 2018年3月4日 (日) 02:59 (UTC)
- @Tigerzeng:其实一开始就是提合并,又为什么要提存废讨论?这未免有些无谓。— 卍・〇・卐 2018年3月4日 (日) 03:05 (UTC)
- 然而有些页面可能由于不熟悉,导致没有合并,故仍倾向提存废讨论后管理员若基于原因无法合并页面,转交合并请求。-- Willy1018(留言) 2018年3月5日 (一) 14:32 (UTC)
提案
编辑不如索性把合并请求并入存废讨论吧,这样可以统一集中处理,而没有争议的合并提案可标记为管理员积压工作,需要处理。存废讨论结果模板标记则可为“正在等候合并”,直至合并完成为止,惟原有的{{merge}}、{{mergefrom}}和{{mergeto}}模板则予以保留,但原本连结至其讨论页的连结则改为连结至存废讨论,而原有“讨论”字样将予以保留。@Moonian、Tigerzeng、WQL、淺藍雪、Outlookxp、@Richard923888、百战天虫、Cwek、*angys*、Iokseng、@KirkLU、MCC214:不知诸君意见如何?— 卍・〇・卐 2018年3月4日 (日) 05:48 (UTC)
- 别这样ping啊喂。之前有在合并请求见过存废讨论过七天存废结束以后,管理员关闭讨论,并说“自行合并”的。有些是完全没有讨论,只是在条目里挂了个merge模板的(甚至挂了只挂了模板没有提交到合并请求的也有。--Tiger(留言) 2018年3月4日 (日) 05:57 (UTC)
- @Tigerzeng:下次不会的了。— 卍・〇・卐 2018年3月4日 (日) 06:05 (UTC)
- 我觉得不错,其实存废讨论那边处理合并的人也不多浅蓝雪❉ 2018年3月4日 (日) 11:47 (UTC)
- 我反而建议集中在合并请求处理以方便处理,讨论七日。然后由愿意处理的管理员结束。--M.Chan 2018年3月5日 (一) 10:46 (UTC)
- 然而wp:PM根本没人看……--【和平至上】💬📝 2018年3月5日 (一) 11:20 (UTC)
- @和平至上:要wp:PM有人看的话,就须作诚如M.Chan君所言般的大幅政革了。我一开始之所以大量地转介至合并请求也是如M.Chan君所想,使合并请求能用得其所,但因为最近引起了争论,故个人认为如果作出的改动能够不影响维基人的习惯,则应实行该改动。— 卍・〇・卐 2018年3月5日 (一) 11:34 (UTC)
- 没人看的话,可以在条目创建者留言,并在条目中加上通往合并请求的连结,可能会多些人看。--M.Chan 2018年3月5日 (一) 13:19 (UTC)
- @Michael Chan:问题在于提合并者仍倾向用存废讨论提合并。既然有倾向如此,同时亦可减省程序(可以直接操作重定向,又可以直接操作合并,不用转介),为何不直接把合并请求并入存废讨论呢?— 卍・〇・卐 2018年3月5日 (一) 13:33 (UTC)
- Sanmosa君:方便区分。--M.Chan 2018年3月5日 (一) 13:36 (UTC)
- @Michael Chan:其实现在我的提议就是想把合并请求和存废讨论索性混为一谈,反倒能减省程序,符合雪球法则的精神,不过不直接以雪球法则显现而已。— 卍・〇・卐 2018年3月5日 (一) 13:43 (UTC)
- 这样也可以。--M.Chan 2018年3月5日 (一) 14:17 (UTC)
- 这样需要完全废弃{{merge to}}等与合并有关的模板,并修改相关项目页面哦。我认为也可以将WP:合并请求当作已有合并共识的待合并页面的记录,可接受包括存废讨论在内的各处讨论的合并共识。--Tiger(留言) 2018年3月6日 (二) 13:49 (UTC)
- merge to}}等模板,不过就变成了{{afd}}的变种了。修改相关项目页面反而是一定的了。第二个提议也不错。— 卍・〇・卐 2018年3月6日 (二) 14:30 (UTC) 其实不需要废弃{{
- (+)支持WP:PM与WP:AFD合并。--MCC214强烈要求维基条目宁缺勿滥#我做了什么? 2018年3月12日 (一) 10:47 (UTC)
- (+)强烈支持:WP:PM和WP:AFD合并处理。感觉合并请求的处理效率太低了。--星源动力Talk 2018年3月18日 (日) 08:05 (UTC)
- 这样需要完全废弃{{merge to}}等与合并有关的模板,并修改相关项目页面哦。我认为也可以将WP:合并请求当作已有合并共识的待合并页面的记录,可接受包括存废讨论在内的各处讨论的合并共识。--Tiger(留言) 2018年3月6日 (二) 13:49 (UTC)
- 这样也可以。--M.Chan 2018年3月5日 (一) 14:17 (UTC)
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
...这个页面的这个模板:
本服务自2019年1月29日起关闭,请移步至此页面提请。 |
[[Wikipedia:頁面存廢討論/記錄/{{#time:Y/m/d}}|此頁面]]: 这一行会连接至UTC+0日期的存废讨论,以至于现在连到的是1月30日的存废讨论...--MeritTim(留言-给予警告) 2019年1月31日 (四) 05:31 (UTC)
- UTC+0没错。--Zest 2019年1月31日 (四) 15:54 (UTC)
- @MeritTim:存废讨论的时间都是以 UTC 为准,即是说如果在 2019/02/01 04:00 (UTC+9) 提删页面,则应到 2019/01/31 的页面。- まっすろな未来 2019年2月1日 (五) 07:54 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
鉴于Wikipedia:合并请求和Wikipedia:移动请求的使用率不高,现发起社群调查
编辑一、如果您要移动一个页面,您会先上手操作,还是先提起移动请求?
二、如果您要提起一项有关合并两个页面的讨论,你会去对应条目的讨论页面提起合并请求,还是提起页面存废讨论选择“(±)合并”选项?
--云间守望 2019年1月29日 (二) 03:24 (UTC)
- 如果是不合命名常规等会直接移动,目标页面存在才挂移动请求;如果条目主体是完全一样的东西送合并请求,类似条目改放AFD选(±)合并--Suaveness(对话.贡献) 2019年1月29日 (二) 05:52 (UTC)
- 见Wikipedia_talk:合并请求,将会挂上历史模板,与afd合并。 Willy1018(留言) 2019年1月29日 (二) 06:04 (UTC)
- 移动请求均是靠模板进行维护,亦即Template:Bulletin中的x个移动请求正在讨论。 Willy1018(留言) 2019年1月29日 (二) 06:13 (UTC)
- 移动的目标页面如果未建立,我会自行移动;有了的话就私下找管理员,实在不行再使用标题这两个页面。存废讨论用的不多。--玉环文旦专卖店 (顾客登记|进店咨询·台州专题) 2019年1月29日 (二) 06:15 (UTC)
- 去年倒是有一个讨论:Wikipedia_talk:页面存废讨论#修订不合逻辑的管理员操作方式,看有没有人愿意ping一下-- Sunny00217 --维基餐厅开幕了,欢迎参观。 2019年1月29日 (二) 10:03 (UTC)
- 有关移动,若可以自行移动,又没什么争议的会直接进行。合并的话,曾在Wikipedia:合并请求提过请求,好像列在页面存废讨论会比较多人处理。--Wolfch (留言) 2019年1月29日 (二) 10:13 (UTC)
- 同Wolfch,我也自己处理过几个案例,有明显很多反对的,于是我驳回了移动请求,有没争议的,于是我直接移动(如果未能移动覆盖重定向的话,幸好我有移动不留重定向功能,我先把重定向移去一个临时名称就好)。SænmōsàThe Trve Lawe of free Monarchies 2019年1月29日 (二) 10:42 (UTC)
- 个人觉得除非无争义但没能力处理的再提交到合并请求和移动请求就好。其余的丢存废-- Sunny00217 --维基餐厅开幕了,欢迎参观。 2019年1月30日 (三) 08:26 (UTC)
- (※)注意:合并请求已经关闭。ΣανμοσαThe Trve Lawe of free Monarchies 2019年2月2日 (六) 02:31 (UTC)
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
虽然合并请求和页面存废讨论已经在1月合并,但是在实务操作上,如果要在AFD提出合并请求,预设的做法是删除条目,不可以用其他没那么带刺的方法申请合并。最近提出合并请求的时候,首先是机器人不认受{{Mergeto}}的地位,认为{{VFD}}才是有效的提删模板,然后其他用户也以“没有悬挂‘有效的提删模板’”为由,否决我的合并请求。虽然我已经表示反对否决,不过估计以这个情况来看,保留的机会率非常高。
我在这里就是看,能不能够做得好一点。有时候仅仅是内容整合,本来的条目不至于删除,而是可以保留作重定向。看看我们能不能:
--春卷柯南编辑数突破二万 ( 论功行赏·刻石留名 ) 2019年4月19日 (五) 08:29 (UTC)
- 个人认为页面存废讨论的应该使用
{{vfd}}
或新建其他模板,ex:Draft:Template:Merge_to-- Sunny00217 2019年4月19日 (五) 14:40 (UTC)- 能否{{VFD}}加一个参数?然后使得其显示为这个模板并且加入分类--及时雨 留言 2019年4月19日 (五) 14:55 (UTC)
- 技术上可行,基本上只要在{{vfd}}加入以下参数:“merge|合併|合并=Merge to”,并把Draft:Template:Merge to移动至Template命名空间即可,但还是要Twinkle配合,以及微调机器人设定。Σανμοσα y=0 regardless the value of x 2019年4月19日 (五) 15:06 (UTC)
- 在此邀请Xiplus参与讨论。Σανμοσα y=0 regardless the value of x 2019年4月19日 (五) 15:06 (UTC)
- 能否{{VFD}}加一个参数?然后使得其显示为这个模板并且加入分类--及时雨 留言 2019年4月19日 (五) 14:55 (UTC)
- 其实为什么要将合并请求提交到存废讨论……这岂不增加存废讨论积压?如果确实需要社群参与,还不如提案到互助客栈条目探讨区。--J.Wong 2019年4月20日 (六) 05:40 (UTC)
- 因为合并请求已经废止了。Σανμοσα y=0 regardless the value of x 2019年4月20日 (六) 07:16 (UTC)
- 之前的原因好像是合并请求效率过低,聊胜于无,合并到AFD可以方便处理。--春卷柯南编辑数突破二万 ( 论功行赏·刻石留名 ) 2019年4月20日 (六) 10:43 (UTC)
- 但存废讨论不是这样用呀……存废讨论应该专注于讨论页面是否需要删除。缺人处理不是合并理由……如果情况确实复杂,应该提到条目探讨区。--J.Wong 2019年4月20日 (六) 11:11 (UTC)
- 效率低的不是特定页面,而是合并这个动作本身。把合并处理移到PFD不会让合并变得更高效,只会让PFD变得效率低下。 --达师 - 370 - 608 2019年4月20日 (六) 13:09 (UTC)
- 认同达师君,而且合并请求亦不应该过于依赖管理员处理。--J.Wong 2019年4月20日 (六) 13:18 (UTC)
- 但是这样不就需要推翻之前的共识,不妥吧?--Cohaf(talk) 2019年4月20日 (六) 14:24 (UTC)
- 共识会改变,没什么不妥。而且之前讨论亦不周,没考虑到效率低之真正原因,只是见到有积压,然后就想办法把积压从这里扫到另一处。个人不相信这样就能解决合并积压。这个合并根本就奇奇怪怪,治标不治本,还有点自欺欺人。--J.Wong 2019年4月21日 (日) 00:38 (UTC)
- 推翻共识没有不妥,毕竟共识会随着时间改变,但是推翻仅1个月经过投票取得的共识略不妥,以及AFD也处理了1个月而已。现在没人说问题解决了,回应下方,但是只是为了模版问题需要调整其它方针,所以建议做调整,其余就运行多一些时间才调整在我看来没有不妥之处。@Wong128hk:。--Cohaf(talk) 2019年4月21日 (日) 06:12 (UTC)
- 随随便便翻一翻Wikipedia:页面存废讨论/积压讨论都能见到不少合并请求积压超过一个月。所以问题解决了?--J.Wong 2019年4月21日 (日) 00:49 (UTC)
- 集中讨论反而能暴露一些问题,就是合并请求没有管理员处理而已。--悔晚齋(臆語) 2019年4月21日 (日) 05:09 (UTC)
- 合并过程中其实甚少需要动用管理员权限,所以说回来是为什么要管理员处理?所以问题是没有人关注及处理,而不是没有管理员处理。--J.Wong 2019年4月21日 (日) 05:39 (UTC)
- 类似历史合并,移动至有一些编辑数量的重定向(需要G8)等?--Cohaf(talk) 2019年4月21日 (日) 06:15 (UTC)
- 其实历史合并是移动请求,关于合并历史的请求,其页面历史合并技术上是以时间排序,故如若2页面时间部相邻合并起来时间混乱,合并起来就会像是破坏一样。 Willy1018(留言) 2019年4月21日 (日) 06:19 (UTC)
- Willy1018君所言甚是。历史合并完其实比没合并还差,整个历史沿革就会断开,然后就会丧失意义。最后看上去就是messy。--J.Wong 2019年4月21日 (日) 06:35 (UTC)
- 非常同意。我有见过效果。我这里只是说有可能使用管理员权限的部分,非全部合并都需要历史合并,这个是确定的事情。我也当然了解。--Cohaf(talk) 2019年4月21日 (日) 06:46 (UTC)
- 参阅过讨论存档12号及14号,虽参与者不少,但问题在从没考虑过效率差是因为合并过程及讨论本身就可以非常费时,亦非一键解决,当中变数其多,牵涉很多编辑技巧及判断。有些条目亦需要熟习相关领域的编者才能决定。本站有海量条目挂有模板,标示有问题需要解决,而合并请求与之其实无异。唯一分别就是合并请求有专页罗列。如此合并只是将积压由一处扫往另一处,而根本无法根治问题。跟因为见到某问题标示模板有很多链入,而决定删去模板一样,根本在自欺欺人,掩耳盗铃。如此决定根本思虑不周,亦令资讯不再集中。就算真的有有心人想协助解决合并积压,亦难以协助,还要花时间于存废积压中将请求逐页逐页找。如此,问题只会更为严重。上述14号讨论仅仅维持四日,亦未有明确通知,有否发过公告?有否公示?如此推翻决定,请问会有何不妥之处?--J.Wong 2019年4月21日 (日) 07:16 (UTC)
- 然后就是如此合并会打乱程序。原本存废讨论应该就是讨论页面应否删除,偶然会有条目可能其实毋须删除而转为以合并解决,但第一目标仍然应该在讨论页面应否删除。如果合并请求亦提案至存废讨论,如此一来,存废复核是否需要去处理这些合并请求复核?但这些页面本来就不会经存废讨论合并,不是那种临界条目。如此一来,不是增加了存废讨论及存废复核负担么?存废复核亦非复核编辑决定之所。又,其实合并请求应该承接存废讨论、存废复核之条目合并请求。亦应该提供场地供社群行使合并权力,《关注度指引》就明订就算条目有来源符合段二要求,社群仍可藉讨论达成共识以合并条目。存废讨论及存废复核可以决定条目是否有关注度。但既然存废讨论及存废复核已经决定条目是否有关注度。就没道理又在存废讨论及存废复核继续打转,去决定条目是否合并,而应该移师合并请求或者互助客栈条目探讨区。而且如此合并亦会吓坏新人或者不谙程序者,存废讨论及存废复核还是应该单纯一点,只处理及讨论应否删除条目。其余编辑判断,请另觅他处进行讨论。--J.Wong 2019年4月21日 (日) 07:44 (UTC)
- 因为合并请求已经废止了。Σανμοσα y=0 regardless the value of x 2019年4月20日 (六) 07:16 (UTC)
- 感谢Wong128hk的说明,可以请执行这个编辑的Willy1018解释为何没有公示就改?以及附送说明关闭的Sanmosa,请看看以上并且回应。感激。--Cohaf(talk) 2019年4月21日 (日) 07:48 (UTC)
- 已有进行公示,请见公告栏存档。 Willy1018(留言) 2019年4月21日 (日) 08:47 (UTC)
- 在下只找到“[公告] 合并请求依据先前讨论已经关闭。2019年02月05日, 星期二 (2个月16日前), 12:47 pm (UTC+8)”,是这个么?但在实行之前,有没有公告过?在相关讨论串表明公示开始?--J.Wong 2019年4月21日 (日) 09:09 (UTC)
- 是的,请见WT:合并请求#鉴于Wikipedia:合并请求和Wikipedia:移动请求的使用率不高,现发起社群调查、Wikipedia_talk:合并请求#WP:合并请求与存废讨论之{{合并}}、WT:合并请求#合并条目,这三个讨论共识均是关闭该计划。 Willy1018(留言) 2019年4月22日 (一) 13:38 (UTC)
- 多次讨论又或者多次计划不代表思虑周详,亦不代表已经处理弊端。当中,[[Wikipedia_talk:合并请求#WP:合并请求与存废讨论之(±)合并|二○一七年四月讨论]],AT君就曾经说过︰“个人认为结论是合并的话,应以转介的认识交给合并请求重新处理,就如关注度一样。”只可惜未有进一步论述。--J.Wong 2019年4月28日 (日) 13:24 (UTC)
- 是的,请见WT:合并请求#鉴于Wikipedia:合并请求和Wikipedia:移动请求的使用率不高,现发起社群调查、Wikipedia_talk:合并请求#WP:合并请求与存废讨论之{{合并}}、WT:合并请求#合并条目,这三个讨论共识均是关闭该计划。 Willy1018(留言) 2019年4月22日 (一) 13:38 (UTC)
- 若要调整合并请求的处理方式,不要在存废讨论中进行,现有存废讨论中的合并请求是否可以仍依旧方式进行?(我在2019年1月在Wikipedia:合并请求/存档/2019年提出将注意力不足过动症的非药物治疗合并到注意力不足过动症的治疗,后来改到存废讨论中进行,我因故延至3/4才在Wikipedia:页面存废讨论/记录/2019/03/04提出合并讨论,目前尚未通过 囧rz...,若又要更动处理方式,我怕又要再等一段时间了)。--Wolfch (留言) 2019年4月21日 (日) 14:14 (UTC)
- 已发至存废讨论者就继续在存废讨论处理吧。--J.Wong 2019年4月21日 (日) 16:38 (UTC)
- @Wong128hk:那现在要怎么处理这个问题?稍后再议? -- Sunny00217 - 2019年4月28日 (日) 12:22 (UTC)
- 打算正式动议,推翻二○一九年二月讨论,重启Wikipedia:合并请求。原打算明日提案,明日才够七日。--J.Wong 2019年4月28日 (日) 13:24 (UTC)
- 基于社群惯性(Inertia),我不认为再度分立是好事。社群由始至终根本不认为合并请求能做些什么,提出合并全是交到AFD,合一的目的并不是为了增加效率,而是为了迎合惯性。Σανμοσα y=0 regardless the value of x 2019年5月1日 (三) 10:28 (UTC)
- 但这个惯性有明显问题,为什么不是予以纠正,反而去迎合这个惯性呢?不太合逻辑。所谓“社群惯性”不能解释“不认为再度分立是好事”,请提供更多理据支持该说法。--J.Wong 2019年5月6日 (一) 13:12 (UTC)
- 既是社群惯性,则为沉默共识,所以除非有充足、广泛讨论认同应该再度分立,否则不迎合社群惯性基本上就和违反共识画上了等号。再者,社群也因为两者的合并而为结案提供了更多选择(例如“ma”参数),社群惯性所衍生的额外问题已正逐步消除。Σανμοσα五四运动百周年 2019年5月7日 (二) 09:18 (UTC)
- 当初合并亦没有充分讨论,上面问题也没有思虑过,讨论过。现在就在讨论这件事呀,请为继续合并提供足够理据支持。何况什么是惯性呢?过往社群并不会将什么合并请求都抛到存废讨论,现在反而是被迫改变习惯,将所有合并请求都抛到存废讨论。“ma”(允许合并)将整件事弄得更为复杂,什么是允许合并?什么状况下不用合并,而要用允许合并?奇怪。“社群惯性所衍生的额外问题已正逐步消除”,请为此论述提供数据支持,例如︰衍生了什么问题,当初合并前是什么状况(基线),合并后到现在又是什么状况,做一个详细比较。--J.Wong 2019年5月18日 (六) 15:02 (UTC)
- 见Template talk:TalkendH#Template:TalkendH新增“允许合并”参数,“ma”的定义是管理员委托其他用户代为手动合并,因为部分管理员在处理已经达成合并共识的AFD时不(多数情况是“未能”)手动合并相关页面。如果社群的惯性是将合并请求提交到PM的话,我当时就不会创造{{delpmh}}了,但是创造了{{delpmh}}还是收效甚微。现在的情况是多了一些合并提案供社群讨论,但有机会页面适宜合并,但没有人参与讨论(当时的一种做法是“暂时保留:请自行合并”,但只是少数做法),加入了“ma”就可以稍微加快部分的合并请求程序。Σανμοσα以有涯随无涯,殆已! 2019年5月18日 (六) 15:22 (UTC)
- 首先,翻查“合并请求”一月份存档,还是有用户向该页提交合并请求,所以请分清楚究竟社群惯性行为是什么。
- 其次,要创建{{delpmh}}并等于社群想将全部合并请求抛到存废讨论,也可以是个别用户误会操作流程。
- 其三,此项讨论其实正正反映出存废讨论无力应对/不想处理大部分由删除请求转化而成的合并请求,所以才会出现“暂时保留︰请自行合并”,那还将其余本身与删除不相关的合并请求往存废讨论推,是什么玩法?这是警兆呀,没留意到吗?由始至终,流程都没有加快呀。页面是没人合并,也是没人合并,别自欺欺人,好不?要是想有人去裁决是否适合合并,合并请求放到“合并请求”一样也可以有人去裁决,裁决者不一定要是管理员。
- 请搞清楚问题所在,再行施药,别药石乱投。以上。--J.Wong 2019年5月19日 (日) 00:45 (UTC)
- 我根本没说过整合合并请求和页面存废讨论能够增加效率。Σανμοσα以有涯随无涯,殆已! 2019年5月19日 (日) 09:19 (UTC)
- 见Template talk:TalkendH#Template:TalkendH新增“允许合并”参数,“ma”的定义是管理员委托其他用户代为手动合并,因为部分管理员在处理已经达成合并共识的AFD时不(多数情况是“未能”)手动合并相关页面。如果社群的惯性是将合并请求提交到PM的话,我当时就不会创造{{delpmh}}了,但是创造了{{delpmh}}还是收效甚微。现在的情况是多了一些合并提案供社群讨论,但有机会页面适宜合并,但没有人参与讨论(当时的一种做法是“暂时保留:请自行合并”,但只是少数做法),加入了“ma”就可以稍微加快部分的合并请求程序。Σανμοσα以有涯随无涯,殆已! 2019年5月18日 (六) 15:22 (UTC)
- 但这个惯性有明显问题,为什么不是予以纠正,反而去迎合这个惯性呢?不太合逻辑。所谓“社群惯性”不能解释“不认为再度分立是好事”,请提供更多理据支持该说法。--J.Wong 2019年5月6日 (一) 13:12 (UTC)
- 基于社群惯性(Inertia),我不认为再度分立是好事。社群由始至终根本不认为合并请求能做些什么,提出合并全是交到AFD,合一的目的并不是为了增加效率,而是为了迎合惯性。Σανμοσα y=0 regardless the value of x 2019年5月1日 (三) 10:28 (UTC)
- 发表些个人意见。我是比较支持合并请求并入存废讨论的(或单立一处,但未见必要),目前合并请求无人处理,就个人想法来说,是因为合并请求的处理流程不清晰,不知道何时、可由谁处理。比如说,有时看到新进提交或已提交一阵子的合并请求无人发表意见/执行合并,我不知道是否能直接完成合并和关闭讨论,希望能有操作流程/指引讲清楚。具体而言:提报多久后可着手合并(如3天或7天且无异议)。合并人能否结案讨论(良性环境下不建议)。有异议或讨论中能否尝试合并(可能唐突,也可能展示、协作出合并成果。后者与问题1有关联)。如何、何时请求管理员协助(如一个标识模板和/或维护分类),移动、合并历史是否要公示等待(因为难撤销)。以及应鼓励发表支持/反对意见。等等。--YFdyh000(留言) 2019年5月19日 (日) 06:16 (UTC)
- 集中处理合并请求的确会比较好,但不是集中到存废讨论。存废讨论应该主要用于处理删除决定及申请,而合并选项只是为了履行“删除乃最后手段”原则而存在,即是如果一开始就不认为需要删除就不应该提交到存废讨论。这点需要重申。所以合并请求由始至终只应该有一处,就是“合并请求”。
- 合并流程的确有欠明确,可以于此讨论一并处理。
- 参考英文维基,有将合并请求分为三类︰一、明显需要及合适,可预期没人会异议;二、需要就是否合并及如何合并于条目讨论页与其他编者展开讨论;三、有争议或难以合并,故而需要其他第三方编者协助决定是否合并。
- 第一类可以直接进行。第二类也只是挂模板就完事。第三类才需要提交到“合并请求”。第二类,申请人应该要有意愿去合并条目。
- 参考英文维基上列标准,第一类,个人认为可以同样毋须提交申请以至悬挂模板。第二类,悬挂模板,列于“合并请求”七日,如无异议,申请人可以执行。执行后,如遇有异议,归为第三类,再议。第三类,讨论以解决争议及困难以及达成共识为本,建议讨论最长维持八周。如八周仍未能达成共识,则应考虑暂且搁置。时机成熟时再重启讨论。如有困难,可同时提交到互助客栈条目探讨区。
- 以上。--J.Wong 2019年5月19日 (日) 08:33 (UTC)
- 1及2类无异议(2类方面,其实是否设立一个请求页面并没有关系,因为可以使用分类追踪)。3类方面,如果最终发现被合并的内容原来应该被删除,而删除理由并非关注度/小小作品,又如何?Σανμοσα以有涯随无涯,殆已! 2019年5月19日 (日) 09:19 (UTC)
- 那不如阁下写一下为什么要并兼。
- 这要搞清楚呀,所谓删除是什么意思,是单纯从页面移走相关内容,还是要整页删去。除关注度以外,基本上是否需要删去,应该很容易分辨。要删除,就去存废讨论;要合并,就去合并请求,很困难么?而且阁下资料也太少,是为什么会“最终才发现被合并内容原来应该被删除”……--J.Wong 2019年5月19日 (日) 12:53 (UTC)
- 于目标页面而言是删除相关内容。“最终才发现被合并内容原来应该被删除”的情况通常是侵权和广告(尤其是前者);AFD参与者普遍上比较眼利,能够分辨到这些问题。至于可供查证性、中立性等等问题,那些内容可以删走,也可以挂模板提示。Σανμοσα以有涯随无涯,殆已! 2019年5月20日 (一) 10:20 (UTC)
- 1及2类无异议(2类方面,其实是否设立一个请求页面并没有关系,因为可以使用分类追踪)。3类方面,如果最终发现被合并的内容原来应该被删除,而删除理由并非关注度/小小作品,又如何?Σανμοσα以有涯随无涯,殆已! 2019年5月19日 (日) 09:19 (UTC)
- 基本上,这些年来,我对于合并的处理大致也是三种情况(类似上面说的英文版情况),我觉得不少人也应该和我的状况类似:第一种是明显无异议的合并,一般都是同一主题不同名称,比如中国历史与中国的历史合并,看到了自己就动手解决了(在有能力的前提下);第二种就是挂模板,可以再分两种子类,一种是自己感觉应该是要合并的,但不是非常确定,挂上模板后可以在讨论页留言(多半的情况是不确定应该是A合并到B,还是B合并到A),另一种是第一种情况的延伸,明显无异议需要合并,但是自己没时间和精力去处理,或者对该领域不熟悉,不知道如何下手去合并具体的内容,那就先挂上模板,让其他有能力合并的人看到后去合并。第三种相当于英文版第三类情况,我一般都是直接提交到存废讨论,一般都是A要合并到B,或者A的部分内容需要合并到B,然后删除A。这样实作的主要原因是,通过TW我只会两种合并操作。要么挂上合并模板,然后讨论页留言,要么提删。我不知道如何用TW提交到合并请求页面?我认为合并请求还是非常需要的,但如何设计流程让其发挥更大作用可能需要重新思考。--百無一用是書生 (☎) 2019年5月20日 (一) 02:45 (UTC)
- 另外,不要忘了还有条目拆分这一类,这是合并的反面,这种又如何处理?--百無一用是書生 (☎) 2019年5月20日 (一) 02:48 (UTC)
- 或许这样:不如弄个暂行办法,在{{vfd}}加入以下参数:“merge|合并|合并=Vfd-merge”,并把Draft:Template:Vfd-merge移动至Template命名空间,然后合并请求是否再分立则另议?至于针对上面提及的分拆的问题,我认为可以照板煮碗让AFD处理分拆请求,并且也照板煮碗设置一个Template,也当作暂行办法,分立也另议?Σανμοσα以有涯随无涯,殆已! 2019年5月22日 (三) 08:53 (UTC)
- 当然,在现时的情况下,如果能够在AFD页面中提示编者只有在未能自行合并或合并有争议的情况下才提交合并请求至AFD,会比较好。Σανμοσα以有涯随无涯,殆已! 2019年5月22日 (三) 08:53 (UTC)
- @Wong128hk、Shizhao、春卷柯南、Hat600、@Willy1018、悔晚斋、Cohaf、94rain、Sunny00217。Σανμοσα以有涯随无涯,殆已! 2019年5月22日 (三) 08:57 (UTC)
- Sunny00217 - 2019年5月22日 (三) 10:30 (UTC)
- Σανμοσα 2019年5月22日 (三) 12:56 (UTC) 其实只是页首加一句“只有在未能自行合并或合并有争议的情况下,才提交合并请求至此,否则应当自行进行合并动作”而已。
可否建草稿好了解一下?(能够在AFD页面中提示编者只有在未能自行合并或合并有争议的情况下才提交合并请求至AFD)-- - 其实我觉得Wong128hk的方式才是正途。毕竟这个是否要删除页面,性质完全不一样。而且合并和拆分经常需要对条目主题有一定了解的才比较好处理。共识是合并了,但是没人知道怎么把具体内容合并起来,那就是长期积压在AFD了,倒不如列在一个专门页面更容易慢慢来做更为稳妥--百無一用是書生 (☎) 2019年5月22日 (三) 11:39 (UTC)
- Σανμοσα 2019年5月22日 (三) 12:53 (UTC)
- 上面到底在讨论什么?没细看还以为是一个月前的讨论被拿出来鞭尸 :P —— Eric Liu 坐等万次编辑(留言.留名.学生会) 2019年5月22日 (三) 13:18 (UTC)
- 现在整个讨论的主题变了重开合并请求与否。Σανμοσα 2019年5月23日 (四) 10:24 (UTC)
所以才说是暂行办法;现在上面的讨论有些混乱,整个讨论的焦点完全变了。 - 上面到底在讨论什么?没细看还以为是一个月前的讨论被拿出来鞭尸 :P —— Eric Liu 坐等万次编辑(留言.留名.学生会) 2019年5月22日 (三) 13:18 (UTC)
- Σανμοσα 2019年5月22日 (三) 12:53 (UTC)
- Sunny00217 - 2019年5月22日 (三) 10:30 (UTC)
- 《删除方针》︰“如果一个页面的内容本质上没有导致删除的问题,而标题不合乎要求(例如,名称不符命名常规或其他专题指引的要求,但内容合适的条目;适合一个命名空间的内容被错误地放在了另一个命名空间中的情形),可以直接将它移动到合适的标题下,或是提出移动请求(对于无移动权限或有争议的情形),而不需要将它提交到存废讨论”然后,Draft:Template:Vfd-merge︰“根据维基百科删除方针,此页面已被提出请求并入Template:Vfd。”当中似乎有所矛盾。《删除方针》其实很明确,存废讨论不是处理合并请求之地。个人不认为可以暂行之道。请恪守《删除方针》,将“合并请求”还原。--J.Wong 2019年5月23日 (四) 09:34 (UTC)
- 如果社群其他人大部分都认同应该可以使用暂行办法的话,我认为这样可以凌驾于方针。还有,社群对于是否重开合并请求似乎没大兴趣,我不认为就讨论在现阶段能够达成什么共识,现在似乎还不是重开的时候,WP:IAR可以适用了。Draft template字句问题已修正。Σανμοσα 2019年5月23日 (四) 10:11 (UTC)
- 个人同样不认为在点出问题后有其他人认为此乃可暂行办法。不应该以此为由凌驾既定方针。而此举亦无为本站带来任何好处,是故亦未见有任何理由可援引《规则忽略方针》。修改模板并无真正根治问题之所有。个人由始至终都未明白是为何故而要将页面强行合并。分拆历史远长于合并,是故支持合并理由准备足够、充分理据。请勿一直回避问题之所在,提出足够理据支持此做法。正如阁下上面回复,此合并并非为效率。然后,又发现此合并并无法改善积压问题,只是将积压由一处扫往另一处。为习惯故?又发现其实过往社群并不会将全部合并请求抛到存废讨论。所以到头来,究竟此合并为何原故?为方便?那请问有没有试过要求技术帝帮忙支援合并请求?又有没有试过改善合并流程?--J.Wong 2019年5月24日 (五) 03:47 (UTC)
- 改善合并流程?基本上,此前有关合并请求的讨论的参与率都不大(除了并入AFD那次),可见社群对于改善这方面的流程已经抱持负面态度(我曾经弄过存废讨论转介合并请求的关闭模板,但最终只用了一会就不用了,也是出于这个理由)。还有,Xiplus版Twinkle似乎只是在近期才开始在老手间热门,而且中文维基百科的Twinkle正式版本是Jimmy Xu版本,即使Xiplus版Twinkle支援了,也不见得效果有多大。Σανμοσα 2019年5月24日 (五) 10:53 (UTC)
- 翻阅以往讨论,一直都未有具体改善方案,往往只是抛出问题,此乃乏人回应原因。断不可以此作为证据支持“社群已对此抱持负面态度”之说。既然如此,连同Jimmy版本一起改就可以了。然后,请勿再次回避问题,请交出合并理据。个人记得之前有人讨论指出“合并请求”乏人问津,以致长期积压。一段长时间后,条目依旧模样。请问合并后,此问题是否已经得到妥善解决?--J.Wong 2019年5月31日 (五) 09:37 (UTC)
- 当时提案把合并请求并入AFD的原因并不是长期积压,而是为方便统一集中处理各类删并,我不认为纠缠于这个伪命题有任何意思。我究竟强调过多少次了,增加效率并不是当时提案将两者合并的原因!Σανμοσα 2019年5月31日 (五) 10:21 (UTC)
- 阁下及社群必先要面对现实,承认合并可以是极复杂决定,程序亦繁复,难以一蹴而就。不然此问题永远没法解决。--J.Wong 2019年5月31日 (五) 09:42 (UTC)
- 所以在下上面是否已经问了“为方便?那请问有没有试过要求技术帝帮忙支援合并请求?又有没有试过改善合并流程?”?既然阁下确认当初是为了方便故。那请解决为方便故而产生之一系列问题。不能一句方便,然后明知有问题都视而不见。这不是什么伪命题。是确确切切存在之问题。请正视及解决。--J.Wong 2019年6月1日 (六) 02:30 (UTC)
- “方便统一集中处理”,这也是支持取消合并之理据呀。要从各存废讨论页面中找出合并请求,也非常不便。阁下可有想过?为方便而产生其他不便。--J.Wong 2019年6月1日 (六) 02:33 (UTC)
- @Wong128hk:如果有其他明确支持两者再分立的意见,我不反对再分立,所以我个人建议多找一些人进来讨论(现在你我二人对答都是隔几天隔几天这样回应,其他人像哑子一样)。另外,我还有一件事希望请你帮忙,我会在你的用户讨论页详细说明。Σανμοσα 2019年6月1日 (六) 07:38 (UTC)
- 上面书生还不够明确?--J.Wong 2019年6月1日 (六) 07:47 (UTC)
- 我的意思是用不用再向其他成员参与过讨论的人再确认一下?Σανμοσα 2019年6月1日 (六) 08:00 (UTC)
- 请便。--J.Wong 2019年6月1日 (六) 12:05 (UTC)
- 上面书生还不够明确?--J.Wong 2019年6月1日 (六) 07:47 (UTC)
- @春卷柯南、Sunny00217、94rain、hat600、Cohaf、@悔晚斋、Willy1018、Wolfch:现就此咨询各位是否同意合并请求和页面存废讨论再分立。Σανμοσα 2019年6月1日 (六) 13:13 (UTC)
- 我比较赞成将合并请求整合到页面存废讨论中--Wolfch (留言) 2019年6月1日 (六) 13:40 (UTC)
- (=)中立,本身就极少在管合并讨论,不做决定 -- Sunny00217 - 2019年6月1日 (六) 13:42 (UTC)
- 支持合并讨论,长期合并请求仅有少数人维护。 Willy1018(留言) 2019年6月1日 (六) 14:05 (UTC)
- Σανμοσα 2019年6月1日 (六) 15:01 (UTC) 这样的情况,我岂不是很尴尬……至少有二人反对分立。
- Wolfch君,请多说一点,说一下理据。Willy1018君,难道现在存废讨论不是只有少数人维护?合并后,还增加了他们负担,把原本不用他们处理的合并请求都推到他们身上,于心何忍呀?而且之前社群一直没有正视问题,提供足够指引,令致合并请求缺人参与,缺乏系统,缺人关注。而且合并请求归到存废讨论,那分拆讨论又要放到哪里?存废复核吗?于理不合呀。--J.Wong 2019年6月2日 (日) 01:05 (UTC)
- 增加负担?afd没有明确共识就用无共识,可以合并无法自行处理使用允许合并,拆分讨论放到条目讨论页或条目探讨。 Willy1018(留言) 2019年6月2日 (日) 01:15 (UTC)
- 原本就不是全部合并请求都交到存废讨论,现在把全部合并请求交到存废讨论,当然是增加负担。而且《删除方针》规定存废讨论最长讨论时长时五周。合并讨论可以非常复杂,超过五周,个人觉得根本不为过。所以什么是允许合并,由谁去合并?为什么会出现“允许合并”,明显就是管理员或者存废讨论结案者不欲参与合并过程,所以这样不是强人所难是什么?--J.Wong 2019年6月2日 (日) 01:22 (UTC)
- 所以为什么合并请求不能在“条目讨论页或条目探讨”进行?--J.Wong 2019年6月2日 (日) 01:23 (UTC)
- 我有参与合并请求,不过不常参与。建议合并到存废讨论的原因是:合并请求的讨论有些会在合并请求中进行,有些会在条目讨论页,但参与讨论的人似乎比较少,若放在存废讨论,比较会有多一些人参与讨论。而且有时存废讨论的结果也可能是条目的合并,若是合并请求和存废讨论分开,存废讨论后可能还需要一次的合并请求,需要多讨论一次。--Wolfch (留言) 2019年6月2日 (日) 06:04 (UTC)
- 首先,个人非常明白主张合并原因之一就是合并请求乏人问津。这点,可以改善,合并至存废讨论并非唯一解决办法。当初缺乏指引及系统是合并请求乏人问津原因之一。用户无从得知申请是否已经获得通过。渐渐就会失去耐性及离之而去。正如上面在下建议,在下很希望分拆之后,合并请求能有系统地处理申请,例如将申请分为三类。如需讨论则订下讨论期限。寻求TW支援。以至适度增加合并请求曝光率,例如第三类,特别复杂个案则可按需同时递交至互助客栈条目探讨区,或者于公告栏作出告示。阁下既有参与合并请求,在下非常想与阁下详谈此等方案。但前提是合并请求从存废讨论独立出来,始能制订适切改革方案,及度身订造合身制度。另一点,在下希望指出是,无错的确存废讨论有时会得出合并决定,但不应因此就将全部合并请求都拨入存废讨论。如果情况简单,存废讨论得出合并决定后,就应该付诸实行,而毋须合并请求再次讨论。但相反,如果情况复杂,存废讨论议决合并就会成为方向。合并请求则应接续讨论相关合并细节。又若然存废讨论结案者并不熟悉条目,未知应该如何合并,其实于判定合并以后,尚应备案至合并请求,甚或条目探讨区或相应专题。合并请求尚应处理复杂合并,如长条目甲可能一部分适合合并到条目乙,一部分适合合并到条目丙。此等讨论并不适合,亦不应该出现于存废讨论。存废讨论结果应有适度约束力,现在合并决定多数适用于关注度不足条目。因为有约束力,所以一般要推翻合并决,需要经存废复核审核。在下虽然这阵子比较少出没于存废复核,然而在下亦非常忧虑因为存废讨论承接全部合并请求,而令存废复核要承接全部合并请求复核。如此,并不合理。--J.Wong 2019年6月2日 (日) 08:49 (UTC)
- 现正式就重新拆分《合并请求》及《存废讨论》交付公示,为期七日,如无合理异议,则视为通过。--J.Wong 2019年6月9日 (日) 04:28 (UTC)
- @Wong128hk:在公示什么,我看上方讨论和议题,多是(“现就此咨询各位”部分)支持整合两者。个人反对目前拆分,社群没有精力和需求维护两个地方。--YFdyh000(留言) 2019年6月9日 (日) 08:08 (UTC)
- 存废讨论同样没有资源处理整合后的大量工作量,而且如此根本破坏制度。如果阁下反对分拆,请回应在下上方论点。而非单单抛出如此理据。--J.Wong 2019年6月9日 (日) 08:39 (UTC)
- 另外,既然没资源维护,请也回答“所以为什么合并请求不能在“条目讨论页或条目探讨”进行?”,为什么非存废讨论不可?存废讨论结案者既然使用“允许合并”去过关了事,为什么阁下会觉得这样就叫处理了?个人对此方案很多疑惑,既然YFdyh000君支持整合,请为在下解惑。在下上面就已经详细分析了此次整合有何坏处,请亦钜细无遗地为大家分析整合后有何好处,解决了什么问题,最好做个数据比对。就例如上面阁下说了“社群没有精力和需求维护两个地方”,请问是否有数据支持此说?--J.Wong 2019年6月9日 (日) 08:51 (UTC)
- @Wong128hk:共识可以改变,“破坏制度”的制度也非定局。上方其他人提出了反对分拆的意见,未见共识改变和简明易懂的理据,最多是无共识而维持现状,即不分拆。“所以为什么合并请求不能在“条目讨论页或条目探讨”进行?”,因为惯例,大家比较习惯放在存废讨论处理(包括投票版式、时间索引、关闭讨论等)与积压、乃至过期,正如存废讨论也会积压。放在条目探讨是过期存档的命运,讨论页则更是关注寥寥。如果有人持续处理合并请求,并提出意见希望分拆,个人认为比较可靠,否则没坏别修。有一个点子,将合并请求作为一个索引页,链向各个存废讨论,如果开始有人跟进并展现出效率,再议拆分。如果想法是将没人处理的合并请求放到更没人理的地方,个人反对。--YFdyh000(留言) 2019年6月9日 (日) 10:54 (UTC)
- 没坏别修,应该是维持分拆,而非维持整合。惯例并非将全部合并请求都抛到存废讨论,所以现在是没有足够理据下强行改变社群习惯。个人亦希望提出方案修订合并制度,但个人觉得前提是确立共识分拆。最多就是不立即执行,但必须先确立此共识。--J.Wong 2019年6月9日 (日) 11:14 (UTC)
- 翻查《合并请求》2019年存档,又不是没人持续处理。在下上面亦说过,要增加曝光,方法有很多。存废复核前身是删除检讨,以前也是门可罗雀,现在呢?由按年存档,到按季存档,到现在按月存档。本站条目数量破百万,有什么可能没有足够合并需求支撑起一个独立申请页……--J.Wong 2019年6月9日 (日) 11:18 (UTC)
- 反对强行通过这一案的提议。在下以为,上方的所有讨论清晰的表明了如下两点:
- 参与讨论的绝大多数参与者反对该项提议或表示中立;且,
- 支持该提议的用户没有强有力的证据来完全驳倒上述反对者,全凭借自身主观感受来判断并不合理。
- 另外,在下建议相关支持者以清晰有条理的方式撰写相关理由,否则会给人一种茹太素的既视感。--悔晚齋(臆語) 2019年6月9日 (日) 11:30 (UTC)
- 我都没有说要强推⋯⋯我提出这个建议是因为现况是合并请求导流到页面存废讨论,不过配套工作没有做好(比如社群不认为{{Mergeto}}是合法的AFD模板,结果我建议合并的时候,在条目上方挂了一个Mergeto模板,人家就说请求无效,予以否决,到后来挂了VFD才没有人阻止),这是客观事实而不是主观臆测。要解决这个问题就两个办法,要么就完全整合,要么就分家。不过后来王爷爷提出反建议(重设合并请求),而且得到不少人的同意,那就顺应一下好了。--春卷柯南编辑数突破二万 ( 论功行赏·刻石留名 ) 2019年6月9日 (日) 11:44 (UTC)
- 作为经常处理afd的管理员,我觉得还是将合并、分拆等迁出afd比较妥当。本身允许并入就是权宜之计,而合并和分拆也只是afd的其中一个结案选项而已,换言之如果本来就是提议合并、分拆的话,置于同一页面整合起来比较清楚。而且,将并拆置于afd内,就算结案是允许并入,到最后是否真的并入好,要跟进起来非常困难,如果有专门页面的话,相信会比较容易跟进。—AT 2019年6月9日 (日) 12:14 (UTC)
- 如果要在存废讨论处理合并事宜,那么请先确定哪种类型的合并应该放到存废讨论,还是所有的合并都放到存废讨论?{{Mergeto}}类模板本来就是挂上模板等人合并用的,而不是提删用的。另外,在存废讨论处理的话,共识是合并,但很久都无人合并应该如何处理?毕竟合并很耗费时间和精力,甚至不少条目的合并还需要一定的专业知识才合并得了。那么如何处理这种问题?一直在存废讨论积压下去?--百無一用是書生 (☎) 2019年6月10日 (一) 02:09 (UTC)
- 大家这样僵持下去并不能解决任何问题,倒不如先采取我之前提出的暂行办法:在{{vfd}}加入“merge|合并|合并=Vfd-mergeto”参数,把Draft:Template:Vfd-mergeto移动至Template命名空间,并在页面存废讨论页首加入一句“只有在未能自行合并或合并或有争议的情况下,才提交合并请求至此,否则应当自行进行合并动作”提示编者。至于是否分立应该另开讨论处理,否则一直这样下去没共识只会造成冗长讨论。Σανμοσα 2019年6月11日 (二) 04:08 (UTC)
- 我觉得将改挂{{Merge}}作为结案选项、作为提报的首选步骤(当原页面内容不急需删除——不处在活跃编辑、非错误名称)为好。对于无需讨论只需合并处理的页面,不建议挂到请求页。--YFdyh000(留言) 2019年6月12日 (三) 13:27 (UTC)
- {{Merge}}提报?那么无需讨论只需合并的页面,由于时间精力有限或者知识不足等原因无法合并的怎么处理?放在那里不管也不挂模板?--百無一用是書生 (☎) 2019年6月13日 (四) 02:11 (UTC)
- Category:需要合并的条目而非存废讨论/合并请求页面中积压,等有兴趣查阅、修缮有关条目的人处置。无共识的合并同上,继续在相关条目中编辑、条目讨论页中讨论。--YFdyh000(留言) 2019年6月13日 (四) 03:22 (UTC) 就是改挂Merge模板并结案啊,放在
- {{Merge}}提报?那么无需讨论只需合并的页面,由于时间精力有限或者知识不足等原因无法合并的怎么处理?放在那里不管也不挂模板?--百無一用是書生 (☎) 2019年6月13日 (四) 02:11 (UTC)
- 我觉得将改挂{{Merge}}作为结案选项、作为提报的首选步骤(当原页面内容不急需删除——不处在活跃编辑、非错误名称)为好。对于无需讨论只需合并处理的页面,不建议挂到请求页。--YFdyh000(留言) 2019年6月12日 (三) 13:27 (UTC)
- 刚提了editprotected,相信很快就能够完成最后的整合功夫,那样页面存废讨论和合并请求就算是暂时完成整合了。至于是否正式再分立,我建议应该另外开新讨论。Σανμοσα 2019年6月13日 (四) 03:16 (UTC)
- 一、本末倒置,为什么宁愿存废讨论没法处理就随他在分类中积压,都不确确切切,踏踏实实解决之前合并请求没系统处理申请而衍生之问题。如果积压到头来能在条目讨论页解决,为什么不一开始就在条目讨论页中解决?
- 二、既然上面都说了此并整未完全完成,而在未完全完成之前,已经有数个用户提出合理质疑,为什么暂行方案不是退回到整合之前,而是继续整合?阁下有什么理由会觉得在下会接受?更遑论该次整合连公示都没有,就随随便便整合。如此重大决定,为什么不用公示?
- 以上。--J.Wong 2019年6月15日 (六) 00:42 (UTC)
- 其实整合的工作早已完成,正确来说这个暂行办法只是为免部分人以为放在同一页的合并请求是删除请求而已,不做也无大碍。Σανμοσα 2019年6月15日 (六) 05:34 (UTC)
- 所以有多本末倒置才需要这样。所以不是说了,存废讨论是处理删除请求之地,很多新人及用户未必对这有这么多了解,一见到要去存废讨论不是给吓倒,就是如阁下所言,混乱非常。如此混乱,根本不是单单转个模板就完事。现在又变成了“整合工作早已完成”了啦?但阁下还是没答为什么如此重大决定不用公示?--J.Wong 2019年6月16日 (日) 02:31 (UTC)
- 因为你们这样僵持落去只会没有共识、一事无成。Σανμοσα 2019年6月16日 (日) 09:58 (UTC)
- 问题会不会是此次整合根本没有完成整个程序,现在亦已有反对声音,根本就不应该继续下去。更没可能容许所谓暂行办法。--J.Wong 2019年6月23日 (日) 12:46 (UTC)
- 这里要讨论是“是否整合”,而非“是否继续整合”。在下已将相关未公示编辑回退。--J.Wong 2019年6月23日 (日) 12:51 (UTC)
- @Wong128hk:完全整合,或完全回复到整合前?-- Sunny00217 - 2019年6月26日 (三) 08:53 (UTC)
- @Wong128hk?—— Eric Liu(留言.留名.学生会) 2019年7月2日 (二) 05:26 (UTC)
- ?--J.Wong 2019年7月7日 (日) 08:25 (UTC)
- (?)疑问@Sanmosa、Wong128hk、YFdyh000、Shizhao:所以这个讨论变相2个礼拜都没有人回应也叫“公示” 囧rz……? 会否有争议存在(等等再不用机器人就存档了)?--Z7504非常建议必要时多关注评选(留言) 2019年7月21日 (日) 10:36 (UTC)
- 个人觉得更大争议在之前整合讨论未曾公示就整合。现在只是恢复该次未公示编辑而已。--J.Wong 2019年7月21日 (日) 10:47 (UTC)
- 不管整合还是恢复,重点是要有人处理。如果哪位有意致力于此,请发表意见,或许更有价值。个人坚持之前的意见,在没有足够的参与者和流程共识前,分立会更加积压、小众化而废弃。--YFdyh000(留言) 2019年7月21日 (日) 11:51 (UTC)
- 还是那句,没道理在存废讨论及存废复核常驻管理员有异议情况下将积压就这样扫往存废讨论及存废复核。--J.Wong 2019年7月21日 (日) 12:09 (UTC)
- 要解决问题又不是只有一个方法,为什么硬要并入存废讨论?--J.Wong 2019年7月21日 (日) 12:16 (UTC)
- 不希望合并入存废讨论。但目前的合并流程需要改进,绝大部分讨论无人参与,无人结案,因此不得已推到存废讨论,也不是不能理解。~ viztor ✪ 2019年7月21日 (日) 12:34 (UTC)
- (?)疑问那“合并请求”是否考虑重定向? 只有两种:一就是恢复“合并请求”页面,并取消存废讨论使用合并请求这功能。二就是现在这个提案。--Z7504非常建议必要时多关注评选(留言) 2019年7月21日 (日) 13:15 (UTC)
- 个人不认为只有这两个方案。个人建议参照关注度讨论做法,先将问题列出,再订立目标,逐点击破。而不是一二三就跳到结论,然后强迫社群接受。--J.Wong 2019年7月21日 (日) 13:38 (UTC)
- 目前存废积压已经900多了。合并问题并入存废只能是使存废的积压情况变得更为严重而已--百無一用是書生 (☎) 2019年7月23日 (二) 12:54 (UTC)
- 所以明明有人反对,什么叫de facto合并?--J.Wong 2019年8月12日 (一) 12:03 (UTC)
- 如果是次讨论要结束,个人相信只有一个结论,就是︰整合是重大决定,理应按惯例先行公示,而之前未有公示,今次讨论又遇有合理异议,故而维持原来分立状态。如仍认为需要整合,应当重新讨论。--J.Wong 2019年8月12日 (一) 12:12 (UTC)
- 我认为阁下现在是为求达到自己的目的而刻意制造冗长讨论。阁下的观点其实也被部分用户反对,依理应该维持现状(可以无共识状态结案),而现状就是de facto合并。산모사 DC17GAN FLN1 FLN2 2019年8月12日 (一) 15:34 (UTC)
- 阁下如果坚持不给维持现状结案的话,我会考虑采取进一步行动。산모사 DC17GAN FLN1 FLN2 2019年8月12日 (一) 15:37 (UTC)
- 我不认为现在de facto是合并,事实是以前什么样基本还是什么样。有提交删除的,有直接挂合并模板并讨论页留言的--百無一用是書生 (☎) 2019年8月13日 (二) 01:56 (UTC)
- Sanmosa君,请回应书生所言。在下意见与书生完全一致。--J.Wong 2019年8月13日 (二) 05:56 (UTC)
- 但基本上请求还是送去AFD,回避{{vfd}} template≠不是de facto合并。书生只说了事实的一半。산모사 DC17GAN FLN1 FLN2 2019年8月13日 (二) 06:01 (UTC)
- 而且我也表示了不反对无共识状态结案,我的重点是Wong128hk你是不是仍然坚持制造冗长讨论。先close这里的讨论好吗,已经没人有精力参与这讨论了。산모사 DC17GAN FLN1 FLN2 2019年8月13日 (二) 06:05 (UTC)
- 其实如果阁下之前结论不是那个,而是“整合是重大决定,理应按惯例先行公示,而之前未有公示,今次讨论遇有合理异议,亦未有共识,故而维持原来分立状态。如仍认为需要整合,应当重新讨论。”在下亦不会重启此讨论。上面在下已经说了,那应该提醒相关用户,而非将错就错。--J.Wong 2019年8月13日 (二) 06:22 (UTC)
- 合并请求和页面存废讨论现在是介乎整合与分立之间,分立状态并不是讨论开始时“原来的状态”。我建议直接只说“维持现状”。산모사 DC17GAN FLN1 FLN2 2019年8月13日 (二) 06:41 (UTC)
- 其实在下上面也已经说了,如非一开始就认为需要删除,又或者不是因为关注度问题,其实就不应该提交到存废讨论。一直以来都是这样,没有变过。至于TW,稍后修改合并程序后,亦应该一并修改。TW提删页面不应该再提供合并选项。该选项无疑加剧误解。存废讨论至所以有合并选项作为结案理由,只是为了满足《删除方针》“删除乃最后手段”此项大原则。如一开始已觉得合并就可以解决问题,为什么要提删?--J.Wong 2019年8月13日 (二) 18:08 (UTC)
- 阁下或者应该看看“合并请求”,两个新请求,证明“合并请求”根本并非无人关注。就不明为什么硬要整合到存废讨论,加剧存废讨论积压,又加重存废复核负担。此动作无疑甚为无理,亦不切实际。--J.Wong 2019年8月13日 (二) 18:17 (UTC)
- 这两个用户不能作准。Gianthard的编辑始于今年3月,编辑次数50次也没有,我认为他是不清楚实况才会在那里提报;而查Kannoflower的贡献纪录,他并不关注客栈的讨论。再者,管理员Xiplus在1月把页面中的{{historical}}模板移除,造成这样的误解在所难免。另外,我个人并不认为存废讨论/存废复核积压、负担是一个问题(反正该结案的讨论,你们大多都还不结案处理,那我多放若干请求进去其实也没分别)。合并请求之所以要并入页面存废讨论,是因为这样这些请求才能得到更高的关注,基本上以前合并请求的关注率都比较低,并且有机会扼杀了部分意见(例如主张不应合并而应保留条目,或主张不应合并而应删除相关内容者)。我不认为维基百科的制度是用来优待管理员的,谈存废讨论积压/存废复核负担于我而言没有什么意义,如何令合并请求得到更高的关注是我唯一在意的地方。산모사 DC17FLN1 FLN2 2019年8月14日 (三) 00:33 (UTC)
- 我刚才看看,我突然发现原来Wong128hk你是想故意回避我的statement。“合并请求和页面存废讨论现在是介乎整合与分立之间”这个statement,究竟你是否同意?산모사 DC17FLN1 FLN2 2019年8月14日 (三) 00:45 (UTC)
- 一、没什么能不能作准。维基百科不是只开放予熟练程序之人。该等请求都是八月才提出,与一月是否挂有模板又有何干?
- 二、阁下说法非常不负责任,亦是无端指责。管理员亦只是义工,什么叫“反正该结案的讨论,你们大多都还不结案处理,那我多放若干请求进去其实也没分别”?又什么是“我不认为维基百科的制度是用来优待管理员的”?这那里优待了?阁下不断放大一个问题,然后又置另一个问题于不顾。个人实在不见得如此于维基百科有何益处,亦不见得讨论下去会有何结果。甚至有扰乱之虞︰因为不满管理员该结案而不结案,做成存废讨论积压,于是明知会加剧存废讨论积压,继续强推,而示不满。
- 三、不认同。两者分立无误。
- 四、在下必须严正指出︰要令“合并请求”获得关注,整合至存废讨论并非唯一方法,而且整合亦非上上之策。阁下执意整合,及坚持所谓“合并请求和页面存废讨论现在是介乎整合与分立之间”,正正障碍“合并请求”改革,令流程无法改善及得到更多关注。
- 以上。--J.Wong 2019年8月19日 (一) 20:13 (UTC)
不同意阁下这样的结案理由。要这么说的话,其实
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
资料来源
编辑大家 早安
请问差别 第一手资料 第二手资料 第三手资料 网络上查得到的资料编写的维基算是第几手ㄛ —以上未加入日期时间的留言是于2019年8月26日 (一) 00:14 (UTC)之前加入的。
- 关于第一、二、三手来源的定义,请见Wikipedia:非原创研究#第一、第二和第三手来源。不知道阁下能给一下相关网站的连结吗?因为网站来源都可以是第一、二、三手来源(尤其前两者)。Sanmosa DC17 GAN FLN 2019年8月27日 (二) 04:06 (UTC)
- 我觉得他后面想厘清的是所谓“维基”算是第几手来源。另外,此话题应移动至求助区。—— Eric Liu(留言.留名.学生会) 2019年8月27日 (二) 06:11 (UTC)
- Sanmosa DC17 GAN 2019年8月27日 (二) 10:29 (UTC) wiki-base页面其实道理也一样:不公开让人edit的page如果是raw data就是一手,归纳raw data的话就是二手,归纳二手(以至三手)来源的就是三手。公开让人edit的(像维基百科一样的)也是三手,但通常不可靠。
- 另外,这也算是请求厘清方针,可以留在这。Sanmosa DC17 GAN 2019年8月27日 (二) 11:19 (UTC)
- “维基百科”的话是第三手来源,如同上面Sanmosa所说。至于“维基”,由于表意不清,说不好是几手。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2019年8月29日 (四) 11:55 (UTC)
- 我觉得他后面想厘清的是所谓“维基”算是第几手来源。另外,此话题应移动至求助区。—— Eric Liu(留言.留名.学生会) 2019年8月27日 (二) 06:11 (UTC)
大家好,我又来了。(怎么老是我?)这次我不是来提议AFD和PM合并的,而是来征求大家一些能提高PM的参与度和使用率的方法。我的方法有三个:
- Twinkle配合(就是拜托Xiplus修改参数就是了;短期);
- AFD转交PM常规化(我曾经弄过专用模板【{{Delpmh}}和{{Delpmf}}】,现在应该用得上;短期);
- 修改PM的做法(例如把PM弄成像AFD或VP一样的版面,直接让人看有什么讨论;长期);
以上,其中短期那两个其实可以即时做,尤其是第二个。Sanmosa DC17 GAN 2019年8月27日 (二) 10:21 (UTC)
- 谨@JWong阁下。—— Eric Liu(留言.留名.学生会) 2019年8月29日 (四) 03:43 (UTC)
- @Ericliu1912:JWong?-- Sunny00217 2019年8月29日 (四) 09:00 (UTC)
- ping错Orz。谨@Wong128hk阁下。—— Eric Liu(留言.留名.学生会) 2019年8月29日 (四) 09:06 (UTC)
- 个人上面已经提议过︰
- 参考英文维基,有将合并请求分为三类︰一、明显需要及合适,可预期没人会异议;二、需要就是否合并及如何合并于条目讨论页与其他编者展开讨论;三、有争议或难以合并,故而需要其他第三方编者协助决定是否合并。
- 第一类可以直接进行。第二类也只是挂模板就完事。第三类才需要提交到“合并请求”。第二类,申请人应该要有意愿去合并条目。
- 参考英文维基上列标准,第一类,个人认为可以同样毋须提交申请以至悬挂模板。第二类,悬挂模板,列于“合并请求”七日,如无异议,申请人可以执行。执行后,如遇有异议,归为第三类,再议。第三类,讨论以解决争议及困难以及达成共识为本,建议讨论最长维持八周。如八周仍未能达成共识,则应考虑暂且搁置。时机成熟时再重启讨论。如有困难,可同时提交到互助客栈条目探讨区。
- 至于上列第一、第二项,个人都赞成。
- 以上。--J.Wong 2019年8月31日 (六) 14:33 (UTC)
我等待一下其他意见,稍后会正式提案。Sanmosa DC17 GAN1 GAN2 2019年9月3日 (二) 11:17 (UTC)