Dev.to 发布质量

回应：

• 我觉得 Dev 中帖子的质量正在下降
• 改进 DEV 提升优质内容的方式

这是一个相当有趣的研究案例。

一方面，我们有一些网站会针对帖子的受欢迎程度（参与度）进行优化，比如 Hacker News 和 Reddit。用户可以对内容点赞或点踩。这些网站往往充斥着负面内容和精英主义。想要登上热门位置很难，但如果作者登上了热门位置，他们就会获得大量的浏览量和评论。

另一方面，我们有一个 dev.to，其主要目标是尽可能保持对初学者的友好。CoC 的承诺使其无毒无害。但内容的平均质量往往较低（个人观点）。由于帖子数量庞大且没有“真实”评分，优秀的作者失去了写作的动力——好文章会被淹没在大量糟糕的文章中。

有出路吗？有哪些替代方案？

• 声誉（或业力）系统是否倾向于让社区精英化？在我看来，缺乏CoC（声誉）会让社区变得有害（而不是因为负面评价功能）。
• 如果我们允许踩点，但只显示反对作者的点赞（这样就不会被公开羞辱了）会怎么样？就像 dev.to 不显示关注者数量一样。只要帖子获得一定数量的点赞，就会获得一些徽章（例如，50 个点赞 = 🦄）。

我不知道这里有什么解决方案。我提出一些想法来讨论。

新手友好是一个好的目标，但有些作者甚至懒得添加一些内容，就把帖子发到成千上万的用户的推送里。这跟垃圾信息有什么区别？新手友好和尊重其他用户之间应该有个合理的界限，对吧？

质量

我也觉得 dev.to 上的平均文章质量相当低。

重要提示：我之所以批评它，是因为我自己也在为 dev.to 写文章。所以这些批评也适用于我。只有红头发的人才能批评红头发的人。

但这其中有个小窍门。你如何定义一篇帖子的质量？如果你读过第一篇帖子的评论，你会发现大家的看法各不相同。

那么，让我们来讨论一下哪些选项，哪些我们认为质量较差。这些选项尚有争议，但并非最终结论。

违反行为准则

不算太坏。

垃圾邮件

垃圾邮件 - 未经请求的、通常为商业性的信息（如电子邮件、短信或互联网帖子），发送给大量收件人或在大量地方发布

—— 《韦氏词典》

我想每个人都会同意垃圾邮件是有害的。

对抗方式：限制新账户的帖子数量、限制新账户的外部链接数量、垃圾邮件检测算法（如 akismet 或类似算法）、审核、垃圾邮件报告系统。

总的来说，这是互联网上一个长期存在的众所周知的问题，并且有成熟的方法来解决它。

注意：感觉在 dev.to 上发垃圾信息比举报更容易。发帖不需要通过验证码，但举报垃圾信息需要证明你不是机器人🤷‍♀️。

抄袭或复制粘贴

剽窃——窃取并将（他人的想法或文字）当作自己的：使用（他人的作品）而不注明来源

韦氏词典

不算太坏。

注意：不要与交叉发布混淆。

缺乏内容

没有任何意义的帖子，例如无法阅读的文本或仅有“测试”或类似的标题。

应对方法：警告作者“你即将发布一篇空文章，虽然你可以这样做，但我们建议至少添加一些文本”

事实错误

对事实进行虚假陈述的帖子。就像 Twitter 和 Facebook 试图打击虚假信息一样，我们可以在帖子中添加一个小的免责声明，就像该主题的官方来源一样……

术语滥用

有时会发生软件开发术语被误用的情况。

以事实呈现的观点

许多无法用事实证明的事情被当作事实来呈现，例如“如何通过避免 else 语句来成为更好的开发人员”。

文本质量差

帖子中存在（大量）语法错误，文风糟糕。

这很有争议，因为有很多非英语母语的人。也许我们可以允许管理员帮忙修改语法🤷‍♀️。

格式质量差

文本格式较差的帖子，例如，代码没有围栏或围栏没有指定语言，缺乏文本结构，例如没有标题。

战斗之道：Markdown编辑器的游戏化介绍

内容浅薄或复述能力差

例如，一篇名为“JavaScript 中的数组方法”的文章，随机选取并展示了 5 种方法，但与阅读MDN等“官方”手册相比，并没有什么价值。这类文章的价值在于，它尝试用现实世界的类比来解释数组方法。

值得争论的是：如果这些文章以“今天我学到了”的风格呈现，那就没问题。

列表文章

每个人都喜欢列表，但一遍又一遍地阅读“<年份>中<主题>的<事物>的前<数量>”有点适得其反。

这些文章的问题在于它们缺乏任何类型的研究——您可以在“很棒的存储库”中或通过简单的互联网搜索找到相同甚至更大的列表。

如果列表文章内容详尽或包含某种比较或这是独特的内容，那么列表文章就是有意义的。

蒂瑟斯

包含部分内容的帖子，并附有原始文章的链接。

有争议，但我不明白这种策略背后的原因。dev.to 有权威链接，所以 SEO 应该没问题。让用户多点击一次有什么意义？

离题

与当前主题完全无关的事情......

城市词典

有争议。甚至还有个标签#watercooler