我担任Stack Exchange贡献者已有两年了,目前在travel.SE上最活跃。不断出现的一件事是,可以吸引两个不同Stack Exchange网站上的受众的问题,但几乎没有任何功能可以利用这些问题。
在旅行中。SE我们经常在户外遇到交叉问题。SE和SE-可能是下一个最常见的情况-但几乎所有SE网站都可能发生这种情况。仅今天,我们就遇到了一个与金钱有关的问题。SE和opendata。SE有一个与我们有关的问题。
我完全确定,这必须在任意对Stack Exchange站点之间一直发生但唯一可以利用的功能是迁移异位问题的可能性,从而使原始问题可以在两个站点之间充当重定向。
我认为错失了在站点之间建立网络的机会一个站点的用户没有意识到他们可以为迄今为止与之无关的姊妹站点做出有价值的贡献。
至少,有一种方法可以在另一个站点上“发布”问题可能对此感兴趣。可能是通过在侧边栏中列出它,那里也有到元问题,链接问题,相关问题,新博客文章和
的链接,但也可能有一些功能可以使某种形式的交叉发布成为可能。围绕跨站点问题或您可以想到的其他问题,可能会添加游戏化/徽章。
我认为这是人们将自己的专业知识从主站点传播到其他站点以建立网络的一种好方法更强大,更具凝聚力,从而使更多的注意力集中在两个站点之间受众分散的问题上。我只能想到正面而没有负面。
其他人是否有任何想法要补充,或者出于任何原因认为这是一个坏主意?

示例交叉问题:
以下是一些我在此处的Stack Exchange网络中发现的交叉问题的链接。 (以前曾将其发布为答案,但更多的人希望它成为问题的一部分。)


:流机票数据


:有可能在足够低的压力下在室温下“煮熟”意大利面吗?



:在潜在语义分析中,如何在截断奇异值后重新组合分解后的矩阵?


:如果要在过于寒冷的地区行驶,应该采取什么步骤来保持车辆足够温暖以驾驶?


:自行车辐条如何工作?


:纽约的高处允许三脚架在哪里城市?


:Twitter图像编码挑战


:如果字母J只有400-500岁,是否存在


:英国逊尼派穆斯林与家人一起访问伊朗


:为什么



:为什么Obi-Wan说如果Vader杀死他,他会变得更强大?



评论

这是一个好主意,我只是担心,如果提供了一个选项“将此问题交叉发布到X网站”或“在X网站上发布此问题”,那么不管帖子的相关性,每个人都只会选择该选项。到其他站点。

需要一些思考。也许“建议这是一个交叉问题”。也许每个站点都有一组默认的交叉站点,而主持人则需要创建到不在该列表中的站点的交叉站点,等等。

例如投票分享给社区X选项怎么样?适用于拥有5k(beta为1k)代表的用户。

另一个相关问题:对其他SE网站上的代理问题的支持|请提供将问题交叉发布到多个Stack Exchange社区的功能|从其他SE网站中选择的“访客问题”

另一个受到好评的相关问题:在多个站点上提问:“软迁移”

另外:如果每个站点的问题都是主题,是否可以在多个Stack Exchange网站上交叉发布问题?

链接的副本已有4年的历史,之前还没有真正的StackExchange网络。这个问题是关于讨论社区建设功能,以通过推广相关问题向其他SE网站介绍用户。这不仅仅是在StackOverflow和Programmers之间交叉发布。

这是一个突出好问题并使人们跨姐妹站点的想法。这并不是使情况变得更糟。我也将其从功能请求更改为讨论。因此,我邀请其他SE贡献者提供意见,以帮助发展这个想法。

很高兴看到这个想法再次引起人们的注意,另一个可能的欺骗:堆叠Exchange网络中存在重叠的问题

+1是一个很好的问题-尽管[显示名称]喜欢'%hippie%'。 ;)来自认知科学(即固有的跨领域)背景,我完全同意。问题所在的网站目前是其唯一的über标签;本体不是那么简单。

