跳转到内容

维基百科讨论:合并请求

页面内容不支持其他语言。
维基百科，自由的百科全书
本页面曾被多次送交存废讨论。
若要再次提交存废讨论，请先参考下列过往讨论记录：

关于重复条目的处理程序？

[编辑]

目前乍看之下有点难以理解，有以下几个问题：

  1. 讨论要有什么样的结果才能付诸执行？
  2. 投票制？多数决制？票数门槛？
  3. 如何处理有所回应（例如赞成意见）却没有继续讨论的重复条目申请？
  4. 谁有权进行条目合并？发起者？管理员？
  5. “发起讨论->没有回应->没有执行”─是否有这类状况的处理方案？

－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:互助客栈/方针/存档/2009年2月。

有没有哪位能界定一下“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)[回复]
想问一下，直接手动重定向岂不是让被Ａ条目的原编辑历史停止了？原编辑者的功夫岂不是白费？这种情况不是不应该手动重定向而是由管理员移动再合并编辑历史吗？--91.142.12.62 (留言) 2009年2月7日 (六) 07:58 (UTC)[回复]
可以参考Wikipedia:合并和移动页面#如何合并页面，在合并两页面时，编辑历史的合并并非是必须的；目前的作法是认为有此需求的话，可以在合并完成后再至移动请求提出，但提出前此两条目必须先将内容整合完成，才能方便管理员进行编辑历史的合并。不过个人并不建议所有合并的条目都将编辑历史合并，因为会产生让编辑历史混乱的问题，可以参考我在Wikipedia:互助客栈/方针/存档/2009年2月#重复条目之编辑历史是否须合并？提出的讨论，如果有任何建议方式也欢迎一起提出。—Alberth2-汪汪 2009年2月7日 (六) 08:19 (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://wikicn.playgoteam.workers.dev/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)

同样的情况，又发生在内搭裤、紧身裤、无底袜条目了

内搭裤和紧身裤两个条目原有的讯息，在这次和这次都全被删掉了（并不是内容合并），并且重定向到无底袜条目。

原子裤
紧身裤

问题是，目前无底袜条目的内容，不可等同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)

好好墓

[编辑]

本主题全部或部分段落文字，已移动至Talk:妇好墓。

“好好墓”实非“妇好墓”的别称，而是个纯粹字误。大家可以先详阅妇好墓条目，看看“妇好”所指的是什么，再用“好好墓”做关键字搜寻一下，即知所言非虚。

因此，“好好墓”宜删除，而非用作“妇好墓”的重定向页，尚祈亮察。

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)[回复]
我也觉得可能是Wing君和Jimmy Xu君百忙中未及细察，所以也邀了他们到talk:妇好墓里再谈，不过，刚才再看，好好墓已经删了 :P--210.6.97.227 2009年7月1日 (三) 08:35 (UTC)

有合必有分

[编辑]

本主题全部或部分段落文字，已移动至talk:叶调。

