我们需要努力的一个主要领域是能够响应和管理社区所需的反馈员工的反应或行动。这篇文章定义了执行此操作的过程。我们还需要找出您可以实际回答的多少个问题，以便我们做出合理的承诺（内部和外部）。以下是测试和制定这些目标的时间表。
管理社区反馈的新流程：
工作人员和主持人会将状态审核标签添加到他们所关注的元问题中觉得需要工作人员解决。此标记可以在网络上的任何元站点上使用。来自整个网络的带有此标签的问题将自动添加到内部跟踪系统中。
不迟于3月16日，CM团队将向MSE发布文档，以确保主持人了解何时使用此标签以及何时不应该使用它（更新：3月12日发布）。用户可以标记一个帖子，认为他们应该被标记为状态审核，版主或工作人员将决定是否添加标签。
CM团队将支持该mod，以便使他们感到有能力做出这些如果他们标记了我们认为不符合指导的问题，则可以做出决定并给予他们有用的反馈。我们将使用这些信息在主持人指南中添加详细信息，或向主持人展示他们可以找到这些问题答案的地方。
CM将按以下方式管理和维护在内部跟踪系统中跟踪的问题：
/>
CM团队将优先处理在MSO（和国际MSO），MSE和主持人团队上标记的问题。
有关子元数据（不是MSO或MSE）的问题将在时间允许的情况下得到解决。
在此过程中，CM团队将充当总机操作员，确保逐步解决的问题能及时解决。内部合适的团队。同样，CM团队将促进信息从上述团队流回社区。
主持人可以将有关主持人特定政策和工具的问题上报给主持人团队的工作人员，并将按上述说明进行处理。
时间表：
从现在起到3月15日，CM团队将致力于建立上述流程以及支持该流程所需的内部系统，并定义其他团队的承诺。
从3月16日到4月30日，我们将测试流程：工作人员或主持人使用状态审核标签对在任何元数据上提出的新问题进行标签。这些问题将进入跟踪系统，CM团队将对这些问题进行分类并将其定向到公司中的适当联系人，以使他们在meta上获得答复。我们将收集有关我们所有元站点上所需人员支持量的数据。
5月15日，CM团队将共享该测试的结果。根据此测试，我们将定义目标，以指定我们可以回复多少帖子以及可以多快完成回复。 （更新：发布在Meta升级/响应流程更新（2020年3月至4月的测试结果，后续步骤）上）
然后将每季度审核一次目标，以使其达到最佳状态-基本上确保我们确定了现实的目标并与他们见面。
沟通：
CM团队还将提出一个问题来跟踪我们每月的参与情况。它将显示统计信息和其他信息，例如：
每个月标记了[状态审核]的帖子数。
它们是什么类型的问题（顶部标签）。 br />我们响应了多少，响应时间中位数是多少。
有多少人正在处理中。
有多少人被删除了。
除了这些统计信息外，该帖子还将突出员工的注意，有趣或有趣的回复。我们希望能够定期看到此信息将强调我们致力于与Meta进行互动的承诺，并提请大家注意我们的员工正在做的一些工作，以改善您在网络上的体验。
对我们内部和所有社区和主持人而言，这都是一种考验。如果事实证明在此过程范围内标记为需要主持人注意的问题数量对于较大的站点（例如MSO和MSE）变得站不住脚，则CM团队将与主持人一起减轻工作量，并可能在课程中期进行调整-或测试后期间。本着这种精神，我们要求您不要用标记请求轰炸mod，特别是对于已存在多年的内容。
我们认为，我们上面概述的过程是透明的，表明我们致力于参与与社区。如果您有任何疑问，请在回答中提问，我们将尽力澄清。我们期待着与我们建立关系并与您建立信任，因此会更频繁地出现在MSE和其他metas上。
注意：请不要在测试开始之前将问题标记为候选标签。
#1 楼
状态审核的含义/曾经是“正在审核”，而不是“需要审核”：带有此标签的功能请求或错误报告既不拒绝也不注定要实现/固定。做出此类决定后，标签将相应更改。
有多个因素可能会使报告受到审查。可能需要考虑所提议的功能或错误修正是否可行或有用。可能会对必要解决方案的复杂性进行调查。所提供的功能或错误报告中可能没有足够的信息。网站开发人员可能会提供其他评论，以请求更多信息或提供与审核状态相对应的状态更新，直到做出批准或拒绝的决定。
新的含义似乎与此矛盾。也许我们可以将标签分为状态需要审查和状态接受审查？
此外，
有关子元数据的问题（不是MSO或MSE）会在时间允许的情况下得到解决。
请考虑将您的至少一部分时间用于这些站点。在非技术性站点上遇到的一些问题可能在MSO和MSE等站点上可能从未遇到过，在这些站点上MathJax和扰流块之类的应用并未得到广泛使用。
评论
JNat对问题的评论：“社区开发团队已经使用该标签将错误报告放入其错误板@ChrisF中，基本上是在构建积压/队列。该标签并不意味着我们承诺会对其进行研究。或有任何解决方案，不幸的是：我们只是没有人力来实际检查和修复我们所拥有的所有错误。这是这种用法的扩展。目标是我们将对问题进行更好的内部跟踪在meta上，并能够对它们进行优先级排序并做出响应-即使响应只是“这似乎是一个错误，但现在我们的待办事项中，谢谢！”
–́Catija♦
20 Mar 4 '20 at 22:29
@Catija然后，这应该反映在标签Wiki和该原则适用的每个元站点的摘录中。
–S.S. Anne
20 Mar 4 '20 at 23:32
是的，更新标签描述/摘录是其中的一部分。
–Catija♦
20 Mar 4 '20 at 23:35
我认为问题是，是的，它本来应该是“正在审核”的意思，但实际上，有如此多的帖子标记有该标签，以致于不可能对它们全部进行实际审核。这会将期望重置为当前使用标签的方式。
– Geoff Griswald
20 Mar 5 '20 at 18:01
#2 楼
我们需要努力的一个主要领域是能够响应和管理需要员工响应或采取行动的社区反馈。
您究竟认为“社区反馈需要员工响应或采取行动”？
是不是在Meta.SO上有超过五千个被标记为
feature-request的问题，尚未被SE Inc.响应？？ 如果没有，为什么不呢？
SE Inc.甚至没有承认，没关系采取行动，这些要求一直是社区的主要难题之一。如果您真的想重建信任，请首先查看该积压。
评论
必须同意-“抱歉，现在不能详细介绍，但我们可能永远也不会这样做”比沉默好。由于请求数量庞大，这听起来像是一个不合理的请求，但是，例如，承诺对具有一定投票数的请求做出响应会走很长一段路
– Pekka
20 Mar 5 '20 at 12:39
他们可以按分数对它们进行排序，然后以稳定的速度从上到下进行工作。
– Trilarion
20 Mar 5 '20在15:44
这正是这个目的吗？任何人都可以提出功能请求。仅仅因为他们拥有，并不意味着它是一个好主意或值得一眼。这样的想法是，主持人执行初始的“废话过滤器”，并使用此新标签促进值得审查的功能请求。任何坐在那里并且没有被状态审查标记的人，您都可以认为不值得一看。
– Geoff Griswald
20 Mar 5 '20 at 18:06
@GeoffGriswald除了...这不是一个新标签。它已经存在了将近十年。主持人根本没有使用它的意义，因为SE Inc.刻意地忽略了用户（包括主持人）的请求，而工作人员却没有使用它，因为...他们是忽略用户请求的人。我很愤世嫉俗的说，这项新政策只会用于将不处理请求的借口从“我们不在乎”更改为“哎呀，我们积压的东西太多了，抱歉，您的请求不是优先”，因此是我提出的问题。
–伊恩·坎普（Ian Kemp）
20 Mar 6 '20 at 7:55
您提到的功能要求可以适合此过程，是的。我们并不承诺实际实施它们，而是尽可能地做出响应，即使响应只是“这似乎是合理的，我们也将其添加到了积压中”。在测试期过后，我们将更好地了解帖子总数，可以承诺回答的数量以及可能实现的数量。我们还将能够看到仍有多少人没有答案。这些数字将使我们尽可能地透明。我很沮丧，但这只是迈向正确方向的第一步。
– JNat♦
20 Mar 6 '20 at 12:16
@Ian Kemp马铃薯马铃薯，您看到的“被忽略”的其他人可能会被视为“阅读，不同意，不会增加价值，继续前进”。同样，任何人都可以提出一项新功能的要求，但这并不值得。实际上，用户提出的绝大多数功能请求都不值得，正如大多数错误报告实际上并不是错误一样。所以，是的，我希望SE inc有充分的理由忽略了绝大多数用户的要求！如果他们没有，我会担心的。
– Geoff Griswald
20 Mar 6 '20 at 12:48
他们不会也不应单独回应每个请求的原因是，提出该请求的人肯定会认为这是一个好主意。回到他们的评论“嘿，我们看了这个，我们认为不值得花时间”，只是邀请他们回答“哦，但我的想法确实很好，您必须不理解它请允许我详细介绍为什么它实际上是一个好主意。”想象一下，这种对话实际上发生了5,000次，您将理解为什么开发人员不响应用户的功能请求。
– Geoff Griswald
20 Mar 6 '20 at 12:51
正如Pekka所说，@ JNat正是我们一直希望听到这么长时间的回复。即使您只是（通过投票）修饰了最重要的10个功能请求，这对于减轻许多人忽视的平台担忧也有很大帮助。
–伊恩·坎普（Ian Kemp）
20 Mar 6 '20 at 12:53
@GeoffGriswald有些功能请求有数百个支持。考虑到与主站点相比，元数据的人口较少，这有力地表明了至少应该关注这些站点。仅仅因为有超过5k的FR未得到解决，并不意味着任何一个都值得丢弃-如果SE Inc.实际上在过去的十年中实际上是在FR出现时对FR进行响应，而不是全力以赴地支持他们-知道-什么，他们将不会超过5k！
–伊恩·坎普（Ian Kemp）
20年3月6日13:00
在某些方面，FR可能不是最佳解决方案。我已经意识到，在很多情况下，产品经理或开发人员需要真正理解和思考的问题是什么-您想在显示器上折断键盘的原因是什么-许多FR都不包含该问题。 。优秀的人做...但是很多人做不到。知道人们正在尝试解决什么问题，将使PM能够灵活地解决问题，而不会陷入特定的实现要求中。
–́Catija♦
20 Mar 6 '20 at 13:16
任何人都可以投票。仅仅因为功能请求被批准并不意味着它有任何好处。这也并不意味着它是合法的，具有商业意义，值得做，代表开发人员的时间和精力得到了充分利用，甚至是可能的。只能告诉开发人员的是，请求很受欢迎。该网站不是民主国家，您的投票毫无意义。
– Geoff Griswald
20 Mar 6 '20 at 14:25
@Catija这是一个公平的观点，但一个公平的对立之处是，如果SE Inc.将Stack Overflow平台视为需要持续改进的产品，则绝不需要许多这样的FR（并因此发布），而不是一年只需要一个大的新功能。事实是，这些重大的新功能几乎与社区的要求几乎没有任何关系，即SE Inc.想要并认为对平台有利的内容与其实际用户想要的内容之间存在巨大的脱节。 。
–伊恩·坎普（Ian Kemp）
20 Mar 6 '20 at 14:52
@IanKemp我认为另一个不连贯的地方是，与职业和团队相比，整个SE网络可能不会为公司带来大量收入，因此感觉好像它被转移到了偶尔查看的那一边，而不是是更高的优先级。
– DForck42
20 Mar 6 '20 at 17:42
令人惊讶的是，很多FR都有很多支持，而没有一个支持。我强烈建议公司研究它们，并尝试以一种或另一种方式解决它们。确实不需要标签，您只需要一个自定义过滤器。当然，它们源于多年的不活动，不可能在几周内解决它们，但是即使如此，即使花费一年，也要开始这样做，恕我直言。
– Trilarion
20 Mar 9 '20 at 10:04
取消功能请求，因为它们是A）不受欢迎，B）太受欢迎或C）某些含糊不清的东西。是的，很有道理。
–烧烤
20 Mar 9 '20 at 19:02
#3 楼
对状态审核的更改很好。一眼就能知道一个元帖子是否定有正式答复，这将是很高兴的。但是...您将以何种方式标记已通过此方式解决的问题员工团队的政策？
我们目前对于已解决或已实现的错误/功能请求的状态已完成，但这并不一定涵盖新版是否解决了特定的元发布问题。状态审查的范围。我觉得拥有某种充当“内部官方回复”标签的标签将是有益的。也许是针对状态或针对状态的？还是应该扩大已完成状态的范围？
有一个标记，指出将要处理帖子而没有某种将帖子标记为已解决的策略对我来说有点奇怪。我认识到这可能是将审查状态从bug和功能请求移开的产物，并且我想知道是否应扩大状态标签的整体范围以适应此更改的想法。
评论
[已计划状态]，[已推迟状态]
–数学
20 Mar 4 '20 at 16:50
如果我们在谈论错误或功能请求，那么状态已完成仍然可以解决问题。如果我们在谈论支持请求或讨论，那么工作人员会给出答案的事实应该明确表明已得到解决，不是吗？ :)
– JNat♦
20-3-4在16:52
我想你是对的，@ JNat。我只是在寻找状态审查现在将提供的一目了然的可见性。
– Spevacus
20 Mar 4 '20 at 16:54
@JNat至少从技术上讲，另一种解决方案可能是将其发布为错误跟踪数据库的只读视图/摘要：显示一切的当前状态。
– ChristW
20年3月4日在16:56
@JNat鉴于对Meta的问答可以有很多答案，在我看来，这个建议是个好主意。提出问题时，人们可以一目了然地看到是否有“官方”答复，而无需滚动浏览所有内容以进行检查...
–辛迪·梅斯特（Cindy Meister）
20 Mar 4 '20 at 16:58
另外，称讨论为“状态已完成”有点……我不知道……吓到我了。讨论的一大优点是，它们是开放式协作和表达思想的场所。状态完成听起来很最终，似乎“关闭”了这个主题，我并不认为这是适当的，我认为它看起来（并被嘲笑）像某个“完成任务”的旗帜。
–Catija♦
20 Mar 4 '20 at 17:09
@Catija也许[状态响应]？
–乔治·斯托克（George Stocker）
20 Mar 4 '20 at 20:48
@GeorgeStocker也可能是来自马口的状态那有点暗示着所有元问题都需要或应该得到官方的回应……而事实并非如此。社区非常擅长此事，我们需要做的是确保确实可以回答我们真正只能回答的问题……但是我不知道为什么需要一个标签来吸引人们注意该答案，我我将需要一些强有力的论据来说明为什么我们需要标签来处理这类事情……如果是的话，我们如何使它保持简单？如果有人只是在报价员工，该怎么办？如果工作人员只是在回答“是的，这个”，该怎么办？
–Catija♦
20 Mar 4 '20 at 20:56
@Catija我知道我们都可以做到并在评论中回答，但也许工作人员不应该在评论中添加重要信息。对于我来说，这并不是最好的解决方案。用“我们同意答案X”回答或编辑答案有什么问题？
– Trilarion
20-3-4在21:47
@JNat-在CM /员工拥有钻石的情况下，很容易发现SE的官方回应，但是如果他们离开公司，则会失去一点影响（因为没有其他迹象表明用户曾经是雇员）。可能有一个规则在任何“官方”公报前面加上“嗨，我是[名称]，[Stack Exchange的职位名称]”，这样无论用户帐户是取消钻石还是删除，响应都具有相同的权重完全。
–罗伯特尼克
20-3-4在21:56
@Trilarion我……真的真的不喜欢……通过写一个新的答案来“认可”某人的答案。我认为这是对平台的可怕使用，并且浪费了空间……而且，如果答案在某个时候被删除，那么员工的答案现在仅是链接。我宁愿提出一个实际的功能，让我们指出“官方”或“认可”的答案。
–Catija♦
20 Mar 4 '20 at 22:21
@Catija然后“标记为公司已解决”。相反，使用注释的问题在于它们被视为第二类，无需阅读。那里的信息不那么明显。
– Trilarion
20 Mar 4 '20 at 22:26
@Catija“关于讨论的最重要的事情之一是，它们是一个开放式协作和表达想法的地方” –很高兴看到一位工作人员这样说。几个月以来，（来自公司）的信息一直是这样的：“讨论是有毒的。我们会听的唯一反馈是与我们亲手挑选的个人进行1-1s交流；其余的人同时也太多了，没有时间去听或思考，很少有人在乎，不会适合我的客厅”。很高兴看到公开讨论再次受到重视。
–user56reinstatemonica8
20-3-4在23:01
也许简单地[状态审核]会有所帮助，以表明该问题已由SO工作人员进行了审核，并且他们采取了他们认为合适的任何答复？
–加文·扬西（Gavin S. Yancey）
20 Mar 4 '20在23:24
@Robotnik，您的观点很不错，理想情况下，我们可以将答案与某些内容联系起来，以表明它们在某种意义上是“官方的”，而不必查看是谁编写的，并尝试回溯是否他们曾经是或曾经是雇员。
– JNat♦
20 Mar 6 '20 at 12:05
#4 楼
删除了多少个。
如果某个问题被排除在考虑范围之外，请问这个问题本身会显示出来吗？这样的问题会永久带有（误导性的）状态审核标签吗？还是在从案卷中删除问题后承诺删除此标签？ （即，将其切换为状态下降的状态？或者，如果不是那么糟糕的话，Gavin S. Yancey的状态审查的出色建议吗？）如果是后者，是否有义务就为何删除该状态提供某种程度的解释？
评论
这些是我们仍在研究中的问题，但理想的情况是两者都应：我们都应能够表明某个问题不再在我们的关注范围内，并至少就为什么不提供基本解释。这将在16日发布的指南中更加明确。
– JNat♦
20 Mar 6 '20 at 12:18
您应该避免以这种方式给出任何负面反馈。我知道这似乎是违反直觉的，或者也许是残酷的，但是实际上响应无意执行的功能请求的最佳方法是忽略它。如果您主动说“不，我们不这样做”，或者关闭请求或将其标记为“已拒绝”或其他内容，则提出该请求的人中有10人中有9次会再次提出该请求，但措词略有不同。这造成了难以置信的流失。最好让它坐在那里，给他们错误的希望，希望有一天能解决这个问题。
– Geoff Griswald
20 Mar 6 '20 at 13:03
已经存在状态递延和状态拒绝的标签。
– Gerrit
20 Mar 6 '20 at 14:40
@JNat非常感谢您的反馈-非常感谢。
– E.P.
20 Mar 6 '20 at 15:28
#5 楼
我对这项政策表示赞赏，并热衷于组织答复，但是指出，我看到如此标记的帖子分为两类。第一个，也是最大的一个小组，是像这样的非常简单的支持/功能请求/平凡的东西第二个，可以理解为稀疏的小组，涉及到更大的政策/环境问题，例如这样的
我对其中的一个非常感兴趣，而对前一个则不太感兴趣，所以我希望看到某种形式的差异化，因此我可以适当地喜欢我感兴趣的领域。
评论
也许您可以通过对所有标签进行过滤来实现这一点：状态审查，但不是bug或功能请求。
– Trilarion
20 Mar 4 '20 at 21:50
如上所述，您可以设置过滤器。他们会产生类似于此搜索的结果。
– JNat♦
20 Mar 6 '20 at 12:17
#6 楼
（再次）首先：非常感谢您为提高透明度所做的努力。我感谢详细的内容和时间表。我在哪里挣扎：
在任何元数据上提出的新问题都将由工作人员或主持人使用status-review标签进行标记。
所有现有的“打开”请求怎么办？其他人提到了自古以来就存在的任何开放式功能请求帖子。是否全部都丢弃了，需要重新申请吗？！
除此之外：如果要完全透明，请考虑使用公共缺陷跟踪系统（也许：使其仅对社区可读） ）。我同意另一个答案，那就是，首先，仅对标签状态进行审查是不够的。也应该有一些状态被接受和状态被拒绝的东西。但是如上所述，理想情况下，当您接受某些工作时，您可能会在内部进行跟踪。如果内部跟踪器（的某些方面）对社区是可见的，那将是非常不错的。
评论
状态完成/状态计划（接受）和状态下降（拒绝）不够吗？
– MEE
20 Mar 6 '20在15:34
知道“将在某个时间点上工作” +“被拒绝”……肯定比没有好。但是，开放的缺陷/故事跟踪器可以帮助社区了解例如“能力”。当您看到平均要完成多少工作时，这确实可以帮助您了解“您的”请求正在取得的进展。开放的跟踪器仅有助于提高透明度。
–GhostCat
20 Mar 7 '20 at 8:02
让“新”问题感到困惑：基本上，我们根本不想看那些，但是我们也不想被所有这些都淹没：这是我们需要权衡的问题，并且需要发布准则到3月16日，这一点应该有所了解。
– JNat♦
20 Mar 10 '20 at 17:34
#7 楼
关于子元数据（不是MSO或MSE）的问题将在时间允许的情况下得到解决。
因此，基本上从不，因为它已经存在了
评论
来吧，现在，这还不太公平。我之前已经报告过有关子元数据的错误，并迅速对其进行了修复。诚然，我几乎不得不动动SE员工来实现它，但是他们仍然在不到两个小时的时间内修复了它。 :)
–伊尔马里（Ilmari Karonen）
20 Mar 5 '20 at 20:20
好吧-我希望作为一个小型网站主持人能够有所改变。特别是如果这意味着向社区站点提供更多实用资源。 SE过去远远不够。这可能是一个改变的机会。
–游侠怪胎♦
20 Mar 6 '20 at 13:49
#8 楼
我认为在您的流程中可能需要注意某种“反馈意见”。一个简单的时间范围（例如72小时）实际上有效地解决了一个问题（例如，阅读回复，发表评论以澄清问题等）吗？在转移到@Spevacus建议的状态标签之前，您的状态标签是否应该具有“正在处理状态”？一段时间后或一旦删除了“正在处理标签”，它还建议您进一步澄清可能需要新问题。
评论
我认为暂时我们可能希望保留现有标签，但是将来肯定会创建新标签。无论如何，您都是有重点的，理想情况下，在积极审查问题的阶段，我们将欢迎您提出反馈意见，并可能要求澄清（如果需要）。我们将看到这与16日发布的指南相符。
– JNat♦
20 Mar 6 '20 at 12:22
#9 楼
RE：沟通CM团队还将提出一个问题来跟踪我们的每月参与情况。它将显示统计信息和其他信息，例如：
每个月有多少帖子被标记为[状态审核]。
它们是什么类型的问题（顶部标签）。 br />我们响应了多少，响应时间中位数是多少。
处理中有多少。
删除了多少。
您可以在列表中添加点吗？
帖子被其他东西阻止/固定的帖子
知道何时有东西很有帮助正在运行中，但目前已被阻止。
侧面思考：托管公共Trello / Jira板可能更容易处理
评论
我认为这可以作为“正在处理的数量”的一个分项，是的。不过，我不确定我们是否计划暂时在Meta帖子中分享更多统计信息（以回应您的想法）。
– JNat♦
20 Mar 6 '20 at 12:24
#10 楼
在2个月内，将对这些状态检查帖子做出一些回应，每季度都会达到上限，直到队列为空为止。老实说，这听起来并不像进展。听起来好像是在内部创建一个用于掩埋反馈的系统。
我知道这里的意图是创建一个标准操作程序来处理看似基于队列的系统，但是这种前景完全误解了关注社区的问题。
随着团队的减少，考虑到协调员工对meta verse的历史性困难，也许现在是时候考虑将所有meta合并为一个地方。
本质上，仅查看MSE和MSO，就已经通过分组在某种程度上做到了这一点。似乎已经完成了对meta的所有拆分，这通常是破坏meta社区。同样，这实际上也使得CM团队无法保持任何有效的沟通。
当出现严重问题时，需要对每个子元，MSO和MSE做出回应只是不堪重负，并导致问题迅速失控。在当前的设置中，影响整个交换的问题一开始就不太可能消除。这是一个值得解决的问题，几个月的排队不是解决方案。
评论
与“每月队列”相比，这更多的是积压，我不认为它会降为0。这个想法也不是掩盖反馈，而是要确保能够响应所提出问题的团队由其Meta站点上的社区实际看到的是这些问题的出现-重点是我们试图尽可能多地应对这些问题。
– JNat♦
20 Mar 10 '20 at 17:38
@JNat-我知道这个想法不是掩盖反馈，但是这似乎是一个方向。我看到社区与员工/ CM之间的交互下降的主要原因是员工和CM团队不知所措。减少团队成员数量只会使这一过程变得更加困难。我理解这里的要点是响应，这是很光荣的，但是所使用的机制并不是完成任务的正确工具。即使此方法在短期内可行，但由于此答案中提到的问题，其扩展使用很可能导致烧坏。
–特拉维斯J
20 Mar 10 '20 at 18:20
@JNat-老实说，如果花在组织正确的方法上以对社区做出反应的内部努力只是花在响应上，那可能会更有效。我显然无权访问内部Stack Overflow Teams网站，但我想……我真的很想知道其中有多少与元/社区相关的帖子，以及是否有关于仅拥有该主题的讨论。对话会公开而不是掩埋。
–特拉维斯J
20 Mar 10 '20 at 18:23
评论
目前[status-review]的用法会发生什么-由于此问题正在由工作人员进行审查？社区开发团队已经使用该标记将错误报告放入其错误板@ChrisF中，基本上可以建立积压/队列。标记并不意味着我们承诺会对其进行观察，或者不幸的是，它将有任何解决方案：我们只是没有人力来实际检查和修复我们所拥有的所有错误。这是该用法的扩展。目标是我们将更好地对meta上的问题进行内部跟踪，并能够对它们进行优先级排序并做出响应-即使响应只是“这似乎是一个错误，现在已经在我们的待办事项中，谢谢！”。
请考虑回答以下相关问题：meta.stackexchange.com/questions/317271/…
所有功能请求（或至少得分为正的请求）是否不属于状态审核类别？关于过去高度评价，经常重复，尚未实现但未拒绝的功能请求有什么想法？是否应加标签？
@Trilarion：我确实有这个问题，所以谢谢您先提出这个问题！我觉得，至少在MSE和MSO之外，对网站元数据进行的最糟糕的功能请求被视为“解决社区所处理问题的一种好方法”，因此，我看到的情况很少（例如，在RPG上）。 SE meta），我不希望员工至少考虑并实施它。
该公司在Meta互动方面的全部180条成就既令人赞叹又令人愉悦。
感谢您为该计划提供一个明确的日期。仅此一点就表明了我们的努力，对此表示赞赏。
理想情况下，可以采用一种不太粗略的方式来按受影响的用户数量确定优先级，但是我很坦诚地说：“在时间允许的情况下，将解决有关子元数据（不是MSO或MSE）的问题”。
您希望增加与社区的对话，然后几乎在下一句话中就在不更改与社区的任何对话的情况下启动站点更改。请告诉我这有什么意义。您是否想进行对话？
@JNat您说：“在任何meta上提出的新问题都将由工作人员或主持人使用status-review标签标记。” -旧的请求/错误等呢？网站能否提出“前5名”或“前10名”未解决的错误/要求进行审查？
我只是想打个招呼，然后再说一遍，我对方向的转变以及实现透明度和协商的这些具体步骤表示赞赏。这些是朝着正确方向迈出的重要一步。
这是否意味着淘汰Meta的计划（有利于其他反馈来源）已更改？
对鹅有好处的对鹅没有好处，一个必须鸣喇叭，而另一个则没有这样的要求。许多人认为这对他们来说是相当平等的。
正如我在这里指出的，@ Trilarion，应该在即将到来的测试期间指南中予以阐明。
编辑第一个“我们”以澄清@tkruse。与以前的编辑一起，我认为这消除了帖子中出现的所有“我们”的含义。