问题陈述

许多新用户都不知道如何提出一个好问题,特别是对于Stack Overflow,超级用户(确定,全部为SE)等技术站点。这导致了许多新问题:


已关闭
已投票表决
已删除

此外,它还会导致一些社区问题尝试确定他们的要求。这会给每个人带来不好的经历-发问者会受到“敌意”,并且社区会浪费精力。

提案

我的建议是创建一个A / B研究,以分析用文本预先填充问题框,以指示问题中对一个好的问题很重要的部分。目标是最初提高问题的质量。

现在,提取问题详细信息的许多负担都在社区中。如果一个问题含糊不清,通常没有评论就无法改善。如果不清楚,类似地,社区也必须问/等。

我想通过为低声誉用户预先填充所需的信息来更直接地将此负担加到提问者身上。

当单击“询问新问题”时,其外观类似于以下内容(可能是单词被锻造)



请注意,其目的是使所有这些文本在输入字段以及实际的帖子正文中均可见。

根据最终在特定措辞上添加的位置,可能需要更改,尤其是第一行。

所需的结果

目标这样的预先格式化的框是:


弄清楚需要什么信息


如果用户不填写此信息(或保留专业格式的文本),很明显,他们并没有去阅读将问题转储到的框。 />能够解决这三个问题的信息的问题很可能是有范围/可回答的问题


不熟悉SE的指南用户(但能够提出很好的问题)如何做


通常简单的错字类型的问题对SE都是毫无用处的
很多人有能力提出好的问题,但对SE却不熟悉。
优化珍珠,不是沙尘


为收到敌意(投票/否决票)的用户提供合理化的反馈,尤其是如果他们公然无视预填充文本的话。 >如果用户忽略一个或多个部分,他们现在有意选择忽略SE的工作方式




A / B学习指南

我建议在A / B研究中使用以下标准和指标来实现这一目标。



目标用户-信誉低于50的用户(或有被禁止提问的风险,无论信誉如何)

目标站点-尽管这很自然地适合Stack Overflow,但很容易被大量站点采用

指标


点击“问问题”后提出的问题转化率。转化率较低->良好。
问题的关闭率较低,->良好
问题的中位数和四分位数更高,-很好
写作的平均时间/中位数一个问题(如果有此信息,则更高)->很好
用户保留率,特别是多少用户提出了其他问题





评论

好消息:它正在审查中。坏消息:它正在审查中,这意味着很可能不会发生。 (至少不会在未来6-8年内)

我不认为这是完全相同的行为。提供一个指导新用户的问题大纲的想法是共享的,但是想法在两个重要方面有所不同:(1)几乎是重复的建议了一个复杂的模板系统,可能扩展了问题编辑器。这个问题不是,而且实施起来很简单。 (2)这个问题提出了可衡量的指标,以找出这种轮廓是否是一个实际的好主意。循证行动是最好的行动。这种想法几乎没有。理想情况下,两个建议都可以合并在一起……@enderland也许可以作为答案?

我真的很喜欢这个提议的提出方式,并且100%符合其既定动机。但是我心中的愤世嫉俗者怀疑,我们已经可以预测拟议测试的结果:对真正关心如何收到问题的一小部分OP的边际改进,以及绝大多数人的公式化漠视,他们的根本动机是让其他人接受尽自己最大的努力为他们做好工作。你不能治愈懒惰。当然,除非SE决定拒绝显示任何不符合某些最低标准的问题。

@DanBron,这是一个理想的结果。我宁愿帮助那些有能力写出很好的问题的人去做,并让他们在懒惰时弄清楚。我真的不介意拒绝/结束懒惰的问题。如果有人在不进行代码转储的情况下离开形式形式文本的情况下,我将无情地投票并投票结束该问题。

@DanBron此外,如果情况是人们拒绝解决预先填充的指导性问题,那将是将这些问题转入某种形式的评论队列的好案例,等等。我没有进行任何分析就问题的正文而言,就A / B研究而言,要想轻松解决问题难度更大(大概是?),但我想您可以对添加文本的问题进行一些有趣的文本分析收到。我想未处理的预填充文本会比其他情况差很多。

我真的喜欢这个主意。对于像“硬件推荐”这样的网站来说,这将是完美的选择,在该网站上,我们会收到很多题外的问题以及没有足够详细信息的问题。

请注意,如果提交时模板的任何部分仍保留在答案中,则该用户将被永久保留。还有其他的东西,但我不知道有什么不好的。

这是一个相当不错的主意,该文本可以由mods编辑。我想团队无法针对每个站点提出专门的消息。

我喜欢这个主意,但是如果其中一个问题不适用或用户的问题不完全适合模板,会发生什么?他们可能不愿问他们。

不要忘记将标题移到底部并将占位符更改为“您要解决的问题是什么?”或类似的东西。

