知道如何使用“正确的信息”提交问题可能是问题立即得到解决或永远不会被合并的区别。我们喜欢社区贡献，因此我认为了解一些需要避免的常见陷阱会有所帮助。

每个人都宁愿做其他事情，而不是归档或分类问题——这不是作为一名工程师最有趣的部分。重要的是要记住，人们对问题的双方都有不同的感受。提出问题的人感到沮丧，因为他们刚刚遇到了障碍，而问题是他们完成任务的障碍。我很沮丧，但请记住，这个问题不是发泄愤怒的地方。想想阅读和分类问题的人，并提醒自己发泄不会帮助您解决问题。不尊重他人只会让别人感到沮丧。

尽量简洁明了

我们在进行问题分类时看到的一个常见问题是许多问题都是以意识流的形式编写的。拥有详细信息固然很好，但让我们尽力提供有助于问题分类的详细信息。让我们来看看创建问题时的一些最佳实践。创建问题时，重要的是要对读者有同理心，并花时间研究文本，使其简洁明了。字数越少越好！仔细选择你的措辞，并考虑如何在没有上下文的情况下最好地向别人解释问题。

不要假设共享上下文

我看到的另一个常见陷阱是问题作者假设对问题进行分类的人与作者具有相同的问题背景。最好总是从描述相关背景开始，以便读者的大脑和作者的大脑在进入问题之前有共同点。请记住，本期只有一位作者，但有很多读者。这是最好的部分：你为澄清而付出的所有努力将为每个阅读它的人带来巨大的回报。

告诉我们如何重现它

问题报告的另一个关键部分是提供简单的再现。其中有两个重要部分：进行重现并确保其易于遵循。您必须提供重现问题的步骤，因为没有这些步骤，团队就无法讨论任何内容。同样重要的是，这些步骤易于遵循，以便可以重现问题。如果示例代码是步骤的一部分，那么将现有代码库转储到问题中是没有帮助的。最好花一些时间来缩减示例，直到无法删除更多内容为止。复制中的代码越少，快速识别问题的机会就越大。只要有可能，使用在线编辑器（例如https://stackblitz.com/ ）只需单击一下即可进行复制。

良好的再现可以引导读者一步一步地进行，同时提供有用的上下文：

1. 打开这个链接
2. 看到这段文字
3. 现在点击这个按钮
4. 它应该会导致这种情况发生，但相反，却发生了另一件事。

如果没有叙述与复制相配合，它就变成了一场猜测作者想让读者看到什么的游戏。假设读者一无所知，然后通过复制逐步引导读者了解令人难以忍受的细节。如果你在这里包含太多细节，你不会侮辱任何人，但排除这些细节不仅会让读者感到沮丧，而且会让团队更难提供帮助。

让我们知道您的想法

最后，最好的问题是尝试猜测 Angular 代码库中问题所在的问题。即使猜测完全错误，它仍然对阅读该问题的人有帮助！提出理论为读者提供了一个良好的起始背景，并且通常会导致更快的解决。

结论

我以同理心的想法开始写这篇文章。问题双方都需要互相同情。感谢您提出问题，因为它只会有助于让 Angular 更好地服务于每个人。请记住，创建问题只是一个开始。拥有清晰的描述、良好的可重复步骤以及您可以提供的任何其他上下文，使得您的问题更有可能被分类甚至修复。感谢您为 Angular 社区做出的贡献！

文章来源地址：https://blog.angular.dev/how-to-file-an-issue-715391a093d2