在Ubuntu和Software Recommendations上,有成百上千的问题将是很棒的主题问题。示例:askubuntu.com/questions/50170/how-to-convert-pdf-to-image

@JonW尽管您的担心可能是正确的,但这恰恰是社区的宗旨以及社区可以控制的事情。您今天已经可以在“错误的”网站上发布一些内容,用户会告诉您。我也认为在多个站点上提供一个问题不会有太大的危害。

我真的很想看到这种情况。

当问题是关于科幻或奇幻电影时,科幻与幻想与电影之间的另一个常见重叠是。实际上,不同用户在每个站点上问相同的问题很普遍,例如为什么Kylo Ren戴口罩? (SF&F,电影)

是!似乎终于有可能解决Stack Overflow / Ask Ubuntu / Unix&Linux / Serverfault难题(或更确切地说是polylemma)。

#1 楼

要以Phil的良好开端为基础,我认为这应该是有效的。
有人问问题
一个物理用户问:

自行车辐条如何工作?

此职位的物理编号为#94,0001。这是一个物理问题。
跨站点用户表现出兴趣
在两个站点上都有帐户的hippietrail正在浏览物理,并且看到了这个问题,并认为在自行车上也很适用。因此,他单击了一个按钮:
在其他站点上推荐
,这会弹出一个列表,列出他是其成员的站点,并允许他选择想要提出建议的站点。其他用户可以在问题上看到这一点,因为他们将进行密切投票:



他们可以沿跨站点推荐投票或不赞成投票。评论行或类似内容。
建议跨站点发布和对现有建议进行投票的建议仅对目标站点上的高级用户可见/可用
评论创建成功将创建目标站点和原始站点的受信任用户审阅任务。对于原始站点,他们可以投票:
迁移或交叉发布
对于目标站点,他们可以投票:
接受或拒绝
接收站点的投票“拒绝”无论如何都不会发送(它停留在原始站点上,类似于被拒绝的迁移)。如果接收站点的投票为“接受”,则它会根据原始站点投票者的选择进行迁移或交叉发布。
管理帖子ID
我们知道迁移的工作原理,因此我们忽略那些现在。原始问题在物理上的ID为#94,001,所有问题的答案在Bicycles上均得到新的ID。 data.se中的post-type可以设置为9 - Cross-post,以便能够区分每个帖子的来源,因为它同时存在于两个时间堆栈的continua中。拉丁人,死了是有原因的。
附加的其他答案将在任何具有相同交叉发布PostTypeID的共享站点上自动分配一个ID,同时在其起源的网站上分配一个正确的答案ID。
在交叉发布中投票
如果您在物理上投票时处于物理状态:

物理源职位上的投票/标志被视为正常
非物理岗位上的投票/标志对声誉/得分没有影响,但影响力显示

如果一个答案积累了太多来自不同站点的向下投票/标记,那么对于从物理角度访问该问题的人们来说,它将是隐藏的。答案可能对自行车有益,但对物理读者却没有太多好处。很好。反之亦然。因此,我们会隐藏网站社区认为不适合他们的所有不适当答案(但不要让其他网站失去它们)。
隐藏来自新用户/ Google用户的交叉帖子
对于新用户(在关联奖励级别下),对于Google抓取工具,应仅应用来自正在浏览的网站的答案。这意味着,bicycles.se答案将更适合自行车搜索词,而physics.se答案将更着重于物理学并区分搜索结果(希望如此)。新用户不会因答案不同或与不同社区标准相关的其他问题而感到困惑,而又不会输给任何东西。
主持这些问题
锁/防护将针对每个站点,并且不会反映在其他网站(无法避免就自行车的普及问题对物理问题给出好的答案)。
关闭投票的方法如下:

在原始网站上关闭▶已迁移至目标-site
在目标站点上关闭▶被视为拒绝迁移

任何一个站点的用户对问题的标记只会显示给该站点的受信任用户/主持人(对另一个站点不进行审核)社区的问题)。
我认为这是一个很棒的主意,它将减少不良的迁移,并为人们提供更好的跨学科主题综合信息资源,从而提高SE作为资源的质量。