原则上,我同意非常需要这样的东西,但是此模板仅涵盖了适用于Stack Overflow的一小部分问题-调试我认为不是最有趣或最有用的问题。您将如何填写此模板以解决一个问题,该问题询问如何解决您尚无任何代码(例如,找不到合适的库或API调用)的特定问题?还是“最佳做法”问题呢?

@IanGoldby您意识到在Stack Overflow上有一个特定的关闭原因是“推荐库/工具”吧?如果人们因为无法将其放入模板而没有要求,那就完美。

@enderland你想念我的意思。因此,不仅仅是“帮助我调试代码”问题。询问(例如)如何使用C#以本地语言获取月份名称是完全合理的。有成千上万的此类高质量问题。找到这些问题的答案是我来参加SO的主要原因。
为了解决Ian Goldby的观点,您可以向提问者提供一小部分(有序的)模板供您选择,以及为那些认为自己的问题仍然适合该站点的人提供“自由格式”模板,并发出严厉警告,如果该问题实际上不是可接受的问题,它将很快被否决,并可能被关闭(甚至删除)。

当前正在堆栈溢出测试:meta.stackoverflow.com/questions/360260/…

#1 楼

这是我的价值所在。

最初,我们确实应该从简单的事情入手,以评估这是否真的可以帮到您(以典型的A / B测试方式),然后才可能压倒一切。

我有点担心,太简单的文本实际上可能会损害问题的质量(比起空的框更是如此),因为用户可能会包括

我们绝对应该在开始时(尽量)避免使用可选的或误导性的部分(或有关部分的任何选择),因为这可能会使用户困惑或劝阻(超出了我们的预期或期望)。

我最初的建议可能是这样的:


问题的描述:

在此处简要说明您的问题。

还包括(1)您的输入,(2)您得到的输出(或确切的错误)以及(3)输出您想要的。

我已经尝试过:

简短地告诉我们您如何尝试解决此问题。你调试了吗?您尝试过Google吗?

我的代码:

在此处输入您的代码或代码,以显示您如何解决该问题。有关发布建议,请参见https://stackoverflow.com/help/mcve。



这就是我们应该努力的方向:(可选部分)


问题的高级描述:

在此处简要说明要解决的问题。

我的问题是:

您需要帮助的哪个具体部分,或者您希望我们如何帮助您?

提出一个句子的问题在这里,我们可以确切地知道
如何为您提供帮助。

我已经完成了哪些研究:

您是否进行了调试?您是Google的问题吗?

包括一些链接并解释它们为什么无济于事-这将确保我们不会告诉您您已经知道的信息。

我的代码:

放置您的代码或代码在此处显示您如何解决该问题。

如果您花一些时间来构造一个最小,完整和可验证的示例(https://stackoverflow.com/help/mcve),这将使它成为现实。

我们更容易为您提供帮助。

不要在这里复制您的程序的一部分,因为问题可能出在您程序的另一部分,那么我们就不会能够帮助您。

示例输入:

将您用于代码的确切输入放在这里。

输出我想要:

将要获取的准确输出放在这里。

输出(或错误)我正在得到:

将您将在此处获得输入的确切输出。

如果出现错误消息,请确保在此处复制完全准确的错误消息。


#2 楼

问题中建议的模板由于以下原因而存在问题:


鼓励用户将SO视为“为我修复代码”服务
不鼓励研究
过分关注用户拥有现有代码的问题。 (一些好的问题甚至不涉及代码。许多好的代码问题太简单了,不需要MCVE,只需要预期的输入和输出。)
杜克林(Dukeling)的答案表明,存在相同问题的一个简短选择,以及过于冗长的一个长期选择。 (用户不太可能阅读冗长的内容。)出于这个原因,我想根据amon的评论提出一个不同的模板:

# How can I.../What is...
Explain what you're trying to do or find out.

# I tried.../I found out...
Explain what you've tried and what information you found during your research.

# But it did this instead.../But my understanding seems wrong because.../But I'm confused because...
Explain what happened that you didn't expect or what makes it difficult for you to understand.


我敢肯定,这可能需要一些调整,但是由于以下原因,我认为此模板是一个更好的起点:


鼓励用户进行研究首先并进行演示
不鼓励“这里是我的代码,现在修复它。”代码转储类型的问题
鼓励用户包括有关他们自己对情况的了解的信息,这使纠正他们的位置变得更加简单出了错
设置用户应寻求信息/知识的正确语气

更容易推广到更多StackExchanges。

确实感觉不完整,我认为这很大程度上是Dukeling最终使用了过于冗长的模板的原因。如果我们觉得这还不够,那么我认为我们应该更多地考虑Petter Friberg的建议,即建议有一种“向导”或演练来提示用户包括特定信息。如果系统只是向他们转储一堵文本墙,那么大多数用户只会跳过它。