我们在一个小办公室里使用 Discourse。如上所述，存在草稿问题。您可能知道，有一种习惯是快速创建一个新文件夹，然后是新文件夹 (2)，一个新文本文档，一个新文本文档 (2)，用不同的信息填充这些文件，并且之后从不重命名它们。
后来发现文本块没有时间参考，没有版本，没有图片，有时由于缺乏自动保存而导致一些东西未保存。
文本文档中的信息混杂且结构混乱。长时间后，在这种文件夹中找到任何东西的机会非常渺茫。内容索引或人工智能可以在此情况下提供一些帮助，Discourse 就能实现此功能。
我提到了办公室团队合作。这意味着员工的本地专有草稿被锁定在用户帐户后面。谈到从事协作任务的员工，没有必要向彼此隐藏他们的草稿。相反，如果草稿能立即提供给所有人，那就更好了。还记得软件开发人员是如何工作的吗？他们将代码（通常是代码形式的文档）放入带有版本控制的共享存储库中。一旦首席工程师检查了更改，它们就会在主分支中提供给所有人。在草稿的情况下，不需要这样的主持人。所以 Discourse 在这方面做得很好。
带有链接图片的草稿问题很容易通过 Markdown 编辑器解决（我一直使用 Typora，尤其是在编辑表格和奇怪的向后 base64 图片转换时 - 没有编辑器会从剪贴板插入此文本）。Discourse 非常适合作为并发工作平台。聊天讨论可以轻松转换为主题或帖子。OpenAI 模型可以在数据处理中发挥重要作用，但内置算法也足以使论坛帖子看起来相关。
我们使用收件箱功能将文本快速作为电子邮件发送到论坛。这样，我们就不会在不分心打开论坛本身的情况下丢失宝贵的想法。然后，我们在头脑风暴中使用这些想法。
使用权限，当主题准备好时，可以轻松地将它们从沙盒移到公共区域。灵活的信任级别允许我们为不同部门组织访问权限。
5 个赞
mcwumbly
(Dave McClure)
25
@Ivan_Rapekas 如果我理解正确的话，贵组织已经在将 Discourse 用作协作笔记应用程序。我的理解准确吗？还是我有什么误解？
在使用 Discourse 作为笔记应用程序方面，您目前遇到了哪些挑战？您是否考虑过进行任何更改来帮助解决这些挑战？
也许这是您目前面临的主要问题？
您是否考虑过创建一个用于草稿的分类，并明确其中包含的是未经打磨的、正在进行中的工作？
4 个赞
是的，我们使用 Discourse 已有 3 年。起初，我是唯一在 Discourse 中分享笔记的人。我意识到我不需要使用文本编辑器来准备文章，然后才能发布。我过去每天都会回答支持团队的相同问题。我创建了一个个人知识库。
一年后，我们雇了一个人，他受到 Discourse 文章的启发。他成为了第一位编辑。作为先驱，他将影响力扩大到了身边的同事。现在，150 名员工中有 1/5 的人积极参与 Discourse 的写作和编辑。主题默认是 wiki 类型，编辑次数不设限制。
起初，团队对 markdown 表格和无法索引附件感到困惑。
然后他们意识到，可编辑的文本比编译后的 PDF 更强大，例如。无需搜索源代码、请求批准、制作二进制文件、上传文件，最后通知更新。
你问主要问题是共享草稿，对吧？是的，就是这样。但我认为根本问题是冷漠和责任感。有时他们害怕展示自己的工作，但他们总是漠不关心别人如何使用他们生产的东西。
此外，人们没有动力公开做某事，因为他们会成为被询问的对象。另一件事是，在这种情况下，论坛成员会在论坛外讨论。他们更喜欢在 Skype 中聊天，而不是引用原始帖子并在同一个地方交谈。在我看来，人们总是喜欢“快速通道”来解决他们的问题。
更新：我们不划分草稿和已发布文章的类别。有时我们会将草稿移至“公告”。就当它是一篇完成的文章吧 
5 个赞
simon
27
我投了赞成票，因为我认为 Discourse 应该在这个领域有所作为。我更倾向于一个本地笔记应用程序，它可以与共享的 Discourse 实例同步。
就我而言，笔记应该以 markdown 文件形式保存在本地，可以用 Vim 编辑，并能轻松地与 Github 和 Discourse 同步。
我去年粗略地开发了一个 Obsidian/Discourse CLI 应用程序。它作为第一次尝试效果足够好。我喜欢 Obsidian 使用文件系统作为事实来源，但如果我再做一次，我会排除 Obsidian，而是使用 SQLite 数据库来保存本地笔记。（我也会使用 Go 而不是 Ruby 来开发应用程序，只是为了让人们更容易安装。）
4 个赞
ToddZ
28
嗯，他们是一家小型企业，相当透明，服务（同步、发布）价格合理，并且拥有强大的插件开发者和用户社区。而且由于一切都基于本地 markdown 文件，所以不用担心平台锁定。我喜欢开源，但在开源和大型科技公司之间，还有很多公司可以发展。
6 个赞