评论


这肯定会很有趣。至于建议进行的试验,您可以查看在MSE和MSO之间共享跨站点内容的情况(很容易假设有关MSE标签的stackoverflow的问题可能是该试验的基础)。

–特拉维斯J
2014年8月5日在14:28

这似乎是经过深思熟虑的,我对此表示衷心的赞同。

–凯尔·斯特兰德(Kyle Strand)
2014年9月3日在18:31

但从切线上讲,我认为拉丁文的多元化要比英语的多元化更为一致。实际上,名词只有5种形式(它们称为“变形”),每个名词的变形类型始终一致地决定了该名词如何变化以代表多元性和句法作用。此外,通常可以根据其拼写来猜测名词是如何被拒绝的。因此,对于那些熟悉该语言的人来说,“中级->媒体”和“连续体->连续体”与“鞋->鞋”一样毫不奇怪,并且远没有“人->人”那么令人惊讶。

–凯尔·斯特兰德(Kyle Strand)
2014年9月3日在18:33

另外,我不确定拟议的投票制度变更是否完全可靠。如果投票将根据当前用户所在的站点产生不同的影响,则可能不应默默地进行;也许可以提供一个简要解释不同行为的通知,或者提供将投票视为“源站点”投票的选项(如果用户是源站点的成员)。同样,如果同一用户是发布问题的每个网站的成员,则不允许同一用户多次对该问题进行投票,并且当然决不应允许OP投票。

–凯尔·斯特兰德(Kyle Strand)
2014年9月3日在18:36

对于我们现在拥有的当前中断的迁移范例来说,这是一个很好的伪替换。实际上,在非起源站点上进行投票时的详细通知不会太过麻烦,因为UX很擅长在其他大多数地方进行解释,这也不例外。我很乐意看到这一点。

– Qix-蒙尼卡(MS)被盗
2014年9月3日18:57



@Qix但是,它得到了处理,这是一个很小的皱纹。

–凯尔·斯特兰德(Kyle Strand)
2014年9月4日下午16:55

交叉发布会具有“共享”链接吗?

–尼古拉斯·拉乌尔(Nicolas Raoul)
2015年4月1日在6:52

源问题所有者的好处显而易见:通过交叉发布,他使更多的用户看到他的问题,并可能获得更多的好答案。对于目标站点上的用户回答交叉发布的问题,我没有任何好处……即使他从站点上的用户那里得到了一些代表,他也会被“明显的责备”(没有代表效果)来自其他网站上的否决票?你能澄清一下吗?该问题如何在Bicycles网站上为用户服务???

– SPArcheon
16-10-22在19:10

我认为这是一个好主意。我希望SE员工至少在状态标签上做出回应。

–读取缓冲区
16年11月6日在21:18



@TheBitByte实际上,我是SE员工(尽管写这篇文章时不是。)这是我们已经开始解决的问题,但存在很多技术障碍。

– jmac
16年11月7日在8:29

哦,我没有注意到您是工作人员,一定错过了钻石标志。顺便说一下,技术上的障碍是什么?

–读取缓冲区
16年11月7日在10:58

就像凯尔(Kyle)所说,投票可能是要考虑的事情。我不确定在不同网站上使用不同的投票分数是否会很好。特别是如果rep没有适当更改。但是无论哪种方式,这似乎都不是一个巨大的障碍。也许对于其他站点上具有足够代表的用户,可以向他们显示“将其视为对[Bicycles] .SE的投票?”的选项。通常,分开投票可能会使处理关闭或锁定或其他职位更为容易。

– Cullub
19-4-22在23:04



@Nicolas是的,交叉帖子将具有共享链接-不同的链接取决于您正在查看的站点。基本上与他们已经工作的相同。

– Cullub
19年4月22日在23:06

@SPArchaeologist用户不会是决定是否交叉发布的用户。两个站点上的Mod或高级用户都可以这样做。这样,这不是用户的选择,就像他们的问题是否在HNQ上不是他们的选择。也许是一个不好的例子,但我认为这很清楚。

