注意：这是我的第一个功能请求，如果我找错了地方或有应遵循的指南，请告诉我。
您好，Discourse 团队：
此功能请求的背景是 Discourse for Teams。
在使用 Discourse 进行异步工作沟通时，很难知道某人是否已阅读消息并打算跟进。例如，我可能想传达以下想法：“我已看到您的建议，下周会跟进。”这对于沟通和管理期望非常有用。没有这个功能，人们很可能会在 Discourse 或即时消息（例如 Slack）上催促您。
目前，可以通过以下方式进行沟通：
。可惜这并不能提供时间表，例如您何时会跟进？相反，我想建议构建一个像 threads 那样的功能/插件。例如，您可以明确表示您将在以下时间跟进：
它将显示如下：
这与 Discourse 中的书签功能非常相似，只是书签是私有的（我建议它们保持私有）。
您怎么看？
抄送 @tobiaseigen
嗯……我们团队确实没有遇到过这种情况，我自己也从未听说过这个请求。通常，我们会在讨论区就何时有时间回复、何时需要完成任务等话题进行交流。我们现在有“分配”功能，这很好，但它也没有提供时间。我们让每个人自行决定何时在论坛上阅读和跟进话题，工作进展相当顺利。
对我来说，期望使用一个功能来告知他人何时会回复，这似乎有点过于严苛和有压力。我们希望 Discourse for Teams 平台能够减轻压力，让工作更有趣、更高效，而不是增加压力。但也许我错了——你能否详细说明一下你的用例？或者这只是你怀念另一个平台上的某个功能，你已经习惯了它？
我的看法略有不同。我认为设定预期很重要。我和我的团队面临的需求是他们能力范围的 10 倍，所以我发现承认我看到了请求但需要一段时间才能处理是有帮助的。我认为这可以减轻压力，因为它区分了“我没看见”/“我看见了但我不关心”和“我看见了，但因为我忙于其他事情，我会稍后处理”。
前者会鼓励人们追问你以获得答案，因为他们没有收到任何反馈。后者让他们有机会接受时间表或在需要更早完成时升级。
正如我所提到的，今天可以通过在主题中发布消息来完成。但我认为这是一种非常“即时通讯”的方法。它不会让对话有太多进展，而且我也不特别想为了这个而顶起一个主题。在我看来，这更像是一种反应。主题的拥有者可能会感兴趣，但其他人是否都想看到一个未读计数器，促使他们打开主题并发现 A 将于下周回复，B 将于周四回复，等等？我认为不会，这会非常嘈杂。
次优的选择是在 Slack 上询问人们何时会跟进，但这现在会导致缺乏透明度和额外的打扰。
我们实际上并没有使用我提到的平台。但是，当我们（在异步工作的背景下）研究各种选项（Discourse 与其他平台）时，这对他们来说是一个非常大的优势，我们的团队可以立即看到它有多么有用。
我真的很想知道有多少人会使用它。不过，感谢您详细的介绍！
正如您所指出的，此功能已作为书签计时器存在。唯一的区别是书签是_私有的_而不是_公开的_。不确定 @martin 和 @sam 的想法，但我不太相信这在实践中会被使用。
我确实喜欢这个想法。让团队里的其他人知道你大概什么时候会回来处理某件事，而无需另外发消息，这很好。我也听到了关于这会变成一件有压力的事情的担忧，如果有人期望你在特定的日期+时间回来处理，而你却做不到，这会让你感到压力吗？但这取决于文化。也许我们应该等待更多关于这类事情的请求，然后再继续。也许公开的收藏夹加上公开的提醒和笔记是个好主意，但据我回忆，我们确实没有听到其他关于这方面的请求。
通常处理此功能的方式是回复：
我已收藏该主题，将在 N 天后书签触发时查看。
这无疑会增加一些噪音，但我也认为这种情况发生的频率不足以需要围绕它构建一个专用功能。
感谢大家的反馈 
。
如果你告诉你的团队或老板你将在某个日期前完成某件事，但没有做到，这会让你感到压力吗？嗯，如果你不沟通，100% 会。
压力不是来自工具，而是来自你未能履行承诺。 这就是工具可以提供帮助的地方。通过列出这些承诺，你可以列出它们并决定如何处理它们（包括什么都不做）。
之前告诉 Tobias 的一个旁注：这个功能对于 discourse 支持的大多数社区来说可能意义不大。它实际上是关于异步工作的。我怀疑元（meta）上的用户中有多少比例将 discourse 用于团队，充其量只是很小的比例，因为 discourse 用于团队是一个蹒跚学步的孩子，而普通的 discourse（一个于 8 年前推出，另一个于 1 年前推出）。
元（meta）上没有讨论团队的类别。很难知道要关注什么以及如何贡献（你很可能与 99% 的读者无关）。
因此，沉默可以有两种解释：这是一个坏主意，或者没有 discourse 团队社区的成员在场做出反应。
discourse 本身不就是为了建立社区而存在的吗？ 
谢谢你，朱利安！一如既往，你的建议都非常好。经过一段时间的思考，我认为你只需在组织内部设定一些规范，就能在很大程度上满足你的需求。例如，向所有人明确沟通，某些类别的主题将分配给特定人员，并承诺在一定天数内回复。这样，人们就会有耐心等待你的回复，而你也会知道首先回复哪些帖子。在少数需要更多时间的情况下，你可以回复告知大家你何时回复，并可能解释为什么需要更多时间进行研究或其他原因。然后给自己设置一个提醒。
你知道你可以将主题中的特定帖子分配给一个组或一个用户吗？你可以将其分配给自己或支持团队，从而与所有相关人员沟通帖子已被看到，并且即将回复。然后，“分配”将显示在“组”页面上。
我确实认为现在是时候开始讨论为 Discourse 添加更多任务管理功能了，我认为这将有助于你的用例。这意味着能够为分配设置截止日期或目标日期，甚至可能还有依赖关系。例如，一旦用户 A 完成了分配的帖子 1，用户 B 就可以开始处理分配的帖子 2。还包括分配的日历和看板视图，以便更轻松地组织任务和确定优先级。
我们确实有 Kanban Board Discourse for Teams 中会很有趣。
我认为我们现在还没有必要设立专门的团队空间。社区功能请求和团队功能请求都可以在 Feature 分类下提出。设立 #team 分类的意义在于提供一个更公开地讨论 Discourse 团队用法的空间，而不是发布 bug 和功能请求的地方。在创建专门的空间之前，我们需要进行更多的此类讨论。
Discourse 对许多人来说意味着很多，团队功能请求和公共支持社区功能请求在这里都受到欢迎。
对我而言，这个特定的请求感觉有点为时过早。
首先，@nbianca 正在着手完善书签列表，以支持一种模式，即你的书签充当待办事项列表，你必须明确删除书签才能将其标记为完成。一旦我们有了这个功能，也许我们可以开始探索共享书签列表的想法……例如，提供一个选项，表示“嘿，我的书签列表是我的待办事项列表，与大家共享，我对此没意见 [ ]”。
现在不是时候，还有很多事情需要先完成。
