如何应对社区指标的挑战

考虑采纳这些建议，以应对为您自己的社区实施社区健康指标时遇到的组织和技术挑战。

本系列前两篇文章探讨了开源社区的健康状况以及用于理解它的指标。它们展示了开源社区如何通过指标衡量其健康状况的示例。最后一篇文章将这些想法汇集在一起，讨论了为您自己的社区实施社区健康指标的挑战。

组织挑战

首先，您必须决定要检查哪些指标。这需要了解您作为社区为实现目标而提出的问题。与您相关的指标是那些可以回答您问题的指标。否则，您可能会被大量可用数据淹没。

其次，您需要预测您希望如何对指标做出反应。这关系到根据您的数据向您显示的内容做出决策。例如，这包括管理与其他社区成员的互动，正如之前的文章所讨论的那样。

第三，您必须区分指标中的好结果和坏结果。一个常见的陷阱是将您的社区与其他社区进行比较，但事实是每个社区的工作方式和行为方式都不同。您甚至不一定能比较同一项目内的指标。例如，您可能无法比较同一项目内仓库的提交数量，因为一个仓库可能正在 squashing commits，而另一个仓库可能有数百个微小的提交。您可以建立一个您现在和过去所处位置的基线，然后查看您是否随着时间的推移有所改进。

隐私

我想讨论的最后一个组织挑战是个人身份信息 (PII) 问题。开源的核心价值和优势之一是贡献者工作方式的透明度。这意味着每个人都有关于谁参与的信息，包括他们的姓名、电子邮件地址以及可能的其他信息。在使用这些数据时存在伦理方面的考虑。

近年来，诸如欧洲通用数据保护条例 (GDPR) 之类的法规定义了关于您可以使用 PII 数据做什么以及不能做什么的法律要求。关键问题是您是否需要征得每个人的许可才能处理他们的数据。这是一种选择加入策略。另一方面，您可能会选择使用数据并提供选择退出流程。

这种区分很重要。例如，假设您正在为您的社区提供指标和仪表板作为服务。为了改进社区，您可能会提出这样的论点：一旦处理完成，（已经公开可用的）信息对社区具有更大的价值。无论哪种方式，都要明确您使用哪些数据以及如何使用它们。

更多关于安全

技术挑战

您的社区数据在哪里被收集？要回答这个问题，请考虑您的社区正在参与的所有地点和平台。这包括软件仓库，无论是 GitLab、GitHub、Bitbucket、Codeberg，还是仅仅是邮件列表和 Git 服务器。它也可能包括问题跟踪器、像 Gerrit 这样的变更请求工作流系统，或 wiki。

但不要止步于软件开发交互。社区还存在于哪里？这些可能是论坛、邮件列表、即时通讯频道、问答网站或聚会。开源社区中有很多活动并不严格涉及软件开发工作，但您希望在指标中识别出来。这些非编码活动可能很难自动跟踪，但您应该特别注意它们，否则可能会忽略重要的社区成员。

在解决了所有这些考虑因素之后，现在是采取行动的时候了。

1. 检索数据

一旦您确定了数据源，您必须获取数据并使其有用。收集原始数据几乎总是最简单的步骤。您有日志和 API 可以使用。设置完成后，（希望是偶尔的）主要挑战是 API 和日志格式发生更改时。

2. 数据丰富

一旦您有了数据，您可能需要丰富它。

首先，您必须统一数据。此步骤包括将数据转换为标准格式，这绝非易事。想想表达简单日期的所有不同方式。年份、月份和日期的顺序因地区而异；日期可以使用点、斜线或其他符号，或者可以用 Unix 纪元表示。而这仅仅是一个时间戳！

无论您的原始数据格式是什么，都要使其与分析保持一致。您还需要确定详细程度。例如，当您查看 Git 日志时，您可能只对提交的时间和提交者感兴趣，这是高级信息。再比如，您可能还想知道哪些文件被触及，或者添加和删除了多少行。这是一个详细的视图。

您可能还希望跟踪有关不同贡献的元数据。这可能涉及添加关于数据如何收集或创建数据的情况的上下文信息。例如，您可以标记在 Hacktoberfest 活动期间做出的贡献。

最后，将数据标准化为适合分析和可视化的格式。

当您关心谁在您的社区中活跃（以及他们可能为哪些组织工作）时，您必须特别注意身份。这可能是一个挑战，因为贡献者可能会在不同的平台上使用不同的用户名和电子邮件地址。您需要一种机制来通过多个在线标识符（例如问题跟踪器、邮件列表和聊天）跟踪个人。

您还可以在数据丰富阶段预处理数据并计算指标。例如，原始原始数据可能具有问题打开和关闭的时间戳，但您真正想知道的是问题已打开的天数。您可能还具有贡献的分类标准，例如识别哪些贡献来自核心贡献者，谁在项目中做了很多工作，有多少“蜻蜓点水”式的贡献者出现然后离开，等等。在丰富阶段进行这些计算可以更轻松地可视化和分析数据，并在后期阶段减少开销。