– Cullub
19年4月22日在23:10

“对于新用户(在关联奖励级别下)和Google抓取工具,应仅应用来自正在浏览的网站的答案。”我不喜欢此答案如何建议根据用户声誉更改搜索结果。我在StackExchange上寻找答案,我应该看到所有相关的帖子...

– kipbits
19年4月23日在18:50

#2 楼

我想这可能会更好,而不是将相同的问题显示在多个站点上,并显示在这些站点的搜索结果中,而只在数据库中保留一个问题,而不是在多个站点上多次发布相同的问题。

我知道这会带来一些挑战,例如确定(每个站点)应该和不应该使用哪些标签,但这将是了解不同社区如何贡献力量的一种很酷的方法。回答相同的问题。

然后答案中可以包含一个图标,指示用户从哪个站点进行回答,并且徽章或声誉仅用于该站点,从而简化了此过程。此外,它可以使一个站点的用户了解其他社区的情况,并可以在姐妹站点上吸引更多用户。

通过让OP指定要访问哪些站点,这种方法也可以工作分享(这些网站可以在其各自的网站上关闭它),或者这可能留给信誉足够高的审阅者-但我认为这两种方式都可以。

评论


与此类似; meta.stackexchange.com/questions/243299/…

–atomh33ls
16年1月20日在15:02

我喜欢带有图标显示其起源于站点的感觉。也许只是浏览器的图标。那将很容易。我认为让OP在其他地方共享他们的网站会遇到问题(尤其是新用户希望尽可能地共享它)。高重复率的建议和审查可能会很好。

– Cullub
19年4月22日在23:20

#3 楼

我会支持这种功能。

我觉得SE网站的细分已经有点过分了(例如,SO,代码审查,程序员和CS)。这导致普通用户(如我自己)更加担心在哪里发布而不是如何正确发布(部分原因是因为担心被更坚决的用户责骂)。就我而言,它最终使我完全放弃了帖子,而在其他地方寻找答案。
我认为交叉发布将使普通用户可以在最合适的网站上发布问题(而不必担心无法到达某些问题)可能感兴趣的专家),并使用交叉发布功能尝试建议将该问题发布在可能也与该问题相关的另一个网站上。

我在这里确实同意其他一些答案,即在某些情况下,一个涉及多个SE网站的问题可能表示一个不好的问题,但我相信这些情况并不是大多数。无论如何,我认为这种功能如果得到适当的审核,将不会导致发布更多的不良问题。

评论


警告:您的问题必须在2个网站上成为话题,这比在1个网站上成为话题更困难。

–尼古拉斯·拉乌尔(Nicolas Raoul)
2015年4月1日,凌晨3:42

奇怪的是,具有相似范围的站点(SO,代码审查,程序员,CS)对于一个终点和另一个起点的精确度要高得多。这些都不是跨站点共享的理想候选者。功能提案中的示例要好得多,例如自行车和物理学。

–通配符
16-10-17在23:23

我不确定我是否同意SO和程序员(例如)之间是否有明确的界线。更像是渐变。

–诺维萨德
16-10-21在19:20

@Wildcard,当然是您选择的四个,但是(至少根据我对线条模糊程度的了解),在U / L上至少有SU之一,有很多问题同样适用(并且经常重复)或SF和SO,也许还有特定于应用程序的站点。也许还会问Ubuntu和/或Ask Different。

–Random832
17年1月4日在20:57



如果实施此操作,则某些类似的站点实际上可能是可删除的...一些数学站点,当然还有E&LU + ELL ...那么,最后一个站点可能并不是一件坏事...

– TylerH
17年1月4日在22:04

支持和反对的几个论点:meta.superuser.com/questions/12007/how-to-choose-a-community

– Pavel
17年1月11日,19:38



#4 楼

我不认为应该有任何交叉功能允许在多个站点上发布一个问题(如何为两个站点的用户计算编辑/关闭特权?)。网站的设计应使主题交叉应该是一个例外,而不是规则。

