将定制功能迁移到 Discourse（写作评论）

社区
1

这是一个关于 Discourse 功能可定制程度以及相关工作量的问题。

我所在的是一个专业科幻作家组织的技术团队，我们主要依赖一套由现已离任的创始人编写的论坛软件。该软件运行在老旧的 ASP.NET Core, an open-source web development framework | .NET Server 架构上，我们非常希望能迁移到一个新的平台。

该软件最受欢迎的功能之一是故事评论功能。用户可以上传文档，包含标题和字数。有一个专门的页面展示所有正在寻求反馈的故事。该软件内置了一些简单的游戏化机制：上传故事会自动创建一个讨论主题，任何回复字数超过 750 字符的用户都会获得积分。当用户收到足够多的回复后，就可以阻止其他人下载该文件。

在故事下载页面，每个用户名旁边会显示他们获得的评论积分数量，以及他们的故事所收到的评论数量。这些积分本应大致保持平衡，但完全依靠自觉；据我所知，从未有人因只索取评论而不提供评论而受到警告。整体运行效果相当不错（除了上述老旧的技术架构问题）。

长期用户有时会积累惊人的积分，我们非常希望将这些积分迁移到新平台，而不是抹去所有人的高分记录。

我的问题是：将此类功能整合到 Discourse 论坛中会有多简单？这是否可以通过定制插件实现，还是需要开发一个通过 API 与 Discourse 交互的独立应用？非常感谢您的任何指导。

4 个赞
2

这应该可以通过插件实现。这些积分可以作为自定义字段与主题、帖子和/或用户关联起来。

为了明确功能细节，有几点需要确认：

这些积分是否仅依据回复的长度来计算？

“足够多”是如何定义的？

我假设“该文件”指的是故事？他们是否需要采取明确的操作？也就是说，是否存在一个“阻止他人下载文件”的按钮，在满足“足够多的回复”条件后解锁？

故事所获得的数量（即积分？）是如何计算的？

5 个赞
3

感谢回复！

任何超过 750 个字符的回复都会获得积分（在批评帖中，可以通过包含“这不是批评帖”这几个字来发布非批评性质的帖子，但我认为从未见过有人这样使用）。如果作者在自家的批评帖中发布了超过 750 个字符的帖子，则不应产生任何积分。

由故事作者自行决定。他们可以判断何时已收到关于其故事的足够反馈。

是的，“文件”即指故事（Word 文档、RTF 文件或其它格式）。作者可以随时点击一个按钮来禁用进一步的下载。如果他们在分享前改变主意，甚至可以在任何人下载文件之前点击该按钮。

与其尝试总结，不如直接提供 SQL 语句：

CASE WHEN WordCount < 1001 THEN 0.5 
 WHEN WordCount BETWEEN 5000 AND 9999 THEN 1.5 
 ELSE Round([WordCount] / 10000, 0) + 1 END

实际上，人们很少上传超过 1 万字的小说。

3 个赞
4

正如 Richard 所说，插件可以实现任何功能。你提出的方案可能只需要几个小时的工作量。或许有一些捷径可以帮你控制预算。自定义徽章也可能有所帮助。你当然可以先开发出新插件，然后在迁移时将数据导入其中。

不要将复制旧系统等同于打造最佳系统。

你可以使用已解决的插件或标签功能来关闭审核时间。

如果你的整个系统是定制开发的，那么定制导入工具的费用通常在 1500 美元左右，而所需的插件可能还需要差不多同样多的费用。

6 个赞
5

你也可以不再区分故事和评论的署名，而是直接复用 Discourse 的“点赞”功能（分享爱心）作为分享署名。这将使迁移和实现变得相当直接。不过，我可能忽略了将署名分开的好处？

2 个赞
6

这个理念是回馈社区。如果有人在阅读你的作品并就如何改进提供反馈，你也应该阅读他人的作品并给予反馈。如果能通过 Discourse 的内置功能来监控这一点就太好了，但我看不出如何实现。

3 个赞
7

您可以对用户的点赞进行更详细的查询。例如，通过查询“故事”类别中初始帖子和后续帖子的点赞数，您可以区分用户因发布故事而获得的点赞和因分享反馈而获得的点赞。

随后，您可以设计徽章（配合用户头衔和标识），以奖励达到特定数量的用户。

2 个赞
8

问题在于，据我理解，点赞是用来展示帖子受欢迎程度的方式，但我正在尝试迁移的系统则是用于监控用户是否达到了基本的努力水平。因此，如果故事线程中任何包含超过一定字符数且非故事作者发布的帖子，能够自动被点赞一次且仅一次，那将符合我们的系统需求。但这似乎与点赞的运作方式不太匹配。

2 个赞