Greg Sutcliffe 是 Foreman 社区 的长期成员，现在是社区负责人。 Foreman 是一个用于物理服务器和虚拟服务器的生命周期管理工具。 他一直在研究社区指标在现实世界的应用如何洞察其有效性，并发现理想与实践之间存在的差距。 他分享了他从数字背后发现的见解，以及他如何利用这些见解来帮助社区发展。
在这次访谈中，Sutcliffe 与我讨论了他们正在使用的指标，这些指标与社区的目标有何关系，以及哪些指标对他们最有效。他还谈到了他最喜欢的工具，并为其他希望提高指标水平的社区经理提出了建议。
James Falkner：感谢你接受这次采访！你能介绍一下你自己、Foreman 社区以及你在其中的角色吗？
Greg Sutcliffe： 感谢邀请！
Foreman 已经存在七年多了，我参与该项目大约六年了。 我一直是用户和社区成员、贡献者、付费开发人员，现在是社区负责人，所以我认为这给了我一个广阔的视角。
该社区与许多项目类似；它大致分为用户和开发人员。 显然，我们从那些选择花费时间为项目贡献代码的人那里获得了巨大的价值，但我确实觉得很容易忽视那些以其他方式做出贡献的用户。 我们的社区在测试和报告方面非常活跃（例如，在新版本发布候选阶段，我们会收到大量反馈和错误报告），并且我们提供完整的本地化支持，因此在文档和许多其他非严格编码的领域都有贡献。
我的角色是支持社区并帮助其发展，这是一个相当广泛的目标，但我真正感兴趣的主要事情是扩大用户群。 总的来说，我不认为你可以直接扩大开发者群体，所以目标是带来更多各种类型的贡献，正如我刚才列出的那样，以及征服世界（正如我们都想做的那样）。
为了做到这一点，我专注于内容创作（例如，我们会定期在 YouTube 上进行演示、深入研究和 案例研究）、活动管理、为 CFP 组织演讲者等等。 挑战在于将信息传递给尚未听说过我们的人——即使在七年后，当我做演示时，我仍然听到有人说：“哇，这将解决我的很多问题。”
除非知道社区正在发展（但无论如何它可能会发展），否则指标实际上并没有帮助。 然而，我的另一个角色是向那些尚未信服的人展示社区的价值，而这正是指标真正发挥作用的地方。 当你游说社区预算时，展示你可以从社区获得的价值量确实可以帮助你。
JF：你在 Foreman 社区中使用指标（包括定性和定量）的程度如何？
GS： 问得好。 目前，我们做了很多收集工作，但没有真正的可视化。 这主要是因为我是一个糟糕的前端编码员，所以虽然我有一个巨大的数据库，但我没有任何东西可以用来绘制它。 这让我很痛苦，因为我真的很想要一个漂亮的仪表板，可以展示给社区。
但是，我确实在我们定期的 sprint 演示（这是公开的，因此社区会收到更新）中运行一些时间点的东西和逐月比较。 这不是很理想，因为没有人可以自己验证我的声明，但总比没有好。
就我们拥有的哪些指标而言，通常会有一些常见的东西（Redmine 打开/关闭的错误、GitHub PR 打开/关闭、软件包下载），这些指标很容易获得，但除了显示“社区正在做事”之外，没有太多价值。 我也开始运行一些查询，告诉我“社区与红帽开发人员打开的错误百分比”和“邮件列表首次回复并非来自红帽开发人员的百分比”之类的事情。 这些数字是开始了解社区提供的价值的一个开端，我计划使用更多这样的指标。
不过，我想补充一点，一位同事曾经说过：“你衡量什么，你就是什么。” 鉴于缺乏足够具体的指标（我认为你称它们为二阶指标），我试图记住这一点，并且我试图不被它们束缚。 当我们有更好的指标时，我们可以更有效地使用它们。
JF：你认为哪些特定指标或指标类型对你作为社区经理的帮助最大？
GS： 我想这直接关系到我上面提到的角色的两个部分。 第一个（社区增长）确实需要与稳定性（错误）、用户保留率、社区满意度等相关的指标。 我们每年都会进行一次社区调查，这确实有帮助，但我们可以从我们拥有的数据中收集更多信息。
第二个（创造的价值）特定于我们是一个拥有下游产品的红帽项目（Satellite 6，红帽的系统管理产品）。 有些工作无论如何都会完成，但如果社区做了，那么红帽现在就有可以用来以其他方式进一步推动该项目的资源——这是一个积极的循环。 在我们的质量保证团队看到它们之前发现（或甚至关闭！）的错误，或者社区支持自身（而不是开发人员花费时间在支持上）的程度，这些指标真的非常有用。
JF：同样，你认为社区成员可以从看到和理解哪些指标中受益？
GS： 像 PR-time-to-commit 或 bugs-time-to-close 这样的社区增长和活动图有助于我们了解我们是否朝着正确的方向前进，或者我们是否需要在项目的某些领域获得帮助。
创造的价值可能对红帽以外的人没有太大的兴趣，但相同的图表可以用来讲述另一个故事。 知道很大一部分被提出和修复的错误、邮件列表支持、候选测试等都来自社区，这有助于我们知道我们是一个自我维持的社区，并且我们可以对项目的未来充满信心。
JF：你最喜欢的分析和报告项目指标的工具或框架是什么？
GS： 对于收集，我正在使用旧的 MetricsGrimoire 工具（bicho 用于 Redmine，pullpo 用于 GitHub），以及一个 Google Groups 网络爬虫，因为 Groups 没有 API（叹息）。 还有一些用于将 Groups 数据导入数据库和用于解析来自我们的 Yum/Apt 服务器的 Apache 日志的自制工具。
正如我提到的，我目前没有在其之上的太多可视化。 我曾经玩过一段时间 Redash.io，但在陷入其他事情之前并没有走太远。 我很乐意了解用于解析数据的替代方案（尤其是 MySQL 或 PostgreSQL 数据库中的数据，因为这就是我所拥有的）。
JF：描述 Foreman 社区的理想指标，无论收集和报告它可能需要多长时间。
GS： 我有一些很难或不可能获得的指标。
首先是不可能的指标——人们离开的原因。 一旦有人离开社区，几乎不可能知道原因，甚至不知道他们已经离开了。 他们不会看到你的博客、你的调查等等，所以你无法联系到他们。 但了解他们的问题可能与改进你的项目有关，特别是如果你从足够多的人那里得到相同的事情。
第二个是用户群本身。 与许多开源项目一样，我们根本不知道谁在使用我们的软件。 Foreman 中没有电话回家数据收集，所以除非你通过与我们沟通来选择自己，否则我们永远不会知道。 我很想知道我们的用户在哪里，这样我就知道在哪里集中精力，例如，聚会计划。
JF：你会给刚开始并且有兴趣通过指标了解更多信息的社区经理什么建议？
GS： 我发现这是一个非常有趣的领域，我希望我有更多的时间花在上面。 我肯定会说，你首先要从你的目标开始。 有很多东西你可以衡量，但获取数据可能需要花费大量的时间和精力，远远高于数据的价值。 这是我通过惨痛教训学到的一个错误，我仍在纠正它。
JF：还有什么想让我们的读者知道的吗？
GS： 如果你对任何项目有建设性的批评，请发送给我们。 我不能代表其他社区负责人，但我喜欢听到和与用户交谈，即使是非常挑剔的用户。 这意味着他们关心，并且它有助于我们作为一个项目做得更好。
如果你需要在 Foreman 中这样做，我通常在大多数地方的 @gwmngilfen。
评论已关闭。