但是,有许多共同感兴趣的领域,因此,我投票赞成在网站之间建立更牢固的链接。例如,通过在左侧添加网络范围内的链接和相关问题部分。该问题始终属于一个站点,但是在其他站点上浏览相关问题会更容易。例如,它看起来可能像这样:

链接(旅行)


问题1
问题2
问题3

链接(其他SE)


/>问题4(户外运动)
问题5(体育锻炼)
问题6(摄影)

相关部分的实施会比较棘手,因为从网络范围来看因为复制必须比基于单词的知识更聪明(我不认为Pets的人会乐于看到每隔两个速记问题都涉及Python编程问题)。

评论


抱歉,luksaz ..我认为此功能将非常有用..它使安静的时间有点延迟,因此在dba.stackexchnage.com上提出了关于SO的问题..这是一个不错的功能

–达瓦尔
2014年1月7日在16:30

我认为跨站点的“相关部分”将是一个非常有趣的机器学习挑战,尽管仅使用tf-idf就可以了。但是,如果存在一种称为“ cat”或“ dog”的编程语言,则可能会更糟(-:但是,将文章提名为其他站点的相关部分的一种方法可以防止这种情况,但这样做的代价是无法自动发现。

–hippietrail
2014年1月21日在2:23



我认为Łukasz웃Lツ恰好在这里。交叉发布可能会降低问题的总价值,同时提高认识并提供进入新社区的机会,有助于所有交流。我建议“其他SE”部分通过一个简单的信誉/标记机制(至少在开始时)来完成,以保持很高的信噪比。实际上,如果通过标记/信誉来完成,则可以将它们放入另一个SE的标准列表中,并清楚地表明它来自另一个SE。希望可以最大程度地减少系统更改。

–kobejohn
2014年2月28日在16:31

实际上,我所写的内容已经被提议作为功能请求:meta.stackexchange.com/questions/59569/…

–努比亚水手
2014年4月2日14:50



#5 楼

我喜欢这个主意,并在一定程度上支持基本原理,因为它可以帮助一个问题吸引感兴趣的听众(而不是造成混乱,低落)。

一些潜在的挑战:


用户权限-具有编辑,删除等功能-在共享站点上的权限大于原始站点...可以吗?
标签-如何处理这些标签?

实施思路:


将其添加为审阅类别(?)-供审阅者包括/排除提名共享的问题?
添加新特权类别(?)-例如,一个人想提名一个要与SO共享的问题,就必须对SO进行一定程度的代表?

--EDIT-

重新阅读这篇文章/稍后会出现的一些答案...

我认为这里没有引起太多关注的一个观点是交叉适应性交叉发布问题的答案。一个问题与两个站点相关是一回事(在这里@jmac很好的答案中使用“自行车辐条如何工作”示例);但是答案在两个站点上都可能是另一回事。例如,我可以想象物理学SE的读者会对描述不同类型的力以及如何使用物理学公式建模的答案更感兴趣。我可以想象自行车爱好者的SE网站上的读者会对完全不同的答案感兴趣(也许更着重于在公路上/越野时使用其他车轮设计进行性能比较)。

我对此没有什么好主意,但似乎应该成为讨论/提议的解决方案的一部分。

#6 楼

这已在国际站点上得到了大致实现,用于从英语的Stack Overflow链接到用其他语言编写的规范问题的用例。

如果您在Stack Overflow上遇到某些问题,并且您的浏览器语言是设置为我们支持的一种非英语语言,您可能会看到一个小横幅,告诉您我们在[语言]网站上有一个几乎相同的问题,并且答案的质量相当。这是由用户在国际站点上指定经过审查和放置的链接对(源自英语站点,登陆国际站点)起作用的。

目前,所有这些功能都可以在代码库中无法正常运行的东西上运行,并且可能要等到Channels的功能更加完善后,才能进行。但是,确实存在某些功能。

我个人希望最终得到与这里以各种形式提出的建议相似的东西;减轻SO与软件工程等站点之间的分散将是很棒的。但是,我无法给出具体的实施时间表或最终的时间表。

我将其标记为延迟,因为这是我真正想探索的东西,但是我无法保证何时能够做到。我可以说,一旦资源可用,对我来说,优先考虑使国际站点得到的粗略实现更加“适当”并得到不需要用户脚本的UI的支持,这对我来说是头等大事我希望看到的东西列表顶部附近的东西,只要我们能够提供,便会引起更多关注。

评论


这也是一种深层次的可能性,关于SO的一些问题在语言上与依赖注入和控制反转无关,可以通过一些与软件工程中某些问题的突出链接来很好地加以补充。精确的用例,而不是对更广泛的群体具有更一般的可见性)。关于如何工作的思考变得有些复杂,但是我非常热衷于最终将其充实。

