业余插件作者案例研究

完全理解。[1]非常喜欢 Discourse,我写这篇帖子是因为我希望 Discourse 能够持续取得成功。

我学到的一点是,社区并不喜欢变革,但如果他们感觉自己拥有自主权,就会对变革更加开放。赋予人们自主权的方式有无数种。例如,可以将教程改为 维基帖子,这样像我这样的人就可以更新它们。实施 ESR 计划也有帮助,因为它让人们可以选择暂不立即进行更改。[2] 能够写下我的经历并让管理开源项目的人看到,也很有帮助。尤其是因为我抱怨的问题在一夜之间就得到了解决。:wink:

在《倾听用户是否有害?》一文中,[3] Kathy Sierra 写道:

我们大多数人都意识到,焦点小组在许多方面 notoriously 无效,但我们仍然假设倾听真实用户的真实反馈是推出新产品和服务以及改进现有产品的最佳方式。但这存在一个巨大的问题——人们未必知道如何提出他们从未设想过的需求! 大多数人提出的建议完全基于_渐进式_改进,着眼于现有内容并思考如何使其更好。但这与拥有某种全新事物的愿景截然不同。

真正的创新很少会直接来自用户所说的话。

正如我所说,我不是前端开发人员。我不太明白为什么会有这些更改,也不清楚它们将如何使我受益。[4] 如果这些更改最终能让 Discourse 变得更好,那也没关系。

不过,如果我能更清晰地看到愿景,就能帮助像我这样的人更好地接受这些变化。对于 这项更改,其宣传点是:

  1. 更佳的开发体验
  2. 将为未来版本的 Discourse 带来显著的性能提升

听起来不错,是吧?我并没有特别注意到第 1 点和第 2 点可能包含多种含义。对我来说,更有效的方式可能是(我完全是凭空想象的):

  1. 在转换官方 Discourse 插件时,我们发现这减少了 X% 的代码行数。将模板与 JavaScript 放在同一文件中,使得代码更易于理解和修改。
  2. 我们设置了一个分支,测试完全移除 Handlebars,发现这一更改使页面加载速度提升了 X%。不仅如此,我们还发现了一种潜在的优化方案,可以解决 [用户提出的一些问题]。

多一些细节,并着眼于教育非专家,对于维持信任大有裨益。我可能不喜欢这些更改,但面对其他用户实际遇到的问题,我又怎能反驳呢?


  1. OpenSSL 也有类似的动态。我们有一个公司(约 15 人)负责销售支持合同,还有一个基金会(10 人,包括我在内)负责非商业利益。我们的文档也存在滞后问题。在撰写原帖时,我发现其中仍引用了上个月已移除的功能。我正在为此提交一个 PR。此外,我们还进行了一些更改,这些更改受到了 下游 项目 的高度批评。 ↩︎

  2. 对于希望支持那些希望紧跟前沿的社区的插件作者来说,这帮助不大。但对我而言这将非常有益,因为我相信我是唯一使用我的插件的人。 ↩︎

  3. 她的博客已从互联网上消失,但这里有一份 PDF 存档↩︎

  4. 这并不是说我在大局中多么重要。我所说的“我”只是代表其他依赖 Discourse 的人。毕竟,我比大多数人更了解自己! ↩︎