既有了把重复条目合并的讨论页面，想问问，维基有没有把条目分割的专门讨论页面？口罩条目就好像有这个需要了。

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.120 2009年7月6日 (一) 11:28 (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.41 2009年8月14日 (五) 10:25 (UTC)

WP:合并请求与存废讨论之{{合并}}

[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2017年4月22日 (六) 16:42 (UTC)。[回复]

这个存废讨论中，有用户提出：“合并后重定向”应去WP:合并请求进行讨论，而非在存废讨论进行。而WP:AFD中也有“如果您可以改善条目，请不要犹豫。同时，你可以选择：重定向、重命名、与其他条目合并、回退、或索性加入清理、小小作品限期改善模版。”，故此类合并讨论确实不应在存废讨论进行。然而：

  1. 在4月7日的存废讨论记录中有非常多的可以“合并后重定向”的讨论，之前的存废讨论亦没有明确的拒绝合并讨论进入的情况。
  2. WP:合并请求中的讨论不了了之者居多，很多被提出合并的条目几个月后仍然保持原状，该页面似乎少有人关注。
  3. 提交存废讨论的入口允许提交合并请求，而未指明合并后是否要删除原页面。（存废讨论中的{{合并}}意义不明）

因此提出以下方案：

  1. 所有不涉及删除页面的讨论都不要提交到存废讨论（例如“合并后重定向”就不需要删除页面）
  2. 在WP:AFD和Twinkle中增加合并页面的引导。（TW中目前是挂合并模板，然后在讨论页讨论，不了了之的也很多）

或：

  1. 允许合并讨论进入AFD

我个人认为后一种方案可行度较高：条目讨论页与合并请求的讨论难以引起关注，全放在互助客栈讨论也不现实。希望社群能在此得到共识，明确存废讨论的适用范围。--Tiger（留言）DDL是第一生产力 2017年4月8日 (六) 00:03 (UTC)[回复]

  • (！)意见虽然tw工具里提删里面有合并...，除了内容一样我会手动合并，如内容不同自己亦不熟该领域就会丢讨论例如音乐名词。-Zest2017年4月8日
  • (！)意见：反对把合并讨论放进存废讨论，不能为了所谓获得关注就把不相关的内容都放到存废讨论中来。合并问题放在条目讨论页足矣，没人反对的话提议合并者就可以合并。放到存废讨论中有时执行者会莫名其妙地把本该保留重定向的被合并页也删除了，或者把不该合并编辑历史的页面合并编辑历史，造成更多混乱。英文维基就不会把合并讨论放到存废讨论中来。--Pengyanan（留言） 2017年4月8日 (六) 04:56 (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)[回复]

合并讨论要在哪里发起

[编辑]

目前{{subst:mergefrom/auto|另外的条目}}、{{subst:mergeto/auto|另外的条目}}将讨论连结到talk:留下的条目，而维基百科:合并请求#说明说新增请求时，讨论要连结至Talk:合并走的条目，是否予以统一？--Towatw（留言） 2017年6月9日 (五) 08:00 (UTC)[回复]

合并历史是否有相关指导？

[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2017年8月17日 (四) 08:42 (UTC)。[回复]

经过搜索，似乎没有在Wikipedia名字空间看到有关合并历史的说明，只有一个空章节。请问：

  1. 合并历史须满足怎样的条件才可进行？
  2. 何种情况需要合并历史？

--Tiger（留言） 2017年8月7日 (一) 01:14 (UTC)[回复]

合并条目

[编辑]

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2018年3月26日 (一) 04:18 (UTC)。[回复]

本主题或以下段落文字，移动自User talk:Sanmosa#合并条目。执行者：— 卍・〇・卐 2018年3月5日 (一) 10:28 (UTC)。[回复]

此讨论是关于是否将合并请求合并至存废讨论，源于我曾经把一些在存废讨论提交的合并请求转至WP:PM。希望大家能多多给予意见。— 卍・〇・卐 2018年3月5日 (一) 10:43 (UTC)[回复]

背景

[编辑]

建议让讨论在存废讨论那边进行7天，管理员结案后再转交到合并请求。现在合并请求那里没有经过讨论的请求，除非一目了然，否则很难处理。而存废讨论关闭后，很少会有人来参与讨论了。--Tiger（留言） 2018年3月4日 (日) 02:59 (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)[回复]
  • 我觉得不错，其实存废讨论那边处理合并的人也不多浅蓝雪❉ 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)[回复]

合并请求

[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2019年2月11日 (一) 16:14 (UTC)。[回复]

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

...这个页面的这个模板：

本服务自2019年1月29日起关闭，请移步至此页面提请。

[[Wikipedia:頁面存廢討論/記錄/{{#time:Y/m/d}}|此頁面]]： 这一行会连接至UTC+0日期的存废讨论，以至于现在连到的是1月30日的存废讨论...--MeritTim（留言-给予警告） 2019年1月31日 (四) 05:31 (UTC)[回复]

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

鉴于Wikipedia:合并请求和Wikipedia:移动请求的使用率不高，现发起社群调查

[编辑]

本主题或以下段落文字，移动自WP:VPO。执行者：--J.Wong 2019年4月21日 (日) 06:49 (UTC)。[回复]

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行人： Willy1018（留言） 2019年1月29日 (二) 06:23 (UTC)。[回复]

一、如果您要移动一个页面，您会先上手操作，还是先提起移动请求？

二、如果您要提起一项有关合并两个页面的讨论，你会去对应条目的讨论页面提起合并请求，还是提起页面存废讨论选择“(±)合并”选项？

抑或者，直接上互助客栈的条目讨论板块、其他板块讨论？

--云间守望 2019年1月29日 (二) 03:24 (UTC)[回复]

建议完全整合合并请求和页面存废讨论

[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：-- Sunny00217 2019年9月2日 (一) 09:02 (UTC)。[回复]

不整合：
WP:PM被强力de facto重启了，再讨论没意思，先关掉吧。Sanmosa DC17 GAN FLN 2019年8月23日 (五) 10:34 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

虽然合并请求和页面存废讨论已经在1月合并，但是在实务操作上，如果要在AFD提出合并请求，预设的做法是删除条目，不可以用其他没那么带刺的方法申请合并。最近提出合并请求的时候，首先是机器人不认受{{Mergeto}}的地位，认为{{VFD}}才是有效的提删模板，然后其他用户也以“没有悬挂‘有效的提删模板’”为由，否决我的合并请求。虽然我已经表示反对否决，不过估计以这个情况来看，保留的机会率非常高。

我在这里就是看，能不能够做得好一点。有时候仅仅是内容整合，本来的条目不至于删除，而是可以保留作重定向。看看我们能不能：

  1. 在页面存废讨论承认{{Mergeto}}的地位，或者
  2. 把{{Mergeto}}的内容转到{{VFD}}。

--春卷柯南编辑数突破二万 ( 论功行赏·刻石留名 ) 2019年4月19日 (五) 08:29 (UTC)[回复]

  • 个人认为页面存废讨论的应该使用{{vfd}}或新建其他模板，ex：Draft:Template:Merge_to-- Sunny00217   2019年4月19日 (五) 14:40 (UTC)[回复]
  • 其实为什么要将合并请求提交到存废讨论……这岂不增加存废讨论积压？如果确实需要社群参与，还不如提案到互助客栈条目探讨区。--J.Wong 2019年4月20日 (六) 05:40 (UTC)[回复]
    • 因为合并请求已经废止了。Σανμοσα y=0 regardless the value of x 2019年4月20日 (六) 07:16 (UTC)[回复]
    • 参阅过讨论存档12号及14号，虽参与者不少，但问题在从没考虑过效率差是因为合并过程及讨论本身就可以非常费时，亦非一键解决，当中变数其多，牵涉很多编辑技巧及判断。有些条目亦需要熟习相关领域的编者才能决定。本站有海量条目挂有模板，标示有问题需要解决，而合并请求与之其实无异。唯一分别就是合并请求有专页罗列。如此合并只是将积压由一处扫往另一处，而根本无法根治问题。跟因为见到某问题标示模板有很多链入，而决定删去模板一样，根本在自欺欺人，掩耳盗铃。如此决定根本思虑不周，亦令资讯不再集中。就算真的有有心人想协助解决合并积压，亦难以协助，还要花时间于存废积压中将请求逐页逐页找。如此，问题只会更为严重。上述14号讨论仅仅维持四日，亦未有明确通知，有否发过公告？有否公示？如此推翻决定，请问会有何不妥之处？--J.Wong 2019年4月21日 (日) 07:16 (UTC)[回复]
    • 然后就是如此合并会打乱程序。原本存废讨论应该就是讨论页面应否删除，偶然会有条目可能其实毋须删除而转为以合并解决，但第一目标仍然应该在讨论页面应否删除。如果合并请求亦提案至存废讨论，如此一来，存废复核是否需要去处理这些合并请求复核？但这些页面本来就不会经存废讨论合并，不是那种临界条目。如此一来，不是增加了存废讨论及存废复核负担么？存废复核亦非复核编辑决定之所。又，其实合并请求应该承接存废讨论、存废复核之条目合并请求。亦应该提供场地供社群行使合并权力，《关注度指引》就明订就算条目有来源符合段二要求，社群仍可藉讨论达成共识以合并条目。存废讨论及存废复核可以决定条目是否有关注度。但既然存废讨论及存废复核已经决定条目是否有关注度。就没道理又在存废讨论及存废复核继续打转，去决定条目是否合并，而应该移师合并请求或者互助客栈条目探讨区。而且如此合并亦会吓坏新人或者不谙程序者，存废讨论及存废复核还是应该单纯一点，只处理及讨论应否删除条目。其余编辑判断，请另觅他处进行讨论。--J.Wong 2019年4月21日 (日) 07:44 (UTC)[回复]
  • 感谢Wong128hk的说明，可以请执行这个编辑的Willy1018解释为何没有公示就改？以及附送说明关闭的Sanmosa，请看看以上并且回应。感激。--Cohaf(talk) 2019年4月21日 (日) 07:48 (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：那现在要怎么处理这个问题？稍后再议？User:春卷柯南、User:Willy1018、User:悔晚斋、User:Cohaf和User:94rain-- 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)[回复]
  • 发表些个人意见。我是比较支持合并请求并入存废讨论的（或单立一处，但未见必要），目前合并请求无人处理，就个人想法来说，是因为合并请求的处理流程不清晰，不知道何时、可由谁处理。比如说，有时看到新进提交或已提交一阵子的合并请求无人发表意见/执行合并，我不知道是否能直接完成合并和关闭讨论，希望能有操作流程/指引讲清楚。具体而言：提报多久后可着手合并（如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)[回复]
    • 基本上，这些年来，我对于合并的处理大致也是三种情况（类似上面说的英文版情况），我觉得不少人也应该和我的状况类似：第一种是明显无异议的合并，一般都是同一主题不同名称，比如中国历史与中国的历史合并，看到了自己就动手解决了（在有能力的前提下）；第二种就是挂模板，可以再分两种子类，一种是自己感觉应该是要合并的，但不是非常确定，挂上模板后可以在讨论页留言（多半的情况是不确定应该是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)[回复]
    • 《删除方针》︰“如果一个页面的内容本质上没有导致删除的问题，而标题不合乎要求（例如，名称不符命名常规或其他专题指引的要求，但内容合适的条目；适合一个命名空间的内容被错误地放在了另一个命名空间中的情形），可以直接将它移动到合适的标题下，或是提出移动请求（对于无移动权限或有争议的情形），而不需要将它提交到存废讨论”然后，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)[回复]
  • @春卷柯南、Sunny00217、94rain、hat600、Cohaf、@悔晚斋、Willy1018、Wolfch：现就此咨询各位是否同意合并请求和页面存废讨论再分立。Σανμοσα 2019年6月1日 (六) 13:13 (UTC)[回复]
  • @Wong128hk：这样的情况，我岂不是很尴尬……至少有二人反对分立。Σανμοσα 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)[回复]
  • 反对强行通过这一案的提议。在下以为，上方的所有讨论清晰的表明了如下两点：
    1. 参与讨论的绝大多数参与者反对该项提议或表示中立；且，
    2. 支持该提议的用户没有强有力的证据来完全驳倒上述反对者，全凭借自身主观感受来判断并不合理。
    另外，在下建议相关支持者以清晰有条理的方式撰写相关理由，否则会给人一种茹太素的既视感。--悔晚齋（臆語） 2019年6月9日 (日) 11:30 (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)[回复]
@Shizhao：就是改挂Merge模板并结案啊，放在Category:需要合并的条目而非存废讨论/合并请求页面中积压，等有兴趣查阅、修缮有关条目的人处置。无共识的合并同上，继续在相关条目中编辑、条目讨论页中讨论。--YFdyh000（留言） 2019年6月13日 (四) 03:22 (UTC)[回复]
目前存废积压已经900多了。合并问题并入存废只能是使存废的积压情况变得更为严重而已--百無一用是書生 (☎) 2019年7月23日 (二) 12:54 (UTC)[回复]
所以明明有人反对，什么叫de facto合并？--J.Wong 2019年8月12日 (一) 12:03 (UTC)[回复]
那事实上是处于合并状态，确实是de facto合并没错。산모사 DC17GAN FLN1 FLN2 2019年8月12日 (一) 15:34 (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)[回复]
@Wong128hk：不同意阁下这样的结案理由。要这么说的话，其实合并请求和页面存废讨论现在是介乎整合与分立之间，分立状态并不是讨论开始时“原来的状态”。我建议直接只说“维持现状”。산모사 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)[回复]
我这里只是为上面针对你的反对意见说话而已，要不然开个投票吧。산모사 DC17FLN1 FLN2 2019年8月20日 (二) 23:47 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

资料来源

[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2019年9月11日 (三) 16:14 (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)[回复]
User:Ericliu1912wiki-base页面其实道理也一样：不公开让人edit的page如果是raw data就是一手，归纳raw data的话就是二手，归纳二手（以至三手）来源的就是三手。公开让人edit的（像维基百科一样的）也是三手，但通常不可靠。Sanmosa DC17 GAN 2019年8月27日 (二) 10:29 (UTC)[回复]
另外，这也算是请求厘清方针，可以留在这。Sanmosa DC17 GAN 2019年8月27日 (二) 11:19 (UTC)[回复]
“维基百科”的话是第三手来源，如同上面Sanmosa所说。至于“维基”，由于表意不清，说不好是几手。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2019年8月29日 (四) 11:55 (UTC)[回复]

关于对合并请求的改善

[编辑]

大家好，我又来了。（怎么老是我？）这次我不是来提议AFD和PM合并的，而是来征求大家一些能提高PM的参与度和使用率的方法。我的方法有三个：

  1. Twinkle配合（就是拜托Xiplus修改参数就是了；短期）；
  2. AFD转交PM常规化（我曾经弄过专用模板【{{Delpmh}}和{{Delpmf}}】，现在应该用得上；短期）；
  3. 修改PM的做法（例如把PM弄成像AFD或VP一样的版面，直接让人看有什么讨论；长期）；

以上，其中短期那两个其实可以即时做，尤其是第二个。User:Wong128hk和User:ShizhaoSanmosa DC17 GAN 2019年8月27日 (二) 10:21 (UTC)[回复]

或者大家也请其他人过来想办法吧。Sanmosa DC17 GAN1 GAN2 2019年8月31日 (六) 07:14 (UTC)[回复]
  • 个人上面已经提议过︰
  • 参考英文维基，有将合并请求分为三类︰一、明显需要及合适，可预期没人会异议；二、需要就是否合并及如何合并于条目讨论页与其他编者展开讨论；三、有争议或难以合并，故而需要其他第三方编者协助决定是否合并。
  • 第一类可以直接进行。第二类也只是挂模板就完事。第三类才需要提交到“合并请求”。第二类，申请人应该要有意愿去合并条目。
  • 参考英文维基上列标准，第一类，个人认为可以同样毋须提交申请以至悬挂模板。第二类，悬挂模板，列于“合并请求”七日，如无异议，申请人可以执行。执行后，如遇有异议，归为第三类，再议。第三类，讨论以解决争议及困难以及达成共识为本，建议讨论最长维持八周。如八周仍未能达成共识，则应考虑暂且搁置。时机成熟时再重启讨论。如有困难，可同时提交到互助客栈条目探讨区。
  • 至于上列第一、第二项，个人都赞成。
  • 以上。--J.Wong 2019年8月31日 (六) 14:33 (UTC)[回复]

我等待一下其他意见，稍后会正式提案。Sanmosa DC17 GAN1 GAN2 2019年9月3日 (二) 11:17 (UTC)[回复]

Xiplus方面，我直接通知他。Sanmosa DC17 GAN1 GAN2 2019年9月3日 (二) 11:18 (UTC)[回复]
检索自“https://wikicn.playgoteam.workers.dev/w/index.php?title=Wikipedia_talk:合并请求&oldid=84763866”