– Tim Post
17年12月26日在17:51

#7 楼

跨站点问题关联

我建议将问题关联机制扩展到所有StackExchange站点。
它已经在俄语的StackOveflow和英语的StackOverlow之间的机制之间起作用了。 br /> [链接到相关问题]。



如果在不同的StackExchange网站(具有某些主题交叉点)上提出了非常相似的问题,我们可以在关联下显示链接问题This question has answers on [StackExchange site of associated question]. [link to associated question].

#8 楼

我完全同意,随着交易所/社区数量的增长,许多重叠的问题正在社区之间蔓延。

我也同意迁移在“不正确的”社区中发布的问题


OP参与并张贴在原始社区中,因为他认为这是所属的。他已经表达了自己对“正确”社区的看法。
一旦问题被迁移(如果可能的话),原始社区中发布的内容通常就会丢失。哪个社区是唯一的“正确”社区是高度主观的,所以Stack Exchange通常会避免这种情况。 -让社区将问题转给其他社区。

我也很喜欢您的解决方案;但是,作为开发人员,实现起来似乎更加复杂。我认为,可以通过允许其他社区看到所提到的问题,但仍然允许它们保留在原始社区中来解决很多问题。

#9 楼

您有一些要点,但是当前无法使用的原因是因为每个站点的点系统各不相同。

徽章主要是每个站点单独使用的。

如果有更多的徽章添加到堆栈溢出中,并且基于点/其他站点的声誉。

我不一定认为在已经有很多金/银/青铜徽章上增加更多的徽章会很好。我认为可行的方法是创建白金徽章或类似的东西,这与您的总代表得分超过1000点或类似情况的站点数量有关。

评论


好点和徽章真的只是玩具。是否以及如何实现这些取决于SE开发人员。主要部分是让人们在站点之间流动。在您的整个网络中(而不只是一个站点)进行活动的白金徽章创意是一个好主意!

–hippietrail
2013年12月30日3:29



如果您是出差旅行,您将获得旅行代表/徽章。如果您是从航空来的,您会得到航空代表/徽章。为什么这会使问题复杂化?每个问题都会有一个基于其起源站点的postID,因此您可以清楚地从哪个站点访问。

– jmac
2014年2月6日在7:24

#10 楼

我建议使用“网络”选项卡,或类似的选项来显示整个网络中有趣的问题。 br />该建议与https://meta.stackexchange.com/a/219824/144630

非常相似,我建议手动显示要显示在该列表上的问题列表。
策展是由两个站点上的信誉决定的可解锁特权。

可能与:


“添加到X的跨站点列表” ,在两个站点上都需要一定程度的代表。大约100会很好,因为关联奖励有点表示“您获得了足够的Stack Exchange,可以在网络中的任何地方赢得一些尊重”。
与投票接近类似,需要具有一定特权的人4票

模型:

是的,在格式上,模型图像是不稳定的,但这只是示例。


我并不完全满意将其作为选项卡的想法,
,但我认为将其单独列出来回答站点上的实际问题确实有一些好处。
所以那些不在乎的用户可以忽略它。
(我希望交叉文章比迁移要多得多,因此将其留在主列表中可能不是很好。或者可能还可以)

#11 楼

在编写相关问题的过程中,我遇到了这个问题:多主题/跨主题问题:搜索可见性...

