该链接将在新站点中打开相同的问题（包括标题和标签）。如果用户未登录到其他站点，则还应建议使用个人资料副本。
这可以节省时间，并可以更有效地将问题路由到适当的站点。
您怎么看？
更新：在您回答和提出评论后，我相信标记分析是正确的方法。我认为，该消息应在键入标签后在
Post your question按钮附近出现。#1 楼
我认为这个问题实际上需要两个解决方案：1。承认他们不知道在哪里提出问题的用户：
我认为Stack Exchange组织中的“全球”位置例如：
https://stackoverflow.com/questions/ask
将是网站推荐系统的好地方。正如乔治·爱迪生（George Edison）在评论中指出的那样，这将是一项艰巨的任务，但我愿意帮助它。从统计上讲，这将是一个有趣的分类器问题。
2。认为自己知道问题所属位置的用户：
要解决此问题-OP的重点-我建议您考虑以下因素：最有用的元数据，用于确定问题是否在主题上；但是，建议添加标签后迁移问题可能会分心。如果新用户不确定如何标记问题，则可以开始输入以查看新的真棒标记建议弹出窗口。在每个标签之后建议一个站点会非常分散注意力，并对用户的体验产生负面影响。因此，如果问题属于其他站点，则在单击“发布您的问题”后应显示迁移建议。主持人迁移问题。
分类器系统并不完美。因此，它不应强迫用户迁移问题。
教育很重要，因此，如果实施了此方法，我认为用户应该从当前站点和建议站点的常见问题解答，以便他们将来可以了解在何处提出问题。
迁移的标签将不起作用，因此，如果用户决定迁移问题时，应提示他们重新标记问题，因为某些站点使用一个标记命名约定，而某些站点使用另一个标记命名约定。
那么页面如何呢，就像CAPTCHA页面一样，该页面在用户单击“发布您的问题”并说（请想象单选按钮而不是[O]）后出现：
解析内容后您的问题，我们相信您的问题可能更适合Stack Exchange网络中的其他站点。请考虑将其迁移到以下其中之一：
[O]超级用户
[O]服务器故障
但是，在我们的建议下，我们可能不是100％准确的，请可以免费将您的问题发布到Stack Overflow（最初选择的站点），前提是社区可以迁移您的问题，如果他们认为这样更适合并在其他地方获得更快或更完整的答复。 Stack Overflow
请从上面的列表中选择一个站点来发布您的问题。
然后，如果用户单击箭头，他们将看到扩展的描述：
解析了您的问题的内容之后，我们认为您的问题可能更适合Stack Exchange Network中的其他站点。请考虑将其迁移到以下之一：
[O]超级用户
适用于计算机爱好者和超级用户。如果您对…
计算机硬件
计算机软件
有疑问，而与…
视频游戏或游戏机无关的话/>网站或网络服务（如Facebook，Twitter和WordPress）
电子设备，媒体播放器，手机或智能手机，但与计算机连接的区域除外
购物或购买建议
超级用户常见问题解答
[O]服务器故障
适用于系统管理员和桌面支持专业人员，这些人以专业的身份管理或维护计算机。如果您的问题是关于...
服务器
网络
您在工作场所维护的台式机
，而不是...
在专业工作场所外联网
在家中运行服务器供个人使用
一般个人计算机故障排除
服务器故障常见问题解答
但是，在我们的建议中，我们可能不是100 ％准确，请随时将您的问题发布到Stack Overflow（最初选择的站点），前提是该社区可以迁移您的问题，如果他们认为这样更适合并在其他地方获得更快/更完整的答复。
[O]堆栈溢出
适用于专业和发烧级程序员，因为他们喜欢它，所以他们写代码。我们认为最好的Stack Overflow问题中包含一些源代码，但是如果您的问题通常涵盖……
特定的编程问题
软件算法
常用的软件工具由程序员
编程界独有的问题
堆栈溢出常见问题解答
请从上面的列表中选择一个站点来发布您的问题。
评论
+1，好主意，迁移建议确实应该在单击“发布问题”按钮后提出。我认为最多应该有两个迁移建议，仅带有标题（太多的信息和问题示例可能会使新手感到困惑）。
–亚当·马坦（Adam Matan）
2011年8月7日14:49
@Adam，我已经缩短了。这更合理吗？我没有办法解决问题，所以只提供了静态版本。
– M. Tibbits
2011年8月8日在6:17
这看起来很棒。希望能听到杰夫的来信。
–亚当·马坦（Adam Matan）
2011年8月8日在13:53
前端实现的想法很好，但是后端呢？例如，无论Siva建议使用哪个IMO作为relatedStackExchange都是非常可行的。
– BalusC
2011年8月10日在20:01
@Chichiray，后端可能包含一个NLP方法以及一个分类器/推理器。基本上，从问题的文本/标题中提取有意义的关键字并添加用户提供的标签。然后根据给定站点的数据转储，使用关键字来预测该问题适合哪个站点。
– M. Tibbits
2011年8月11日在1:21
附言我很乐意为此类系统的设计和实施提供帮助。我只是不确定在过渡期间将其托管在何处（在开发者的祝福之前），以及Stack Exchange希望使用哪种语言来实现它。
– M. Tibbits
2011年8月11日在1:25
这里提出了类似的想法，杰夫·阿特伍德拒绝了。因此，如果要执行此操作，则必须将其作为查询辅助的清除工作-我们可以使用算法来识别可能的未解决的未解决的问题，但我们仍然需要自己仔细检查结果并手动投票关闭。为了组织特定标签的清理工作，我们可以在Meta上发布一个标题为“ [[tag name] tag cleanup””的问题。这也允许对建议的清理工作发表批评。
–罗宾·格林（Robin Green）
13年11月23日13:00
#2 楼
标签可能会起作用...计算所有三个站点中与每个标签相关的问题数量，找到计数最高的标签，并建议移动（如果它在其他站点上）。
评论
好主意啊。并且它可能会提出来自姐妹网站的类似问题。
–亚当·马坦（Adam Matan）
09年9月5日在11:02
如果我以已关闭的类似建议为例（meta.stackexchange.com/questions/81209/…），在Stackoverflow上，问题将被标记为“ drupal”，而在“ Drupal Answers”上，流行标签将更具体之类的东西，例如“ ahah”或“ forms-api”，因此您不能假设最受欢迎的标签是相关的。
–狂话
2011年3月1日19:26
现在，围绕着所有SE-2.0网站，这是一个更有价值的建议，我对此提出了要求
– Tobias Kienzler
2011年3月8日在11:34
标签可能意味着某些内容，并且在不同的站点上具有不同的上下文。例如。标签上Serverfault“SSL”：关于“SSL”的SysAD主题，堆栈溢出“SSL”：规划的相关，在“超级用户”，“SSL”，“安全”等自动化这个假设标签的每个标签的问题数量和相同的名称可能会使它一团糟。
–西比尔·彼得斯（Sybille Peters）
20年8月21日在14:39
#3 楼
我为这个问题提出了以下建议：如何将新的（不是算法/宏特定的）TeX / LaTeX问题带到tex.SE而不是SO？但是，我认为以下消息会引起那些没有注意到Wiki摘录的用户的更多关注。可以将新属性（例如relatedStackExchange）添加到标签，但并非对所有用户可见（可能只是菱形主持人）。这些属性将定义标签可能更适合的网站。例如：latex标签在新属性relatedStackExchange中将具有值https://tex.stackexchange.com/。问题上具有属性relatedStackExchange的值，如果是，则可以显示以下消息。如果想更进一步，用户可以单击该框，问题可以转移到相应站点的“问问题”页面（在本例中为https://tex.stackexchange.com/）。此外，如果还没有新帐户，则可以在新站点上为该用户创建一个新帐户（在本例中为https://tex.stackexchange.com/）。
我不确定这会涉及多少工作，但是我希望这可以节省关闭和迁移不属于SO但与其他网站相关的问题的时间。
评论
真好！我认为应该有一个迁移链接，因为复制粘贴问题确实很痛苦。
–亚当·马坦（Adam Matan）
2011年8月7日下午13:39
@亚当·马坦：谢谢。是的我同意。如第3点所述，单击框或新的迁移链接可以为用户转移问题，如果没有用户，还可以在新站点中为他们创建一个帐户。
–user162697
2011年8月7日在13:42
没错，我误解了这一点。
–亚当·马坦（Adam Matan）
2011年8月7日13:52
新的relatedStackExchange属性看起来非常可行。我不知道为什么这个答案没有得到更多的赞誉？是因为提出了前端实施建议吗？
– BalusC
2011年8月10日在20:07
#4 楼
我建议您编辑标签Wiki摘录，以指示有关这些特定标签的问题可能属于其他站点。这些摘录现在显示在标签输入时，并提供了一种向新用户介绍标签的方法：
评论
一种。我认为这不适用于新用户。 b。仍然没有简单的方法来迁移问题，您必须将主题，问题和标签复制粘贴到另一个站点。
–亚当·马坦（Adam Matan）
2011年8月7日，11：51
我非常喜欢如何显示标签的新方式。真。但是，正如亚当（Adam）所述，我认为这对于新用户来说无法很好地使新用户在正确的Stackexchange网站上发布问题。
– BalusC
2011年8月10日在20:04
#5 楼
原则上讲，这是一个不错的主意，但在实践中，它有点成问题，无法使用。标签设置并迁移到给定的网站。鉴于重新标签的数量以及对标签错误的问题的投诉，我很警惕在自动化过程中使用假设1作为主要输入。
我需要查看一些关于迁移数量到有争议迁移数量的确切数字，以了解是否值得在自动化流程中用作可靠指标。
我还需要查看一些好的数字（也许现在名不见经传的数学实习生）可以工作在标记集和迁移相互映射的良好程度上。该建议是针对消息而不是自动迁移-因此没有不可逆/有害的更改-但我对消息过多问题同样敏感以及建议可能会提示不应采取的措施的问题。
我希望大脑参与其中，但是我经常看到聪明人在其他地方做愚蠢的事情，因为“系统说我应该”或“如果这是一个坏主意。
评论
为什么？如果标签组合在其他站点上更为常见，则建议进行迁移。
–亚当·马坦（Adam Matan）
2011年8月7日13:38
@Adam更新了答案以解决您的问题，并从一开始就填写答案。
– AnonJr
2011年8月10日在18:59
#6 楼
如果听起来像是个好主意，并且可能效果很好。但是，值得实施吗？跟踪问题/迁移历史记录对服务器造成的额外负担是否值得？
我不知道每天发生的迁移量。但是，如果每天只有几次，那可能就不值得付出努力/资源了。
评论
我认为该实现尚未取得成功，它将大大减少经验不足的用户和主持人之间的挫败感。
–亚当·马坦（Adam Matan）
2011年8月7日13:40
#7 楼
最好实施投票机制，因为已经针对“删除”，“标记”，“关闭”问题实施了投票机制。当然，这将考虑用户标志的权重。在我看来，这是对一个实际问题的非常直观的解决方案！或主持人即可获得结果。这就是SE的美丽，它由社区主持。我认为用一些人工建议算法破坏潜伏在这里的用户/主持人的工作是不公平的。把它交给社区，并给他们+5，以获取成功的迁移建议！ ;）
评论
现在，我们有了此功能（作为“关闭投票”的一部分），但它仍然不理想，因为它需要5票，这需要花一些时间才能在一些很少关注的标签上实现。
–罗宾·格林（Robin Green）
13年11月23日在13:46
#8 楼
太复杂了。像这样的大多数建议很容易被拒绝，因为它们被建议实施起来过于复杂。仍然建议采用简单的实现方式，即20％的工作量可以解决80％的情况。站在自己的腿上。截至2015年1月的完整列表：树莓派，drupal，joomla，Windows Phone，搅拌机，Magento，emacs，wordpress，tex。仅此而已。
评论
+1很棒的建议。什么样的“特征”？
例如，根据用户迁移历史记录，很可能属于另一个站点的单词。
赏金仅仅是为此功能要求而引起的至少关注。
我的问题与此有关。我提起这个问题时并不知道这个问题。