Lorawan-stack: 问题的问题模板

所以“行动”将是我们直接更新引用此问题的文档（如果这是唯一的更改）并在导致错误修复/功能请求时打开另一个文档？

确切地。 “问题”问题的结果通常应该是我们文档的更改，或者我们的常见问题解答的补充。

我不知道将“问题”问题复制粘贴到“错误报告”问题中是否有意义。 如果我们决定将问题转化为错误报告或功能，也许我们应该在评论中添加相关部分（或编辑问题）。

同意，但这也应该适用于论坛和松弛。

本质上，所有信息都应该在 repo 文档中，如果某些信息是在论坛、问题或 slack 上引用的，那么我们没有制作文档。
在 slack 上提出的问题或问题，除非不努力寻找信息，否则论坛应弥补文档中的更改。

我会添加一个链接到 github/doc 上的查询（一旦搜索是 impl），而不是“你看过那里”的列表。 在 github 问题中查找信息可能很乏味，并且论坛不应包含文档没有的信息/解释。 指向已建立查询的链接（例如查找错误）将有所帮助。 还可以设想在文档中添加已知错误部分。

如果一个问题揭示了错误，则由开发人员将其限定为错误（并将问题编辑为错误报告），或者如果问题的唯一部分涉及错误，则打开另一个问题。

我完全同意我们应该更好地监控论坛和 Slack，并将（好的）问题转化为文档改进（至少对于v3 类别和lorawan-stack 频道）。 @Sypheos您如何看待它在实践中的作用？

“你看过这里吗”的目标更像是在进行任何搜索之前对提交问题的人进行过滤。 下一部分更有用，我们可以要求问题提交者链接（或引用）相关论坛帖子、松弛消息等。

我认为这是个好主意。 让我们保持这个问题的范围和问题模板真的是一个新问题。

至于文档改进，即论坛和 Slack 上我们想要部分文档的非正式回答，我们可以考虑额外的“文档请求”问题模板，它是最小的； 它基本上描述了文档差距和信息现在所在位置的链接（即论坛/Slack 消息的链接）。 但是，对我来说，这又超出了这个问题的范围。

对于问题模板imo：
正在寻找/做什么？
你在哪里看的？
_欢迎添加任何网页、问题、查询 github、文档、论坛_
为什么不满意？
_404 not found 是合法的 anwser_

标签： 问题

如果没有资源可以回答问题，请打开“文档请求”问题。

我们真的应该确保任何答案最终都出现在文档中，否则这里关闭的问题会变成 V3 知识库，我们应该避免这种情况。 所以也许我们甚至应该跳过“问题”模板，直接进入“文档请求”。

此外，当这个存储库的使用增加时，这最终成为提出问题的首选地点，我们很难调整它（即指向文档和关闭问题），我们将来可能会后悔。 请注意，像VS Code这样的大型存储库表明您不应该过于激进地提出问​​题：

简而言之，让我们考虑一下；

• 根本不允许提问，只允许“文档请求”问题。 问题仍然有效，但前提是它确实没有记录，否则它不是有效的文件请求，我们将其关闭
• 直接向文档（当我们有它们时）和论坛提出问题

文档请求实际上是“问题”，因为他们正在寻找某些东西但找不到它。 一开始他们有一个需要回答的问题。
为了朝着这个方向前进，通过 github 上的问题简单地拒绝任何文档请求和问题会更有意义。

如果有人想问一个问题，他们会去 slack 或论坛，核心团队或审核人员可以在文档 PR / bug 问题 / 功能请求问题中提出他们的问题。

决定：我们将使用https://github.com/TheThingsNetwork/lorawan-stack/issues/890#issuecomment -507324845。 指向论坛的问题模板和文档请求模板