这个问题也与2012-META非常相似:多个站点:“软迁移”。

我想知道一个简单的补丁解决方案是否可以通过相关主题/站点的问答填写搜索结果?我认为这将有助于提高问题的可视性,并为StackExchange周围的临时用户提供更多的回答机会。

以我的示例为例:


diy_search = affinity + fan
engineering_search = affinity + fan

截至2019年4月,这两个主题之间总共只有约4个搜索结果。用来自相关主题的可能相关材料来补充这样的搜索不是很有意义吗?可能的结果可能仅限于带有相关标签的问题,并且位于指定的协调主题中。

过去两年来,针对外语主题/站点,似乎已经完成了一些相关工作,如Vadim的答案中所述,尽管我不确定确切如何工作以及是否更普遍适用。它是否只是在问题本身上做注释?如果我不公开问题怎么办?问题浏览如何?

我想建议修改搜索结果。

另外请注意,也许关联奖金可以由每个主题的特定协调主题之间存在的奖金积分和徽章代替。

评论


在您访问的网站之外显示搜索结果可能会引起混乱;并非所有标签在不同的网站上都引用相同的内容。

–fbueckert
19年4月25日在16:35

不,不会,它只会带您进入另一个主题。它们都有不同的标题

– kipbits
19年4月25日在16:36

因此,SO中的盐和烹饪中的盐不会引起混淆吗?我将不得不不同意。

–fbueckert
19年4月25日在16:40

我是说可以按主题决定...?

– kipbits
19年4月25日在16:41

idk也许这完全是废话。我真的应该回到修理我的空调系统上。夏天快到了!

– kipbits
19年4月25日在16:42

#12 楼

交叉发布是不好的。

可以在两个不同站点上回答的问题不是一个好问题。也许需要更合理地确定范围。也许询问的人需要更好地了解他们的问题,以便他们知道谁最好寻求解决方案。也许他们需要更好地了解听众并重新表达问题,以便他们清楚需要知道什么。


流机票数据->这与旅行无关。这是关于从互联网上的特定数据库获取数据。一个旅行者可能有这个问题,但这不是旅行者的问题。
是否可以在室温下以足够低的压力“煮”意大利面? ->这是两个不同的问题。 “面食需要煮熟还是需要补充水分?”和“烹饪是通过温度还是水的状态变化发生的?”它们都属于烹饪。
如果要在过于寒冷的地区行驶,应该采取什么步骤使车辆保持足够的温暖来驾驶? ->作者特别声明他们不希望提供车辆建议,而是想要在旅行期间针对特定类型的紧急情况的一般程序。您可以发布类似于应急准备/生存/荒野站点的内容,但还是要为该组专家量身定制。

我可以继续,但这是关键:

如果针对特定专家组的问题写得很好,就会激怒另一组专家。如果它胡扯或试图解决这两个群体,只会激怒他们两个。它将获得紧密投票,表明该网站不适当的性质的评论等。

我们已经允许问题中的链接。因此,我已经看到了很多提出问题的问题,然后提供了另一个网站上相关问题的链接。答案是不一样的,因为每个站点上的专业知识都不一样,应该也不一样。

可能还有其他工具条的空间,“其他SE网站上的相关问题”链接到显式链接的问题,并使用关键字和标签链接到其他位置的相关问题。在两个不同的网站上看到相同的确切问题。它表明对该问题所针对的专家组缺乏了解。我们不想鼓励这种行为,因为它需要尝试解决两个不同专家组的坏问题。如果用户不确定,请让他们将其发布在他们认为最好的网站上,版主可以对其​​进行移动,其他人可以对其进行编辑,以使其在正确的网站上正常工作。

不应该鼓励或支持交叉发布。

评论


对于不同的观点,您可以阅读有关以下主题的Stack Exchange官方博客文章:Pee-Wee Herman Rule

–hippietrail
2014年5月21日14:21

再一次,这似乎是一个稻草人,同意这个主意,但不同意另一个不是这里提出的主意。

–hippietrail
2014年5月21日14:24

