我们可以在站点之间建立隔离墙吗？我的第一个想法是完全阻止迁移。当问题超过60天时我们已经这样做，因此有一些先例。当然，它只会对Stack Overflow1产生最小的影响：最近90天内在网站上发布的问题：
Migrated To site Away from site Migration % Site
-------- ------- -------------- ----------- ----
1498 728 770 0.20 Stack Overflow
我特别关注了ELU => ELL连接。随机询问可解决学习者网站上的大多数问题。但是，每季度从通用英语站点进口几百个。据我所知，这发生时摩擦很小。尽管有我的主观印象，但问题迁移通常还是可以的，因此我们不应该将其删除。
什么时候迁移才有意义？
在社区经理之间的讨论中，关于迁移问题的时间，他表达了两个相互排斥的想法：
不要迁移太多的历史，因为这往往会在目标站点上引起问题。
不要迁移没有很多历史的问题，因为让人们在其他地方觅食没有什么可失去的。
看看从英语和用法（主要是英语学习者）迁移过来的问题，似乎在迁移之前，通常不会对其进行回答或对其进行过多投票：
700 434 266 4.07 Super User
541 24 517 9.52 English Language and Usage
495 482 13 14.61 English Language Learners
410 157 253 4.55 Statistical Analysis
367 60 307 3.94 Server Fault
282 49 233 4.23 Electronics and Robotics
267 149 118 3.21 Unix and Linux
265 207 58 0.62 Mathematics
204 251 79 5.72 IT Security
显然，由于我们不允许60天后进行迁移，因此我们正在预先选择新问题。我还假设这是正常的网站互动。查看最近迁移的问题，似乎是将对这些问题的互动限制为评论（通常指出了主题偏离）。特别是，人们似乎在避免投票或回答可能会迁移的问题。 ，这是在挽救原本注定要删除的内容的情况下。但是我们已经有了解决该问题的现成解决方案：历史锁定3。既然旧问题只能由员工迁移，迁移就不是保存内容的实用工具。因此，我想提出一个替代的迁移理论：
迁移问题时可以节省提问者的精力。提供给误解了Stack Exchange网站复杂结构的人们。与其强迫他们在新站点上创建一个帐户，复制并粘贴他们的问题（包括标题和标签），并可能从两个不同的站点获取评论和答案，我们不如将它们移到它所属的地方。 >
这是我们为主持人编写的guide4背后的理念：不要迁移废话，请记住，目标站点可以通过关闭迁移问题来拒绝它们。如果您仍然认为需要迁移一个问题，请遵循以下准则：
如果该问题在被询问的站点上是正确的，并且已得到回答，请立即拒绝。 （如果您觉得自己很慷慨，请检查举报者是否也是应答者，并在这种情况下进行迁移。）
如果问题是题外话或未解决，并且举报者在目标站点上享有很高的声誉，请继续进行迁移。他们可能知道他们在说什么。
如果问题是题外话，但看起来似乎写得很好，并且您理解得很深，以至于认为它属于目标站点，请进行迁移。除非您真的有兴趣了解有关其网站范围的更多信息，否则请注意潜在的迁移。请务必阅读该站点的帮助/主题页面。
我很乐意收到您对这种建议的迁移哲学的反馈。但是，有一些事情可能集中在建设性上：
目前，UI迁移存在一些UI问题。虽然更改界面以符合功能目标是一个好主意，但让我们先确定迁移的目的。
如果您看到了不良迁移的示例，则仅在说明了错误的情况下进行介绍上面没有考虑的原理。基于多年的轶事证据，我的主观判断是迁移无法正常进行。但是，从汇总数据来看，我知道这是不好的分析。
你怎么看？
脚注：
公共数据中的数字与之所以在下面加上数字，是因为公共数据不会保留有关已删除帖子的帖子历史记录信息。这些数字也来自我几周前写这个问题的草稿时的数字。但这是有代表性的。
我有时会感到用户认为CM对事物在我们网站上的工作方式具有统一的看法。这是精心制作的幻想，它是通过在私人场合进行激烈的辩论，然后将胜利的观点写成供公众消费而产生的。很多时候，我们都在谈论录制对话以播客或类似形式发布。
不幸的是，Meta有时会使互联网变得更糟。 Google在搜索“历史锁”时出现：什么是历史锁，它的作用是什么？
如果您是主持人，请在您的网站上查看
/help/mod-tl。该文章还包括有关教师休息室的信息，这是您可能已经忘记的宝贵资源。#1 楼
是的，目前，迁移是一个很难理解的悲伤和沮丧之球。让我们修复它。 IMO的目标是使迁移者更轻松地进行迁移。为此：处理迁移建议，例如重复建议。当有人投票/标记建议迁移时，将该建议与另一个站点的主题摘要一起呈现给OP（类似于此建议，但在接收方，而不是在紧密投票方）。如果他同意，则为他创建帐户（如有必要），迁移并在原始站点上创建存根。这应该使用户可以在新站点上回答他的问题，因此他将在那里，并且可以进行进一步的编辑，标记等。这种方法还可以加快OP获得答案的速度；他可以立即采取行动，而不必等待社区迁移或mod来处理标志。不允许重新投票或编辑； OP已继续。
这应该是迁移的唯一途径。没有社区迁移，没有mod行动。 “迁移”实际上是“移动”，这取决于OP。1OP对此进行控制是有意义的，因为他已经可以去那里提问题了，而不必重复。
此外，如果OP没有在另一个站点上继续执行，除非对另一个站点的要求非常高，并且不需要评论中的说明，否则它对另一个站点将无用。您看到多少迁移的问题，而没有用户附加到问题上？我认为这是大多数迁移。有时我想知道这些问题的答案是否对所有人都有帮助。 （是的，答案不仅适用于OP，还适用于每个人，但是当我回答一个问题时，我知道至少有人在乎。除非不是因为没有用户，否则都是这样。）
因此，让我们代替社区做出迁移的决定，而让我们帮助问问者移动并维护他的问题。我见过这会给OP带来麻烦，但我认为我从未见过这样做。由于迁移问题的唯一方法是通过OP的操作，所以没有意义。这使情况等同于“关闭并重新发布在新站点上”，而不是使用户对他的问题的真实位置感到困惑。 。如果您不希望在某些情况下迁移问题，则不会向OP提供该选项。 （理想情况下，在这种情况下，您还应该禁用关闭/标记选项，但是我们现在不具备此功能，因此MVP不需要此功能。您可以回到这一点。）可以看到让mods进行迁移的论点，但是作为mod，我对评估迁移到多个不同站点的请求并不感到兴奋。 Mod不应被认为是正确性的仲裁者。因此，我宁愿mod迁移是一个不寻常的例外，而不是SOP。我亲眼目睹了社区迁移的成功率不高。
评论
@Makoto当社区现在建议这些迁移时，尽管（在评论中），OP可以重新提出要求，并可能会相互发布。我不知道会发生多少。这样至少我们可以帮助他重新安置它，而不是产生更多的副本。
– Monica Cellio
16-10-7在19:53
我不喜欢这个主意谁在乎OP的想法？最终决定不应该取决于他们。当然可以，让他们有机会参与讨论，但是对于其他寻求该问题答案的人来说，是否回答问题也很重要。
–hichris123
16-10-7在19:55
这绝对是一个有趣的主意，但是我不能认为仅将决定限制在OP是个好主意。
–蔡
16-10-7在20:03
@ hichris123 OP可以立即在另一个站点上重新询问该问题，因此他已经拥有足够的控制权。这实际上只是帮助他做到这一点的一种方式，而不会产生重复的问题和流离失所的存根，而这些都不是我们当前系统的结果。
– Monica Cellio
16-10-7在20:07
@Cai让社区迁移问题的问题是由于缺乏目标站点的知识而导致的高失败率。关于解决此问题的方法，有很多元问题。这将使这种情况不再发生。如果OP不随迁移一起进行，那么他的问题就可以解决了，就像他可以解决但不能解决的其他任何问题一样。
– Monica Cellio
16-10-7在20:09
@MonicaCellio我知道这是一个问题，但是我不认为OP有比mod和/或社区更好的判断力吗？
–蔡
16-10-7在20:10
@Cai，他的判断可能不会更好，但是既然他现在可以去那里问，这并不能给他带来他无法做的任何事情-只会使UX变得更好。作为mod，我真的不想强迫自己对每个建议进行评估，而且我已经看到社区经常犯错。
– Monica Cellio
16-10-7在20:14
@MonicaCellio我完全同意这一点，而且我认为总体上来说这是一个好主意，我只是认为将OP的决策限制于任何人都不会受益。 “作为一个mod，我真的不想被迫评估每个建议”对我来说听起来并不像是一个有效的论点。 Dupes / CV等都需要进行评估，只是让OP决定似乎有点过分。
–蔡
16-10-7在20:33
我认为更好的解决方案是将其完全视为欺骗性建议，并且针对mod的指导仅将迁移作为例外。在所有情况下都不需要mod进行审查并做出具有约束力的决定，但是如果需要，他们仍然可以选择。
–蔡
16-10-7在20:37
+9999，表示不通过推回原始版本拒绝迁移。那是SE上最糟糕的功能。
–内森·塔吉（Nathan Tuggy）
16-10-7在20:45
我想我们大部分人都在同一页面上Monica :)
–乔恩·克莱门特
16-10-7在22:06
@蔡：我喜欢这个主意的地方是，它把一个不受欢迎的问题的责任放在了应该得到它的人身上：OP。在当前系统下，目标站点对试图做正确的事情的源社区感到愤怒。在这种系统下，操作人员好像是在正确的位置而不是错误的位置上询问。
–乔恩·埃里克森
16-10-7在22:08
我喜欢OP能够单手迁移其问题的想法，但不喜欢迁移必须涉及OP的想法。回到类似的情况，OP可以做的就是加速流程-未经OP同意，mod或足够的社区投票仍然可以完成工作。我已经看到问题在未经OP同意的情况下迁移了（甚至可能没有OP在目标站点上设置帐户），这些问题对于目标站点仍然是有价值的问题。
–兰德·托尔
16-10-7在22:21
再考虑一下，我不确定我是否同意OP能够单手迁移他们的问题。考虑以下合理的常见情况：有人发表评论说“它属于XYZ.SE而不是”（不是因为它很好，或者因为XYZ.SE也不会采用）， OP信守承诺。如果OP能够在此之后立即转移问题，那么在知识渊博的人来驳斥第一条评论之前，那将比当前系统更糟。
–兰德·托尔
16-10-7在22:24
@RobertHarvey不错，但是请记住，一旦提出建议，他们就可以轻松地在其他网站上发布。向用户呈现此建议的理想UI将包括显示来自其他站点的主题信息（类似这样）。我已经在此答案中添加了一些内容。
– Monica Cellio
16-10-13在16:04
#2 楼
目前，迁移的问题在于，在目标站点上，提出问题并拒绝迁移是两个相互关联的不同决定。为此，VtCing在目标站点上的含义已被重载。是的，“应该搁置”和“这个问题不属于这里”之间有重叠，但是重叠并不是100％-我说这在更短的时间内甚至取决于该网站。这也意味着，在收到即将来临的迁移问题时，暂缓付款不执行他们在罐子上所说的话– VtCers实际上是投票永久拒绝，而不是临时暂缓，无论他们是否知道
不同的哲学需要不同的工具行为。除极少数情况外，迁移目前的行为无法使迁移成为理想的工具。 -麻烦：一种轻量级但可能导致目标站点首页上“废话”的增加不为零，而另一种则需要开发时间（和调试等），但对开发人员更加友好且侵入性较小目标网站。两者都会使在源站点上的迁移决策更加容易。
1。仅在VtC设为“非主题”时拒绝迁移
在目标站点上以非主题形式关闭已迁移的问题时，才拒绝迁移。
没有什么意义的是什么时候可能暂时搁置“请给我们更多细节”（不清楚），或者“请添加您所面临的特定问题的信息”（太宽泛），或者“这个问题可能是在其他地方回答”（重复）也拒绝迁移。 （基于观点的观点有点折腾：有时表示“嘿，这需要工作以要求更客观一些” ”。
作为解决方案，仅使“脱主题”会导致迁移被拒绝。出于所有其他紧迫原因，将问题留在目标站点上，以便临时搁置可以按预期进行。问题不是出于主题，而是出于某种原因仍然关闭并保持关闭状态的问题只会在目标网站上而不是在源网站上“存在”。当目标站点使用“未真正脱离主题”的“脱离主题”自定义关闭原因时，它仍会显着减少意外拒绝的频率。
似乎可以在其他地方讨论但显然需要一些工作的问题可以迁移，而不必担心它们会很快被拒绝。这样就消除了为解决当前迁移系统的缺陷而出现的“您应该在站点B上进行一些编辑”的过程。
不能完全消除担心迁移是否合适的源站点。
仍然可以在具有自定义关闭原因的站点上错开迁移拒绝，这些原因在技术上属于“非主题”类别，但实际上不应该。
2。提出要在目标站点上进行审核的迁移建议
或者，构建一些中介基础结构，以便迁移关闭源站点上的问题，然后将它们扔到目标站点上的审核队列中在其出现在首页上之前，已由评论级别的用户进行了审核和接受。如果它们被拒绝，则将其发送回去，就像迁移拒绝的当前效果一样。
这将完全替代VtC和迁移拒绝之间的当前绑定。通过传入的迁移审核而由于任何原因而后来被关闭的问题，将被视为目标站点上的任何其他问题。减少了源站点上关于是否适合迁移到目标站点的决策焦虑。源站点迁移者可以做出最明智的决定，而不会感觉到他们正在将目标倾倒在目标站点上。具有自定义关闭原因的问题，即使那不是他们的意思，也都算作主题。
网站上的所有问题都是一等公民。 />
上述开发时间，可能无法忽略。
评论
要点1的一个小问题-“关闭主题”是唯一因自定义关闭原因而存在的地方，并且许多站点的自定义关闭原因实际上并非出于主题。
–Catija♦
16-10-8在0:08
@Catija这是一个好点。与现在相比，它仍会减少误报拒绝的数量……但是就个人而言，出于很多原因，我还是选择＃2。 :)
–SevenSidedDie
16-10-8在0:10
对于迁移的问题，也许应该有一个明确的“不应迁移”的明确原因。这样，可以使所有其他接近的原因（包括“ off-topic”下的自定义原因）不拒绝迁移。
–伊尔马里（Ilmari Karonen）
16-10-8在0:23
正如@Catija所说，“脱离主题”并不一定意味着“脱离主题”，对于OP中提到的ELU-ELL迁移路径，我们有很多问题需要关闭，如Details Details（尚不清楚），并且根本没有理由锁定它们。但是太宽泛了吗？主要基于意见？是的，这些可以更容易锁定。
–内森·塔吉（Nathan Tuggy）
16-10-8在1:11
这是一个很棒的建议。我希望＃2将被实施。这是唯一有意义的。我还要进一步预测：（a）功能请求，允许将问题立即添加到多个站点的传入迁移队列中，如果不同的支持者投票赞成不同的目标迁移站点； （b）如果一个问题可以同时存在于多个传入迁移队列中，请抱怨这会增加时间开销。
–通配符
16-10-8在4:32
选项3：只是不拒绝迁移。如果问题被迁移后又被关闭，为什么不将其保留在其着陆的地方，除非有人认为它应该再次迁移到其他站点？
– Monica Cellio
16-10-9在1:58
“作为解决方案，仅使脱主题引起迁移拒绝。出于所有其他紧要原因，将问题留在目标站点上，以便临时保留可以按预期工作。” ←我认为这对ELL是完美的。我们经常以“请提供详细信息！”来结束问题。亲密的理由，希望当询问者添加了我们所要求的其他详细信息或上下文后，重新打开它们。我们对“不清楚您的要求”做了类似的操作。但这在迁移问题时不起作用-它被拒绝并且永远无法重新打开（至少在没有主持人干预的情况下）。
–user215040
16-10-9在5:38
@snailplane但不是您的“详细信息，请！”在非主题下找到接近的理由（例如ELU上有“不显示研究成果”）？那意味着紧密的理由拒绝移民。选项＃2实际上是从一开始就应该实现迁移的方式。迁移是关闭的一个完全独立且独特的功能，并且两者永远不应该在系统中进行任何直接接触。
–贾努斯·巴斯（Janus Bahs）球拍
16-10-9在11:49
@JanusBahsJacquet是的，你是对的。我个人的观点是，这是对离题关闭原因的误用（它们并不是真正的离题！），应将其关闭，以免“不清楚您的要求”。我们需要切换“不清楚”的理由才能使该建议对我们有效。
–user215040
16-10-9在11:55
我同意选项1；当问题关闭但在主题上时拒绝迁移，然后将其发送回肯定不在主题范围内的站点是不好的。我不同意备选案文2；我以前也曾认为迁移的审查队列会很好，但是由于我们不审查直接发布的新问题（通过“新帖子”除外），因此与直接发布相比，迁移带来了更多负担。首先，我们已经推迟了帮助OP进行迁移的过程；我们不要添加更多。 （此外，让我们确保来自新用户的迁移进入“新帖子”审核队列。）
– Monica Cellio
16-10-9在17:14
s /新文章/第一篇文章。我的意思是审核队列，对不起。
– Monica Cellio
16-10-9在22:50
我特别同意不拒绝重复。由于副本在关闭后会保留起来，以充当寻找类似措辞的人的路标，因此甚至可能存在一个论点，即故意迁移一个您知道在目标站点上将是副本的问题。
– trichoplax
16-10-10在20:11
我正要发布此建议，并看到您击败了我。迁移应作为“建议的迁移”进入目标站点上的审核队列，然后该站点上了解其站点范围的人员将能够接受或拒绝该迁移。因此，具有足够特权的任何人都可以建议迁移……但是，最终取决于目标站点上的社区来接受或拒绝它。
– Tim B
16-10-11在15:16
@trichoplax：据我所知，重复已经不被拒绝。
–内森·塔吉（Nathan Tuggy）
16-10-12在20:50
#3 楼
我得出的结论是，迁移通常不值得为促进迁移而付出的努力。造成这种情况的原因有很多。有些人将其用作解决劣质问题的代理。他们知道问题不在主题之列（或者说很不好），但是他们建议迁移作为摆脱问题的一种方式，而不被看作是“讨厌我的人”。
人们不理解他们建议作为迁移目标的站点范围。他们要么过时了（程序员软件工程），要么简单地误会了。因此，如果问题被迁移，则所有OP仍将被关闭，但问题不得不走到其他地方才能找到答案。指出交叉发布或问题已关闭，因为它仍然是X上的话题。“
人们无论如何都不会关注他们的问题。”我无法计数看到问题迁移到用户仍然顽固地变灰的次数。这对任何人都没有帮助。 OP不会阅读答案和/或评论，并且试图提供帮助的人员也无法获得任何反馈。
带有答案的问题通常会被转移。这实际上并没有帮助任何人。质问者可能已经看到了答案并找到了解决方案，新答案将很难与随问题迁移的现有建议答案竞争，并且这些答案可能不像在新站点上那样严格。 br />
将迁移作为用户可以做的事情来解决上述所有问题（除了“ Belongs on X”注释，但我们对此无能为力）。所有非主题问题都将被关闭并最终被删除，因此暂时不在多个站点存在一个问题将不是问题。
有时可能会迁移少数几个恒星但没有主题的问题，所有站点都会时不时地出现问题，但这甚至可能成为主持人额外标记的来源。我们必须判断它是否是目标站点上的主题，而我们无法可靠地做到这一点。
评论
我认为＃4是您可以提出的最强点。在建议迁移问题时，我最大的担心是用户不会关注他们的问题，或者在某些情况下会忘记它。但是，我确实想知道是否可以发送某种通知或某种机械过程来通知他们他们的问题已移至该站点，并且他们应该尽快创建一个新帐户，尽管我担心也将被忽略。
– Makoto
16-10-7在19:46
我会推后一个想法，那就是当OP不遵循该问题时，它不会帮助任何人。如果回答了问题（回答了许多迁移的问题），它可以帮助每个通过Google查找内容的人。
–乔恩·埃里克森
16-10-7在19:47
@JonEricson：我们可以得到这方面的一些统计数据吗？我真的很好奇，看看我是否怀疑和ChrisF暗示的是由于堆栈溢出导致的某种采样偏差。
– Makoto
16-10-7在19:48
@JonEricson-如果这是一个很好的问题，我将全心全意地同意，但是如果有任何需要进行任何形式的讨论的话，那么对整个互联网的好处就会有所减少。
–ChrisF♦
16-10-7在19:49
@Makoto：我在问题中提出了几个问题。如果您分叉我的查询，可以添加许多其他统计信息。
–乔恩·埃里克森
16-10-7在19:52
“在目标站点上顽固地变灰的用户”与永远不会在原始站点上再次参与该问题的用户完全相同。提出即发即弃问题的偷渡用户。该人口永远不会改变，并且与移民哲学问题无关。
–丹·布朗
16-10-7在20:12
@DanBron：但是确实如此。迁移需要为目标站点的用户进行额外的工作和麻烦（甚至超出了已经忍受的源站点的正常麻烦），这浪费了没有响应的用户。当然，更糟糕的是，这种方式浪费了额外的精力，导致站点间的交互作用恶化。
–内森·塔吉（Nathan Tuggy）
16-10-7在20:47
@NathanTuggy它如何为目标站点创造额外的工作，而又超出了直接在目标站点上提出的懒惰/卑鄙问题所产生的正常工作呢？如果您是说这会为源站点带来更多工作，那又如何呢？他们都是VTC：只有原因改变。我个人开始得出一个结论，目标站点应该有两个选择：“这个问题与这里直接问到的问题的90％没什么不同（包括因为不清楚，缺乏研究，需要澄清等而封闭的问题）”和“这个问题永远不可能成为话题”。
–丹·布朗
16-10-7在20:49
第三点与迁移问题无关：即使完全取消了迁移，这仍然是一个问题，因为人们仍然会说“您应该将其发布在X上”，而不是“应将其迁移到X”。 IMO，第4点不是问题，因为SE的一部分是建立对他人有用的内容的存储库，所以即使OP从未接受，一个好的问题仍然是对目标站点的净收益。答案等。（是的，@ Jon在他的第一个评论中说了什么，我只看到了:-P）
–兰德·托尔
16-10-7在22:31
@NathanTuggy问题将是迁移后的重定向，因此，如果OP返回，他将能够找到它。如果他保持不响应，那么与其他任何问题中不响应的OP相比，这不是一个更糟糕的问题。 |注意：从理论上讲，（目标站点的）3k +用户具有决定话题性问题的能力，为什么他们不能简单地为接受或不接受迁移提议投票？
–peterh-恢复莫妮卡
16-10-7在22:39
@DanBron：迁移需要完成问题的所有工作，处理一个新问题（可能有答案）的所有工作，要求一个不同的站点并由4个迁移选民推动，并确保用户付款。注意搬家。因此，我要说的是，它没有完成任何事情，并且，如果有的话，比简单地关闭问题并让用户使用SE在正确的站点上提供的内联帮助重新提出问题要糟糕得多。如果迁移只不过使站点变得更加困难，那么显然这是一项失败且无用的功能。
–内森·塔吉（Nathan Tuggy）
16-10-8的1:00
就我个人而言，这是正确的。我在网络上跟踪systemd标签。这些问题可能最适合Unix和Linux，但有时还是Serverfault或Superuser。他们不应该严格限制在StackExchange的范围内，但是大多数问题都会在此处发布。我过去常常花精力尝试完美地提出问题，但是现在我大多数人都放弃了，只是在人们问的任何站点上回答“系统的”问题。
–马克·斯托斯伯格
16-10-10在14:34
“所有主题外的问题都只会被关闭并最终被删除”，这是很明显的错误：许多关闭的问题不符合自动删除的条件。潜在的移民材料是这里的主要犯罪者，因为它具有一定的价值，可以保证投票和tick答。
– ivan_pozdeev
16-10-13在9:59
即使当前形式的迁移可能比它试图解决的问题更多的是一个问题，但我认为完全放弃迁移就像是为最初的问题投入了头脑：在错误的位置提出的问题。我们应该尝试找到一个可行的方案，而偶然的现行方案并不是迁移无法奏效的良好指标。
–马滕·博德威斯（Maarten Bodewes）
19-10-13在12:48
优点。迁移无效。在极少数情况下，可以手动（由主持人）进行处理。如果OP完全错过了现场问题，则很可能不值得迁移。目标范围也是一个巨大的问题，更不用说网络在此期间增长了，固定迁移目标通常确实很合适。 IMO唯一可能通过CV进行的迁移路径是其meta的主站点。
–抵抗是徒劳的
19/12/17在20:03
#4 楼
一些松散相关的想法：迁移还可以为回答者提供服务
例如，如果问题在当前位置处于临界状态，则必须根据具体情况做出决定由主持人或亲密的选民组成。自然不可能预测这个决定（否则这个问题不会是临界点）。现在，如果我对这个问题有一个很好的答案，我通常现在想立即回答。我不想等待问题被关闭，迁移，交叉发布，重新发布或完全放弃。我只想回答这个问题，帮助别人，并可能获得一些讨人喜欢的反馈-通过评论，接受或赞扬来表达。预测他们将被迁移，重新发布还是被丢弃。
作为答复者，我希望我的答案被有关人员阅读。一个好的迁移系统应该确保这一点，而无需我跟踪任何问题。
UI至关重要。功能是个好主意，让我们先确定迁移的目的。
当前情况的一个大问题是用户不知道如何处理自己认为放错了地方的问题：
他们是否应该发表评论以鼓励请求者在适当的站点上重新提出请求？
他们是否应发表评论以鼓励请求者进行迁移？
他们应该标记它吗？
他们应该投票关闭它吗？
最重要的是，关于迁移的许多评论都被误导了–无论是有关当前站点的范围还是有关站点目标站点。
数量不多的Meta帖子都可以令人满意地解决上述问题（尽管可以缓解这些问题）。良好的UI可以通过吸收常规用户的意见并将其转变为适当的响应来解决其中的一些问题，例如，主持人标志，与质询者的对话（例如重复项），甚至可能是实际的迁移。此外，它可能会通过让主持人或大多数选民/举报者/任何人拒绝的建议来处理虚假信息。 。部分原因是主持人需要花费一些时间，部分原因是：
弄清主持人何时可以使用“移民锤”
迁移候选者在其当前站点上处于边缘主题。作为主持人，我面临以下难题：
我应该立即提出这样的问题吗？如果我在这里做出了不错的选择，这将迅速弄清情况，并可以为提问者和潜在的回答者提供最佳的体验。但是，我绕过了社区关于问题的主题性的决定。
我应该等到社区结束问题后，再说吗？这样，我可以确保问题不在我的网站上真正成为话题，并且在迁移时不会有什么损失。但是，这可能会花费相当长的时间，并会给问问者和潜在的答复者带来更多混乱和更糟的体验（请参见上文）。在那些抱怨我没有选择以上两个选项中正确选项的人面前挥手。
评论
我认为，这整个过程应该简单易行。网站的用户可以通过公平投票（*）解决彼此之间的整个问题，仅在特殊情况下才需要mod干预。 | *：例如，以2 3k +的投票数可以在源站点上发起迁移，而正常的关闭/重新开放投票可以在目标站点上进行决定，无论是否接受。
–peterh-恢复莫妮卡
16-10-7在22:56
对于您的最后一点，这些是要求主持人做出的艰难决定。 ;-)除了我在问题中发布的指导之外，您还可以阅读尊重社区-您自己和他人的信。如果我很确定提问者在其他站点上会有更好的时间（而且问题不是垃圾），我就不会等待迁移。如果不确定，我可能会把问题留在哪里，然后尝试通过编辑和注释的组合来改进它。 （这当然有助于了解两个站点。）
–乔恩·埃里克森
16-10-7在23:04
我认为我不同意迁移为回答者服务。我当然同意它会影响他们，但我倾向于认为迁移比其他方式更可能损害答卷人。如果没有其他事情，您会错过您在原始网站上可能获得的声誉。 （显然，有些用户将在两个站点上都拥有帐户，但是我想大多数人都希望使用信誉较高的“主站点”。）这就是为什么我在上面发布的指南中建议回答问题的迁移标志减少。
–乔恩·埃里克森
16-10-7在23:11
@JonEricson：如果我很确定提问者会在另一个站点上度过更好的时间（而且问题不是垃圾），我就不会等待迁移。 –将其写入审核指南，以供大家查看，我很高兴。这并不是说我不能做出快速（可能是“正确的”）决定。除非我能指出官方政策，否则任何一项决定都会引起人们的抱怨。
– Wrzlprmft
16-10-8在6:02
@JonEricson：如果没有别的，您会错过您在原始网站上可能获得的声誉。 –假设迁移的替代方案将问题保留原状。但是现在，主要是关闭，删除或拒绝投票（至少据我所知）。在所有情况下，这个问题所吸引的见解要少得多。
– Wrzlprmft
16-10-8在6:09
#5 楼
作为两个主题相似的网站（音乐SE和音乐迷SE）的主持人，我认为迁移是一个需要解决的重要主题。使按需移动问题变得更加容易，这将是一个很大的帮助，但是需要仔细考虑如何完成。当一个站点的用户知道该站点不在主题范围内时，通常会看到指向另一个站点的信息。虽然通常是真诚的，但这并不总是正确的，并且可能导致问题不适合目标站点。例如，我看到一个用户在Music SE上发布了一个题外话的问题，但也基于观点。然后，另一位用户建议将其更适合于Music Fans SE。然后，该用户交叉张贴在Music Fans SE上，两个问题都结束了。我还看到了这样一个案例：一个问题的措词不佳，迁移到“音乐迷”的速度太快了，但实际上它在Music SE上是热门话题，而在Music Fans SE上却是热门话题。
在另一个示例中，问题被意外迁移到了Music Fans SE，而不是Sound SE上的Music SE。在Music Fans SE上，它显然是不合时宜的，并且很快得到了解决，但是进行仔细检查可以防止错误迁移的发生。
这些问题以及遇到的其他类似事件使我建议双方都进行检查
在传入和传出站点上都添加一个队列，以方便交换。
背后的想法是发布站点需要确认它不在主题范围内，传入站点需要确认它在主题范围内。分别对close＆和reopen队列采取不同的处理方式。
这使传出网站可以：
确保问题实际上不在当前网站上。
在此之前改善帖子转到目标站点
这使传入站点可以：
确保问题实际上是话题性的。确保问题没有其他问题（过于广泛，重复，基于主要意见等）。
根据需要清理标签和问题本身。
（希望如此） ），将一个站点上的用户暴露给另一站点，反之亦然。我唯一看到的缺点是，由于双方都需要参与迁移，因此该过程显然会较慢，但是希望它将带来总体上更好的迁移体验。
评论
我认为您的答案与我在相关问答中发布的答案一致：meta.stackexchange.com/questions/90118/…该答案被授予赏金，并倡导迁移的推/拉模型。
– PolyGeo
16-10-13在6:47
#6 楼
这基本上是WGroleau的建议的一种变体。迁移问题涉及两个部分：告诉问题不在所询问的主题范围内，并且同一问题（或非常相似的问题）将在网络中其他站点的主题上。当前流程将所有焦点都放在了脱离主题的位置。 （据我所知）根本不需要了解目标站点的范围。
如果仍然存在迁移，那么就需要集中精力解决问题是否会
在目标站点上设置最低信誉阈值可能是一个较低的门槛（可能在beta站点上设置100-200，在已建立站点上设置500-1000）？必须调整确切的值，以确保我们不会限制可以做太多事情的用户。）以确保建议迁移的用户至少对目标站点的范围有所了解。另一种选择是在网络上投票的独立职位（可能仅限于问题）。如果用户不符合要求，他们仍然可以提出迁移建议以供审核，但建议本身并不具有任何意义（就像低响应用户的标志一样）。
，也有可能向非钻石主持人开放以迁移到网络中从源站点没有已建立的迁移路径的站点，因为将进行检查以确保用户进行实际投票
我对目标站点的主题范围有所了解。我怀疑这样小的变化可能会大大减少拒绝的迁移，同时在许多情况下也会使钻石审核员脱颖而出。
如果需要，则可以使用已建立的迁移路径作为允许不符合该条件的用户进行迁移的方法。
评论
这几乎正是我试图建议一样，可惜我太生气专注于:-)（在我的版本，甚至迁移路径将不存在，目标站点可以简单地从列表中选择的建议，但我只是感到震惊，技术上如此出色的SE几乎不能忽略这种显而易见的逻辑解决方案。当然有我的支持。
–peterh-恢复莫妮卡
16-10-11在20:05
在30k用户特权建议中，我提出了类似的建议：加快了迁移到您站点的能力
–维尔纳
16-10-12在18:59
#7 楼
该过程应关闭为关闭主题，关闭投票者可以选择其他具有足够声誉的堆栈交换站点作为该主题上的站点
关闭关闭为关闭主题列出可能存在主题的站点
提出问题的用户可以一键点击推荐的站点之一（如果有的话）来提出问题。
关闭是因为主题脱掉了可能是主题的站点，而是链接到重新提出的问题的站点
，回答该问题的用户可以一键式在另一站点上回答该问题。
仅在没有主题的情况下才迁移问题
向提出问题的用户通知其存在主题的站点
不惩罚用户如果只是在错误的网站上提出了问题（只需单击一次即可）
迁移错误的问题的责任从迁移的社区转移了从站点到提问者，再到迁移到该问题的社区的用户。
在过程阶段2中，它看起来像：
{question}
此问题不在本网站的主题范围内。
它可能是以下站点之一的主题：
stackoverflow
...
在过程的第4阶段中，它看起来像： br />它已移至{link}
评论
您的步骤1至5实际上很出色。做得漂亮。这是如此明智和简单，所以永远不会做。
–法蒂
16-10-9在11:33
我不太了解4）-是否可以交叉发布？
– ivan_pozdeev
16-10-14在3:36
#8 楼
换句话说，迁移是我们为误解了Stack Exchange网站复杂结构的人们提供的服务。与其强迫他们在新站点上创建一个帐户，复制并粘贴他们的问题（包括标题和标签），并可能从两个不同的站点获得评论和答案，我们不如将它们移到它所属的地方
我一直都这么想迁移。我有点困惑，这是什么新知识。
这是我在网络上看到的内容：比它可以迁移。
在其他站点上，迁移可以正常进行，因为用户正在努力保存问题，并且可能在两个站点上都处于活动状态。
在其他站点上，两个站点的范围重叠，并且仅通过进行评论，以便向那些希望专家提出最佳答案的社区提出建议。
使迁移成为成熟的审核工具
到目前为止，迁移路径受到限制，以避免滥用功能。而是允许进行类似于结束投票过程的投票过程，该过程需要一定数量的投票。用户可以提出迁移目标（不一定是每个用户，请参见下文）和/或对现有目标进行投票。
达到特定阈值时，问题将被迁移。在此过程中，每次都要求提问者简单地单击“是的，我想迁移到那里”，以完全自动地将问题迁移到建议的位置。就像建议的重复项一样可以接受。
将迁移理解为跨站点审核任务
跨站点审核任务需要跨站点知识。
建议迁移问题或拒绝该问题应基于声誉。在网站上享有较高声誉的用户证明（希望）他了解该网站的范围，并且可以估计一个问题是否适合某个特定网站（或不适合）。
目前，从希望摆脱问题的站点开始，迁移是一项推动性的工作。允许有经验的用户启动该过程仅有助于迁移在目标站点上有效的问题。但是，可以（应该？）有一种机制可以使接收站点接受或拒绝迁移“请求”。
为此，请在每个站点上创建一个迁移审查队列，其中列出了其他站点的问题至少获得投票决定要迁移到该网站。这个队列基本上是关于“嘿，我们一个活跃于另一个站点的知名会员建议将这个问题转移给我们，您同意吗？”允许该队列的审阅者加入迁移投票过程，即使他们不是最初提出该问题的网站的用户也是如此。应该是允许对网站进行迁移的建议以及迁移所需的投票数。
评论
如果问题是主题，理论上可以由目标站点的3k +用户确定。我认为，为什么要将其提升到站点间mod级别，唯一的原因是SE软件不完整。
–peterh-恢复莫妮卡
16-10-7在22:35
我认为您的答案与我在相关问答中发布的答案一致：meta.stackexchange.com/a/186461/215590该答案被授予赏金，并倡导迁移的推/拉模型。
– PolyGeo
16-10-8在23:43
@PolyGeo，以防万一，在摄影方面，我们会遇到一些摄影测量学问题，这是您网站上明确存在的话题（但在摄影上也没有（非常）失落）。我希望有一个来自地理信息系统的人，他们具有专业知识（和声誉），可以将提问者引导到正确的站点，如“嘿，这个站点是关于拍摄漂亮的照片及其背后的技术，如果您想处理的话。数字，我们可以为您显示数学和工具”。我什至会赞成一个好的迁移建议。
–显示名称
16-10-9在0:11
“为此，请在每个站点上创建一个迁移审查队列，其中列出了其他站点的问题，这些问题至少被投票决定要迁移到该站点。”为此+1
–被称为2voyage
16-10-14在17:37
#9 楼
最好的系统是可行的。我是那些不确定时会定期与其他mod进行检查的mod之一。问题并不在于迁移本身是不好的，而是我们可以做得更好。我不想迁移废话。那就是说“废话”是相对的，我有时会咨询其他mod，看看它是否符合标准。我可能不是目标站点中的主题专家。
没有真正的迁移可见性，并且目标站点无法控制要迁移的内容。对我来说，这是迁移的主要弱点。我们不需要一堵墙，我们需要一个简单的边界检查站将夫拒之门外。
对我来说，解决方案似乎很简单。任何迁移都会进入队列。让目标站点对其进行分类。所需的任何编辑均在接受迁移之前完成，并且具有足够经验的mod或X用户像其他审阅队列一样对它进行查看。这样一来，我知道迁移是否良好，没有犯规，在迁移完成之前会被撤回，并且从目标站点着眼。
迁移完成后，如果是新用户，向他们发送一条消息，指出对迁移过程的解释将非常方便。
评论
首先，您说“最好的才是有效的”（与现实相反，恕我直言）。然后，您建议使用完全不同的系统，对我来说，这还不错。我真的不知道我应该放弃还是放弃:-)
–peterh-恢复莫妮卡
16-10-8在21:00
因此，我们整合了我们在幕后所做的事情，并试图缓解这些问题。让另一个网站上的人看一下，或找一个mod向另一个网站上的mod询问迁移的工作原理。让社区分类问题只是让我们所做的事情无论如何都可以扩展
–游侠怪胎♦
16-10-9在2:09
给定的站点“ X”会收到很多废话问题。这只是SO的本质。这些胡扯的问题必须解决。问题是自然的还是迁移的，这可能有什么不同？整个讨论有些奇怪。
–法蒂
16-10-9在11:42
我什至没有提到。确实，这意味着提高迁移问题的质量。我们将处理自己的废话，而无需再将TYVM铲到墙上
–游侠怪胎♦
16-10-9在13:53
我喜欢您关于边境检查站的想法。我在ELL上进行迁移的主要问题不是我们必须处理低质量的问题，而是应该帮助用户的过程实际上确实使我们的某些学习者尝试使用某种语言操作时感到困惑。他们不会流利。迁移的问题是重复的，这是很常见的。将他们的问题在一个站点上关闭以迁移到另一个站点，然后由于重复而关闭，因此许多用户认为他们提出了“不好的”问题，因此灰心。那没有帮助他们。
– ColleenV
16-10-9在14:38
嗯实际上，对编辑和拒绝的有机反馈也是很好的。
–游侠怪胎♦
16-10-9在23:54
我认为这与我对另一个相关问题的答案一致：meta.stackexchange.com/questions/90118/…
– PolyGeo
16-10-13在6:54
#10 楼
迁移是沟通失败的结果。迁移一个问题，会有人认为它应该留在原地，有人认为应该将其关闭，有人认为可以。因此，这取决于这些人中谁拥有最大的力量。使用我们的代表系统，您可能会认为最有经验的用户才拥有最大的力量。不是。这是经验最少的人。是OP。
OP可以一键删除。 OP可以迁移到任何地方。当错误提交的问题有时有时有时甚至有时不会正确地出现在正确的位置时，OP将会感到困惑。直到后来，我才意识到这是我不知道自己需要的缩进中的人为编辑。停止一次又一次地做到这一点。
我不仅在这里讲话。我一直在程序员上这样做。 （很快，便愿意将其命名为Software Engineering）。 ELL与ELU的情况几乎相同。我们是如此的糟糕，以至于我们有一个机器人在堆栈溢出中的任何人甚至提到程序员时都会在白板上通知我们。为什么？因此，我们可以阻止OP和亲密的选民在不首先了解我们所要关注的内容的情况下考虑发送内容的方式。与我们的主题（顺便说一句，这是与系统开发生命周期直接相关的问题，除了代码疑难解答和书面代码请求外）。因此，我一直在密切关注，并在我关闭时发表评论。 gnat有一个很好的习惯，即在他关闭时发表评论，而不仅仅是使用关闭消息进行交流。
我正在努力做得更好。我不只是告诉OP出了什么问题。我告诉OP怎么做。 br />
欢迎使用软件工程。我们仅支持良好的主题问题。其他站点有不同的主题。随时将您的主题带到适当的站点。首先搜索现有答案。请不要在此处未删除您的问题以免交叉发表。请参见下面的浏览和帮助链接。
欢迎是因为用户是新用户，所以友好和宽容是正确的设置。
良好的主题链接涵盖了我们关闭过的所有大多数原因。保持积极的语气可将敌对情绪降至最低。
介绍其他网站以及不同的主题，既可以识别也可以帮助您轻松地迷失并最终进入错误的网站。我绝对喜欢其他规则页面。我不建议任何人仅在其他地方提出一个问题。我希望OP可以考虑他们学到了什么，要去哪里，并适当地重新表达他们的问题。
我还希望他们先搜索现有答案，然后再闯入其他网站。他们以前可能已经足够聪明，可以搜索我们的东西，但是现在我们走到了另一个地方。
结尾处有指向游览的手势，并在页面底部提供了帮助链接，这些链接最初可能避免了这种混乱。 br />我记得看到一个精心设计的问题被否决并结束而感到沮丧。在那一刻，您正在看着宝宝死亡。您会听任何东西以弄清楚如何使其停止。这是进行交流的时间。
现在，我们可以使人们始终将内容从Stack Overflow发送到Programmers。有时候那些人是对的。有时他们错了。但是我希望他们都做的是指出REASON转到其他站点。因为这是教学的时刻。我们所有人还没有看到足够多的问题，这些问题以“我被告知在这里发贴，所以请不要怪我”开头。
，请向程序员发送更多问题。我们喜欢好问题。但是，当您派人时，请了解我们的身份，解释我们的身份，如果您没有那么多时间，请至少使用以下链接：
[Programmers](https://softwareengineering.stackexchange.com/help/how-to-ask)。 比起其他任何一页，它在教导我们关心的所有事情方面做得更好。
我们的每个站点都有一个。这是我派人到您家时使用的页面。
如果您必须投票同意迁移，请先阅读。
评论
不，我想我的更改将按照我说的做：消除其他网站允许出现不良或偏离主题的问题的印象。消息的其余部分保持原样，并且似乎是朝着目标迈出的重要一步。
–msh210
16-10-12在23:05
我认为您的消息，结合我的更改，仍会说出您的意图，同时也减少了理解其他SE网站允许出现题外或不好的问题的可能性。
–msh210
16-10-13在7:58
#11 楼
迁移必须（都）更容易触发，并且执行起来必须更加精确。正如您已经知道的那样，向Programmers迁移不良的问题非常严重，以至于我们实际上有一个机器人可以接管注释中有关迁移建议的信息，这样我们可以得到一些早期警告，并有机会在迁移发生之前提供一些明确的指导。关于程序员的最常见的误解是在这里提出不属于Stack Overflow的“较软”问题的地方。
程序员没有足够的人积极地对该站点进行审核，以使迁移有效。我们通常不能聚集足够的关闭/迁移票，而当我们这样做时，它会在数小时后发生。因此，迁移对我们来说是一种钝器。在那些我觉得Stack Overflow可以从Programmers迁移中受益的极少数情况下，我标记了版主的注意力，而不是投票赞成迁移。很少有人向程序员提出良好的堆栈溢出问题会从我们中有些人受益，他们有一把金锤可以立即移植这些问题。很小，大约为1-2％。
我很高兴迁移对ELL有效，但是我怀疑迁移有效的原因是E.SE和ELL.SE之间的分界线非常清晰，明确的从历史上看，程序员的站点范围很小。站点范围之所以难以理解，是因为人们经常会错误地理解迁移的内容。
用户已经在自动创建和关联帐户方面获得了很多帮助。我看到的迁移的唯一真正好处是消除了交叉发布。
如果SE软件检测到跨站点重复并询问OP，“您不能将相同的问题发布到两个站点。您希望在哪个站点进行发布？”
评论
我相信您，程序员在人们误解范围方面存在问题。在我可以使用审核工具的站点上，绝大多数出站迁移均成功。但是它们也是较小的站点，迁移量也相应减少，所以也许这很重要。
– Monica Cellio
16-10-13在17:42
机器人要么a）出色地工作，要么b）浪费时间。在过去的90天里，有8个问题已从SO =>程序员迁移而来。只有一个被拒绝。 （将其与统计数据比较为87，将元数据比较为60。）
–乔恩·埃里克森
16-10-13在21:27
@JonEricson，您的答案是“ a）”-只需查看我的有用评论标记的历史记录-在这些标记可能造成预期的危害之前，就剪掉了数百个愚蠢的建议。我们计划通过更改程序员名称后请求删除单个标志的功能来提高效率
– gna
16-10-14在6:36
...而我的旗帜只是机器人所做的一部分。我经常会发现bot所引用的注释以及要标记的问题已被删除。我怀疑罗伯特应该为此归罪，他经常使用Whiteboard，并且可能在bot发现的垃圾中使用SO mod power。那些对更完整图片感兴趣的人可以通过分析bot报告的Duga游乐场评论存档找到答案
– gna
16-10-14在6:48
@gnat：您让我思考了程序员上问题迁移的历史。我们没有一种简单的方法来跟踪交叉发布（每个站点的单独数据库的成本），但是我们确实知道Programmers自2012年以来一直是迁移问题的净出口商。（但是，正如Robert指出的那样，迁移现在，由于从站点开始到2011年共引入了约12,000个问题，你们所有人仍然处于亏损状态。如果您有兴趣的话，我可以在meta.programmers上分享这些数字。
–乔恩·埃里克森
16-10-14在18:04
@JonEricson关于程序员问题迁移的历史？根据SE员工可用的数据得出的数字？我绝对有兴趣，如果您在那分享，将不胜感激
– gna
16-10-14在19:07
E.SE和ELL.SE-BS之间的分界线。我有一个问题，对从ELL强制迁移的ESL显然没有用。自然地，那里没有答案，因为那是关于ESL的教学和口语。这与学习英语作为第二语言无关。
–user2617804
17-10-26在0:12
#12 楼
保持迁移的可能性很重要，我同意这是一个很好的动机： >，只要对此感到担忧，就可以缓解：
请不要“马匹交易”问题。不要迁移废话，切记目标站点可以通过关闭迁移的问题来拒绝迁移的问题。 ”，“不清楚”，“基于意见”等），他们也很可能意识到自己可以选择要发布的位置。这意味着可迁移的问题往往来自没有经验的新用户。在这种情况下，迁移由于其他条件而被拒绝的相对无辜的问题是解决以下问题之间差异的一种方法：
“好的，它们具有规则，标准和最佳做法-好而公平！”和
“这只是一个荒谬的，失控的官僚机构……”，并直接通过了buck按钮。
作为主持人，我自己的政策是大部分）对与已迁移问题有关的质量相关标准稍微严格一点，如果它们没有通过，则将其关闭的范围太广/不清楚/等，然后花一分钟时间在必要时更具体地解释该问题，并包括指向我认为更合适的网站的链接。
由于这种态度，我们（Rasberry Pi）与包括SO这样的大型网站有很多交叉，所以我实际上很少迁移，但我经常关闭如前所述，使用cookie切割器注释ala
“更适合我们的父母/大兄弟姐妹________”。
我认为这对问题来自新手/天真的用户很有用，因为它避免了官僚沼泽的出现，并为他们提供了一些可借鉴的东西。在极少数情况下，有人会说：“难道您不可以移动它吗？”在这种情况下，我要么做，或者更可能地我不做，然后再进一步解释为什么我觉得这个问题首先需要投入更多的工作。如果他们已在正确的方向上给出了一些提示，则可以考虑一下。他们仍然可以总是打开另一个帐户并剪切粘贴，但是在那种情况下，问题至少并没有真正恶化，如果问题没有通过其他地方，而不是拒绝迁移，那么问题就会转移回来。 （希望）坚定不移地提出“要考虑并解决您的问题”。
1。尽管我承认人类会偶尔因为狮子而把人们扔到狮子身上，但这不是狮子的目的吗？
评论
您自己的不迁移的策略（作为mod）只能关闭。原因是您要避免与其他站点和mod发生冲突。为此，您宁可驱逐SE网络的新用户，也可以帮助他们找到更好的站点（如果他们从错误的站点开始）。 SE的系统目前鼓励您采取这种行为，但请不要忘记：所以这不行。如果可以解决，则不支持不良系统。不幸的是，@ JonEricsson的提议进一步恶化了它，但也许不会永远如此。
–peterh-恢复莫妮卡
16-10-8在18:29
@peterh您已经在我的嘴里说了很多话，由于某些更广泛的对话，我会无意中认为。首先，我确实要迁移，这很清楚。我在任何地方都没有说过类似的理由，因为我“想避免与其他站点和mod发生冲突”-TBH我不太在意。我关心的是与帮助新用户找到其他站点有关的一切，因为当另一侧关闭了迁移的问题时，它会被退回，这使我感到困惑和无益，因此，我宁愿在本地关闭并提供链接到另一个站点（如果也有人）
–金锁
16-10-9在15:25
懒惰地削减n'粘贴BTW，我认为这不是通过迁移“帮助”他们的有效借口）。 ...如果我将上述政策明确化，意味着我将“不清楚”，“过于宽泛”等作为优先事项，并且我认为应该予以优先处理，即不以存在的名义直截了当，便会有所帮助有用，因为它不是。
–金锁
16-10-9在15:26
我确实认为可以缓解此问题的一项网络策略更改是，接收站点是否可以选择退出迁移，因为该问题被认为是脱口而出，但由于不相关的原因也可以关闭并保持该问题已被发布。那里。现在情况并非如此。我收到一定数量的移民胡言乱语，以公平对待施加于其他所有人的标准为准。这反弹了迁移，不是因为它偏离主题，而是由于其他原因，我认为这给答案中描述的毫无意义的官僚主义印象。
–金锁
16-10-9在15:26
如果您至少提供一个链接，我认为它会更好，但是我认为，没有真正的理由反对仅由用户级投票处理的简单而自动的迁移系统。我认为迁移不应该是罕见的或例外的。相反，我认为来源方的社区应该决定要约（因为这是要约，而不是请求），而目标方的选民应该决定他们是否接受。我认为它像太阳一样清晰明了，而且自从多年以来，这不是正常的做法，这只是不合理的禁忌。
–peterh-恢复莫妮卡
16-10-9在15:30
很抱歉，如果您认为我已把事情告诉了您，但尽管我不是一名国防部长，但多年来我一直在思考，询问和调查此事，因此，我知道例如移民问题多次导致领土冲突在网站和国防部之间。我也很清楚，mods的重要目标是避免发生任何冲突情况。这在他们（您）的角色中完全不稳定，但是不幸的是，尽管他们可以在其他SE网站上得到公平的待遇，却导致许多好内容的关闭（后来删除）。
–peterh-恢复莫妮卡
16-10-9在15:34
对我来说，一个严重的问题是，作为较小站点之一上的mod，如果我等待离开某些明显偏离主题或质量低劣的问题，并由5个用户投票关闭，这可能很容易就花了一周的时间，因为我们只需由于所有网站都采用“一刀切”政策，因此没有足够的用户拥有足够的声誉来完成工作。这只是浪费每个人的时间，一次又一次地造成了毫无意义的官僚主义印象。快速有效地为每个人的利益处理这些问题是我角色的重要组成部分，也是锤子的作用。
–金锁
16-10-9在15:34
@peterh“迁移问题多次导致站点和mod之间的领土冲突。” ->我相信有时候这是对的，但是近两年来我从未在其他mod上遇到任何令人难忘的问题，所以我不知道这个问题的严重性。
–金锁
16-10-9在15:39
我也知道，小型网站通常比大型网站更友好，尤其是对于新帐户而言。因此，我对这个问题的苦难主要不在您的事上，尽管我经常感到非常难过，因为我看到一个站点随着它的发展而越来越敌对。我认为，小型网站的mods可以更紧密地合作，他们可以充分学习彼此的范围，以建立“移民联盟”，这将带来广告和网站的增长，而您不必犹豫快速解决问题，但又是题外话。
–peterh-恢复莫妮卡
16-10-9在15:40
“此外，我知道小型网站通常会更友好”->我喜欢这样思考，尽管我认为这可能会引起争议，但我看到我们以及大型网站的跨界活动提供了机会，向人们简要介绍较大的SE家庭，这就是为什么我很乐意提供链接，却又犹豫不决，因为我在上面半开玩笑地说，把人们扔到狮子身上，例如S.O. “我看到一个站点随着它的发展而变得越来越敌对”->可能是；当每天只处理十几个问题时，结实而友好的联系可能会更容易。
–金锁
16-10-9在15:47
如果您在这种情况下没有问题，则意味着您在内部模组合作方面做得很好，并且可以避免或防止冲突。但是，要做到这一点，您必须关闭问题，因为在具有类似主题的网站上快速关闭网站可能会得到更好的处理。
–peterh-恢复莫妮卡
16-10-9在15:47
我认为没有足够的审阅者，因此，即使在非例外情况下，mod也必须介入以加快审阅过程的问题是非常不幸的。我不知道该怎么办。我认为SE基本上忽略了这个问题，它表示：扩大您的站点，问题将自行解决，并且与其他小型站点的mod进行迁移合作可能会导致这一方向。
–peterh-恢复莫妮卡
16-10-9在15:59
#13 楼
在此讨论中，很多都将迁移视为端到端的过程，必须处理对站点和所有参与者的所有可能影响。它包括复杂的规则，特殊条件，对目的地站点的审查和批准，取决于问题如何到达的不同问题标准等。如果将其重新构造为简单的“重新发布帮助”，几乎所有这些都将消失。 br />与没有迁移的过程相比，迁移不需要更加复杂。如果没有迁移，那么题外的问题将被关闭。
如果我们知道主题在另一个网站上涉及，我们建议该人员在该网站上提问。
如果他们在另一个站点上询问，并且不在范围内，则会在该站点关闭。
那是基线。引入迁移的唯一原因是使SE对用户更加友好。迁移的整个画面可以看作只是将OP节省了重新发布的工作。其他所有内容均与基准相同。
仅迁移OP同意的那些问题的想法解决了很多问题。
迁移（或缺乏迁移）可以过滤掉明显的废话。但是，成为其他站点范围内的专家并不是一个站点的用户或主持人的工作。如果我们要帮助将问题路由到可能更好的站点，则我们的职责应该只是帮助用户最大程度地减少重新发布的工作。
不管问题如何到达那里，要由目的地站点自己执行内务处理。如果用户首先知道在那儿张贴，或者因为建议而这样做，他们还是会这样做。问题的到达路径应与处理方式无关。
会有一定程度的滥用，例如人们迁移废话而不是关闭废话。那就是做生意的成本。无论如何，大部分垃圾都会通过重新发布最终出现在另一个站点上。我们不需要整个基础架构来阻止它。只需忽略问题的出处并正常处理即可。
主持人有足够的工作要做。一个站点的主持人无需与其他站点的主持人讨论是否需要此问题。 SE网站由社区主持。我们依靠经验丰富的用户的判断。如果这些用户要解决一个离题的问题，并相信他们可以通过将OP迁移到一个更好的站点来完成OP，那么这应该是它的范围。目的地站点应该像OP将其发布时一样处理它。
#14 楼
如果问题更适合其他网站，为什么不能简单，轻松地将其移到该网站？我很抱歉遇到您最忌讳的一个禁忌，但请注意：我也冒一点风险。
实际上，您根本不会在整个帖子中都回答这个问题。
“我们可以在站点之间建立隔离墙吗？”
不，您不应该，但是您可以。这是SE网络中完全没有意义的非理性禁忌之一。
您对迁移的真正问题是什么？
是的，我知道它们可能是站点之间领土冲突的根源。我们都知道-尽管我敢肯定，您永远不会承认-不断回避，强化，缩小问题迁移的唯一真正原因是迁移会造成领土冲突。根本没有其他理性原因。但您知道，应该以更好的方式处理此原因（例如，如果目标站点接受了问题，则让他们投票给目标站点）。禁止。
你说，“它将产生最小的影响”，是的，这是事实。因为基本上已经禁止了问题迁移。在一个健康的系统上，迁移问题将如此简单，普遍，例如关闭。
我认为，在站点之间使用这样的“柏林墙”只会损害您的质量站点网络。我认为您非常了解亚当·斯密的无形手理论，它是您本国经济理论的基本概念。
好吧，如果您愿意，您可以销毁自己的系统-它是您的-但最终SE替代品将取代您的位置。
评论
没有任何实际经验主持网站的人，这是一个毫无用处的咆哮。您没有看到任何迁移请求，因为您不是任何地方的主持人。
–马丁·彼得斯（Martijn Pieters）
16-10-10在0:53
@MartijnPieters 1）我可以在我活跃的3k +网站上看到其中的大多数... 2）我从未听说过该网站仅适用于mods 3）迁移与mods无关对于审阅者而言，在目标站点上应该是10k +或3k +的事物，并且应该更容易，快速和简单4）我看不出对此有明确的论据，不幸的是，权威人士的论证是“一个有力的论据。 |您在钻石出世之前就曾是一个强烈的反移民用户，即使在那个时候，您也没有明确的论点（当时不是
–peterh-恢复莫妮卡
16-10-10在5:55
@MartijnPieters仍然100％清楚地表明SE（Inc）希望在其网络中命名为SO的大型整体混乱。迁移禁忌可能是当时SO的超级用户/ mod出于避免其“分裂”的政治意愿。但是，既然SE（Inc）选择了最糟糕的解决方案，就像多年来以来所做的那样，并且从这个意义上讲，SO不再处于“危险”之中，我认为您不应该仍然坚持这种政治要求。如果可以轻松且普遍地进行迁移，那么即使在这种情况下，SO也不会处于“危险”之中。）
–peterh-恢复莫妮卡
16-10-10在6:00
请注意，亲爱的@MartijnPieters，您也对该帖子没有任何明确的论据，只是它是“无用的rant”。
–peterh-恢复莫妮卡
16-10-11在16:23
@peterh我觉得您完全误解了这一点（或者，我想也许我已经明白了）。他们正在征求有关如何改善迁移的反馈-包括他们对备选方案的想法-而您的回答是基本上只是说“当前的系统糟透了，而您却因未解决此问题而糟透了”。即使您知道这就是他们正在尝试做的。
–安东尼·格里斯
16-10-12在12:15
@AnthonyGrist不，这是进一步缩小范围的“建议”，本质上是禁止问题迁移。您能否说出将扩大他们的观点，或者您生活在另一个维度？此外，我的观点是答案，尽管我承认我无法从愤怒中集中精力。我主要支持这种观点（尽管第二种观点可能太严格了，我认为如果3k +用户可以就主题/主题问题做出决定，则应该允许他们在迁移中也这样做）。
–peterh-恢复莫妮卡
16-10-12在19:14
@AnthonyGrist是的，这是我的看法，尽管我认为SE在技术上比任何其他全球站点都压倒性的好，但是拒绝移民就像在婚礼蛋糕上的一块沥青一样。他们完全无法解决如此琐碎的事情，简直让我感到震惊。我的主要问题是您的评论似乎更多地集中在样式和内容上。好吧，在这么生气的帖子之后，我真的不能对此抱怨，但是也许您也应该将注意力集中在内容上。检查我写的链接，它们确实是不错的建议。
–peterh-恢复莫妮卡
16-10-12在19:27
@peterh除非不是。我觉得您只能读到“我们可以在站点之间建立隔离墙吗？”。然后写下了愤怒的回应。它甚至在该部分的结尾处说：“尽管有主观印象，但问题迁移通常还是有效的，因此我们不应该将其删除。”这不是做任何事情的建议，它是思考如何最好地改善迁移的起点。
–安东尼·格里斯
16-10-13在8:47
@AnthonyGrist提案的主要重点是减少问题迁移的可能性，而不是扩大范围。当然，您可以说太阳是绿色的。如果我说，您甚至可以对我投反对票，是的，它是黄色的。我认为这个演讲毫无意义。
–peterh-恢复莫妮卡
16-10-14在12:30
@peterh从我的角度来看，感觉更像是你在说太阳是绿色的。同意这是没有意义的，因为我们已经以非常不同的方式清楚地解释了整个过程。
–安东尼·格里斯
16-10-14在12:34
#15 楼
我想基于我作为Stack Overflow r标签和Cross Validated的用户的经验给出一个观点，他们在Stack Overflow上可以投票关闭主题并迁移。这些站点之间有很多迁移。一些废话已经迁移了，但是总体而言迁移工作良好，因为这些站点的用户基础充分重叠，并且我们已经对迁移有了一个大致的了解[1、2]。原则上，尽管我不确定这些准则有什么新变化，但您建议的准则应该能很好地发挥作用。但是，需要解决的是一些技术问题：
经常发生以下情况：（i）一个（新）用户提出了一个不符合以下条件的问题：主题，但非常适合其他网站。 （ii）告知用户该问题将更适合其他站点。 （iii）用户交叉发布（无论如何，他有时这样做）。 （iv）问题被移植。现在，姐妹站点上有两个相同的问题。 （v）需要关闭交叉位置。
，因此，您应该使用技术措施来防止这种情况，并在准则中提及交叉位置。我也从来不了解关于评论的规则。有时我看到迁移期间删除了有价值的注释，有时不相关的注释随问题一起迁移。您的准则也应解决此问题。
#16 楼
这不是对所提议的哲学的直接讨论，但是我发现迁移问题不一定适合“帮助提出问题的人”模型，因此，我提供了该哲学未涵盖的一些见识，以进行扩展。 br />我与迁移有关的最大问题是作为答复者。适用于原始站点的答案并不总是适用于目标站点。因此，遗留答案可能会在新家中引起不必要的讨论。讨论是在一个应答者可能从未签署过的小组中进行的，并且可能不在意他不在意的小组中没有防御的答案。出于这个原因，我建议从目标群体中没有成员资格的用户中删除所迁移问题的答案。他们不同意的迁移。我建议，信誉良好的答案将因此而无法进行迁移。如果原始站点认为该问题不在主题之列，则剩下的选项是关闭，或者让用户对不适合该站点的问题的答案进行投票，从而使该问题可以迁移。我认为此过程的最终结果将是将某些决策过程从mod转移到用户社区。
除了我在此处添加的细节之外，我更喜欢@Monicacellio的方法。
评论
这是个好的观点。在原始站点上合适的答案在目标站点上可能不合适（例如，考虑宗教场所之间的迁移）。回答者不必监管迁移（保持沉默！），也不必在他从未发布过的网站上获得大量反对意见。
– Monica Cellio
16-10-9在2:02
哇-我实际上收到了“已迁移答案”消息
–斯科特·塞德曼（Scott Seidman）
16-10-10在1:08
斯科特，哇，很高兴听到！然后，不再保持沉默-更好。迁移答案仍然会造成麻烦（或额外的工作），但至少现在您知道了。
– Monica Cellio
16-10-10在1:54
#17 楼
假设X组的主持人认为问题A是题外话。他们认为它更适合Y组。对Y组的主持人说，让他们主持。如果答案是否定的，请尝试另一个组，或者关闭或删除。
评论
并且，考虑到3k +用户也被允许参与主题/主题决策，也许即使mods也不应因处理迁移请求而超载。这整个事情可以变得非常容易和快捷。
–peterh-恢复莫妮卡
16-10-7在22:15
因此，我对迁移感到沮丧的部分原因就是这正是主持人聊天室中发生的事情。 “这很适合您的网站吗？”其次是在各个站点的mod之间来回切换。这不是一个可怕的系统，但是它无法扩展。
–乔恩·埃里克森
16-10-7在22:17
嗯，这比只转移问题的站点主持人好。但是接收mod可以查看（或不查看）的队列可能比聊天更有效率。
– WGroleau
16-10-7在22:18
@JonEricson任何想法，为什么迁移的问题不在目标站点中以“已删除”状态开始，然后（在目标站点上）投票决定是否允许它们出现？只需对SE软件进行最少的修补，整个系统就可以很好地扩展。国防部不得不谈论单个迁移请求已经很久了。
–peterh-恢复莫妮卡
16-10-7在22:28
@JonEricson在将问题迁移到社区时不仅要分配主持人，还要分配主持人，因为当前，除了迁移可以解决该问题以外，几乎所有事情都是这样。
–显示名称
16-10-7在23:08
@Jon-如何使迁移进入目标站点上的待处理状态，以便该站点的mod批准/拒绝。对于普通用户不可见，只是要批准/拒绝的修改操作。也许是第一个站点上的mod用户的链接，以便他们可以开始讨论。
–罗伯特尼克
16-10-10在23:07
@JonEricson我实际上喜欢您下面的评论中提出的想法，我认为答案本身并未对其进行充分描述...这是“让我们在TL中探查目标站点mods”和“让我们发现”之间的中间立场。只需迁移一下，看看他们是否将其扔回去”（第二个让我发疯了！）。目标站点上的队列中包含建议的迁移，主持人或高级用户可以主持迁移，这听起来像是一个很好的快乐媒介。然后，我可以接受良好的迁移，并拒绝不良迁移，直到它们出现并耗尽用户的时间！
– WendiKidd
16-10-16在4:47
#18 楼
我想用其他一些更深远的（进一步？）的想法来扩展我的其他答案，这些想法需要单独表决。使迁移成为一种扩展行为，而不是扩展行为运动
是的，他非常想模糊站点范围的界限，这本身就有些问题。但是，迁移的一个候选问题是错误的范围或许多范围的一部分。这并不一定意味着问题过于广泛。
但是，有很多站点的范围重叠。
迁移问题不应将问题移至目标站点，但添加它。迁移过程应将迁移后的问题保留在最初询问的站点上。如果该主题不在该主题范围内（因此应将其删除），那么紧密投票是该职位的正确工具。
迁移过程使问题可以遍及整个网络，吸引更多专家，并允许他们在其网站范围内回答问题。另一方面，如果一个问题的用户决定，关闭问题仍然会阻止该问题在该特定站点上的生活。
在这里思考Conway的“生活游戏”。人们可以投票使问题在网络的另一个单元中存活，也可以投票使问题死在网络的一部分上。
好处是，在此过程中，问题可以有机地在网络中找到其“正确”的位置。 ，如果有的话。当前的迁移过程严格是是或否，可能并不适合每个问题。
评论
如果我对您的理解正确，则建议交叉张贴。这已经被建议并在以前被击落。
– G-Man说“恢复莫妮卡”
16-10-8在4:26
它还会将信息散布开来，使其更难找到。我看不出“扩展”相对于“运动”的优势是什么。 “吸引更多专家吗？”不，在提出问题的过程中，固有的问题是要确定要针对的专家，以及要在哪个站点上提出问题。我们不想用问题来模拟人生游戏。他们还活着。
–科迪·格雷
16-10-8在11:00
@Cody Gray我了解您的担忧。请注意，信息是由问题合并在一起的。显示所有站点上所有站点给出的所有答案的组合列表并标识其来源可能是将信息保存在一个地方的另一种策略。不幸的是，“不，在提出问题的过程中固有的是要确定要针对的专家”，这一决定并不像您所说的那样琐碎，因为它需要有关站点内部的知识。软件工程。不过，我的概念主要是针对合法地跨越多个站点范围的问题。
–显示名称
16-10-8在11:17
好吧，程序员是一个非常可怕的例子。没有人真正了解该网站的范围。自推出以来，它已经发生了许多变化。那里的社区（再次）正在努力改善范围并重新命名网站以反映这种变化。正如G-Man所说，交叉发布被反复“击落”的原因是，正确地进行发布会花费很多工作。必须针对您要查询的站点量身定制一个问题。对于Stack Overflow和Unix / Linux来说，Linux编程问题可能都是热门话题，但很可能在两者上阅读的内容完全不一样。
–科迪·格雷
16-10-10在10:32
#19 楼
为什么不实施交叉发布（即问题能够出现在多个站点上）？这样，您就不必迁移，只需要做的就是添加或删除出现问题的网站。当然，所有这些站点的问题和答案都必须是主题。评论
从理论上讲，这不是一个坏主意，但在实践中它很快就会变得混乱。提出问题后，提问者将在哪个站点上赢得声誉？
–乔恩·埃里克森
16-10-7在22:30
尽管这是一个有趣的想法，并且因为它是一个彻底的解决方案而值得考虑，但我看到有关标签创建的实现问题，并且人们（包括mods）对站点A上的问题/答案/评论采取了特权操作，而他们对此没有特权站点B。然后，站点B上的某人可以留下将出现在站点A上的评论-哪个站点的本地文化可以审核这些评论？如果标记了帖子或评论，将通知哪些mod？
–SevenSidedDie
16-10-7在22:32
也许标记，标记和分数应该保持特定于站点？
– reinierpost
16-10-7在22:33
这不是一个简单的解决方案，但是考虑了吗？
– reinierpost
16-10-7在22:35
我不会将其视为交叉发布（这是重复形式，但是已实现）。我将其视为与它相关的许多网站上出现的问题。在如此大的信息集上强加层次化组织本质上是局限性的，并且只会引发争议。宁可让站点将问题拒之门外，为什么不让他们采用源自其他站点的问题呢？许多有趣的问题跨越了站点的任意边界。网站只是问题的分类系统，许多问题属于一个以上的类。不要迁移，分类。
–user341668
16-10-7在22:51
@JonEricson在获得投票的站点上获得了声誉。如果不存在任何帐户，则不会获得声誉。迁移问题时，如果发件人还不是用户，则邀请发件人加入目标站点。说明这可以简化与答辩者的交流（允许评论，投票等）
–显示名称
16-10-7在23:12
请参阅此其他功能请求，以获取有关其工作方式的信息。那里有一些非常有趣的计划，但是到目前为止，他们什么都没有。
– Ben N
16-10-8在1:15
这是一个很好的解决方案，可能已经考虑过了。不幸的是，这将要求SE更改其软件，而他们不久前并没有这样做。我怀疑这是针对CM的中央决策。但是您有我的投票权-我认为您是对的，这将是理想的解决方案。我的想法（使迁移在源站点上变得容易，并让目标站点的3k +用户投票接受/拒绝）是有意调整的，因为它只需要SE软件的最小修补程序。不幸的是，这两种想法可能只有很小的机会。 :-(
–peterh-恢复莫妮卡
16-10-8在18:31
回答问题的人不必弄清楚他的回答是否也适合他不参与的网站。而且，在一些网站的组合中，人们可能会交叉提出一个问题，在该问题上答案不可能适合所有这些问题。应该允许每个站点按照其自己的有效性标准进行操作。
– Monica Cellio
16-10-9在2:04
我提出了这样的建议。到目前为止，对实现细节的担忧甚至阻止了人们对如何实现这一目标的讨论。
–拉斐尔
16-10-9在13:08
我可以看到有人担心其中一个站点的答案不是主题，但我不确定这是否真的会在实践中出现。我很少看到答案因为不在主题上而被拒绝。
– reinierpost
16-10-12在9:14
#20 楼
我的建议是将更大的堆栈交换划分为组和子组。同一亚组中不同社区之间的迁移将相对简单。英语和英语学习者网站提供了对此的说明。将这两个都放在同一个子组中，迁移可能很简单，而且相对简单。同样，“询问Ubuntu”和“ Unix和Linux”社区可能在同一个子组中，从而允许简单而简单的迁移。另一方面，Bicycle社区和棋盘游戏社区可能位于不同的子组中，从而导致这两个组之间的迁移更加困难且费时费力。当前堆栈交换的类别社区是一个很好的起点，可以在这些社区中创建更多的下属子组。
另外，创建虚拟网桥可能很有价值，在虚拟网桥中，不同子组中有两个组，迁移更有价值。
#21 楼
我的意见可能有偏见或受到影响，因为我将大部分时间都花在Stack Overflow上。我认为在原始站点的权限范围内不能确定目标站点的主题和主题。我也不会在原始站点的权限范围内决定要进行迁移的“足够质量”和拒绝迁移的“质量缺陷”。这些问题由目标站点而不是原始站点回答。我建议用户发起迁移是首选工具。如果原始站点的用户建议，则允许发布者自行移动问题。它避免了跨政府的问题，并且将控制权重新放到了发帖人的手中。如果发布者不通过执行迁移来留意原始站点的建议，则将问题作为题外来解决。我发现，大多数进入偏心的新用户只需要指出正确的方向。我可以设想紧密的耦合，并且我想有些人会问“这些站点之间有什么区别”和“这些站点应该合并”，...也许应该以ELU.SE和ELL.SE为例外，而不应该遵循网络范围内的程序。
评论
确实，ELU / ELL是一个离群值；不承认这一点很疯狂。
–法蒂
16-10-9在11:43
ELU / ELL可能是一个离群值，但在某些方面它们与SO和Programmers具有令人惊讶的相似关系。特别是，ELL不是ELU的垃圾桶。
–内森·塔吉（Nathan Tuggy）
16-10-12在20:52
#22 楼
以下是我的看法：看看您是否可以首先改进问题：
如果问题的核心适合于- SE网站的主题政策已发布，然后理想情况下应首先对其进行编辑和改进。
但是，如果问题的核心不是SE网站的主题，则将其发布继续，那么也许可以迁移。
问题真的需要迁移吗？
如果可以轻松或快速地回答问题，并且您知道有效答案，请尝试提供帮助。 “ SE网站可能是一个更好的问题提出者，然后才通知OP您打算迁移该问题。
总是请OP进行澄清：
不要承担任何事情。如果您认为OP应该更多地澄清他的问题，那么请以礼貌的方式要求他或她这样做。为澄清起见，并且有99％的把握确保它即使在SE网站上也不会成为主题，即使它有所改进。是否打算将其迁移到？
想象一下您要迁移到计算机科学SE的问题。您是否检查过并确定问题是否在那里？您还没有完成。
也许这个问题更适合理论计算机科学SE，而不是普通计算机科学站点。务必仔细检查！
也许没有适合该问题的SE站点，在这种情况下，如果您有有效的解决方案且答案很短/容易，或者您可以自己帮助OP，或者该问题的主题足够有趣，并且符合Area51标准，然后考虑为其提出一个Area51网站。
也许这个问题可能通常不适用于SE。即使您对此有超99％的把握，也可以考虑对Meta进行提问。我认为边缘案例应一一处理。
这个问题可能适合多个SE网站吗？
问在尝试执行任何操作之前，请先在相关的Metas上进行操作。
是否存在上述要点未涵盖的内容，或者您不确定什么？
始终询问相关的Metas，即使您认为自己可能是对的。
#23 楼
如果两个站点之间正在进行大量迁移，则站点的目标可能非常接近或部分重叠，这可能表明站点可能需要/想要合并。鉴于迁移的发生率较低在其他地方，它显然有其目的，就是将某个站点上明显不在主题范围内的内容移动到另一个在家中更重要的位置。我想为所有人提供帮助。
我们应该防止的是，人们只是在一个站点上提出问题，并依靠迁移系统将其分发到他们所属的地方。看到实际的数字，这显然不是问题（尽管您不仅要查看问题的数量，还必须查看用户发布的内容，以确保这一点，例如，如果从700迁移过来的问题来自于仅10位用户发生了什么事，主持人与这10位用户之间的静默聊天可能井然有序，或者是删除而不是迁移其特定问题的某些过滤器。
#24 楼
我同意这里所说的很多内容，也几乎不同意。这是我的迁移工作原理：当一个问题被VtC列为题外时，VtCer会被问到是否还有另一个SE站点将其作为主题。如果是这样，它将成为VtM（投票迁移）。
此时，用户会收到与提示为重复的提示相同的提示，如Monica Cellio所建议。
如果提示被接受或总共获得了5个VtM，它被搁置在原始站点上，而目标站点得到了建议。 ，因此我现在尚不确切知道类似的事情如何工作，但从本质上讲，这应该由目标网站批准或拒绝。仅当目标站点不在主题范围内时，才应拒绝它。如果是一个不好的问题，应该接受它，但由于适当的原因应立即关闭。我的逻辑有两个方面：
它向提问者传授了两件事：提问者现在知道他们应该在哪里发布有关该主题的问题（即SO与程序员，ELU与ELL），以及为什么这是一个坏问题。我在这方面几乎有亲身经历：我最初针对Ubuntu的Hyper-V样式Hypervisor问题被关闭，因为他们认为这不是企业设置，因此成为了话题。如果不是企业，我永远不会知道要求Linux等同于Windows程序是不受欢迎的。但是，按照我在这种情况下的想法，它本可以迁移到SU或Unix / Linux上，然后关闭，告诉我应该在哪里问类似的问题，并告诉我为什么这是一个坏问题。
甚至是坏问题对某人可能意味着某些可以说，我的方法是对垃圾桶进行适当分类。
为了防止人们不在乎问题应该张贴在哪个站点上，对于那些经常迁移问题的人们，我们应该实施某种类型的问题禁止和/或声誉损失系统。
评论
请支持者请解释一下您的立场？
–邓肯X辛普森
16-10-13在21:34
投票者可能不希望像这样的VtCer具有迁移到Programmers的任何权力。那家伙不仅是一个案例，请参见例如，请停止使用Programmers.SE作为您的抽水马桶，并使用新的SE Chat Bot功能来识别何时在堆栈溢出中提到了Programmers
– gna
16-10-13在22:28
@gnat这就是目标站点接受或拒绝的目的。
–邓肯X辛普森
16-10-13在22:51
这种排序表示您不知道当网站常客拒绝大量无意义的迁移而感到不知所措时，而不是享受现场的问题和答案
– gna
16-10-13在23:05
@gnat你是正确的。我从来没有任何经验。也许使用编辑审阅队列，所以负担分散在许多人之间？
–邓肯X辛普森
16-10-13在23:20
当诸如Stack Overflow之类的源站点比诸如Programmers之类的目标站点大200倍时（每天8K问题对40个问题），那么传播就无济于事
– gna
16-10-13在23:22
评论
对于您提出的更改或这些图像会有什么具体效果，我目前还不是100％清楚，但是我可以告诉您，在EL＆U上使用20K拍摄时，我会非常想念迁移到ELL的能力，从而展示出谷歌的人已经将错误的站点引导到了一个可以找到熟悉具体情况的专家帮助的地方。没有它，我们将变得更加沮丧和愤怒，仅仅是因为Google的引擎不了解SE结构的内部。就是说，我不能说两个站点之间在迁移问题上没有摩擦。@Catija这意味着85％的迁移是一件好事，对OP有所帮助，并为ELL提供了更多好的问题和流量，同时也使OT问题脱离了ELU？对我来说似乎是全方位的好处。
@Catija：数据表明从ELU到ELL的迁移中约有12％被误认为是错误的。我认为这还不错。
坦白说，只有85％的人是因为ELL的选民非常友善，不愿回答移居的问题，因为他们（我们）知道自己将陷入困境。当它们到达时，已经做了很多工作来修复它们，但是这不应该由ELL来完成。。。 d有点像垃圾桶吗？
@Catija您不应该将ELU视为发送错误的问题，而应将其视为Google发送的问题。他们一开始就在错误的地方着陆。那是我们无法控制的，期望我们充当另一个站点的预过滤器或编辑服务是不公平的。首先，您应该将它们视为在正确的网站ELL上被询问过。如果您接受Jen是因为否则他们会陷入困境，那么无论是否从一开始就在ELL上询问他们，您都将这样做。
@Catija的问题是，许多ELU亲密的选民并不十分了解ELL的范围。尽管2k信誉可能是决定您所参与的SE网站上内容的一个很好的门槛，但这并不意味着人们知道目标站点。也许只有在拥有一定目标站点信誉的情况下，一个人才能投票赞成迁移。
您能解释一下您在这里提出的建议吗？我不知道这是用于更改UI还是用于更改有关迁移或文化变革的指南。
@Helmar IMO，指望一个站点熟悉另一站点的规范是不合理的，尤其是因为它们可能会发生变化。我的立场是，首先应将问题视为已在ELL上提出，这就是迁移的整体思想。首先在错误的位置询问他们是无关紧要的。如果它们是接近值的，则应将其关闭；如果它们需要编辑，则ELL社区应对其进行编辑，依此类推。 EL＆U只是陷入困境的旁观者。如果英语学习者问有关学习英语的问题，则属于ELL
@DanBron，但这不是迁移的工作原理……我们无法VTC进行某些操作，请等待OP对其进行修复，如果已迁移，则重新打开……我们必须坐在拇指上等待它打开或发送陷入困境。
@Catija不，对于在原始站点上不在主题范围内的VTC事情没有意义，因为没有大量的编辑可以使它们成为主题。迁移它们之后，目标站点将完全像直接在站点上直接询问它们一样对待它们（也就是说，忽略了OP选择错误的站点进行询问的无关紧要的事实）。如果这意味着VTC并等待编辑，那么您应该VTC并等待编辑。仅仅因为google在他们的控制范围之外，就会误导人们，试图迫使一个社区成为另一个站点的辅助警察是不公平的。
@DanBron您无法关闭问题并等待编辑，因为迁移不会发生这种情况。如果关闭了迁移的问题，则会将其强制返回到刚刚被删除的问题所在站点，因此处于困境。您无法重新打开这些问题。
@Catija和sumelic OHHHH！我不知道！现在一分钱终于掉了。嗯，现在我有一些灵魂要去做。确实应该有两个选择：“拒绝迁移”（没有多少编辑可以挽救这个问题，这是关于独角兽，而不是学习英语）和“对待问题，就像首先被问到这里一样”（表示其主题关闭，因为它很糟糕或不清楚，但是如果有任何站点可以提供服务，那就是我们。）
我希望收到您的反馈-你们真的在乎用户的反馈吗？
@Alien先生：是的，我们愿意。现在，我们并不总是完全按照用户的要求进行操作，但是我问这个问题的唯一原因是获得反馈。
我真的不了解这项建议的最新内容。