这是不正确的。在三部曲时代,它曾经是,但仅此而已。例如,简单的bash问题是有关超级用户,堆栈溢出,Ask Ubuntu,Unix和Linux,Ask Different和Raspberry Pi的100%主题。如果我要问“如何为bash中的变量赋值”,则根本没有办法对其进行调整以使其更适用于任何这些站点。它适合所有人。它们的范围重叠。我们现在所拥有的是相同的基本问题,不同的用户在所有站点上都重复了相同的问题。这恰恰是无交叉发布规则试图避免的浪费工作。

– terdon
15年7月24日在10:40

@terdon我不同意。当然,对于明显简单且非常容易的“可商谈”的问题,有很多重叠,但是由于该答案中所述的原因,重叠在琐碎的问题之后结束。尽管如此,随着Stack Exchange迁移到单一登录并进一步整合社区,谁知道-也许他们会将整个事情变成Yahoo Answers或Quora。我希望不是,但这是他们的网站。

– Pollyanna
15年7月24日在11:17

@AdamDavis不,许多站点的范围有很多重叠。例如,在Ubuntu和Ubuntu上配置WiFi是100%关于Unix和Linux的话题,请问Ubuntu和Super User(我是前者的mod,前两个是> 20k的用户)。

– terdon
15年7月24日在11:40

@terdon请量化“站点重叠很大”。这是否意味着我们可以在一个站点上回答80%的问题,在另一站点上原样提问,并获得相同的答案?还是您在争论一些问题,可能需要对其进行一些修改以使其真正适合该网站?如果是前者,那么站点应该简单地合并(老实说,unix / linux / ubuntu是一个奇怪的情况-我们应该讨论自行车和Opendata,或者stackoverflow和烹饪)我毫不怀疑您的经验和观点,我只是不认为这是需要解决的问题。

– Pollyanna
15年7月24日在11:46

@AdamDavis它指的是每个站点上很大一部分问题。基本上,我之前提到的6个站点中的任何bash问题都将是所有6个主题的话题。它们代表的站点百分比是多少取决于所讨论的站点。至少有80%的非盟问题也是关于U&L的话题。关于SU的所有* nix问题都将作为U&L的主题。 AU和U&L之间的区别是:i)有些东西仅是Ubuntu(属于AU),并且ii)Ubuntu用户倾向于面向GUI,因此答案倾向于基于GUI。

– terdon
15年7月24日在11:49

我的观点是,对于特定的问题和站点子集,重叠确实是巨大的,是的。显然,并非适用于所有站点,也不适用于所有问题。范围是重叠的维恩图,而不是同心圆。

– terdon
15年7月24日在11:49

@terdon我对AU和U&L不感兴趣。就我而言,一个应该作为另一个的副本关闭。它们充其量是本讨论中的异常值。我仍然不相信其他网站应该允许交叉发布,只是因为您希望自己喜欢的网站允许它。

– Pollyanna
15年7月24日在11:58



@AdamDavis几乎没有异常值。从网络流量来看,它们实际上是第三(AU)和第八(U&L)站点。 SU是第二,SO是第一。我提到的唯一不在前10名的网站是Rpi.se(Apple位居第八)。我说的是网络上一些最受欢迎的网站的共享范围。我同意并非所有站点的作用域都重叠,但是我们现在有数十个站点,其中许多范围确实存在重叠。结果是,不同站点上的不同用户提出了相同的问题:确切地说,应避免使用无CP规则。

– terdon
15年7月24日在12:05



@terdon我不是指使用或社区方面的异常值。在讨论中,我的意思是离群值-他们的维恩图不仅重叠-U&L圆完全包围了Ubunto圆。 Ubuntu很显然可以成为U&L的标签。因此,继续使用它们作为为什么要实现此功能的主要示例真的没有意义。也许这是那些网站的问题。对于网络的其余部分而言,这不是一个重要的问题,并且进一步的交叉发布并不能解决一个大问题,因此不需要实施。

– Pollyanna
15年7月24日在12:10



让我们继续聊天中的讨论。

– terdon
15年7月24日在12:12